They make a first cut at a problem,
get a "nominal" solution out there for people to implement and test, but in
the process they cut some of the wrong corners (because you just don't know
which things are important before you use them.) This particular problem
exists because OGC cut the wrong corner, became too popular, and now can't
un-cut the corner easily. Popular vs. Right. Right will still be right
tomorrow, but popular might not still be popular.
ISO, on the other hand, is more interested in building a coherent,
vertically integrated suite of standards. They adapt some of the prototype
standards, integrate some of the lessons learned, and produce something
which "fits" with the rest of the standards better. They are somewhat
concerned with maintaining compatibility with what currently exists, but
the priority is to fix hacks and produce something which is well-designed
at the single-standard and collection-of-standards level.
Put another way, ISO seems to be "version 2.0.0" of OGC standards: major
API change in some cases, but changes are for the good in the long run.
Obviously, this causes "distress" during the transition. However, if you
want to know what you'll need to support in five years, look to ISO's
activity now.
The reason WMS 1.3.0 is more of a mess then usual is because it is a
joint release with ISO.
See. :) Transition. Transition hard.
The OGC is the new kid on the block, and makes newbie mistakes. EPSG has
been doing geodesy since before the OGC formed and their axis order follows
ISO 6709, published in 1983. OGC created this particular mess by ignoring
~20 years of "accepted best practice" when they started publishing
standards in ~2000. Whoops.
This particular discussion is perhaps the best argument for moving to
"version 2.0.0/ISO" (WMS 1.3.0) with all available speed.
- "EPSG:CODE" is in the order of the EPSG database for WMS 1.3.0
(someone correct me if I am wrong)
You're right. From ISO 19128:2005 (WMS), published by ISO on 2005-11-23:
"EXAMPLE EPSG:4326 refers to WGS 84 geographic latitude, then longitude.
That is, in this CRS the x axis corresponds to latitude, and the y axis to
longitude."
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.
Add Jody's [confirmed] observation that WMS 1.3.0/ISO 19128 is the opposite
decision to this quote. And Paul Ramsey's note that all future work will
abandon the currently popular convention. During transition, we should
handle both. We should plan on deprecating the currently popular
convention in a 2-10 year time horizon.
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.
As to industry's stance: Eventually an update to the WMS spec will have a
feature that every manager MUST HAVE. Some IT managers right now gotta
have the latest version of everything. The first company to offer a WMS >=
1.3.0 solution which is backwards compatible with previous versions will
trigger a lemming landslide. Give industry a transition path and they'll
grab it.
Do OGC web services report the version of the spec they implement? That
could be used to apply the correct interpretation of "EPSG:CODE".
(now != future)
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).
I do not think it is appropriate to state that the OGC has made a decision
on this topic. They say one thing in WMS 1.3.0/ISO 19128 and apparently
they say another in previous WMS versions, and a letter or report or some
other place. Rather, it is probably appropriate to say that OGC has made
"both" decisions. Paul Ramsey's quote indicates that their decision is to
conform to the ~23 year old practice for all future work.
I would argue that OGC's inability to make a _single_ decision on this
topic, coupled with their break from 23 years of best practice, plus the
fact that this is definately relevant only to web services and perhaps not
to features serialized to GML or some other format, and finally, their
desire to "do the right (opposite) thing" from now on, speaks to the need
for an adaptation layer for the EPSG namespace.
I suggest that the EPSGAuthorityFactory should represent the EPSG's
definitions. A middleware layer could take on the task of bidirectional
authority name translation for old versions of OGC web services. This
middleware should affect only the authority name, not the CRS definition.
Our internal "URI" or "CRS" or "Geotools" authority namespace would hide
the "real" CRS name. Or we could just make an axes swapper CRS adapter.
Whatever we come up with is temporary and will be deprecated within 10
years.
The thing that bothers me most is that I'm really not clear about whether
the OGC's advice on this matter (such as it is) extends beyond web services
to other things CRS is used for. I don't think our referencing module
should be locked into one _application of_ referencing (OWS), and this
seems to be the risk we're running.
This middleware could be generalized to the notion of a "namespace
convention translator". Using middleware, we can implement WMS 1.3.0 and
previous versions with the same base code.
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.
I think if we take the middleware approach, the DataStore implementors will
have to apply an appropriate namespace translator or axes swapper to the
CRS. Most important: you can have defaults, but a human programmer or
end-user should be able to override them. The Human can tell if the axes
are backwards, and the Human can read the natural language metadata. They
need the power to correct an inappropriate default.
I hate computers which automatically do the wrong thing and offer no way to
make them do the right thing.
Bryce
-------------------------------------------------------
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&kid=107521&bid=248729&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
