[Requests] Inconsistency of GeoServices REST API proposal with other OGC standards
even.rouault at mines-paris.org
Sat Jul 28 14:57:20 EDT 2012
Even Rouault, <even.rouault at mines-paris.org>
OGC documents 12-054r1 to 12-062r1
2. Implementation Specification Section number:
4. Comments/justifications for changes:
I totaly second all the comments made by Adrian Custer, Peter Baumann, Cameron
Shorter and Pat Cappelaere on the GeoServices REST API proposal ( see
What is fundamentally shoking in the submission is the complete overlap, and
sometimes contradictions, with many other existing OGC standards, and the lack
of effort or willingness to resolve that overlap. This is acknowledged in
12-062r1 (GeoServices REST API – relationship with the OGC baseline), and
anyone reading that document will wonder why OGC has even considered
standardizing GeoServices REST API.
Quoting 12-062r1, "While it would be possible to develop new versions of the
OGC Web Services standards using a consistent framework and with support for
JSON representations and a RESTful "binding", this will likely take significant
time due to the unresolved REST-related discussion items, the current
organization of OGC SWGs based on the individual standards and the
fragmentation into separate standards. " --> if this statement is true, how
can OGC publish that without questionning how it works !!! So this proposal is
in fact a way to "shortcut" the standardization procedures used by OGC. It is
expected that standardization takes some time, otherwise you have a high risk
of ending up with half-backed standards.
Other quote from that document : "Over time, harmonization between the
specifications should be considered with regards to the necessary migration for
existing implementations." Certainly, but if OGC adopts the proposal, it would
have to provide migration plan for the existing standards AND the GeoServices.
So the pain would be even greater.
Letting aside those general comments to concentrate on the specific issue of
spatial reference (§9.2 of 12-054r1). Hardly anything is defined :
* How does wkid relate to EPSG codes ? There's clearly overlap, but can we
assume that if wkid XXXX match EPSG XXXX when both codes exist ?
* WKT. Foreword: it is already a shame that in existing approved standards,
the valid values for projection and parameter name are not more standardized
than the few samples that are mentionned in 06-103r4 (Simple Feature Access -
Part 1 - Common architecture) and 01-009 (Coordinate Transformation Services).
But it is well known for long that ESRI WKT diverges from other
implementations in some projection or parameter names : where are those
specificities defined ? For example, from my search in sr.json, ESRI WKT has
only "Lambert_Conformal_Conic", whereas 01-009 lists
"Lambert_Conformal_Conic_1SP" and "Lambert_Conformal_Conic_2SP" (§ 10.6.1).
Actually, that difference has been known for long (
http://home.gdal.org/projects/opengis/wktproblems.html ). And what is the
Mercator_Auxiliary_Sphere projection used for wkid = 102100 ? Not defining more
rigorously WKT severely impedes interoperability.
Finally, OGC must make a clear statement : if the GeoServices REST API
represents the way to go, then OGC must clearly deprecate all other existing
overlapping standards (WMS, WFS, WPS, WMTS, etc etc....). It would cause a lot
of confusion if that GeoServices REST API proposal would coexist with existing
ESRI is certainly free to publish and document the "API" to its services and
promote it, but I believe OGC should not just act as a rubber stamp and should
pay close attention of having a consistant body of standards. It would
certainly loose a lot of credibility if it blesses as a standard a vendor
specific protocol that clearly conflicts with other standards it has already
developed and adopted (this reminds me of the controversy about ISO finally
adopting OOXML after having also adopted ODF)
More information about the Requests