OAPIF Queryables attribute title

GeoServer GeoServer User
1

When serving OGC API Feature Services the Queryables conformance class adds an endpoint collections/<id>/queryables, which lists all attributes that can be used for filtering the dataset. When accessing this resource as application/json+schema or application/yaml the properties array contains all attributes with their human-readable name as key and up to three members: title, type and format, that right now always seem to be set to the same value, i.e. the data type of the attribute (string, integer etc.).

  "properties": {
    "Object ID": {
      "title": "integer",
      "type": "integer"
    },
    "Short Name": {
      "title": "string",
      "type": "string",
      "format": "string"
    },
    "Long Name": {
      "title": "string",
      "type": "string",
      "format": "string"
    },
    ...
  }

Isn’t it more plausible to use the title-attribute for the human-readable name, and the technical name as the array key, e.g. like ldproxy does: https://demo.ldproxy.net/zoomstack/collections/roads_regional/queryables?f=json

  "properties": {
    "objectid": {
      "title": "Object ID",
      "type": "integer"
    },
    "shortname": {
      "title": "Short Name",
      "type": "string"
    },
    "longname": {
      "title": "Long Name",
      "type": "string"
    },
    ...
  }

Or is it already possible to access the title-attribute to serve human-readable names somehow? Is there a template file I can manipulate?

Sorry if this has been discussed before. And thanks for any help.

2

that indeed appears to be using the data type’s name as the title (below output from GeoServer 2.28.4), eg.

{
  "title": "begroeidterreindeel",
  "type": "object",
  "properties": {
    "identificatie": {
      "title": "string",
      "type": "string"
    },
    "lv_publicatiedatum": {
      "title": "DateTime",
      "type": "string",
      "format": "date-time"
    },
    "creationdate": {
      "title": "Date",
      "type": "string",
      "format": "date"
    },
    "tijdstipregistratie": {
      "title": "DateTime",
      "type": "string",
      "format": "date-time"
    },
    "eindregistratie": {
      "title": "DateTime",
      "type": "string",
      "format": "date-time"
    },
    "terminationdate": {
      "title": "Date",
      "type": "string",
      "format": "date"
    },
    "bronhouder": {
      "title": "string",
      "type": "string"
    },
    "inonderzoek": {
      "title": "boolean",
      "type": "boolean",
      "format": "boolean"
    },
    "relatievehoogteligging": {
      "title": "integer",
      "type": "integer"
    },
    "bgt_status": {
      "title": "string",
      "type": "string"
    },
    "plus_status": {
      "title": "string",
      "type": "string"
    },
    "plus_fysiekvoorkomen": {
      "title": "string",
      "type": "string"
    },
    "class": {
      "title": "string",
      "type": "string"
    },
    "begroeidterreindeeloptalud": {
      "title": "boolean",
      "type": "boolean",
      "format": "boolean"
    },
    "geom": {
      "title": "Any geometry",
      "format": "geometry-any"
    },
    "geom_kruinlijn": {
      "title": "Any geometry",
      "format": "geometry-any"
    }
  },
  "links": [
    {
      "href": "https://snapshot.tailormap.nl/geoserver/ogc/features/v1/collections/test:postgis_begroeidterreindeel/queryables?f=application%2Fschema%2Bjson",
      "rel": "self",
      "type": "application/schema+json",
      "title": "This document"
    },
    {
      "href": "https://snapshot.tailormap.nl/geoserver/ogc/features/v1/collections/test:postgis_begroeidterreindeel/queryables?f=application%2Fyaml",
      "rel": "alternate",
      "type": "application/yaml",
      "title": "This document as application/yaml"
    },
    {
      "href": "https://snapshot.tailormap.nl/geoserver/ogc/features/v1/collections/test:postgis_begroeidterreindeel/queryables?f=text%2Fhtml",
      "rel": "alternate",
      "type": "text/html",
      "title": "This document as text/html"
    }
  ],
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://snapshot.tailormap.nl/geoserver/ogc/features/v1/collections/test%3Apostgis_begroeidterreindeel/queryables"
}

from https://snapshot.tailormap.nl/geoserver/ogc/features/v1/collections/test:postgis_begroeidterreindeel/queryables?f=json

looking at the (draft) schema spec:

Each property SHOULD have a human readable title (“title”) and, where necessary for the understanding of the property, a description (“description”).

having the data type as title IMHO does not really conform to that, but atm it is AFAIK not possible to configure an “alias” to be used as a property title, so it would need to fall back to the property name

3

Hi,
it’s not a matter of templates, one needs to change some java code.

The class that needs to be modified is this one:

It should extract attribute descriptoins (and possibly restrictions too) in a way similar to how WFS DescribeFeatureType does it:

If you want to get this done, please see this guide:

Cheers
Andrea

4

While attributes don’t have a title, they can have a description (enable attribute customization):

image
image1451Ă—418 45.7 KB

If the user is careful to enter a short description, it could well work as a “title” too… The alternative is to add a proper title in there too, for OGC API usage (this is a larger modification) of course, but it would be better from a long term perspective, as one day the title might show up and the description would then have to used for the same named schema property.

Cheers
Andrea

1 Like