Ciao Martin, ciao a tutti,
I would like to expose some thougths about the proposed solution.
I read and understood all objections and concerns stated by different
people in these set of emails. My objection is (do not yell at me
please...) that we are not solving the problem or at least not the
problem I stated at the beginning of this thread.
I think this solution looks promising in the mid term, but I see a big
problem if try to look at the short term (1-2 months).
Let's look at the actual GeoTools-GeoServer supposing that the
proposed solution is in place. If we remove epsg-wkt from classpath
and we drop epsg-hsql things will not work again (especially if you
try to reproject). This does not surprise for various reasons.
1>I do not have any control on the plugins and if one plugin (for
example shapefile) is not making use of the proposed HINT things will
not be as expected due to the axes swap. This means that if I
substitute epsg-wkt with epsg:hsql I will get coordinates in the wrong
CRS.
I frankly doubt that in the short term we will ever be able to align
all the codebase with this HINT.
2>I have to go look all over the GeoTools-GeoServer code to track down
all the places where that HINT should have been used. It is not just
about Referencing or plugins, I am also talking about for example the
Renderer. This applies also to all the applications built upon
geotools where a CRS is instantiate using the EPSG:CODE fashion.
In all and every module/plugin/app where the epsg-wkt has been used if
you just drop the epsg-hsql you will run into a lot of troubles unless
you have been really really careful with checking the axis order. If
you ever made the assumption (wrong assumption but you might have made
it) to get always coords as easting,northing nothing will not work
anymore.
Conclusion
For the above mentioned reasons as a short short term hack I would
have really loved to see the refactor of
OrderedForgotTheNameAuthority.
I know it has a system wide effect but it is really what I would like
to have as a hack!!! If you have to make an hack make it visible and
consistent therefore when you will remove it nothing will change in
the rest of the code.
If we go with the proposed solution we will have probably to change
many plugins, modules and applications built on top of them, which
will bring confusion and bugs (hopefully not), just to substitute
epsg-wkt.
Frankly, If I were a user with an application built on top of GeoTools
I would NEVER drop epsg-wkt for epsg-hsql and change all my code
around it. I would rather use something that guarantee that my
codebase wil continue to work so that I can start removing all the
wrong assumptions I made and get aligned with the correct codeline.
That *something* would be a system wide switch as I proposed with the
refactor of the old authority (and as also someone else before me
proposed since OrderedBlahBlahAuthority was the answer to some user's
question, it did not fall from the sky see
http://jira.codehaus.org/browse/GEOT-694).
It is worth to point out that this quick hack would not clash with the
solution proposed by Martin that is btw elegant and correct but would
be more like a transition thing to help people remove wrong assumption
from their applications. Once we are sure that all geotools codebase
is using Martin's HINT we could deprecate and then remove the
OrderedBlahBlahAuthority.
I think (and many people say this as well ) that one of the most
annoying things of Geotools and of Open Source Software in general is
that it changes too much!! (correct Bryce?). You write your app now
and in 6 months if you recompile nothing will work (I am being a bit
pessimistic sorry).
So my proposal is:
1>Martin's HINT is correct and more than welcome(I would say mid.-term
solution).
2>Quick awful bad dirty system wide hack to help people (module
maintainers and external applications) check their code and make it
stronger. This would be the refactoring of
OrderedForgotTheNameAuthority.
3>Have all the module maintainers review their code looking for wrong
assumptions to be removed (mid term).
4>URI based authority (mid-term to long term solution).
I hope that this contribution from me is of help. I always try to
suggest what I believe would make Geotools more popular and accepted.
Simone.
On 5/25/06, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
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.
--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant
http://simboss.wordpress.com/
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
-------------------------------------------------------
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&kid7521&bid$8729&dat1642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
