PB-2354: Add CF extension fields

[asteiner-swisstopo]

This adds CF extension fields cf:standard_names and unit to a STAC Item.

Example:

"properties": {
                ...
                "cf:standard_name": "air_temperature",
                "unit": "K",
            },

It follows the example of the forecast extension properties. So we add the fields to:

1. ... the model and the serializers, so it's available in the Item/Feature endpoints.
2. ... the admin UI.
3. ... the OpenAPI specs.

The more peculiar bits:

1. Add the fields to the POST /search endpoint. However, as for the forecast extension fields, they are excluded from the GET request because of the colon : character in the URL.
2. List the extension only if one of the two fields is present. For the forecast extension, this is only done for collection ch.meteoschweiz.ogd-forecasting-icon.
3. Add the fields to the e2e test input. Not strictly necessary as the fields are optional but I figured it makes sense to keep this example representative of the DB schema.

As discussed:

1. There is no additional validation like checking if cf:standard_name is from the CF Standard Name Table.
2. cf:cell_methods / description are left out on purpose.
3. As the list of properties in the OpenAPI specs is already quite long, we might want to group them by extension using the "Any of" feature. I propose we do this in the follow-up task PB-2355.

❓ To be clarified: In #653 a trigger update_collection_child_trigger_etag_only was added to update the ETag if a field changed. I am not familiar with how this works, Do I have to add another trigger for the new properties?

[boecklic]

Thanks a lot.
I'd generalize handling of extension, see comment below.

[asteiner-swisstopo]

On hold until this is merged: #658

[asteiner-swisstopo]

Finally adapted to the changes made in #658: Can you have another look please @boecklic?

To test manually:

1. Run the STAC API server: make setup && make serve

2. In the Django admin UI, add a token, here for example b5c95f9615d610635c88226d03344fee8ea2ea67.

3. Create a collection using that token:

   curl -X PUT \
     "http://127.0.0.1:8000/api/stac/v1/collections/cf-collection" \
     -H "Content-Type: application/json" \
     -H "Authorization: Token b5c95f9615d610635c88226d03344fee8ea2ea67" \
     -d '{
       "id": "cf-collection",
       "description": "A test collection",
       "license": "Test license"
     }'

4. Enable the CF extension in the Admin UI:
   

Then create a feature with the putFeature endpoint (:warning: declare the CF extension in stac_extensions!):

curl -X PUT \
  "http://127.0.0.1:8000/api/stac/v1/collections/cf-collection/items/cf-item-1" \
  -H "Content-Type: application/json" \
  -H "Authorization: Token b5c95f9615d610635c88226d03344fee8ea2ea67" \
  -d '{
    "id": "cf-item-1",
    "geometry": {
      "type": "Point",
      "coordinates": [8.5417, 47.3769]
    },
    "properties": {
        "created": "2018-02-12T23:20:50Z",
        "datetime": "2018-02-12T23:20:50Z",
        "updated": "2018-02-12T23:20:50Z",
        "title": "Feature title",
        "cf:standard_name": "air_temperature",
        "unit": "K"
    },
    "links": [],
    "stac_extensions": ["https://stac-extensions.github.io/cf/v1.0.0/schema.json"]
  }'

Which can also be retrieved through the POST /search endpoint as with the forecast:* properties:

curl -X POST \
  "http://127.0.0.1:8000/api/stac/v1/search" \
  -H "Content-Type: application/json" \
  -H "Authorization: Token b5c95f9615d610635c88226d03344fee8ea2ea67" \
  -d '{
    "cf:standard_name": "air_temperature"
  }'

[asteiner-swisstopo]

From offline discussion with @boecklic regarding POST /search:

Currently, to query /search for a field in properties, you need to send a payload like this

"query": {
    "title": {
       "eq": "CF Collection 1"
    }
}

For the other fields, you can just do

{
    "datetime": "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z"
}

This is in accordance with the query extension. However, currently "query" only accepts the following fields:

• title
• created
• updated

For the forecast:* properties, it works as for the other fields:

{
    "forecast:variable": "ALB_RAD"
}

But this is a bug! It should work like this:

"query": {
    "forecast:variable": {
       "eq": "ALB_RAD"
    }
}

So for the CF fields, we should do it correctly from the start: They need to be queried through the "query" field. We agreed to do that in the scope of this ticket.

Other possible follow-ups identified:

1. Also move the forecast:* properties into the "query" field for POST /search.
2. The /conformance endpoint does not list the query extension even though it is supported (albeit partly non-compliant).
3. The query extensions docs say "It is recommended to implement the Filter Extension instead of the Query Extension.": We might want to do that in the course of the transition to SWISSGEO.

[asteiner-swisstopo]

Update: To filter by a CF field, you need to go through the "query" parameter in the POST /search endpoint. For example:

"query": {
    "cf:standard_name": {
       "eq": "air_temperature"
    }
}

This is now also reflected in the OpenAPI docs:

⚠️ In the course of implementing this, I found a bug in the "query" parameter. It only takes into account the first field passed to it, the other are ignored. So, for example, here the "unit" field is ignored:

"query": {
    "cf:standard_name": {
       "eq": "air_temperature"
    },
    "unit": {
       "eq": "K"
    }
}

As agreed with @boecklic: We ignore this for the moment as POST /search does not seem to be used a lot. Instead, we fix this properly when moving service-stac to SWISSGEO by replacing the Query Extension with the Filter Extension. This is also what the Query extension recommends:

It is recommended to implement the Filter Extension instead of the Query Extension. Filter Extension is more well-defined, more expressive, and uses the standardized CQL2 query language instead of the proprietary language defined here. There is no plan to deprecate this extension, but it is also unlikely to see any further refinement or changes.

Impact on the geoadmin STAC Browser: Probably none - the Query Extension is not supported as far as I can see. The latest STAC Browser (not the geoadmin fork) is compatible with CQL, so I understand that it rather supports the Filter Extension instead of the (deprecated) Query Extension.

[boecklic]

🎉