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


--- In [email protected], "mark2atsafe" <[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
> Yes it's just a case of duplicating the first point in the feature 
and
> sorting everything to get it into the correct order.
> 
> The CSV Reader 2 workspace on fmepedia is a good example of this
> concept - see how a Counter gives a unique ID. In your workspace 
I'd
> start the count at 1. Then add a Tester to grab the first point 
from
> each line (count = 1). Where count=1 (PASS) use an AttributeSetter 
to
> set the text line and to set count=0. Then route both the Tester
> PASSED and FAILED ports and AttributeSetter output into a Sorter. 
Yes,
> include the PASS port else you'll be missing the first point. Sort 
by
> count. So Count=0 (the header) now comes first.
> 
> In this case you would probably also want to sort by feature ID - 
make
> sure the feature ID sort is BEFORE the point ID sort in the Sorter 
list.
> 
> There you are and Bob's your uncle.
> 
> Oh - See http://www.fmepedia.com/index.php/CSV_Reader_Workspace_2 
for
> the example I'm talking about.
> 
> Hope this helps
> 
> Mark
> 
> Mark Ireland, Senior Product Specialist
> Safe Software Inc. Surrey, BC, CANADA
> [EMAIL PROTECTED] http://www.safe.com
> Solutions for Spatial Data Translation, Distribution and Access
> 
> --- In [email protected], "jusiheap" <jusiheap@> wrote:
> >
> > Hi all
> > 
> > I'm translating from GML file(s) to a text file. Nothing flash, 
just 
> > converting each feature into an id plus a list of coordinate 
pairs - 
> > one entry per line in the destination text file, the whole file 
> > sorted by feature type.
> > 
> > However, now I'd like the translation to insert additional lines 
of 
> > text. That is, before the start of each block of feature type 
> > entries I'd like a header, indicating the feature type itself. 
> > Something like:
> > 
> > Feature Type: RoadLink
> > ... several lines of RoadLink features ...
> > Feature Type: RoadNode
> > ... several lines of RoadNode features ...
> > etc
> > 
> > Any suggestions?
> > 
> > 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/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/fme/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[EMAIL PROTECTED] 
    mailto:[EMAIL PROTECTED]

<*> 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/
 



Reply via email to