How can Clients dynamically determine the ID-Field of a collection?

[sebastianfrey]

Most recently, I've been working extensively with the OGC API Features and I noticed that there is no way for a web client to dynamically determine the ID column of a collection.

Consider the following scenario:

A Web-GIS-Client, which allows to browse OGC API Feature collections in a generic attribute table needs to retrieve a specific feature again to update the associated row.

Without any additional configuration or explicit knowledge about the underlying dataset, that client would not be able to re-fetch a feature by its id.

Therefore I would suggest to add a new property to the Collection interface. I can imagine a property like idColumn or idField:

{
   "title": "Collection of Features XYZ",
   "id": "xyz",
   "idField": "the_id_field",
   ....
}

I dont't know if the Queryables interface can be leveraged for this, but as I understand there is no way to mark a certain field as ID within a JSON schema.

What's your opinion on that matter?

[cportele]

The behavior depends on the feature encoding. For example, in a GeoJSON encoding the id member of the GeoJSON feature object is used.

So, if you access https://example.com/collections/buildings/items with Accept: application/geo+json you will get a GeoJSON feature collection. To directly access an individual feature get the value of the id member and fetch https://example.com/collections/buildings/items/{id}.

The id may also be encoded in the properties object, but this is not required.

For GML it is similar, the gml:id attribute is used.

For other encodings it will depend on the specification of the format.

Does that answer your question?

[sebastianfrey]

You're right, one might use the get feature by ID API endpoint. But let me ask the question another way:

How can I query multiple features by ID, using the filter query parameter, without having explicit knowledge about the name of the ID column.

Example query:

${ID_COLUMN} IN (1,2,...,n)

Without knowing what the name of ${ID_COLUMN} is, such querys can not be performed dynamically.

[cportele]

This is supported by Part 3, if the API declares a queryable for this.

General question to the group: Would it make sense to add a recommendation to define such a queryable with the name 'ID' (or 'id' or ?)?

[sebastianfrey]

Sure, such an ID field must be declared as queryable, to be accessible in filter expressions. The question then is, how such a field might be described by a JSON schema. As I understand in JSON schemas you cannot label a certain property as ID field. I know, there is the format parameter for uuid, but it has a different semantic than a plain ID field, and in addition it can only be leveraged on string types.

I know I'm not asked, but call it a community concern :-). IMO a labelled field with the name ID or id or whatever is not ideal from an implementation point of view. Records of data sets often are already labelled with a distinguished ID field. So that would require additional mapping for server implementations, to fullfil such convention. Therefore an additional property on the collection interface, might work out.

[jvanulde]

This is supported by Part 3, if the API declares a queryable for this.

General question to the group: Would it make sense to add a recommendation to define such a queryable with the name 'ID' (or 'id' or ?)?

Can it not be inferred through the IRI for an item in a given collection?

[cportele]

Meeting 2022-05-09: The ability to request features by identifier is a common practice, probably it would be better to have a separate query parameter (e.g. ids) like bbox, datetime to filter on the identifier. It should be a separate conformance class, not as part of Part 3. That is, it should be specified in a new part. The label was changed to "Future Work", proposals are welcome.

[sebastianfrey]

@cportele I see that the proposal has been accepted. I would be interested to know what exactly the next steps are? I am aware that this will take some time, I am just curious how exactly the process works. =)