[postgis-devel] Motion: vote for considering SRID <= 0 as "unknown"

[Howard Butler]

On Oct 4, 2011, at 9:54 AM, Mark Cave-Ayland wrote:

> On 04/10/11 14:56, Sandro Santilli wrote:
> 
>> Trying to get out of the impass about SRID, I'd like to split
>> the issue in two:
>> 
>>  (1) Considering SRID<= 0 as "unkwnown"
>>  (2) Finding a consensus about how to advertise "unknown"
>>      at the SQL level
>> 
>> I'd like to vote on (1) first.
>> If we agree, the parsers (all of them) would take any SRID<= 0 as
>> semantically equivalent to an "unknown SRID", storing NO srid in
>> the binary representation.
>> 
>> This would mean that no matter what we decide to return from ST_SRID(g)
>> it will be possible to get in output something different from what was
>> specified in input.
>> 
>> I'll start with my +1.
> 
> My only comment would be what do the various standards (SQL-MM/OGC) say about SRID values? As long as they don't specify anything, I guess we have a bit more freedom to interpret the specification as fits best with PostGIS.


A short recap of my discussion on IRC yesterday is that there's a big difference between changing function names/arguments and adding new functionality/behaviors and *changing returned data*. I'm in to tearing things up and making them right as much as the next developer, but this decision that was made long ago is not changeable without a lot of pain. People have baked the assumption that srid == -1 == unknown into their client code [1]. There's a whole raft of closed-source developers who use PostGIS too, and they've presumably baked the same thing in. Yes people will have to update their client code to use PostGIS 2.0, but the difference with changes that alter returned data is they're much harder to find.  

Major versions are not an excuse to make your user base start over.

Howard

[1] http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/pg/ogrpglayer.cpp#L1602