Bryce L Nordgren a écrit :
If we agree than starting from now, "EPSG:whatever" should be understood as
being always
(longitude,latitude) axis order (as OGC decided recently in my understanding of
a recent
Jody's mail), then it is a new authority factory derived from the previous one
I wouldn't agree to that. Now we cannot handle data which correctly
declares that it is EPSG:4326. Same problem different direction.
My understanding (please Jody correct me if I'm wrong) is that:
1) "EPSG:whatever = (longitude,latitude) axis order no matter what the EPSG database
said"
is now a formal OGC decision, and every OGC-compliant data sources in the
world should
comply with it.
2) About every OGC data sources in the world are already using the above-cited
convention,
because of the (broken) way the OGC's WMS specification was wrote. Actually,
the above-
cited OGC's decision was just a recognition of the current stade of affair
of most data
in the world.
3) If a user wants to said "EPSG code like the EPSG database really intented it to
be", then
the authority prefix is something else than "EPSG:". It is currently a very
verbose URL
(for myself, I would really like something shorter. Maybe "OGP:" since it is
the new name
for the EPSG organisation?). Yes I agree, it is confusing. "EPSG" should means
"the real
EPSG database" and some other name should means "The modified EPSG
database". Unfortunatly,
in my understanding of Jody's email, OGC formaly decided the opposite (and
confusing) way
arround.
My point was that the CRS in the file does not have to be the CRS returned
by the DataSource. The referencing module should not be involved, except
perhaps to provide a DerivedCRS which swaps axes from the BaseCRS (...and
returns a DerivedOperation which swaps axes, etc.). Every module except
the Data Sources should trust that the CRS provided is accurate.
I fully agree. What the referencing module is trying to provide is an authority factory capable to
creates CRS from EPSG code as OGC (and current practice) said they should be, which are not the way
the EPSG database said it should be. In other words, the "OGC" definition take precedence over the
"EPSG" definition for the "EPSG" name space (yes I know, this is the confusing above-cited stuff),
and a new name space need to be found for the real EPSG definition (currently URL according OGC, but
I find them too verbose).
DataStores would use this factory, since it is now the standard. All code everywhere in Geotools and
client side should trust that the CRS object is accurate, as you rightly point out. However,
Geotools and client code should check the full CRS object - they should not trust blindly the
authority code. In other words, never pass an authority code as a String argument to a method;
always pass a full CRS object. There is a risk of confusion only if a CRS is described by its
authority code only. Otherwise, everything should stay clean.
Anyway, for now I plan to keep "EPSG:whatever" as "real EPSG" for now (despite OGC decision) and
users would have to invoke OrderedAxisAuthorityFactory.register("EPSG") explicitly if they wants the
(longitude,latitude) axis order.
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&kid7521&bid$8729&dat1642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
