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.<br>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.<br>
Another solution would be to store everything in its original coordinate system, mixing several srids within one column.<br>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".<br>
<br>I'm curious about the community's opinions about that. Any and all comments welcome.<br><br>And then: how much can i trust such a changed index? What does this do to my database system? (never done that before)<br>
Would it change my original Gist index, or create a new one that i can apply to a geom column?<br>What are the things that i should test before taking something like this to production?<br><br>cheers,<br><br>WBL<br><br><code><br>
CREATE OPERATOR CLASS gist_geometry_ops_norecheck FOR TYPE geometry USING gist AS<br>        OPERATOR        3        &&,<br>        FUNCTION        1        LWGEOM_gist_consistent (internal, geometry, int4),<br>        FUNCTION        2        LWGEOM_gist_union (bytea, internal),<br>
        FUNCTION        3        LWGEOM_gist_compress (internal),<br>        FUNCTION        4        LWGEOM_gist_decompress (internal),<br>        FUNCTION        5        LWGEOM_gist_penalty (internal, internal, internal),<br>
        FUNCTION        6        LWGEOM_gist_picksplit (internal, internal),<br>        FUNCTION        7        LWGEOM_gist_same (box2d, box2d, internal);<br>UPDATE pg_opclass <br>    SET opckeytype = (SELECT oid FROM pg_type <br>
                          WHERE typname = 'box2d' <br>                          AND typnamespace = (SELECT oid FROM pg_namespace <br>                                              WHERE nspname=current_schema())) <br>
    WHERE opcname = 'gist_geometry_ops_norecheck' <br>        AND opcnamespace = (SELECT oid from pg_namespace <br>                            WHERE nspname=current_schema());<br></code><br><br><br><br><br><div class="gmail_quote">
On Fri, Apr 11, 2008 at 10:21 PM, Obe, Regina <<a href="mailto:robe.dnd@cityofboston.gov">robe.dnd@cityofboston.gov</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I just noticed this blog article on Planet PostgreSQL.  I haven't read<br>
it but looks interesting.<br>
<br>
<a href="http://people.planetpostgresql.org/gsmet/index.php?/archives/2-A-PostGIS-wrapper-for-proximity-queries.html" target="_blank">http://people.planetpostgresql.org/gsmet/index.php?/archives/2-A-PostGIS<br>
-wrapper-for-proximity-queries.html</a><br>
<br>
Thanks,<br>
Regina<br>
-----------------------------------------<br>
The substance of this message, including any attachments, may be<br>
confidential, legally privileged and/or exempt from disclosure<br>
pursuant to Massachusetts law. It is intended<br>
solely for the addressee. If you received this in error, please<br>
contact the sender and delete the material from any computer.<br>
<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
</blockquote></div><br>