I have read the engineering report, and there are two use cases I would like to add. Not sure though if this is in scope of JSON-FG.
Use Case 1: Associate information to points of a geometry
All geometries are made up of points, surveyed in one or another way. They all have uncertainty, and its magnitude determines what the data can be used for. Sometimes it is possible for the feature itself to carry the information (i.e. we derive the uncertainty from the points), but this may be misleading or not useful, so sometimes it needs to be part of the points.
Example 1: Real properties (administrative units) are made up of surveyed points, connected to lines forming a polygon. The points are often also their own feature type (let’s call it “BorderPoint”) and the coordinates are shared by several real properties.
Users of data are mostly interested in the polygons, but the uncertainty of the individual points are important. The uncertainty is however carried by the BorderPoint feature. Since the uncertainty may vary greatly, associating the uncertainty to the real property feature is not really useful.
So in this example you want to associate uncertainty to the points of the polygon (to avoid exchanging duplicate information).
Example 2: You may also have other feature types, with geometries that should coincide with the real properties, or its border points. The geometry of real properties may be the base for planned land use, rights, nature reserves etc. These may have its own legally defined geometry and belong to a data set managed by someone else, so in case of a change in data, it may not be possible to update the geometries of all these features (for both technically and legally reasons). But there is still a value in knowing that the coordinates “should” be the same.
So in this example you want to reference a feature and say “I mean the position of this feature (a BorderPoint) in the real world, but I don’t manage it, so my coordinates may not be up-to-date.”
Use Case 2: LoD
I think that with the introduction of polyhedrons, there will also be a need for LoDs.
A standardized solution for this would be beneficial. And what I mean by that is the ability to say “this geometry is LoD 1, and that geometry is LoD 2”, and not that the levels itself should be standardized. That is up to the community to agree upon.
I have read the engineering report, and there are two use cases I would like to add. Not sure though if this is in scope of JSON-FG.
Use Case 1: Associate information to points of a geometry
All geometries are made up of points, surveyed in one or another way. They all have uncertainty, and its magnitude determines what the data can be used for. Sometimes it is possible for the feature itself to carry the information (i.e. we derive the uncertainty from the points), but this may be misleading or not useful, so sometimes it needs to be part of the points.
Example 1: Real properties (administrative units) are made up of surveyed points, connected to lines forming a polygon. The points are often also their own feature type (let’s call it “BorderPoint”) and the coordinates are shared by several real properties.
Users of data are mostly interested in the polygons, but the uncertainty of the individual points are important. The uncertainty is however carried by the BorderPoint feature. Since the uncertainty may vary greatly, associating the uncertainty to the real property feature is not really useful.
So in this example you want to associate uncertainty to the points of the polygon (to avoid exchanging duplicate information).
Example 2: You may also have other feature types, with geometries that should coincide with the real properties, or its border points. The geometry of real properties may be the base for planned land use, rights, nature reserves etc. These may have its own legally defined geometry and belong to a data set managed by someone else, so in case of a change in data, it may not be possible to update the geometries of all these features (for both technically and legally reasons). But there is still a value in knowing that the coordinates “should” be the same.
So in this example you want to reference a feature and say “I mean the position of this feature (a BorderPoint) in the real world, but I don’t manage it, so my coordinates may not be up-to-date.”
Use Case 2: LoD
I think that with the introduction of polyhedrons, there will also be a need for LoDs.
A standardized solution for this would be beneficial. And what I mean by that is the ability to say “this geometry is LoD 1, and that geometry is LoD 2”, and not that the levels itself should be standardized. That is up to the community to agree upon.