[postgis-users] PostGIS wrapper for proximity queries
Willy-Bas Loos
willybas at gmail.com
Thu Apr 17 01:51:06 PDT 2008
It seems (in the article) that PostGIS is optimized for storing more than 1
SRID in a table. Or at least it suffers a performance impact in order to
allow it.
We are currently looking for a solution to store (and use, combine)
information from different original coordinate systems in one table. It
seems like the best solution to store the geoms in WGS84 and convert it to
whatever srid the client needs.
Another solution would be to store everything in its original coordinate
system, mixing several srids within one column.
The latter seems like asking for trouble, but maybe it's not so bad. Either
way you'd have to use a lot of "transform".
I'm curious about the community's opinions about that. Any and all comments
welcome.
And then: how much can i trust such a changed index? What does this do to my
database system? (never done that before)
Would it change my original Gist index, or create a new one that i can apply
to a geom column?
What are the things that i should test before taking something like this to
production?
cheers,
WBL
<code>
CREATE OPERATOR CLASS gist_geometry_ops_norecheck FOR TYPE geometry USING
gist AS
OPERATOR 3 &&,
FUNCTION 1 LWGEOM_gist_consistent (internal, geometry,
int4),
FUNCTION 2 LWGEOM_gist_union (bytea, internal),
FUNCTION 3 LWGEOM_gist_compress (internal),
FUNCTION 4 LWGEOM_gist_decompress (internal),
FUNCTION 5 LWGEOM_gist_penalty (internal, internal,
internal),
FUNCTION 6 LWGEOM_gist_picksplit (internal, internal),
FUNCTION 7 LWGEOM_gist_same (box2d, box2d, internal);
UPDATE pg_opclass
SET opckeytype = (SELECT oid FROM pg_type
WHERE typname = 'box2d'
AND typnamespace = (SELECT oid FROM pg_namespace
WHERE
nspname=current_schema()))
WHERE opcname = 'gist_geometry_ops_norecheck'
AND opcnamespace = (SELECT oid from pg_namespace
WHERE nspname=current_schema());
</code>
On Fri, Apr 11, 2008 at 10:21 PM, Obe, Regina <robe.dnd at cityofboston.gov>
wrote:
> I just noticed this blog article on Planet PostgreSQL. I haven't read
> it but looks interesting.
>
> http://people.planetpostgresql.org/gsmet/index.php?/archives/2-A-PostGIS
> -wrapper-for-proximity-queries.html<http://people.planetpostgresql.org/gsmet/index.php?/archives/2-A-PostGIS-wrapper-for-proximity-queries.html>
>
> Thanks,
> Regina
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20080417/32022c58/attachment.html>
More information about the postgis-users
mailing list