Hi Mark, Thanks once again for your advice. After playing around with the transformer the one thing that seemed to make a big difference was when I changed the "consider self" option from what I originally set, "no", to "yes". I was trying to find the closest polygon (candidate) to a line (base)and didn't think that this option would make a difference given the base and candidate were two discrete data sets.
However, it seemed to as to process a set of 200 base records against a set of around 2000 candidate records went from over a day down to around 10 or so minutes. Hugh. --- In [email protected], "mark2atsafe" <[EMAIL PROTECTED]> wrote: > > Hi Hugh, > I can't think of any obvious method - but I asked our development team > and will file an enhancement request for a "Candidates First" option - > in the same way as the Clipper has Bases First. That could help speed > things up and reduce memory usage I'd think. > > Besides that - the manual states... "After all features have been > received, the factory then looks at each BASE feature and finds the > closest CANDIDATE feature within <maxDistance> distance of the BASE > feature." > > ...so there are (candidate * base) comparisons going on and there > isn't really anything you can do except cut down on the number of > candidates by preprocessing the data. > > For example, if your max distance is 100m then create a 100m buffer > around the bases, overlay the candidates to find which are within this > buffer and use them as the neighborFinder candidates. > > Of course, the buffer/overlay would take some time - perhaps more than > you would gain in the neighborfinder - and there's plenty of proof > that our developers aren't dumb and would've thought to add that in > automatically, but it's the only thing I can think of at this point. > > Besides that - if it's a complex workspace with other transformers - > be really sure that it is the NeighborFinder which is slow and not > another part. There's a whole fmepedia category of performance related > tips at... http://www.fmepedia.com/index.php/FME_Performance_Tuning > > 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], "hughblackstock" <hughblackstock@> wrote: > > > > Hi There, > > > > Do you have any advice on how to increase the speed that a > > neighborfinder transformer works? > > > > I'd like to find the closest polygon (suburb) to a line segment (road) > > but this seemingly simple task seems to take a long time to process > > even when I have a very small number of records. > > > > Thanks, > > > > Hugh. > > > For insights into what's up at Safe Software and what's on the development horizon, visit Safe's blog at spatial-etl.blogspot.com. Safe Software has also made slides available that outline enhancements planned for FME 2007. The slides are from the "Road Ahead" presentation given on Day 2 of the FME Worldwide Users Conference. To view these slides, 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/
