Extensions

[rob-metalinkage]

Good to see some formalism here.

in the description it references "extensibility". At first reading I don't see any guidance as to handle extensibility.

Presumably there are three cases (at least) of interest that relate to this schema:

1. extending the schema to be applied to the use Overture data in a local application context with additional properties
2. ingesting data from external schemas aligned to the Overture (e.g. exposing an application schema that conforms to the Overture model and includes other properties relevant to the source) (inverse of first case in terms of transaction direction)
3. describing a mapping from another schema to equivalents

#3 is more complex and we can discuss that separately if needed, but an example would be very helpful:

An example of extensibility challenges is the use of GeoJSON - which does not seem to allow its geometry classes to be extended, and is hence not useful for describing either topology of objects or 3D versions of buildings.

As an exercise, how could the Overture schema be extended to support 3D buildings with, say, floor space areas and volumes?

[vcschapp]

Hi Rob! Thanks for engaging, we absolutely appreciate the feedback.

There's actually quite a lot packed into your comments - and I'm not sure if I'll be able to do it all justice, but let me try to hit on a few points.

All my comments should be taken with the caveat that the schema is still in an early draft form, and it may change quite dramatically, hopefully taking feedback like yours into account.

• Extension. With to extension in general, we're at a pretty early stage here and I don't think it has yet gotten the attention it deserves even in terms of thinking through what kinds of extension we can allow.
  • For the time being the only extensibility built into the schema is the ability to specify arbitrary extension (ext*) properties as top-level properties. This design goes to your first case of interest, but the design might be incomplete in the sense that we currently don't support extension properties within "nested" properties. We'd be interested to hear your thoughts on whether this is interesting.
• GeoJSON.
  • We are viewing GeoJSON as a "mental model" or "canonical format" and but not likely as a final distribution format. However, our plan is most likely to release the data in one or more widely-supported geospatial formats that are "conversion compatible" with GeoJSON.
  • There are trade-offs between formats which natively capture topology and those that don't. (We also have a separate internal discussion about non-geometric referential integrity between features. Again, there are trade-offs.) Our current thinking is that our data output is probably most broadly usable consumable as simple features that contain all the information needed to reconstruct topology. (e.g. the transportation theme segment and connectors paradigm).
  • We'd like to hear more about the standard data format or data formats you are most interested in, and why.
• 3D.
  • Taking 3D as a separate topic, our current line of thinking is that the initial themes will be 2D data that would provide an anchoring base layer for subsequently-released 3D data.
  • We're leaving open exactly how and when we would bring on new 3D layers, possibly with their own schemas.
  • Coming back to GeoJSON for a moment, my understanding is that the format is capable of a third dimension, as the definition of a GeoJSON position supports a third dimension and this is supported at in the format's JSON Schema (which is actually more permissive). geojson.io also allows a third dimension. Theoretically at least the "mental model" shouldn't break if someone chooses to extend the existing schema into a third dimension...

[rob-metalinkage]

Thanks

I've been experimenting on this pattern to allow for simple GeoJSON or the proposed OGC "FG-JSON" which is extensible..

 "anyOf": [
    {
      "$ref": "https://opengeospatial.github.io/bblocks/annotated-schemas/geo/json-fg/featureCollection/schema.json"
    },
    {
      "$ref": "https://geojson.org/schema/FeatureCollection.json"
    }
  ],

and this pattern (below) to separate the properties from the GeoJSON container model - allowing them to be reused directly:

note that this allows for:

• datatyping enforcement using FG-JSON
• extension and inheritance by extending the properties objects

any feedback welcome - this is the best idea I can see so far but anything more elegant would be cool (and any flaws gratefully acknowledged.

in YAML for "brevity" :-)

SurveyPoint:
    allOf:
    - anyOf:
      - $ref: https://opengeospatial.github.io/bblocks/annotated-schemas/geo/json-fg/featureCollection/schema.json
      - $ref: https://geojson.org/schema/FeatureCollection.json
    - type: object
      properties:
        featureType:
          const: SurveyPoint
          x-jsonld-id: https://icsm.org/csdm/Type
          x-jsonld-type: '@id'
        properties:
          $ref: '#/$defs/SurveyPointProperties'
          x-jsonld-id: https://purl.org/geojson/vocab#properties
    required:
    - featureType
  SurveyPointProperties:
    type: object
    properties:
      name:
        $ref: ../../datatypes/compoundName/schema.json
        x-jsonld-id: https://icsm.org/csdm/commonpatternsname
        x-jsonld-type: '@id'
  SurveyMark:
    allOf:
    - type: object
      properties:
        featureType:
          const: SurveyMark
          x-jsonld-id: https://icsm.org/csdm/Type
          x-jsonld-type: '@id'
        properties:
          $ref: '#/$defs/SurveyMarkProperties'
          x-jsonld-id: https://purl.org/geojson/vocab#properties
      required:
      - monumentedBy
  SurveyMarkProperties:
    type: object
    properties:
      allOf:
        $ref: '#/$defs/SurveyPointProperties'
      monumentedBy:
        $ref: '#/$defs/Monument'
    required:
    - monumentedBy