[postgis-devel] Optimizing distance routines in PostGIS

Daniel Baston dbaston at gmail.com
Tue Nov 1 05:54:58 PDT 2016


Not as a strict port from JTS, no.  The IndexedFacetSequence class
gives us the two closest FacetSequences only.  If the two closest
points are needed, it should be possible to add a
FacetSequence::closestPoints method.  If you're comparing two
collections and need to know the two closest components, it's possible
that you could work this out from the CoordinateSequence pointers held
by each FacetSequence.

Dan

On Mon, Oct 31, 2016 at 6:36 PM, Sandro Santilli <strk at kbt.io> wrote:
> On Mon, Oct 31, 2016 at 06:17:34PM -0400, Daniel Baston wrote:
>> I recently ported the IndexedFacetDistance class from JTS to GEOS.
>> This class provides optimized distance routines that work by
>> constructing Rtree indexes over both of the input geometries, and
>> performing distance calculations only between the nearest portions
>> (facets) of the two inputs.  This can produce massive performance
>> improvements on distance calculations.  (An example discussed in trac
>> #3587 goes from about 42 seconds to 0.1 seconds.)  Additionally, the
>> indexes can be retained (much like a PreparedGeometry), for the case
>> where many inputs need to be tested against a single large geometry
>> (this last bit hasn't been exposed in the C API).
>>
>> Is this something we should explore using in ST_Distance / ST_DWithin,
>> or maybe elsewhere in PostGIS?  It would have to be limited to types
>> supported by GEOS (2D only, no curves), and we'd probably need to find
>> some heuristics about when it's worth the effort (rather than a
>> standard lwgeom_mindistance2d).
>
> I've been working with distances recently, for a new snap algorithm
> in librttopo, and found myself in need of not just a distance value
> but also which element was closest (to a point, in my case).
> The liblwgeom functions (in measures.c) seem to be returning the
> detail in terms of "closest points", but that's still not enough
> detail for what I needed.
>
> Could the yet-to-be-exposed part of the API give additional details ?
> To which level ?
>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list