What are the lessons learnt from the Web Mapping Code Sprint?

[ghobona]

Please post the comments here

[tomkralidis]

Security/access control: the Eurogeographics WMS access token as applied in OGC API - Maps via pygeoapi brought forth questions about how cascading / broker services deal with secure services. As discussed with @doublebyte1 and others, it makes sense to have a sprint (or thread in same) focused on general security/access control issues, across OGC API and broader OGC standards.

[Youssef-Harby]

@tomkralidis I totally agree as I discussed this with @doublebyte1 and others, please can we have a direction of OGC standards with the security topics?
According to this: https://dive.pygeoapi.io/advanced/security-access-control/ not enough information to dive into. :)

[IvanSanchez]

I'm quite happy on how the mentor session for the Leaflet client for the Maps API turned out. Maybe there's a need to write down some impromptu recommendations as actual technical recommendations:

• Clients for API Maps should make a best effort to avoid making several requests in shorts periods of time (e.g. 1 second)
• Servers for API Maps can reply with HTTP code 429 Too Many Requests if a client is straining the server resources

I've also become interested in how HTTP content negotiation should work. I know about opengeospatial/ogcapi-tiles#142 , but I feel like there's room for improvement. I've written my thoughts on the matter (in a quite informal way) at https://ivan.sanchezortega.es/development/2022/11/02/ogcapi-content-negotiation.html

There's the question of how to enforce client-side ("proactive") content negotiation, since the OpenAPI/Swagger interface only allows to control the ?f= URL parameter and not the HTTP headers.

Maybe the APIs would benefit from a session focused on what can be done at the HTTP layer? That could also include caching and auth.

---

On a different note, I'm slightly worried about API Styles being overreaching in scope. In particular, about mandating a set of line joins/ends instead of having it as an optional conformal class. I'd also like to spend more time studying the implications of allowing for several UoMs (Units of Measurement).

[doublebyte1]

Mentor Stream

The code sprint featured two excellent tutorials on the mentor stream, which were both well attended. In addition, we organized some ad-hoc meetings for the mentor stream, providing some general orientation and ideas to work on projects. Perhaps it would be a good idea for future code sprints, to add an "orientation meeting" to the schedule, possibly in the first day?

[doublebyte1]

Feature Count

Many clients have the need to retrieve a feature count element from the server, in order to construct their visualizations. This leads them sometimes to issue two separate get items requests: one to count the items, and another one to actually draw them.

If this is a request which is traversal to many OGC APIs, perhaps one idea could be to add a get feature count request to common?

[doublebyte1]

Cancel Requests

When requesting tiles, and panning around, we often leave behind requests from tiles which are no longer in the viewport. This has a performance cost, as we are overloading the server with requests which are no longer needed. One way of handling this situation, would be to fire a cancel request, for tiles which are no longer in the viewport. @jerstlouis has an example implementation of this behaviour.

Perhaps this could be added as a best practice/recommendation for OCG API Tiles?

[doublebyte1]

QGIS and OGC APIs

It seems that QGIS already has support for OGC APIs, although the UI is not clear about this.

Maybe it could be an idea for a pilot/test bed to add better UI support for unleashing this functionality. It would be great to also add matching documentation and other educational materials (e.g.: blog post, video).

[IvanSanchez]

Feature Count

If this is a request which is traversal to many OGC APIs,[...]?

There's a parallel with Coverages: one of the use cases is fetching the coverage metadata (width, height, dimensions (2-3), bit depth, time dimension, number of channels/bands, native CRS) but not the data itself. That's how the pygeoapi viewer implementation works as of now.

For Tiles there's the TileMatrixSet definitions (AKA "tile pyramids"), which are metadata about tiles. So in a way this is already implemented.

[ghobona]

Thanks for the excellent feedback, everyone!

[jerstlouis]

We investigated the issues loading OGC API - Tiles and Maps into QGIS and it was caused by an issue with the GDAL OGC API driver not being up to date with the latest changes to the specifications, as described in
OSGeo/gdal#6832 .

[jerstlouis]

The Styles & Symbology team identified portrayal use cases and as a result new conformance classes or functionality that would be required to support these. More details in opengeospatial/cartographic-symbology#26 .