[Requests] OGC Seeks Public Comment on new version of OpenSearch for Earth Observation Suite of Standards

Tonneau Stéphane Stephane.Tonneau at nrb.be
Thu Aug 2 07:34:01 EDT 2018


PART A


1. Evaluator:
                VITO NV
                Boeretang 200
                2400 MOL
                Belgium

2. Submission:
                17-047r0  Version: 0.5.0D8
                OGC OpenSearch-EO GeoJSON(-LD) Response Encoding Standard



PART B

1. Requirement:
                10 Future Work (Non-Normative)

2. Implementation Specification Section number:
                Propose JSON encoding for the OpenSearch Description Document and OpenSearch Parameter Extension which are XML-based to enable a JSON-only implementation of an OpenSearch interface considering alignment with OpenAPI specification.

3. Criticality: Major

4. Comments/justifications for changes:
        We think that an encoding should already be proposed in this document, as without JSON OSDD:
        - A client would still need to parse xml (to get the description), which shall make it more complex and shall lower the interest of using geo/ld-json support. And without access to OSDD, there is no possibilities to perform the recommended 2 steps search.
        - The temptation to implement specific JSON enabled OSDD is quit big, which shall lead to interoperability issues in the future or at least shall require server and client adaptations.


PART B


1. Requirement: General


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes:
                The document doesn't indicate where to place vendor specific information.  Are they still supported?
                This is a major issue for VITO as we have several important metadata's stored in those fields (MapProjectionReference, MissingDataPercentage, ProductVersion, LandPercentage...).


PART B


1. Requirement:
                Table 9: Links object properties


2. Implementation Specification Section number:
                search                   $.properties.links.search
                                                $.properties.features[*].properties.links.search

3. Criticality: Minor

4. Comments/justifications for changes:
                In $.properties.links, the opensearch "self" link is not provided anymore, while it is mandatory in OpenSearch best practise documents.

                In table 9 Page 43 - "$.properties.links.search "
                - The first sentence "Reference to a resource from which the present response document is derived" seems to be related to the first "$.properties.links.search", while
                - The second sentence "This shall at least contain a reference to the OpenSearch Description Document that describes the search interface" seems to be related to $.properties.features[*].properties.links.search.  In the actual document, the 2 sentences seems to be linked only to the first point.
                In comparison to the OpenSearch specification, it is quite annoying/confusing to have the same "search" relation to be interpreted differently whether we are in a given context or in another one.  The same approach as for xml should be kept (that is distinguishing "self" and "search" relation).

PART B

1. Requirement:
                Table 4: FeatureCollection object properties

2. Implementation Specification Section number:
                properties $.properties                                 One (mandatory)

3. Criticality: Minor


4. Comments/justifications for changes: [Comments]
                It is stated that "properties Groups all other properties of the search response not covered", and that the field is mandatory.
                This is a little bit confusing as this document also applies for ld-json 1.1 response, and in that schema of response, the "properties" field is not mandatory (see JSON-LD 1.1 (Expanded) examples of this document)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20180802/2b38c5f2/attachment.html>


More information about the Requests mailing list