First of all I think it is worth that everybody involved in this
discussion were aware of this link:
http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue
That said, let me first start with a snapshot of the situation, but
let me also remind that the guru here is Martin.
Situation is as follows for GeoTools right now:
- 2.2.x and successive --
# epsg-wkt generates long-lat order CRS for EVERY single EPSG code and
this is incorrect from the EPSG perspective while it is correct from
the OLD OGC perspective as well as for the common-practice.
# ALL the others EPSG factories (HSQL, PostgreSQL and so on)
generates CRS following STRICTLY the information provided by the EPSG
database. This means that if a CRS in the EPSG database is lat,lon
these authority will create a CRS with a lat,lon axis order for that
particular CRS. As an instance, this apply to EPSG:4326 AKA WGS84
lat,lon.
It is worthwhile to note that while this approach meets EPSG
requirements, it does break what the common practice is causing
numerous headaches to developers, hence afaik neither uDig nor
GeoServer actually uses any of these authorities but they stick with
epsg-wkt.
- 2.3.x and successive-
We tried to start tackling the problem described here above with non
EPSG-WKT factories by using a combined approach describe in the web
page provided above which would like in the longer term to tackle the
problem completely.
The main thing that martin has done for the moment was as follows:
a) Giving the user the option to specify the order of the axes when
instantiating a CRS. An example of code is as follows:
Hints hints = new
Hints(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, Boolean.TRUE);
CRSAuthorityFactory factory =
FactoryFinder.getCRSAuthorityFactory("EPSG", hints);
CoordinateReferenceSystem crs =
factory.createCoordinateReferenceSystem("EPSG:4326");
or as follows:
CoordinateReferenceSystem crs = CRS.decde("EPSG:4326",true);
a) Giving the user the option to specify a system-wide flag in order
to force all th factory to behave as common-pratice would expect, that
is, ALWAYS lon,lat.
System.setProperty("org.geotools.referencing.forceXY", "true");
or
java -Dorg.geotools.referencing.forceXY=true
or
java -Dorg.geotools.referencing.forceXY=true
org.geotools.referencing.FactoryFinder
java -Dorg.geotools.referencing.forceXY=true
org.geotools.referencing.factory.epsg.DefaultFactory 4326
The medium term solution would be coming up with an authority based on
URN instead of on simple EPSG codes.
--My thoughts--
Ok, now the point is how we should behave while we wait for the
definitive solution. My answer comes from practice since I have been
using EPSG-*SQL factories for a years now in my apps as well as in
GeoServer and I think that is not only reasonable way but also, let me
be a bit arrogant, the only way that may actually work as of now. Let
me summarize.
----Data providers MUST provide adequate information to build a CRS
and the relative georeferencing for the data they provide otherwise we
should just throw a very bad error exception.
----DataStore maintainers should check if there are any predefined
axes order at format level and ALWAYS follow that order. An instance,
if you read the GeoTiff spec carefully you'll notice that they
implicitly assume that the axis order is lon,lat. Well the GeoTiff
store MUST ALWAYS generate CRS information following such approach no
matter what the user says, no matter which system-wide option has been
set. The CRS axes order should be decided at the datastore level as
far as talking about data I/O and that SHOULD NOT be changed
implicitly or transparently.
---We should remove any implicit assumption on the CRS axes order in
all the core modules like main and, especially, rendering.
I found myself many places inside the streaming renderer where the
assumption of having ALWAYS a lon,lat CRS was implicitly made. This is
wrong and may lead to unpredictable drawing effects. As I said above
the CORRECT CRS for data should be decided at DataStore level and
NEVER changed afterward, at least not implicitly. All the modules that
actually work with the real data abstraction like feature or coverage
should just trust what the DataStore provide and make no assumptions
but always check the axis order where needed.
---So, why a system wide setting? It is so bad...---
Yeah it is bad, but it is needed for the transition. Anyone wondered
why both uDig and GeoServer uses EPSG-WKT and not the others? Because,
they rely on code that sometimes make assumptions on the axes order.
Do you think that it is feasible to replace EPSG-WKT with EPSG-HSQL
and start fixing the errors? If you think so, go ahead and go luck.
We need to use this system wide hint in order to allows this big
applications to switch over to the new factories without pains while
giving them time to remove any existing assumptions. When GeoTools
will not have any assumption, and all the datastore will provide
correct CRS and when this applications will have removed any internal
assumptions as well we could even remove the system wide flag, but for
the moment I am afraid it is the only way to trigger the transition.
--Why should I stop working with EPSG-WKT if it works for me?---
Well, I never said everybody should transition, at least for the
moment. EPSG-WKT does its work for most apps, but not for all because
IT DOES NOT CONTAIN all the information needed to generate all
CRS-related objects. As an instance, with EPSG-WKT the new plugin for
geotiff would not work because I need to construct CRS starting from
low level building blocks like prime meridian, uom, etc.
I think that GeoServer and uDig have to start using the other
authorities first of all for robustness and coherency.
---But if datastore maintainers fix the issue deciding the correct
order, isn't that enough?
The answer is NO. Forgetting for a moment about the possibility to
have assumptions about the infamous axes order here and there in the
core modules code, like rendering, which is concrete btw. You need to
be aware of the issue at least as long as we will have authorities
behaving differently. Moreover if someone wants to come up with a
plugin for a new format he has to be aware of this issue.
---Should I have problems with my WKT?
Well, afaik it depends on what you write. The CRS generated from WKT
will respect what you wrote, hence from the hints point of view no
hint or flag should impact WKT, but I am afraid we need to wait for
MArting to answer this.
--My 2 Cents--
I regularly work with many different data providers, Uk MetOffice,
German MetOffice, Italian Navy MetOffice, US NRL, etc... and you know
what I think?
Never rely on anybody following standards and/or knowing what is doing
and giving you the right hint about what he is doing.
1)We need to bend a bit towards common practice but not too much, or
we will loose standardization. The only way to do this is providing
few well controled flags/hints to users
2)Always trust what the data says
3)Trust what standard says but never forget about common practice or
people will think you are useless.
-----CONCLUSIONS (hpefully... 
)-----
1>For the moment we need the system wide hints but hopefully somewhere
in the not so nrea future we will remove it
2>We will always need the one - shot hint at least until there will be
around services (WMS, WFS, etc..) that implicitly assume a lon,lat
axes order and/or data format with different axes order from the
official one.
3>The problem must be handled first at datastore/(de)serialization
level, but also at rendering, management etc....
4>URN based authorithy is good but I am afraid it won't be the right
of good touching GeoTools. We will still be dealing with axis order
but at least with a deterministic clear way of managing them.
5>We need to remove any assumptions on the axis order anywhere in the
code of geotools and related apps.
6>We need soon to deprecate EPSG-WKT since it is substantially incorrect.
7>I think nobody is going to get this far so I am going to stop, my brain hurts!
Thank you all.
Simone.
in 2.2 and earlier, the order of coordinates One and Two is
> long/lat
> Users are expected to transform their data to fit
>
> in 2.3 and later, the order of coordinates follows the crs
> Users are expected to generate a correct CRS for their
> data
>
> epsg-wkt generates long-lat order info
> epsg-* generates lat-long order info
> pre-built convenience CRS's in Geotools are long-lat
> Factories/Builders will follow:
> (1) the system wide preset if it has been set
> -Dorg.geotools.forcelongitude...
> (2) the hinting mechanism if it has been set
> (3) the authority in use
> and users are expected to be aware of
> the order in the authority they are
> using.
>
> A policy such as this seems workable, especially if we have a well
> written explanation for workarounds. Something like
> CRSFactory.makeLongFirst(CRS)
> CRSFactory.makeLatFirst(CRS)
> if users have the right CRS and the wrong order.
>
> This is how I understand things today. Please let me know if things are
> different because I'll eventually write this up. Thanks, adrian
On 8/3/06, Rob Atkinson <rob@anonymised.com> wrote:
Andrea Aime wrote:
> Andrea Aime ha scritto:
>
>> Bryce L Nordgren ha scritto:
>>
>>> I missed the discussion, but I agree wholeheartedly with this email!
>>>
>>> 1] No one-size-fits-all hint.
>>> 2] Internal data models adopt a single axis convention. (no hints at all;
>>> just use CRS order)
>>>
>> Sorry, my understanding of Rob proposal was that everybody should use
>> long/lat axis order internally.
>>
> ...
>
> Ah, on the same note, there is also the consistency problem:
> with grid coverages the sole idea of having grids in long/lat even if their
> native format is lat/long makes my head hurt. Here again we do the eventual
> reprojection only as the last stage after cutting/zooming whatever to
> avoid scary performance problems (Simone correct me if I'm wrong).
>
Ah - but isnt that pushing it into the DataStore tier - where it
belongs? The point is that the logic of how to send the right request
to the data store would be simplified, and not dependent on
consitentency in alternative definitions of the same CRS. All I'm
saying, is that the hint belongs to the data store, not the system as a
whole.Forgive me if the coverage stuff dosent work that way - I havent looked
into this yet - but thats how feature stores do and should work.My point was that "internally" needed to be unpacked into how the data
model gets represented across different tiers of the architecture.Rob
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions
-------------------------------------------------------