Markus<br>

Thanks your reply.<br>

Given that I had already implemented a trigger to transform the data

entered at the front end I feel a little foolish for not having thought

to take it that step further. Where I am currently stuck though is in

trying to pick from the 26,761 SRID's available. I have already

experienced the glitches that result from trying to use Projected

Geometry ( see an earlier thread on trying to understand why my Scale's

were all wrong), but I remain unclear on how to pick the SRID I should

use as the common standard. Much of my incoing data is either in the

form of shape files  or from Feild surveys conducted using a

Differential or even ordinary GPS. I have tried using SRID 4326, but I

run into the same scale problem i ran into earlier because apparently

this SRID is projected. But when I do a like search on WGS84 I get

hundreds of resuts, and reading the srtext and proj4 feilds to try and

figure out which SRID I should be using is not especially user

freindly. Is there somewhere where I can egt a list of the more common

datums that I can check my database agaoinst.<br><br><div><span class="gmail_quote">On 11/25/05, <b class="gmail_sendername">Markus Schaber</b> <<a href="mailto:schabi@logix-tt.com">schabi@logix-tt.com</a>> wrote:</span>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi, Johan, Johan Wehtje wrote: > Is it possible to store geometry with differing SRID's in one table?

<br>><br>> I want to keep track of a heterogenous collection of Geometry, sometimes<br>> loaded from Shapefiles, or from GPS surveys - and would like to know if<br>> I have to create a seperate Table for each SRID, or whther I have to

<br>> somehow convert all the geometry to a single standard.<br><br>It is possible, but not OpenGIS standards compliant.<br><br>You can simply drop the SRID constraint that was created by<br>addGeometryColumn().<br><br>

Alternatively, you can use a "before insert" and "before update" trigger to transparently transform() all input geometries to a common SRID. This has the advantage that map display or index searches work better.

<br><br>If you need both the original data for exact reproduciton and the<br>unified ones for efficient processing, you can use two geometry columns<br>- the first one contains the original geometries with mixed SRIDs, and

<br>the second one is automatically populated by transform()ing the first<br>one via triggers.<br><br>Markus<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">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br></blockquote></div><br>