[postgis-devel] Prepared Geometry API

Paul Ramsey pramsey at cleverelephant.ca
Sun Oct 5 15:24:20 PDT 2008


Now that the things actually work, a discussion of the user-facing API
is worth entering into.

Right now, we have

ST_Contains(geom_a, geom_b, id_a)
ST_ContainsProperly(geom_a, geom_b, id_a)
ST_Covers(geom_a, geom_b, id_a)
ST_Intersects(geom_a, geom_b, id_a, id_b)

We could easily enough add

ST_Within(geom_a, geom_b, id_b)

as an inverted implementation of contains.

The id_a/id_b keys are usually going to be primary keys, and
occasionally constants, in the case of tests against geometry
literals. Because this approach is the fastest, and guaranteed to not
degrade as the candidates get larger, I would like to see this API
around, no matter what we do with any other API.

Discussion? I am loath to volunteer do to a head-to-head of a
memcmp'ed cache against a key'ed cache, but that's because I'm lazy.
Oh, wait, I do have a trivial solution to that, though it isn't a
direct comparison:

ST_Contains(POLYGON, POINT) will use the postgis-internal 1-d rtree
cache, and a memcmp'ed cache.
ST_Contains(POLYGON, POINT, ID) will use the geos prepared geometry
and an id based cache.

It's not a true head-to-head because the geos version has to traverse
the geos geometry creation step, but if there's a huge *disadvantage*
to the memcmp case, it should show up here.  Tests with varying
amounts of

- polygons-to-points ratio
- polygon complexity

will be required to get a true feel.

Anyone want to volunteer? :)

P.



More information about the postgis-devel mailing list