Introduce separation of map concerns from render

[emmanuelmathot]

Establish a clear distinction between mapping, styling, and data source concerns in the rendering process. This proposal aims to refine the scope of rendering to focus solely on pixel transformations while introducing a new mechanism for handling map-specific constraints. The changes will enhance clarity and usability in the integration of mapping resources.

[vincentsarago]

technically I thing we would follow the same way as the vector

{
  "rel": "map",
  "href": "https://tiles.example.com/tiles/{tileMatrixSetId}/{z}/{x}/{y}.png",
  "type": "image/png",
  "title": "True color map",
  "render": "true-color",
  "minzoom": 8,
  "maxzoom": 14,
}

using /tiles/{tileMatrixSetId} follows the OGC Tiles spec

[m-mohr]

Actually, templated links would go into linKTemplates, not links in the future of web-map-links.

[m-mohr]

Thanks @emmanuelmathot, this is very close to what I've been sketching. I agree with:

• the three-way split into data sources, styling and maps, and a new stac-extensions/maps repository
• keeping render to pixel transformation and moving zoom/tile matrix set constraints out of it
• aligning with OGC API – Styles (rel=stylesheet) and OGC API – Maps
• reusing the render cross-reference on links
• looking at tiled-assets instead of reinventing tile matrix set limits

Where I'd suggest a different shape is what a "map" is. A rel: map link with one source, one style and zoom limits is effectively a web map link: the raster example is an XYZ link with render. The generic rel also loses the protocol (XYZ, WMTS, OGC API – Tiles). So I'd propose:

• web-map-links gets OGC API – Maps and OGC API – Tiles as service types. Tile links carry the tile matrix set and zoom range per TMS. Templated URLs move to link-templates.
• maps is a composition: a projection, a default extent, and layers ordered bottom to top. Each layer has one source (an asset, a web map link or a render) and optionally a style (a stylesheet link or a render). The single-link case in this PR is then just a map with one layer. It also covers things rel: map can't, such as a COG rendered client-side, GeoParquet with a stylesheet, several layers together (Add a property to define the (default) map visualization? #22), or a basemap under the data.
• render may keep an optional visibility range for client-side rendering, where there are no tiles. I think it could be CRS-independent: ground meters per pixel at the layer's centre, which clients convert for their CRS.

I'm happy to follow up in more detail together with maps v1 and web-map-links v2 proposals.

[emmanuelmathot]

Thx for the review. I integrated most of your remarks. Two things:

render keeping any resolution/visibility range for the client-side/no-tile-server case. That case is already a maps document with one layer and no TMS, so a dedicated field on render would just duplicate what maps would already cover, and would reopen the discussion on the resolution etc...

Reusing tiled-assets I referenced it earlier as prior art, but after actually checking it, I don't think it composes with what we're building here. Per its own README, its only defined purpose is to feed the {TileMatrixSet} placeholder inside asset_templates. it's solving asset tiling limits as only.

Please give another look so we can start the maps extension on a common ground.

[m-mohr]

Thanks @emmanuelmathot, agreed on both points.

I've opened two PRs with what I already had from fiddling with it before you opened this PR. Both are still early drafts and I'm still working on them. Everything is open for discussion ;-)

• maps: Proposal for maps extension maps#1
• web-map-links v2: First draft for v2 web-map-links#31