search

SDFIdk / skraafoto_stac_public

Other
6 stars 1 forks source link

Implementation of CQL-TEXT encoding for filtering #43

Closed fhyttel closed 2 years ago

fhyttel commented 2 years ago

As per OGC recommendation 2, "[i]f a filter expression can be represented for its intended use as text, servers SHOULD consider supporting the CQL-TEXT encoding" [in addition to CQL-JSON].

This would be very useful for endpoints not (currently) supporting POST-requests.

AsgerPetersen commented 2 years ago

Hi @fhyttel

Thank you for reaching out.

It is possible that we may add support for CQL-TEXT in the future, but for now there are no plans.

If I understand you correctly you may solve your problem by using the same CQL-JSON filter for GET requests as you would do in POST requests. Obviously it needs to be URL encoded for GET.

Consider this POST request (token left out):

POST https://api.dataforsyningen.dk/skraafotoapi_test/search
Content-Type: application/json

{
    "filter": { 
        "intersects": [
            { "property": "geometry" },
            {
                "type": "Polygon",
                "coordinates": [[
                [721250.0000012278, 6190390.000002561], [721244.0000012267, 6191220.000002562],
                [722491.0000012581, 6191080.000002566], [722493.0000012588, 6190540.000002567],
                [721250.0000012278, 6190390.000002561]
                ]]
            }
        ]
    },
  "filter-crs": "http://www.opengis.net/def/crs/EPSG/0/25832",
  "crs": "http://www.opengis.net/def/crs/EPSG/0/25832"     
}

The exact same request as GET (token left out):

GET https://api.dataforsyningen.dk/skraafotoapi_test/search?filter-crs=http%3A%2F%2Fwww.opengis.net%2Fdef%2Fcrs%2FEPSG%2F0%2F25832&crs=http%3A%2F%2Fwww.opengis.net%2Fdef%2Fcrs%2FEPSG%2F0%2F25832&filter=%7B%22intersects%22%3A%20%5B%7B%20%22property%22%3A%20%22geometry%22%20%7D%2C%7B%22type%22%3A%20%22Polygon%22%2C%22coordinates%22%3A%20%5B%5B%5B721250.0000012278%2C%206190390.000002561%5D%2C%20%5B721244.0000012267%2C%206191220.000002562%5D%2C%5B722491.0000012581%2C%206191080.000002566%5D%2C%20%5B722493.0000012588%2C%206190540.000002567%5D%2C%5B721250.0000012278%2C%206190390.000002561%5D%5D%5D%7D%5D%7D
fhyttel commented 2 years ago

Thank you for the extensive reply.

No argument there, JSON certainly does the job - but the concise, made-for-GET text-encoding would do it slightly more elegantly.

Either way, well done on the solution - I look forward to the public launch!