Thanks Jody, Bryce, Paul and everyone for your input.
So the best compromise I can imagine right now is:
* CRS created from EPSG codes will still as specified in the EPSG database
(i.e. latitude,longitude axis order) by default. The EPSG factories stay
basically unchanged - no hack.
* Users need to be able to force (longitude,latitude) axis order on a case-
by-case basis. It must be entirely under user control - the referencing
module will never swap axis without user request. It is up to the user
(or to the DataStore implementor) to decide if the DataStore in use requires
such axis swapping or not.
* Deprecate the OrderedAxisAuthorityFactory.register(String) method, because
it has a system-wide effect: it violate the "case-by-case" requirement
above.
Note that the OrderedAxisAuthorityFactory class itself will still in use.
* Introduce a new hint in the org.geotools.factory package:
Hints.FORCE_ORDERED_AXIS.
* If a user want to create CRS from EPSG codes with (longitude,latitude) axis
order, he must provides explicitly the above-cited hint when requesting for
a CRSAuthorityFactory:
Hints hints = new Hints(Hints.FORCE_ORDERED_AXIS, Boolean.TRUE);
CRSAuthorityFactory factory =
FactoryFinder.getCRSAuthorityFactory("EPSG", hints);
If the FORCE_ORDERED_AXIS hint is not provided, the default value if
Boolean.FALSE.
Under the hood, when Hints.FORCE_ORDERED_AXIS is set to Boolean.TRUE,
Geotools's
FactoryFinder will just returns the standard EPSG factory wrapped in a
OrderedAxisAuthorityFactory instance.
* Maybe add a CRS.decode(String code, boolean forceOrderedAxis) convenience
method.
* As Jody pointed out, all CRS arguments should be CoordinateReferenceSystem
objects,
never a plain String, in order to avoid ambiguity. The referencing module
should be
able to handle correctly CoordinateReferenceSystem objects in all cases, no
matter
what the axis order is, as long as axis are correctly defined in the CRS
object.
* The potentially dangerous side-effect is that the same running JVM may have
different
CRS with different axis order while claiming the same EPSG code. It can
lead to some
errors like StackOverflowError in non-cautious code. The referencing module
has been
made more robust (GEOT-854). However, I'm not sure if the same kind of
error may occurs
in client code.
* Changes will be applied on the trunk (toward 2.3 release) only. The changes
seems a
little bit too significant to me for the 2.2 branch.
Does it make sense?
Martin.
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
