Hallo Jason, Simon Counter uses a Global Variable (not a global attribute). I had the same problem sometime in Nov 2005 ... here is my mail conversation from back then
> --------------------------------------------- > > Problem: Namespace for Compound Transformers > > (LOCAL vs. GLOBAL variables) > > --------------------------------------------- > > I used a COUNTER transformer in my Compound Transformer. > > The behaviour when I used that compound transformer more than > > once in my Main mapping file was unexpected. > > > > The problem was, that COUNTER uses a GLOBAL variable for counting, > > thus numbering ALL features of my workbench uniquely, > > instead of numbering them within the compound transformer "locally" > > > > I have no solution for that still, as I would need a "local counter" > > or a way to name the counter variable according to the individual > > transformer name. > > > > In general every transformer which uses global variables poses > > a problem within a compound transformer !!! > > > > > > Remark: I havn't tested this with a Custom transformer, but expect the > > same result. If you publish the counter name and set it differently within the compound transformers, the resulting count list will not be global. Hope this helps Michael --- In [email protected], "Jason Birch" <[EMAIL PROTECTED]> wrote: > > > It may be because the Counter uses a (terminology unsure) global > attribute to store the current count. You may need to expose this > parameter of the counter, and set it differently for each input. > > Jason > > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of > jusiheap > Sent: Thursday, September 07, 2006 09:06 > To: [email protected] > Subject: [fme] Re: Inserting section headers into text file > > OK, my follow up question is a bit more involved. Here goes ... > > My workspace has a number of different source feature types down the > left hand side (e.g. Road, River, Rail, ...). Individually, each feature > type feeds into its own set of transformers. Functionally, each set of > transformers does the same thing (that is, performs the sequence of > translations that we've discussed in this thread in order to generate > section headers). The chief reason for each feature type having its own > set of (duplicate) functionality is because each feature type needs to > set up and use its own Counter transformer. Ultimately each of the > threads feeds back into a single text writer, but nevertheless there's a > lot of duplication on my workspace. > > Aha, I think - surely I can build a custom transformer that embodies > this set of common transformations, and which can be called individually > from each of my feature types. So I created a single custom transformer > from one of my common sets - now on my main workspace I had a single > custom transformer and the remaining sets of common transformations. > Then I replaced each of the remaining common sets with copies of the > single custom transformer. I ran the translation and ... didn't get what > I wanted - in that I wanted each separate copy of the custom tranformer > on my main workspace to be invoked independently of the others, but > instead it appears that they all got thrown into a single custom > transformer. Thus, for example, the Counter transformer was invoked on > the entire set of features and therefore only one feature was identified > as being the first. > > If any of this makes sense, I have two questions: > 1. Is my understanding/expectation of custom transformers > incorrect/misguided? > 2. What solution would you recommend, in order to reduce complexity and > duplication in my workspace.? > > On a more general note, my evaluation of FME is all about proving (or > otherwise) that the benefits of using FME outweigh those of implementing > translation software in-house, and a key issue for me will be the scope > for modularisation, abstraction, code re-use. > > So the floor is open to anyone that wishes to comment on this aspect of > FME ... > > Thanks > Simon > Join us at the FME Worldwide User Conference Sept. 21-22, 2006 Vancouver BC Canada. For more information, visit www.safe.com/2006uc. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/fme/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
