wow, that sounds pretty funky!<br>doesn't the unioning etc kill your performance advantage?<br>have you done any benchmarking to quantify the performance of this solution?<br><br>do you have lots of user behavior rules?<br>
the system that we are building on will be managed pretty de-centralized, so if everyone has his own policy on how to fill & maintain the database that would be a problem.<br><br>thank you!<br>WBL<br><br><div class="gmail_quote">
On Thu, Apr 17, 2008 at 7:50 PM, Brent Wood <<a href="mailto:pcreso@pcreso.com">pcreso@pcreso.com</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;">
<div class="Ih2E3d"><br>
--- Willy-Bas Loos <<a href="mailto:willybas@gmail.com">willybas@gmail.com</a>> wrote:<br>
<br>
> We are currently looking for a solution to store (and use, combine)<br>
> information from different original coordinate systems in one table. It<br>
> seems like the best solution to store the geoms in WGS84 and convert it to<br>
> whatever srid the client needs.<br>
<br>
</div>Hi,<br>
<br>
I use a variety of projections for my data, for several reasons, & have found<br>
PostGIS eminently capable.<br>
<br>
For optimum retrieval performance, I have physical tables with a separate<br>
geometry column for each projection. One example is a table of some 1,000,000<br>
polygons, natively in WGS84 lat/long, but also in a separate custom equal area<br>
projection for areal analyses of the polygons. Each column with it's own<br>
spatial index.<br>
<br>
Generally, I use a view which generates the additional projected versions on<br>
the fly from the base WGS84 polygons, so that queries on this table do not need<br>
to include the transforms for output data. This approach may well suit your<br>
use.<br>
<br>
Occasionally I have used views with transforms from data stored natively in<br>
different projections using union to concatenate the different tables/datasets<br>
without physically merging them into a single table.<br>
<br>
Multiple geometries for features is something I think PostGIS does well, much<br>
better than most GIS packages. In addition to different projections for a<br>
feature, I also store startpoints, endpoints, lines, buffered lines/polygons as<br>
physical geometry columns in some tables, having 5 geometries in a table is not<br>
that unusual. Data issues mean I don't always have tracklines, or both start &<br>
finish positions, so need to handle a variety of incomplete spatial data values<br>
pertaining to individual features/rows.<br>
<br>
<br>
HTH,<br>
<font color="#888888"><br>
  Brent Wood<br>
<br>
</font></blockquote></div><br>