[OSGeo-Standards] Inconsistency of GeoServices REST API proposal with other OGC standards

[Even Rouault]

PART A


1. Evaluator:
        Even Rouault, <even.rouault at mines-paris.org>

2. Submission: 
	OGC documents 12-054r1 to 12-062r1


PART B


1. Requirement:
	All

2. Implementation Specification Section number:
	All

3. Criticality:
	Major

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 
http://lists.opengeospatial.org/pipermail/requests/2012-July/date.html ).

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 
adopted standards.

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)