Use mitab (http://mitab.maptools.org) in a dll. Its quite a bit more involved, but worth it for the ~1000x performance improvement.
Best Regards, Martin Higham Avantra Geosystems ph (61 3) 8504 0428 0425-730-428 fx (61 3) 9596 7997 www.avantra.com.au > -----Original Message----- > From: Peter Horsb�ll M�ller [mailto:[EMAIL PROTECTED] > Sent: Thursday, 11 November 2004 21:13 > To: Uffe Kousgaard; Mapinfo-L > Subject: RE: MI-L Fast node search on an object > > > 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 > --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 13997
