Review of "Alternate Encoding for INSPIRE Data: GeoJSON"

[cportele]

https://github.com/INSPIRE-MIF/2017.2/blob/master/GeoJSON/specification.md

• [x] While the Introduction says that the encoding will be an alternate or additional encoding depending on the source data, the encoding is also called the "GeoJSON alternate encoding". Isn't this misleading?
• [x] "alternate" and "alternative" are both used. Based on the glossary, "alternative" should be changed to "alternate" throughout the document.
• [ ] Technical issues: At least the following identified issues are in general not "resolved" by the encoding rule:
  • "Most GIS software cannot fully make use of non-smple attributes and nested structures for styling, processing and filtering" - the conversion rule creates arrays
  • "Support for multiple values per property is an issue in ArcGIS and other GIS tools" - the conversion rule creates arrays
  • "References to other features often cannot be resolved by GIS tools; Propertes of referenced features cannot be used in styling or for filtering" - association roles are retained as they are
• [x] Technical issues: What is the difference between "Abstract geometry types for an object mean that a wide range of different geometries can be used" and "Mixed geometry types in a FeatureCollection are usually not supported"? Can we remove one?
• [x] Schema Conversion Rules: The statement that "all model transformations are applied at the UML level" is not consistent with some of the text in the section. For example, "General types" discusses conversion rules to (Geo)JSON, not UML.
• [x] I would question the statement that "JSON Schema cannot be considered stable enough". To me the argument for not specifying a JSON schema at this point is that all the targeted software is not using or supporting JSON Schema. For conformance testing using JSON Schema still makes sense, but for operational purposes it is not relevant at this time. The expectations are different than in the GML/XML case.
• [x] General types: What are general types? What makes type XYZ a general type and GM_Point or a union type not a "general type"?
• [ ] "All types that have the stereotype <> are converted to GeoJSON objects". "GeoJSON objects" -> "GeoJSON features".
• [ ] 19107 Table: "XML Schema datatype" -> "ISO 19107 type"
• [ ] 19107 Table: "GM_MultiSurface | Polygon". "Polygon" -> "MultiPolygon"
• [ ] 19107 Table: "GM_Object | not supported". Instead of "not supported" this could also be "any GeoJSON geometry". Similar for "GM_Primitive".
• [ ] 19107 Table: Remove GM_Ring
• [ ] The SimplePeriod, the SimpleCitation and other model transformation links result in a 404.
• [x] Abstract Types and Inheritance: "the inheritance hierarchy is collapsed to the concrete types" - how does this "collapsing" work in UML ("all model transformations are applied on the UML model")?
• [x] Union Types: ReferenceType and BuildingType are not types in the INSPIRE UML model, they sound like GML type names. I also do not think that "the most common use case for union types in INSPIRE is to offer a choice between encoding an object in place or to encode it by reference" is correct; at least it should not be correct as this is not something for the conceptual level. That said, I am not sure, where <> is used in the current INSPIRE application schemas.
• [x] Union Types: What is the "concrete type in the union"? What type is used in the converted UML model instead of the union type?
• [x] Union Types: There is a "For" at the end. Is something missing?
• [ ] Types: Don't we need a rule for data types?
• [x] "TODO: Should namespace prefixes be retained for the JSON property names?" - My view: Don't include them, they are confusing for most, make the data harder to read and do not seem to add value.
• [x] "Mapping Property types from Conceptual Model to GeoJSON Logical Model" - The use of "property types" is misleading, these seem to be basic types and could be moved to a section "ISO 19103 - Basic types".
• [x] Arrays: This covers simple value types. Should a statement be added how cases with non-simple value types are handled? Probably that the model needs to be transformed first to remove such cases?
• [ ] Instance conversion rules: There should also be a rule how identifiers are converted.
• [x] Conformance Classes: These are defined "per theme". Wouldn't "per INSPIRE application schema" be more appropriate. Take geology as an example. Or maybe "per theme or application scheme"?

(to be continued)

[thorsten-reitz]

Note: Some of the checklist items can't be checked. It seems that those that start with a character other than a letter are affected. The current PR should address...:

• [x] Types: Don't we need a rule for data types?
• [x] 19107 Table: "XML Schema datatype" -> "ISO 19107 type"
• [x] 19107 Table: "GM_MultiSurface | Polygon". "Polygon" -> "MultiPolygon"
• [x] 19107 Table: "GM_Object | not supported". Instead of "not supported" this could also be "any GeoJSON geometry". Similar for "GM_Primitive".
• [x] 19107 Table: Remove GM_Ring
• [x] The SimplePeriod, the SimpleCitation and other model transformation links result in a 404.

[thorsten-reitz]

@cportele please let me know if we can close this issue.