search

INSPIRE-MIF / 2017.2

Repository for action 2017.2 on alternative encodings
6 stars 11 forks source link

NL-review GeoJSON/specification.md #73

Open PalmJanssen opened 5 years ago

PalmJanssen commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

michellutz commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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.