[postgis-devel] Hey, you broke... (SRID=0)

[Paul Ramsey]

Maybe a quick poll of our highest profile clients would help? FME,
Mapserver, Geoserver, Mapnik, SIS, etc. See how many use -1.

On the one hand, -1 never actually appears in a serialization, since
the EWKB flags simply note "no SRID here". On the other hand, it does
show up in GEOMETRY_COLUMNS, so it's possible external apps do look at
it fairly frequently.

One "bright side" of changing it over is that it's almost all #defined
now as SRID_UNKNOWN. Still leaves the regression tests and a few error
strings to change over, but going back to -1 won't be nearly as
painful as going to 0 was. Maybe an hours work.

P.

On Thu, Sep 29, 2011 at 6:43 AM, Howard Butler <hobu.inc at gmail.com> wrote:
>
> On Sep 29, 2011, at 5:27 AM, Sandro Santilli wrote:
>
>> On Thu, Sep 29, 2011 at 11:00:00AM +0200, Sandro Santilli wrote:
>>> On Wed, Sep 28, 2011 at 05:03:14PM -0700, Paul Ramsey wrote:
>>>> Well, it regresses...
>>>> While I like having SRID=0, I have the worry that this particular
>>>> change-for-changes sake will rebound on us poorly. It's done, but I'm
>>>> waffling.
>
>  This is churn, in the Frank Warmerdam sense of the word, and I've not been convinced of the practical benefit other than for API purity's sake. The *public API* of ST_SRID has always been -1, and there might be quite a number of application-level things that have baked -1 into their logic already. It's also the kind of thing that gets rolled into complicated if-then logic as a magic number that's assumed to never change.  That's their fault, sure, but fixing it isn't as simple as a function name change that can be doctored up with an #ifdef POSTGIS2
>
> I'm not a PostGIS dev, and you can take my opinion as such, I think this change is going to inspire the hate.
>
> Howard
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>