Additional properties in collections?

[m-mohr]

Looking at the record collection schema ( http://docs.ogc.org/DRAFTS/20-004.html#record-collection-schema ), I'm confused about how to add additional properties.

The "Table of collection properties" (Table 11) lists a properties field for "Additional catalogue-specific properties".

On the other hand, Permission 2 says:

• A collection object MAY contain any number of additional properties not listed in Table 11. The meaning of these additional properties is not defined in this standard.

I assume the "collection object" in Permission 2 is the (JSON) top-level object that also contains the type, id, title, license, ... properties.

Where to place additional properties? Top-level? In properties? STAC places them in the top-level, both fields that are in core STAC (e.g. assets), but also extensions (e.g. sci:doi from the scientific extension). Thus my preference it top-level, of course ;-)

[m-mohr]

Probably a related question that came up recently about Recommendation 17:

If the records can be represented for the intended use in GeoJSON, implementations SHOULD consider supporting GeoJSON as an encoding for records and catalogues (i.e. record collections).

How would a GeoJSON encoding or a record collection look like? Which properties are top-level, which are in properties? What's the relation between bbox in GeoJSON and extent (the spatial part in Collections)?

[pvretano]

@m-mohr my idea was to add additional collection properties to the "properties" section, like GeoJSON, and thus make the object describing the collection look like just another record. There seems to be a missing requirement that says the additional properties go into the "properties" section. Thinking about it now though I am not so thirlled about the idea so I think I'll remove that and just let extension properties be added to the top level.

Recomendation 17 only applies to records. Right now the specification does not say anything about the JSON encoding for a collection/catalogue or a folder. In PR #260 I renamed the GeoJSON conformance class to just JSON and added the JSON encoding for the missing pieces there.

Too many ourstading PR's! Need to merge a few soon!

[m-mohr]

Thanks, Peter.

With regard to Rec. 17A: It says:

If the records can be represented for the intended use in GeoJSON, implementations SHOULD consider supporting GeoJSON as an encoding for records and catalogues (i.e. record collections).

The bold text confuses me. What does that mean? It feels like it should be removed then.

[pvretano]

Hmm... that is not what I am seeing here: https://github.com/opengeospatial/ogcapi-records/blob/master/core/standard/recommendations/records-api/REC_json.adoc. B.T.W. One of the other pull requests extends this statement to include folders too.

[m-mohr]

I'm seeing it in the link?!