[Requests] GeoService REST API general comments

Matthijs Laan matthijslaan at b3partners.nl
Sat Aug 18 11:00:33 EDT 2012

1. Evaluator:  
        Matthijs Laan, B3Partners <matthijslaan at b3partners.nl>  
2. Submission: GeoServices REST API  
1. Requirement: General  

2. Implementation Specification Section number: General  

3. Criticality: Major  

4. Comments/justifications for changes:

There are numerous problems with the standard and the specification. Some are
already commented on by others, but in addition another non-exhaustive list:

- It does not support cross-origin resource sharing (http:www.w3.org/TR/cors/)

- Export Map does not specify ordering of layers, unlike WMS

- Export Map does not support spatial filtering

- Export Map does not support custom styles (for highlighting for example)

- The Export Map "layerDef" expression is different from not only OGC CQL but 
  also the "where" parameter for the Query service

- It is a serious flaw that the "where" parameter for the Query service is specified
  as only "any legal SQL WHERE clause" without a grammar. 

- Separating the spatial query relation and geometry means limited spatial 
  querying where CQL like "geometry intersects polygon(...) OR other_attribute = ..." 
  and "geometry intersects polygon(...) and geometry intersects linestring(...)" 
  are not supported. DWITHIN and BEYOND are not supported either.

- Not supporting response paging is a serious limitation as is the lack of a 
  sorting capability.

- It is apparently the intention to establish a new naming authority for 
  "urn:ogc:def:crs:gsr" and "urn:ogc:def:uom:gsr" URN's which - if submitted at all - 
  will only serve to codify the incompatibilities and redundancy with existing
  naming authorities. If the naming authority is submitted to OGC-NA it will 
  have to be seen if it is accepted and will live up to the responsibilities 
  in ISO 19135 (referenced from OGC 09-046r2) and make any effort to resolve 
  the noted incompatibilities with other authorities concerning referencing.

Apart from these problems and others, the "12-062r1" document is a lengthy 
document trying to provide a justification for the standard. Whether it is 
convincing anyone that this standard is a serious effort to promote 
interoperability or just an attempt at standardization of a single-vendor
implementation with all its limitations and technological debt is up to the
community to decide. 

Our opinion is that this draft standard is be a step backwards for interoperability
and technical progress for the spatial community and efforts are better directed
to improving the WxS standards instead of creating limiting, incompatible, 
under-defined and already outdated new standards.

Matthijs Laan,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20120818/239d0fba/attachment.htm>

More information about the Requests mailing list