I known that CRS.decode(...,) and CRS.decode(..., true) are commonly used -
they
will not change. But are anyone using the same method with a "false" argumment
value?
In GeoTools 2.6 we have:
CRS.decode(..., true) : set FORCE_LONGITUDE_FIRST_AXIS_ORDER to TRUE
CRS.decode(..., false) : do not set FORCE_LONGITUDE_FIRST_AXIS_ORDER
CRS.decode(...) : do not set FORCE_LONGITUDE_FIRST_AXIS_ORDER
(i.e. use system-wide default axis order)
The two last lines duplicate each other. I'm tempted to define (note that only
the second line change):
CRS.decode(..., true) : set FORCE_LONGITUDE_FIRST_AXIS_ORDER to TRUE
CRS.decode(..., false) : set FORCE_LONGITUDE_FIRST_AXIS_ORDER to FALSE
CRS.decode(...) : do not set FORCE_LONGITUDE_FIRST_AXIS_ORDER
(i.e. use system-wide default axis order)
The goal is to avoid a conceptual complexity since the current relationship
with
FORCE_LONGITUDE_FIRST_AXIS_ORDER is convolved for no functionality since
current
CRS.decode(...) and CRS.decode(..., false) are strictly synonymous. On the
implementation side it would bring a very slight simplification with more
symetric code (less special cases).
You would be affected by this change only if you use CRS.decode(..., false)
with
"false" for the boolean argument *and* your system-wide defaut axis order
(defined through system properties at startup time) is "longitude first".
Martin
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
