{StyleId} and partions as maps and as tiles.

[joanma747]

Assuming that {styleId} is a path parameter... In the current description of the spec we have:

First issue:
Lets imagine that we have this geospatial data resource (a collection):
/collections/{collectionId}/

You create a map by associating a style:
/collections/{collectionId}/map/{styleId}

The you can retrieve it as maps subsets or as tiles:

/collections/{collectionId}/map/{styleId}?crs=ccc&bbox=bbb&width=www&height=hhh
/collections/{collectionId}/map/{styleId}/tiles/{tilematrixsetId}/...

So, potentially, for each style you can have a different tileset configuration.

Second issue:
Lets imagine that we have a dataser resource (the root):
/

You create a map by associating a style:
/map/{styleId}

but what this styleID represents?. A single style name for all collections!!.

Now lest filter by geospatial data resources:
/map/{styleId}?geodata=buildings,roads

It is the same styleID but now applies only two collections?. How?

Third issue:
StyleID becomes mandatory in the path and cannot be replaced by a SLD file as a POST or as a URL to the style description. URLs cannot be a nice path parameter.

So, I'm not sure that I like the StyleID any more as a path parameter. If is is a query parameter it is easier to make it optional (and describe it in a separated conformance class that can replace it by other things in the future.

[joanma747]

The Tileset description will be linked from: /collections/{collectionId}/map
It is good to have StyleId as a path param to have static tiles with different styles.

[joanma747]

Having /map/{styleId} is more compatible with the styles API that had /styles/{styleId}

[joanma747]

It is still possible to send a SLD document to a POST to "/map" and return a URI template to a map and then you will be able to use bbox, width, height... This is possible define a conf. class with this. Or to send the SLD as a POST to /styles.

[jerstlouis]

Similarly you could POST to /map/tiles to get back a Tiles URL template to map tiles.

[joanma747]

For the dataset map:
/map/{styleId}
What collections are compatible with a style?
/map lists the styles. For each style we could have a list the collection supported as well as the list to the /styles/{styleId}

[jerstlouis]

I detailed what that advanced custom rendering conformance class by POSTing a style (or an RenderMap process execution document) could look like in #42.

[jerstlouis]

We have pretty much settled on /styles/{styleId}/map now, with future custom styling specified by the client discussed as potential extension in #42. Can we close this issue?

[joanma747]

Discussed and agreed that is the approach selected by the group in core. Decided in regular telco.