INSPIRE-MIF/2017.2

Review of Alternate Encoding for INSPIRE Data: GeoJSON (hv/DK)

Closed this issue · 3 comments

heidivanparys commented

My comments so far on https://github.com/INSPIRE-MIF/2017.2/blob/master/GeoJSON/specification.md

General

Title

  • Another title should be chosen, as also said in #76 . How about "INSPIRE UML-to-GeoJSON encoding rule"? Although encoding is often used as synonym for encoding rule (#74), I think the title should use the preferred term.

Introduction

  • TopoJSON is mentioned only in the introduction. Should this paragraph be removed altogether?
  • The description of IETF should be more neutral. How about "It has since been formalised as an internet standard of the Internet Engineering Task Force (IETF), a standards organisation, which develops specifications concerning the Internet".
  • I think that the paragraph regarding the difference between alternative encoding and additional encoding does not belong in a introductory section.

Scope

  • Replace "GeoJSON alternate encoding" with "INSPIRE UML-to-GeoJSON encoding rule" (or whatever decision is made regarding the title, see previous comment).

Use cases

  • How good is support for GeoJSON in desktop client software? I definitely agree that the encoding rule addresses data usability in web client software, as GeoJSON was developed to do just that, but is there any research available regarding GeoJSON and desktop client software? Spatial Data on the Web Best Practices states regarding tool support for GeoJSON: Supported in some GIS tools. Widely supported in Web libraries and mapping APIs.

Technical Issues

  • Rephrase the last paragraph to something like: The GeoJSON format cannot deal with 3D geometries and coverage/raster data, therefore this encoding rule cannot be used for those types of data.

INSPIRE Requirements for Encodings

  • This is not GeoJSON-specific. Should this section maybe be moved to a new document, that could be the "container" for the other documents?

Schema Conversion Rules

  • A suggestion to solve the comment regarding JSON Schema in #76:
  • Remove "There is no equivalent to such a logical schema language for JSON." and "NOTE At this point, JSON Schema is undergoing rapid development and cannot be considered stable enough.".
  • Add the paragraph below instead, and add reference below to the references section.

This way, it is not the 2017.2 group that expresses an opinion, but a quote from a peer-reviewed article. The quote addresses both the stability of the specification and the adoption of it by software vendors.

[...] JSON Schema is the only general attempt to define a schema language for JSON documents, and it is slowly being established as the default schema specification for JSON. The definition is still far from being a standard (the specification is currently in its fourth draft but there is already a growing body of applications that support JSON schema definitions, and a good deal of tools and packages that enable the validation of documents against JSON Schema. [...] Despite all the advantages of a schema definition, the adoption of JSON Schema has been rather slow. One of the issues that have prevented the widespread recognition of JSON Schema as a standard for JSON meta-data is the ambiguity of its specification. [Foundations of JSON Schema]

Reference (link to copies can be found via Google Scholar, I didn't want to include one of them here):
PEZOA, Felipe, REUTTER, Juan L., SUAREZ, Fernando, UGARTE, Martín and VRGOČ, Domagoj. Foundations of JSON Schema. In: Proceedings of the 25th International Conference on World Wide Web. International World Wide Web Conferences Steering Committee, 2016. p. 263–273. WWW ’16. ISBN 978-1-4503-4143-1.

  • Rephrase the sentence below, it is unclear what exactly is meant.

All model transformation rules are applied in such a way that the resulting property names for valid XML element and type names, and are useable as property names in JSON.

Conformance classes

  • (added after meeting 20190329) Remove gml:id, gml:name and gml:description from the model mapping: it is a mapping from UML to uml, not from GML to UML or from GML to GML.
thorsten-reitz commented

Would we also have to remove gml:name?

thorsten-reitz commented

Notes on my changes:

  • I kept the clarification about when this can be alternative and when it is an additional encoding rule, but changed the wording so that it is hopefully clearer. I think it is important enough to keep it in a prominent place.
  • I did not address the comment about how good GeoJSON support is. I have, however added a reference to 2017.3 and the caniuse repo to the Preface.
heidivanparys commented

Would we also have to remove gml:name?

In my opinion, yes, and for the same reason: it is a mapping from UML to uml, not from GML to UML or from GML to GML.

From the GML standard:

The gml:name property provides a label or identifier for the object, commonly a descriptive name.
[...]
Often, a special identifier is assigned to an object by the authority that maintains the feature with the intention that it is used in references to the object. [...] gml:identifier is a predefined property for such identifiers.

In the INSPIRE model, properties with those semantics are modelled explicitly:

  • for identifiers: fx inspireId, hydroId (hy-p), nationalCode (au), nationalCadastralReference (cp), attributes that use ThematicIdentifer (Base Types 2) as type, etc. etc.
  • for names, the attributes with GeographicalName as type