<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Doing some RTFM I see on the posgis page here:
<a class="moz-txt-link-freetext" href="http://workshops.opengeo.org/postgis-intro/projection.html">http://workshops.opengeo.org/postgis-intro/projection.html</a><br>
<br>
"
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Be careful of getting too happy with using <strong>ST_Transform</strong>
for on-the-fly conversion. Spatial indexes are built using SRID
of the stored geometries. If comparison are done in a different
SRID, spatial indexes are (often) not used. It is best practice
to choose <strong>one SRID</strong> for all the tables in your
database. Only use the transformation function when you are
reading or writing data to external applications.</p>
</div>
"<br>
<br>
So unless I here otherwise I think above suggests that what I called
option #1 below is the best practice to follow.<br>
<br>
On 01/06/2011 06:00 PM, Farrukh Najmi wrote:
<blockquote cite="mid:4D26497F.1070606@wellfleetsoftware.com"
type="cite">Hello,
<br>
<br>
My application needs to support storing of geometry instances with
different SRID values in the same table and then be able to query
it using spatial operations and a filter geometry which could be
in any SRID.
<br>
<br>
One possible option (Option #1) is to use ST_TRANSFORM function to
transform all geometry instances on WRITE to the same internal
SRID (say 4326) and transform the filter geometry used by the
query to the same SRID used internally (say 4326) before doing the
spatial operation.
<br>
<br>
The other option (Option #2) is to store all geometry instances
with their original SRID values on WRITE and use ST_TRANSFORM
function in the query to transform all internal geometry instances
to match the same SRID as that of the filter geometry used by the
query.
<br>
<br>
It seems option #1 is less accurately preserving the original data
but is much more efficient on query while option #2 stores
original data without any change but may have serious performance
issues due to the transform on query.
<br>
<br>
What do people advice based upon their experience with postgis for
my requirement and possible solution.
<br>
<br>
Thank you for your help.
<br>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Farrukh Najmi
Web: <a class="moz-txt-link-freetext" href="http://www.wellfleetsoftware.com">http://www.wellfleetsoftware.com</a>
</pre>
</body>
</html>