Feature Info queries in OGC API - Tiles and OGC API - Maps

[ghobona]

There is a need to include support for FeatureInfo-like queries in OGC API - Tiles and OGC API - Maps.

[ghobona]

@aaime and @pomakis mentioned during the 2021-05 sprint that they could build on existing code to implement a prototype.

The capability will be implemented in Extensions (Part n where n >1) for OGC API - Tiles and OGC API - Maps.

[pomakis]

The "OGC API - Maps" endpoint that makes the most sense for this is probably:

.../map/info/{pixelRow}/{pixelCol}

Templated links to such endpoints could exist in the same place that rel="map" links currently exist (including in the style resource as per #80).

One open question IMO is what should be returned for maps of coverages (or image sources in general). Perhaps a point feature indicating the measurement(s) at the specified pixel?

Here are a few query parameters that I think make sense to consider standardizing:

width, height and bbox (or whatever subset parameters are ultimately adopted for the map endpoints) - These is necessary so that the spatial extent and resolution of the map can be ascertained.

radius (default: server's discretion (suggest 4px?)) - But is this a search radius to the actual feature data (e.g., the infinitely thin lines or infinitely small points), or to the rendered images of the features (e.g., multi-pixel-thick lines or icons)? The latter makes more sense but is more difficult to implement. Hmmm, perhaps it'd be easier all around if we didn't have this parameter and just left such logic to the discretion of the server (allowing them to have a vendor-specific parameter if they like of course).

maxFeatures (default: 1) - The maximum number of features to return. Sometimes the client may be interested in just one, and sometimes it may be interested in a few. But it certainly wouldn't want to get a million features back. I suspect there are those who would want a paged response here in the case of a lot of features, but I personally think that'd be overkill for this endpoint.

getGeometries (boolean; default: true?) - If the point of making the request is to simply show a pop-up of the attribute/value pairs of the feature(s) at the clicked-on pixel, there's no need to include a vector feature in the response.

simplifyGeometries (boolean; default: true) - If the client application wants to highlight the clicked-on feature on the map, it only needs the vector data at the resolution of the current map image. Returning a million-point vector just to plot it into 20 pixels on the screen would be hugely wasteful. Given the known spatial extent and resolution of the map being queried, an info request could return geometries that are simplified to exactly the appropriate level of detail.

If {pixelRow} and/or {pixelCol} out of bounds for the specified map, I think the server should be free to either return 404 Not Found or a valid result (as if the map extended to the specified pixel).

[pomakis]

As for an "OGC API - Tiles" info endpoint, perhaps it could be

.../{tileMatrix}/{tileRow}/{tileCol}/info/{pixelRow}/{pixelCol}

Note that isn't specific to maps; it could just as easily be for coverage or vector tiles.

It wouldn't need the width, height or bbox query parameters, but otherwise would share the same query parameters as the "OGC API - Maps" info endpoint.

[jerstlouis]

Because of how well the OGC API access mechanisms are integrated with Common collections, most of the use cases for the info queries can be addressed by OGC API - Features or OGC API - Coverages (or EDR) for the same collection.

I thought we have agreed that this would at least not be in Part 1: Core for Maps, so suggesting to move this to Extensions.

However, I see that the "Scope" still includes:

• Query operations that allow a client application to retrieve data (e.g. feature attributes) at a point on a map

We at least we need to remove that from the Scope of Part 1 first.

[aaime]

I don't understand how Features and Coverages can truly replace a GetFeatureInfo.

The classic GetFeatureInfo reports information about the pixel the user clicked on, whose contents depend heavily on styling, considering various aspects including scale dependencies, filters embedded in the style, symbology size and, for strict implementations, symbology shape (if the symbol has holes or is asymmetric, the user might have clicked closed to a point, but not on the symbol representing it).

Are you saying a client should perform a full style interpretation in order to build a matching query to OGC API Features? The latter might not even provide CQL, so performing the same filtering happening in the style might not even be possible (let alone considering the effects of symbology).

[jerstlouis]

@aaime

I understand Features doesn't really handle the case of picking symbols, and that would be a good use case for a GetFeatureInfo extension. However, I think that's also quite inefficient, involving server round-trip on every movement of the mouse cursor, and in general, I think a lot of styling / rendering is moving and should be moving towards client-side rendering requiring less data transfer and facilitating switching rendering styles, with ubiquitous GPUs even on mobile devices and WebGL. Of course OGC API - Maps is still largely focused on server-side rendering, so an extension for this would make sense, but still my own opinion is that it does not need to be in Part 1: Core. For servers supporting complex rendering rules, it would make sense to also support filtering e.g., with CQL2 as well in a Features access mechanism.

[joanma747]

Task A:
Done in #98

Task B:
Actually offer an GetFeatureInfo functionality directly as a path. This will be "part 2". @pomakis suggested some interesting additional parameters.
I would like to have common output defined. It could be a geojson. In the case of coverages we can have a point with properties representing the values in all the fields (range types). Geojson can be used for small coverages represented a a point grid (or point cloud).