[postgis-devel] Implement New Geometry Index Method?

[Rémi Cura]

Hey,

it is conceptually possible to accelerate a query on a single row content
(aka one big geometry).
The probleme is that it is no more a database index (which is a way to find
a row very quick, but in this case we __already__ know the row).
It is a bit like the raster storage and the JPEG 2000 standard with
embedded pyramidal view

You could implement something similar, but there is no clear equivalent to
this pyramidal simplification for vector (for instance, you may want a
pyramid of simpler and simpler geometries (1000 points in contour, then 100
points, then 10 points), or a pyramid where a surface becomes a point at a
given level, etc). You would have all sort of topological problem.
This whole "how do I simplify a vector" is a very actively researched area
(and no fully automatic solution found yet )

Postgres index system could probably be hijacked because you can index the
result of any function, but it would be a bad idea.

As a side not
_ in your first use case, you could have forced the use of index by adding
to the intersect :
AND admin.geom && other.geom,
or even computing this as a first step.
_your admlinistrativ limit seems to be a partition of the space (no
overlaping). In this case there exist very fast way to get the intersect
answer, but it is not used in GIS field.


Cheers,
Rémi-C



2014-05-21 15:12 GMT+02:00 Alexander Korotkov <aekorotkov at gmail.com>:

> On Wed, May 21, 2014 at 1:02 PM, Jeremy Palmer <JPalmer at linz.govt.nz>wrote:
>
>>  Hi PostGIS Devs,
>>
>>
>>
>> I have a daily process that I would like to optimise. The process
>> includes a spatial intersects join between a small administration
>> boundaries table for New Zealand that contains large geometries (100,000+
>> points per polygon) and a large dataset with small line strings.
>>
>>
>>
>> The first iteration of SQL I developed for the process I used standard
>> join (WHERE ST_Interesects(admin.geom, other.geom)) and it took 4 hours to
>> complete. No spatial index was used. Not acceptable.
>>
>
> So, your task is so-called "spatial join". We are now doing researches on
> it. It would be nice if you could share your dataset so we can do
> experiments on it.
>
> ------
> With best regards,
> Alexander Korotkov.
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20140521/6a2dc3e3/attachment.html>