[postgis-devel] SRID / Spheroid / Units

[Paragon Corporation]

Paul,
Would it be bad to just require GEOGRAPHY data to be in 4326 and assume EPSG
numberings prevail, and throw an error during load if it isn't.  We can even
get fancy later I suppose and autotransform during load if it is in the
wrong spatial ref.

That way you can hard-code the spheroid. Sure people who insist on storing
their data in NAD27 (or some other spatialref) people will be unhappy, but
then again I doubt they make up that much of the population of the people
who want to use GEOGRAPHY.

I figure if you go around changing well known numberings you have serious
problems elsewhere anyway.

Hope that helps,
Regina


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Saturday, July 18, 2009 1:16 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] SRID / Spheroid / Units

I am assuming that the GEOGRAPHY type will include an SRID and that if one
is not defined, WGS84 parameters will be assumed. Unlike GEOMETRY, any
measuring operation (length, distance, area) against a GEOGRAPHY is going to
need to know the spheroid parameters in order to return an answer, which
implies a spatial_ref_sys lookup.

I am not fond of the idea of having to do a lookup, because it's going to
have to happen so often. Particularly for some well-known values, I'd like
to short-circuit that process. Unfortunately that cuts against the grain of
the spatial_ref_sys concept, which is that the srid numbers are in fact
internal to the database, and not universal (srid 4326 could be anything,
it's not guaranteed to be WGS84). Any advice or guidance? Maintain the
pristine theoretical underpinnings of spatial_ref_sys, or bow to the
universal use we have promoted, which is to expect the values in
spatial_ref_sys.sql (and hence, EPSG
numberings) to prevail.

P.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel