[postgis-devel] Rant on SRID -1 vs 0
Stephen Woodbridge
woodbri at swoodbridge.com
Mon Jul 15 14:38:22 PDT 2013
bborie,
Thanks, these are helpful suggestions.
On 7/15/2013 5:36 PM, Bborie Park wrote:
> Stephen,
>
> I can't say much about the behavior changes for ST_StartPoint() and
> ST_GeometryN() but for SRID, you should try...
>
> SELECT ST_SRID('POINT(0 0)'::geometry)
>
> That will always give you the correct unknown SRID value for whatever
> version of PostGIS. For your example...
>
> select addgeometrycolumn('unnoded', 'the_geom', ST_SRID('POINT(0
> 0)'::geometry), 'LINESTRING', 2);
>
> I forget but can't you just shove in -1 for SRID? PostGIS 2.0 should
> automatically clamp values < 0 to 0.
Yes this works, I was avoiding it because it raises an notice which
messes with them test infrastructure.
Thanks,
-Steve
> -bborie
>
>
>
> On Mon, Jul 15, 2013 at 2:23 PM, <maplabs at light42.com
> <mailto:maplabs at light42.com>> wrote:
>
> I was around during this discussion..
> (most respect to SWoodbridge and some empathy for the frustration..
> but..)
>
> 2.0 was clearly a major change, with the binary format of geometry
> first and foremost.. If there was any time to make a somewhat
> arbitrary change like the "unassigned" value,
> 2.0 was arguably the best time to do it..
>
> Personally, the zero value makes more sense to me, and I think I
> said so at that time also
> $0.02
>
> --
> Brian M Hamlin
> OSGeo California Chapter
>
>
> On Mon, 15 Jul 2013 17:10:51 -0400, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:
> I need to vent some frustration with the the change from srid=-1 to
>
> srid=0 for the undefined projection because this totally breaks
> scripts and makes it very hard to test things like pgrouting
> that need to work on both 1.5, 2.0 and 2.1.
> For example:
>
> select addgeometrycolumn('unnoded', 'the_geom', 0, 'LINESTRING', 2);
>
> does not work on POSTGIS="1.5.3" GEOS="3.3.8-CAPI-1.7.8"
> PROJ="Rel. 4.8.0, 6 March 2012" LIBXML="2.7.8" USE_STATS
>
> And this is just the first of the problems I'm trying to track
> down.
> The second is the change in behavior of st_startpoint() with
> multi geometries and the change of st_geometryn() with simple
> geometry. This forces every function that uses these to check
> the postgis version conditionally implement access.
>
> Grummble, gummble, gummble, off to find some kind of solution(s).
> -Steve
> _________________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org>
> http://lists.osgeo.org/cgi-__bin/mailman/listinfo/postgis-__devel <http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel>
>
>
>
>
> _________________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org>
> http://lists.osgeo.org/cgi-__bin/mailman/listinfo/postgis-__devel
> <http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel>
>
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>
More information about the postgis-devel
mailing list