Geometry to Geography cast enhancement auto transform

[robe]

I'm finding myself doing a lot of this:

SELECT geography(ST_Transform(the_geom, 4326))

Which is not bad for inserting data, but for the common use-case I can think of where one would want to keep their data in a good for presentation projection but use geography for distance calculations or across inherited tables, then they would be doing this a lot in queries which makes things a bit cluttered.

Being able to do geography(the_geom) is so much nicer.

Would be nice if the geometry -> geography cast was smart enough to read the SRID of a geometry and if it is a valid SRID (not -1 or 0), then it would do the transformation automagically to 4326.

[pramsey]

I considered this, but there's a future issue, which is: when GEOGRAPHY supports other geographic SRIDs. The "convenient" automagic transform turns into a hidden SRS coercion in order to maintain the transparency of the operation. So you'll get conversions from nad83 to nad27 happening silently under the covers if you should insert a 4269 geometry into a 4267 column. People keep telling me that kind of behavior is a Bad Thing, so I hesitated to go down the road.

[robe]

Oh I thought the coercion of going straight from 4269 to 4326 without transformation was a bad thing or guessing at the SRID and assuming people stored their data in 4326 when no SRID was specified was a bad thing. I thought that's what we were complaining about before. Maybe I misunderstood that conversation.

For this I thought about the ambiguity of this automagic and leaned toward its such a well established thing that if you denote the wrong SRID for your native data you are screwed anyway (and doing a ST_Transform from nad27 to wgs 84 is a common accepted practice) . I decided it was more annoying having to do that same transformation over and over again especially for legacy data where I want to use a geography spatial index but don't want to store my data in geography.

I imagine for the future when we do support other spatial refs then we would do the automatic transform only if SRID not in(-1,0,4326,4269 etc).

[robe]

May I add we are doing something much worse because I can do this:

SELECT geography(ST_GeomFromEWKT('SRID=4267;POINT(33.0860404968262 68.9635467529297)') )

So it seems our geography is completely ignoring the SRID since the above should be illegal.

[pramsey]

The ability to convert any srid geometry into geography right now was put in so that things like 'POINT(0 0')::geography would work (ie, to allow unknown SRIDs to go it). I can tighten it up a little so that only 4326 and unknown are allowed in. All the inputs are checked for range validity automatically.

[robe]

Probably best to tighten it up tominimize on confusion even though we'll probably end up taking it out. I think when we start supporting the others if people are running with a newer on one box and an older on another, they might get the idea that the older supports all long lat SRIDs.

[pramsey]

Restriction to unknown or 4326 committed at r4711.