Hi Uffe, Would you think it would be faster to do the search in an external DLL which would require that you ran thru the nodes to insert them into an array before sending them to the DLL ?? Or could you send the "object" as it is to the dll ?
If you had to dump them to an array it would actually require that you ran thru all the nodes twice !? Peter Horsb�ll M�ller GIS Developer Geographical Information & IT COWI A/S Odensevej 95 DK-5260 Odense S. Denmark Tel +45 6311 4900 Direct +45 6311 4908 Mob +45 5156 1045 Fax +45 6311 4949 E-mail [EMAIL PROTECTED] http://www.cowi.dk/gis -----Original Message----- From: Uffe Kousgaard [mailto:[EMAIL PROTECTED] Sent: Thursday, November 11, 2004 9:55 AM To: Mapinfo-L Subject: Re: MI-L Fast node search on an object Hi Bill, Your approach is as fast as it gets without creating an index of some sort in advance. Only possibilities for improving is to: 1) Do the calculations in a DLL. Could be worthwhile if you are doing it many times / have large regions. 2) Looking at vertical and horizontal distances compared to present best solution before doing the distance() calculation. That may save you from some SQRT calculations, which are slow. ExtractNodes() won't help you at all. If you want to find the nearest node from a basically unsorted list of nodes (making up a region), you will have to look at all of them at some point. With very large regions, it may actually be worthwhile to sort the coordinates first, before doing the calculations, but it requires a lot more work and may be overkill. Kind regards Uffe Kousgaard www.routeware.dk ----- Original Message ----- From: "Bill Thoen" <[EMAIL PROTECTED]> To: "MapInfo-L" <[EMAIL PROTECTED]> Sent: Thursday, November 11, 2004 3:09 AM Subject: RE: MI-L Fast node search on an object Milo van der Linden writes: > But I can't see this exercise being a problem with a single point in a > not to big region so I think your problem revolves from performance > problems on large regions or a large set of points. Right. It's only a problem on the largest objects. It's just that I sense a "code smell" that tells me that looping through all nodes is inefficient, and I wondered if there's a more elegant solution. > What you might consider is first doing radius select to decrease the > number of nodes tested. For instance, do a radius search with a diameter > of 1 mile, if the count of the objects returned is larger then zero, do > your calculation, otherwise increase the radius with certain steps. > (Think big, start small) This is a matter of fine tuning for your > specific situation. For objects that are near the center of a big region > this will always be a problem. This won't help because the nodes in MapInfo objects cannot be accessed directly with MapInfo's higher spatial functions. You still have to examine every point and determine if it's in the buffer or not. And if you're going to have to do that, the fastest algorithm is still just the "brute force" method of comparing every point to the given X,Y coordinate. There's only one other hope that I can think of. There is the ExtractNodes() function, which is a fast way to extract a sub-polyline object from a polyline or region object. Can we use this? If there are n nodes in an object, and you use ExtractNodes() to pull nodes 1 to n/2 and find that the Minimum Bounding Rectangle (MBR) of the returned object is not in your area of interest, then you can immediately eliminate nodes 1 to n/2 from your search. That is a faster way to eliminate nodes (if you're lucky) than the brute force method. But of course, this won't always yield cool results, because the sequence of nodes has nothing to do with their spatial distribution, but is it worth exploring ExtractNodes()? Is there anyone interested in applying the lever of their mind to this problem who isn't afraid that the effort might also flip their brains out between their ears? - Bill Thoen --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 13991 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 13994 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 13996
