jechterhoff
commented
1 year ago Good point. A solution is a bit tricky, though. On first glance, I would agree: if a feature type only has a single geometric property, then that should automatically be used as primary geometry, without having to tag it as jsonPrimaryGeometry = true.
The tricky cases are:
- If the value type of the single geometric property is a type whose JSON Schema implementation is incompatible with the ones allowed for the GeoJSON "geometry" member, this would not work.
- I guess that your proposal is referring to section 7.5.1 in order to cover this case. However, the requirement in section 7.5.1 should be read as
IF the value type of the geometric property is one of the types listed in the first column of table 9 THEN the according JSON Schema definition listed in the second column of that table shall be used. Application schemas are allowed to use other geometry types (for whatever reason; NOTE 1 below table 9 gives one). In such a case, a suitable mapping (to one of the GeoJSON geometry schema definitions) needs to be found. That means that the requirement in 7.5.4 should not be based upon the geometry types listed in section 7.5.1, table 9, afaics.
- I guess that your proposal is referring to section 7.5.1 in order to cover this case. However, the requirement in section 7.5.1 should be read as
- The single geometric property may be tagged with
jsonPrimaryPlace = true(see 7.7.3). Then the property shall be encoded within the JSON-FG "place" member, and likely not within the GeoJSON "geometry" member. However, whether or not to encode the property only in "place", but not in "geometry, is a key point! There can only be domain specific reasons for doing it one way or the other. One could argue that we could phrase the requirement in 7.5.4 in such a way that it takes tagjsonPrimaryPlaceinto account. I would prefer to avoid that, since that would create some kind of dependency from abstract requirements class /req/geojson-formats to requirements class /req/jsonfg, which we do not want (only the other way round).- However, when thinking this through, I see a way to modify the requirement in 7.5.4 by just using
jsonPrimaryGeometry. I kept the lengthy explanation in here to document the reasoning behind my proposal (see below).
- However, when thinking this through, I see a way to modify the requirement in 7.5.4 by just using
That is why we ended up with current phrasing, i.e., requiring explicit tagging of the UML property that is to be encoded within the GeoJSON "geometry" member.
I see two solutions:
- Give this explanation within a note in section 7.5.4, and state that a model transformation could be used to generate the tag
jsonPrimaryGeometry = truewhere appropriate (to be determined by the transformation logic). - Update the requirement in 7.5.4, as follows:
- Part A: If a UML property has tag "jsonPrimaryGeometry" with value equal to, ignoring case, "true", and the property is directly owned (i.e., not inherited) by a
<<FeatureType>>, then that property shall be encoded as the primary geometry of the feature type (see part C). - Part B: If the set of (direct and inherited, but ignoring redefined) UML properties of a
<<FeatureType>>only contains a single UML property with a geometric type (defined by ISO 19107:2003, i.e., having a name that starts with "GM_", or made known to be a geometric type by external means), and that property is directly owned by the feature type, and that property does NOT have tag "jsonPrimaryGeometry" with value equal to, ignoring case, "false", then that property shall be encoded as the primary geometry of the feature type (see part C). - Part C: In the JSON Schema definition of the
<<FeatureType>>, the primary geometry property shall be encoded as a type restriction for the top-level "geometry" member. The primary geometry property shall not be encoded within the "properties" member. - Part D: In instance data, the value of the primary geometry property shall be encoded within the (GeoJSON) top-level "geometry" member of the JSON object that represents the
<<FeatureType>>.
- Part A: If a UML property has tag "jsonPrimaryGeometry" with value equal to, ignoring case, "true", and the property is directly owned (i.e., not inherited) by a
Afaics, the second solution covers all cases - but please double-check, because the devil is in the details. In case of a single geometry property, where that property shall NOT be encoded within the GeoJSON "geometry" member for some reason (in both the GeoJSON and JSON-FG compliant encodings), it needs to be tagged with jsonPrimaryGeometry = false. Reasons include, but are not necessarily limited to:
- Incompatible geometry type
- Subtypes of the
<<FeatureType>>define their own primary geometry properties
In the application schema example in Annex B, we could then omit tag "jsonPrimaryGeometry" (the diagram note erroneously says "primaryGeometry") on feature type Parcel. We could also do that for feature type Building_Core, but it does not hurt to keep the tag there, since subtype BuildingPart has property extent3d, which is tagged with jsonPrimaryPlace = true. The explicit tagging makes it clear which property is the primary geometry and which is the primary place.
I'm open for further suggestions.
lvdbrink
It would be nice not to have to tag each geometry property with
primaryGeometry = trueif you have a UML model that only has classes with one geometry property (which is very often the case).I'm wondering if we could make a rule that says "a UML property that is owned by a
<<featureType>>and has as type one of the types from 7.5.1 and no sibling properties that also have one of these types shall be encoded as a type restriction for the top-level “geometry” member. "Or some other way of stating the rule in 7.5.4 only applies if a class has more than one geometry property.