CRS decode error
Description
Environment
Activity
codehaus April 10, 2015 at 2:57 PM
CodeHaus Comment From: aaime - Time: Thu, 8 Jan 2009 04:20:23 -0600
---------------------
I am reluctant to apply the patch to the postgis datastore as it may have some side effect on our stable series of datastores.
For Justin and Christian, this patch allows the datastore to keep working in enviroment where the EPSG authority axis has not been forced to a lon/lat orientation. In the SQLDialect.createCRS we have a
return CRS.decode("EPSG:" + srid), I guess we can safely turn that into return CRS.decode("EPSG:" + srid, true) and everything will keep working as expected, no?
The only database that experimented in returning data in lat/lon order was SQLServer, but afaik an outcry from the user base made Microsoft step back and return data in lon/lat order instead:
<a href="http://blog.cleverelephant.ca/2007/12/lets-call-whole-thing-off.html">http://blog.cleverelephant.ca/2007/12/lets-call-whole-thing-off.html</a>
<a href="http://blog.cleverelephant.ca/2007/12/they-called-it-off.html">http://blog.cleverelephant.ca/2007/12/they-called-it-off.html</a>
So I guess we should be fine? Anyways a dialect can override createCRS and do it its own way if it needs be.
codehaus April 10, 2015 at 2:57 PM
CodeHaus Comment From: aaime - Time: Wed, 8 Oct 2008 10:10:09 -0500
---------------------
Well, actually the assumption is that someone configure the referencing subsytem to use only lon/lat order, but anyways, the patch is the same 
CRS authority for postgis datastore assume coordinates are in lat long order.
It should be long lat order.
To solve it change line 124 from class : org.geotools.data.postgis.referencing.PostgisAuthorityFactory
from
return CRS.decode(name + ":" + id);
to
return CRS.decode(name + ":" + id,true);