NL-review GeoJSON/specification.md

[PalmJanssen]

All,

I put my review remarks on https://github.com/INSPIRE-MIF/2017.2/blob/master/GeoJSON/specification.md in this one issue

---

replace alternate with alternative

use case.

Don't we have a general use case description? Refering to client based, that is end user based data usage where data can directly be imported without any conversion...... Particular in cases where data validation is of minor importance ..... etc

ISO 19107 Geometry types

In table refer to ISO 19107 geometry types (or datatype) and not XML Schema datatypes.

Union types

The UML stereotype Union is a choice between multiple properties. This is independent from their valuetypes. So leave out 'with different value types'.

Enumerations and Code List

Inspire has the rule that enumerartions are defined with in the apllication schema and CodeLists outside. So the content of CodeLists within the application schema are considered as 'a suggestion'. The real content is in the codelist register.

Arrays
repave 'may use' to 'shall use' (?)

Voidable
Add: So a <> attribute that is mandatory (with a multiplicity of 1..) becomes an optional attribute.

Asscociation Roles
I belief that in the Inspire GML encoding all asscoiations roles are encoded as xml by reference. Is that also an issue here?

Common Rules
GEOJSON-REQ-02: can be refered to a link where the positional error is explained that occurs when etrs89 data are considered asl wgs84?

Replace 'CRS84' with 'WGS84' ?

Model Transformation
Do I understand correctly that these transformation rules are based on XML encoding?

The same for Model Mapping

Model mapping
It is difficult to understand what is happening here. I toke the address UML and tried to follow the mapping.

General remark
I still have the feeling that a UML (GeoJSON) implementation model of Addresses would help in communicatiing the described transformation rules and resulting encoding.

[heidivanparys]

I belief that in the Inspire GML encoding all asscoiations roles are encoded as xml by reference.

Many of the associations have no tagged value inlineByReference, and then the default is inlineOrByReference (see also https://shapechange.net/app-schemas/uml-profile/#Tagged_values_of_properties). And some associations have explicitly set tagged value inlineByReference to inlineByReference. See this overview.txt (when no tagged value inlineByReference is set in the model, the file contains inlineOrByReference in the last column).

[thorsten-reitz]

@PalmJanssen Please let me know if we can close this issue.

[michellutz]

@thorsten-reitz Have you implemented the changes proposed by @PalmJanssen ?

If not, could you please discuss which ones have been accepted and which ones not (and why)?

[thorsten-reitz]

@michellutz @PalmJanssen most of the points, where concrete enhancements were suggested, were implemented. I did not add a UML model of the simplied addresses model though. Should we still build one?

[PalmJanssen]

@thorsten-reitz @michellutz Sorry to let this wait for such a long time.
One would expect that a simplified UML of Addresses is clearifying because of this statement in the doc:
'In this encoding rule, we take a two-step approach, where we apply model transformations on the level of the conceptual model. This model can then be encoded in simple GeoJSON using the general schema and instance conversion rules laid out in the next sections '.

So the transformation on the UML level is step one in the approach

I am still interested to see how the technical (simplified and GeoJSON implementation appropriate) UML model would look like.