Martin Desruisseaux wrote:
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.
OGC is sick of the problem, it is a political problem with no good
solution - as such I do not expect a formal decision from them.
(It is not helpful for a standards body when the real world does not
want to agree).
The OGC has *three* solutions on the table:
- "EPSG:CODE" is in easting/northing order all the time for WMS (prior
to WMS 1.3.0 I admit - but WMS 1.3.0 is not being implemented because of
this issue).
- "EPSG:CODE" is in the order of the EPSG database for WMS 1.3.0
(someone correct me if I am wrong)
- URI - is in the order of the EPSG database
The reason WMS 1.3.0 is more of a mess then usual is because it is a
joint release with ISO.
I am trying to learn as I listen to the discussion, it seems the problem
comes from OGC services sending us just this String, if they were
sending us the
real CoordinateReferenceSystem definition we would all be good? The
CoordinateReferenceSystem object does have enough information for everyone,
including the renderer to work correctly?
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.
Got it.
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.
Got it. And frankly the OGC could not claw back the use of "EPSG:CODE"
there is too much infrastructure
deployed around their earlier specification. They did try (for WMS
1.3.0) changing their mind - but industry
is ignoring them.
Perhaps this is the reason someone is funding additional WMS cite tests
this time around?
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.
Yes! Please :-)
And for a best practice I would like to see us encourage the URI syntax
in such things
as code examples. But perhaps that is me playing politics and not
helping solve the problem?
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.
Ack, for many DataStore implementors will need to invoke that
OrderedAxis thing all the time? But you are quite right that the
responsibility to make that assumption
(and provide control over it) rests at the data store level.
Cheers and that for the breakdown of the issues Martin,
Jody
-------------------------------------------------------
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
