This link.... http://www.fmepedia.com/index.php/Group-Based_Transformers#Output_and_Output_Attributes
...tells you why the output doesn't carry over the attributes. The only way to get it would be to group-by the unique ID too. As long as there is only a single point per line then that shouldn't be a problem - it's when there are multiple values to your "unique" id that it won't work (for example when there are points at both ends of the line). I'm sure there are ways to hack out a result this way, but you'd be better off using the NeighborFinder or the SpatialRelator. Ideally the SpatialRelator is the transformer to go with. In practice I don't know how well the Touches test would work for a point/line interface, so I would consider buffering the line features first by a very small amount so you end up doing a point/area test (Contains or Within). The other consideration I'd mention is that it's not always the case that your point is exactly on the line - no matter how carefully it's created with that aim in mind. There are certain issues relating to precision (of coordinates) that may give dubious results. It's another reason for using the NeighborFinder or a buffer-based SpatialRelator - when you have some form of tolerance then the results are much more certain. Hope this helps, Regards, 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], "Brian" <[EMAIL PROTECTED]> wrote: > > That method works, sort of. > When I use the PointOnLineOverlay, it breaks the lines. So like you > said I added the _counter to the Input Line Feature so I have unique > ID's on the original Line. > It goes threw the PointOnLineOverlay transform and outputs the > original single line as 2 smaller lines (broken at the point > intersetction) and both lines contain the Unique ID. > But when I run it threw the LineJoiner and use the _Counter as the > Group by, it joins the lines but does not carry over the attributes > from the Point. > My output line ends up with _Count, fme_geometry and fme_type. > The Invalid side of the LineJoiner has the attributes that were > combined from the Point and Line at the PointOnLineOverlay. > Any thoughts on that one? > > Oh, and if I visualize the Invalid side of the LineJoiner, there is no > features present. > > --- In [email protected], Hans van der Maarel <hans@> wrote: > > > > Jason Birch wrote: > > > > > > > > > Can you guarantee that there is only at most one point per line? > > > If not, what do you want to do in the case where multiple points > touch a > > > line? > > > > > > My recommended strategy would be to use a NeighbourFinder. The > choice is > > > yours on how to implement this. You could either directly use the > > > NeighbourFinder directly on the lines as Base specifying the > points as > > > Candidates, or you could do it the other way around and use a > > > FeatureMerger to join the points' attributes back onto the lines > after > > > exposing the first close candidate list member. I haven't tested, but > > > the latter is potentially more efficient. > > > > How about this: > > Assign a unique id value to the original lines, then do the > > PointOnLineOverlayer which breaks them up. Next, run them through a > > LineJoiner, let it join based on those unique id's and create a list of > > the rest. > > > > -- > > Hans van der Maarel > > Red Geographics > > www.redgeographics.com / hans@ > > > 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/
