use case for OGC API - Tiles

[tomkralidis]

As discussed at API SWG 2025-06-11, a valuable use case for OGC API - Tiles is fine grained tile generation based on events. This means if data represented in a tile is updated, send a notification to renegenate only the tile(s) associated to that data (vs. the entire data set).

cc @jerstlouis @ghobona

[jerstlouis]

@tomkralidis what do you mean by "send a notification to renegenate only the tile(s) associated to that data"?

That sure seems like the sensible thing to do, but what kind of event are we talking about triggering this?

I feel this is mostly related to the back-end implementation of the OGC API - Tiles service and has nothing to do with the API itself.

Whatever data the API - Tiles is serving, of course if the implementation becomes aware of a change then it should invalidate any affected cached tiles and re-create fresh tiles upon the next request.

So for example if the backend subscribes to a pub-sub service for updates to source data, or if a user updates the backend data using CRUD requests, such as for example uploading a new Scene using the planned OGC API - Coverages - Part 3: Scenes, all cached affected tiles are discarded and upon the next client request those tiles will be re-generated from the latest information.

Is there anything this is still missing?

[chris-little]

@jerstlouis We are trying to avoid users having to "poll" the server, even if it has the best behaviour that you describe. - safety critical info has to be pushed. Examples: Big road crash, lava flows, current or forecast flood inundation.

[jerstlouis]

@chris-little @tomkralidis Yes, it would make sense for both clients requesting these tiles and servers generating the tiles to subscribe for notifications to then re-generate / re-fetch the tiles. The notification would likely include the affected area.

But I think this all works mostly the same for any OGC API data access mechanism (Features, EDR, Coverages, Tiles, Maps, DGGS...)

[tomkralidis]

But I think this all works mostly the same for any OGC API data access mechanism (Features, EDR, Coverages, Tiles, Maps, DGGS...)

Agreed. The plan is to socialize the first pass specification across the various API SWGs for feedback on these and additional workflows.

[tomkralidis]

@jerstlouis we've implemented tile workflows as CloudEvents types as part of #15 (see https://github.com/opengeospatial/pubsub/blob/main/standard/requirements/message-payload-cloudevents-json/REQ_type.adoc).

(Note: once the document is put into the nightly DRAFTS autobuild I will reach out to the various OGC API SWGs for review).