Simone Giannecchini a écrit :
I am pretty sure that in gdal (which
uses Proj) EPSG:4326 is lon,lat as expected, moreover Jody told me
that OGC, after a long debat, now states that EPSG:4326 is lon,lat and
not lat,lon as EPSG db (please Jody help me here).
If this is an OGC decision, then the EPSG factory needs to be updated in order to comply with it.
Does someone has a link to the OGC decision? (the last OGC meeting I attended was in september 2005;
at that time, such decision was not yet taken. I would like to see if OGC make some recommandations
like (longitude,latitude) order optional in some cases, or mandatory in all cases, etc.).
What I suggest is having an authority that tries to follow OGC
convention and common convention and probably without making it the
default one (although I personally would like to do it), in order to
have CRSs behave as expected: if I ask EPSG:4326 I would like to see
lon,lat instead of lat,lon and, morevoer, once I get this crs and I
ask for the code I want to get 4326 not "modified axis whatever" :-) .
A problem is that, even if "EPSG:4326" as (longitude,latitude) is consistent with OGC, it is
inconsistent with other tables in the EPSG database like "Coordinate_Operations", which may lead to
some problems. If a user looks into the "Coordinate_Operations" table from the EPSG database for a
transformation path from "EPSG:4326" to "EPSG:whateber" - or in GeoAPI words, if he invokes
CoordinateOperationAuthorityFactory.createFromCoordinateReferenceSystemCodes("4326",
"whatever");
then the user get a CoordinateOperation from "4326" to "whatever" built from the information
provided in the EPSG database. But of course, the coordinate operations defined in EPSG are
consistent with the EPSG definitions of CRS, which are inconsistent with the user CRS if axis order
were inverted.
Well - we could make the referencing module yet more complex by switching the CoordinateOperation
axis as well as CRS. But similar burden may apply to every users wanting to look into the EPSG
database by themself. The removal of the authority code was an attempt to avoid misleading such users.
There is some proposals in no particular order. Lets see which one may work the
best:
1) Always use (longitude,latitude) axis order and keep authority code unchanged (e.g.
"EPSG:4326").
2) Change the authority code into something easy to parse (but non-standard), e.g.
"WGS:EPSG:4326",
in order to avoid the above-cited confusion risk but still allowing
applications to get the
authority code. Keep all other properties (e.g. the plain English name)
unchanged.
3) Creates GeographicCRS with (latitude,longitude) axis as specified in the
EPSG database, and
wrap them into a DerivedCRS with (longitude,latitude) axis order with same
properties
(including same EPSG code).
pros: - Users can know if the CRS is as defined in the EPSG database or
a modified CRS by
checking 'if (crs instanceof GeographicCRS)' or 'if (crs
instanceof DerivedCRS)',
even if the CRS has the same EPSG code. DerivedCRS already
exists in Geotools, and
the "DerivedCRS" name is rather explicit. So the distinction between
"original" and
"modified" CRS would be obvious on a programmatic point of view,
while using the same
authority code.
- If the CRS is a DerivedCRS, users can get the original CRS with
(latitude,longitude)
axis order by invoking DerivedCRS.getBaseCRS(). This capability
is not available with
proposals #1 and 2 above.
cons: - A (longitude,latitude) CRS is not immediately visible as a
GeographicCRS to users.
Users need to be aware of this GeographicCRS / DerivedCRS usage,
which would be (I
guess) non-standard. Note: if we feel that this aproach is the
best one, maybe we
could submit an explicit GeoAPI interface (as a DerivedCRS
sub-interface) to OGC.
Martin.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
