[postgis-devel] SRID / Spheroid / Units

[Paul Ramsey]

I think certainly as a first approximation the best thing is to have
the SRID field, but only accept 0 and 4326 as arguments. 0 is
"unknown" so it defaults to 4326. That way we can have a working
implementation, and if a demand for alternate spheroids develops we
can deal with it later.

P

On Sun, Jul 19, 2009 at 1:42 AM, Paragon Corporation<lr at pcorp.us> wrote:
> 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
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>