Closed lvdbrink closed 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 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.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 tag jsonPrimaryPlace
into 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).
jsonPrimaryGeometry
. I kept the lengthy explanation in here to document the reasoning behind my proposal (see below).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:
jsonPrimaryGeometry = true
where appropriate (to be determined by the transformation logic).<<FeatureType>>
, then that property shall be encoded as the primary geometry of the feature type (see part C). <<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).<<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.<<FeatureType>>
.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:
<<FeatureType>>
define their own primary geometry propertiesIn 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.
Part B: If the set of (direct and inherited, but ignoring redefined) UML properties of a <
> 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).
The only question I have is: what if the property is of type GM_Solid
or some other 19107 type that is not supported by GeoJSON?
But then again, we are not checking that in the current 7.5.4 A, either. My feeling is it's up to the model owner to make sure only geometries that GeoJSON supports end up as primary geometry, and to tag others with jsonPrimaryGeometry = false
.
@lvdbrink: Yes, your feeling is correct: It is up to the model owner to make sure only geometries that GeoJSON supports end up as primary geometry, and to tag others with jsonPrimaryGeometry = false.
Decision: Update the requirement as proposed, and in part B of the solution
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 (as defined in section 7.4.1), 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).
It would be nice not to have to tag each geometry property with
primaryGeometry = true
if 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.