Part 9: Simple text search to search multiple collections

[MichaelGordon]

I'm very supportive of the proposals for Part 6 to provide simple text search. I think it would be further improved if that could be slightly extended to support simple text search across multiple collections.

For Ordnance Survey's next generation data, exposed via an OGC API - Features implementation as well as via Geopackages etc, we organise our data into a series of collections - buildings, land use, addresses, transport networks etc.

It would be useful to be able to provide a single GIS compatible text search pattern which users can utilise across 1 or multiple collections. For example a user may wish to search for a name across roads, buildings and land and it would be useful if that was the same pattern with a simple GET as doing a text search just on buildings.

As for the actual API pattern this could look something like:

Standard single collection search: GET api.domain/ofa/collections/{collection}/items?q={text-search}

Multi collection search: GET api.domain/ofa/collections?q={text-search}

[cportele]

@MichaelGordon

You mention "Part 6", but I assume this is about Part 9 (Text Search). Part 6 is "Property Selection".

Multi collection search: GET api.domain/ofa/collections?q={text-search}

This does not work as the Collections resource cannot return Features, this would break the HTTP semantics.

The current plan is that Part 10 will define the /search resource for multi-collection queries. Part 10 will support POSTing a JSON query expression. See the original proposal or the Testbed-18 Engineering Report that has an updated API proposal.

What could be done in principle is to also support GET on that resource, that is, support something like api.domain/ofa/search?q={text-search}.

According to Part 10, GET on /search will return a list of stored queries. Supporting GET for executing queries would require that we move the stored query functionality to a different endpoint.

If we would support something like api.domain/ofa/search?q={text-search}, we should also allow other query parameters that can be applied to /collections/{collectionId}/items.

[MichaelGordon]

Hi @cportele - thanks for the reply.

I thought I hadn't quite got the semantics right this morning. Certainly what you propose would fulfil the need and I think provides a more understandable interface - if I do a GET on a /search resource I expect it to search rather than say what queries / searches can be done. As you point out however that would mean putting the stored queries in somewhere different.

[cportele]

Meeting 2024-07-15: We think that GET on /search with the generic query parameters (bbox, datetime, q, limit) is a good idea. It might be a good idea to move stored queries to another endpoint. We should use a future code sprint to work on the search extension.

[jerstlouis]

Perhaps @MichaelGordon 's use case could also work with hierarchical collections, where the parent collection contains all of the features of the children collections and can expose a regular /collections/{collectionId}/items end-point, but the individual children collections only contain their own items.