[postgis-devel] RE: 40% faster st_distance and returningmeasurepoints :-)

Paragon Corporation lr at pcorp.us
Sat Mar 14 18:16:43 PDT 2009


Nick,
 
Some general tips when suggesting changes.  
 
1) Add an entry to our bug tracker system
2) If you are providing code -- attach it to the bug tracker system, but we
would prefer a patch instead of a full file.
For windows development, I usually use Tortoise SVN.  It makes it wicked
easy to create a patch and to work against the latest PostGIS subversion
trunk and branch.  Presumably this patch you have is against trunk since for
branch we only accept minor changes and bug fixes that do not introduce new
functionality.
 
Aside from that -- keep up the good work and welcome to the club.
 
Thanks,
Regina

  _____  

From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
nicklas.aven at jordogskog.no
Sent: Thursday, March 12, 2009 11:12 AM
To: postgis-devel at postgis.refractions.net
Subject: [postgis-devel] RE: 40% faster st_distance and
returningmeasurepoints :-)


Hi again
 
I found that my modification crashed st_dwithin, but this version I think
will work.
 
/Nicklas
 
 
 
 
Datum: 2009-03-11 13:46:35
Från: nicklas.aven at jordogskog.no
Till: 
Ämne: 40% faster st_distance and returning measurepoints :-)



Hallo

I'm new to this list and have done my first steps in writing c-code. Thanks
to the very well-written and readable source-code I think I have succeded
over my expectations.

What I have done is rewriting quite great parts of measures.c. My goal was
to get the points out of st_distance from where the distance was calculated.

The result was that st_distance worked about 40% faster on my small
testmaterial. The points I wanted is also there, but I don't know the best
way to output them.

The idea I have followed is just to store the shortest distance and it's
points in a new structure I have called DISTLINE. 
Then I only do testing if a diastance is closer then the "earlier shortest"
in "distance2d_pt_pt" so there is no testing in the looping of the other
relateted functions. 

I think the progress in speed should make it interesting for implementing
but someone experienced have to take a serious look at it. 
I also would be greatful if I could get some help with the output of my
points. they are included in the structure DISTLINE like 

typedef struct
{
  double d;  /*distance*/
  POINT2D *p1;  /*1st measure point*/
  POINT2D *p2; /*2nd measure point*/
} DISTLINE;

and they will be present when the process returns to function:
lwgeom_mindistance2d_recursive

I attach my measure.c, libwgeom.h a small dataset with som roads in Norway
and my resulting dll

The test I have done to compare speed is just 
select a.vegnummer,b.vegnummer, st_distance(a.the_geom,b.the_geom) as
avstand from distancetest a,distancetest b;
on the attached dataset.
My result was:

original measure.c
Total query runtime: 3999 ms.
400 rows retrieved.

The new measure.c
Total query runtime: 2374 ms.
400 rows retrieved.

This increase in speed could be quite important on big "nearest neighbour"
calculations.
I also mean som function like st_shortestline(geom1,geom2) would be nice and
now the points for that line is ready to use.

Have a nice day
from a quite proud beginner

Nicklas Avén

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090314/837a91e9/attachment.html>


More information about the postgis-devel mailing list