[postgis-devel] Distance patch

Paul Ramsey pramsey at cleverelephant.ca
Sat Nov 21 10:49:43 PST 2009


Mark, if you're going to do a review, let me know, otherwise I'm going
to proceed with the integration early this week.

P

On Sat, Nov 21, 2009 at 10:43 AM, Paragon Corporation <lr at pcorp.us> wrote:
> Paul and Nicklas,
> The patch looks good to me.  So if Nicklas is ready I would say its good to
> go in.
>
> Nicklas -- your subgeom change fixed the anomalies I started to notice (with
> my neig parcel dist checks).  I tested on a wider
> Distribution of geometries and they look fine.  There are a few cases (not
> sure the percentage since I have to have the query run for a while just to
> pick up one where the diff from old and new < 0.
>
> In the cases where it is the diff is about e-9 (worst case)  to e-11.  So
> around the range when the floating precision artifacts cloud the numbers
> anyway.
>
> Here are my test results using sample linestrings and polygons (these are
> not multi though since the data that had a good mix didn't have multis) The
> n-n2 range are the number of points (so testing distance between lines of
> 10-20 points vs. polygons of 10-20 points).
>
> -- (0-9, 5000 recs: new 312 ms, old 344 ms (they both fluctuate between
> 213ms and 625 ms so hard to tell which is faster)
> -- (10-20, 5000 recs: new 344 ms, old: 750 ms)
> -- (20-40, 5000 recs: new 359  ms, old: 2344 ms)
> -- (41-50, 5000 recs: new 860  ms, old: 5609 ms)
> -- (51-60, 5000 recs: new 1828  ms, old: 9984 ms)
> -- (61-70, 5000 recs: new 1922  ms, old: 12657 ms)
>
>
> Regarding the other issue that Nicklas brought up about how to test these
> things.
> I do find being able to run both a PostGIS 1.4 distance and PostGIS 1.5
> distance in the same database very useful for testing. Its better than
> defining a dist_old in postgis code because its one less thing we have to
> remove and also doesn't run the risk of not being able to test old behavior
> that has changed because of core code base changes.
>
> As to whether this is useful in production to say run new PostGIS 1.5
> functions you badly want and still maintain your PostGIS 1.3/1.4 -- Yes and
> No.
>
> The person in me that just wants a single feature (say faster dist or better
> distance spheroid functions) from say 1.5 wihtout rocking my exisitng
> installs says Yes.
> The person in me that likes consistency and ease  of upgrade says No.
>
> So I guess we could say its possible to hack your PostGIS into a mutant
> 1.3/1.5 or 1.4/1.5 install but we don't support it.
>
> Thanks,
> Regina
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



More information about the postgis-devel mailing list