Generalization ...

[pvretano]

From the JUN 2021 TC, there was discussion about generalization. The point was raised that this, in the features SWG, is a function of the API (i.e. the generalization/simplification task). Also discussion about how the generalization level is communicated ... in the payload (i.e. the JSON-FG) or a header.

[cportele]

Having a key that declares the "zoom level", if there has been processing involved, for example, by an API implementing OGC API Features, would make sense.

Another Content header sounds reasonable, too, but that would be defined by the Features API SWG.

[hylkevds]

The "zoom level" seems very situational, and difficult to translate between different use cases.
Eurostat uses a more traditional "scale" for their datasets, see this example
A demo of this data set, with different scales, is here, in the layer tree you can choose the nuts level and scale you like.

It would be really nice to have some guidelines on how to register/expose this scale/zoomlevel/resolution in a data set.

[pvretano]

@hylkevds I am not in favor of a parameter named "zoom" either because that is meaningless without some additional metadata defining the zoom level. I would prefer something like resolution (or resX, resY) that is simple to compute on the fly using the number of pixels and the extent.

[cportele]

I used "zoom level" as a placeholder for whatever mechanism (scale denominator, resolution, some level of detail, etc). They all have their problems so there is no silver bullet and we would have to pick one.

Personally, I have a preference to a zoom level based on the WebMercatorQuad/Google Maps tiling scheme, because this is in broad use in web mapping and I think more intuitive for most than the scale denominators or resolutions from the paper maps (and easy to convert if you make some assumptions on the display).

In any case, my main comment on this aspect is to avoid the approach of the Tile Matrix Set standard that now requires that all values are provided : scale denominator, cell size plus the tile matrix level. I think we should pick just one ("we" = in Features and in JSON-FG, if we decide to add such an indicator).

[cportele]

Meeting 2022-01-24:

• In general, such information could be useful, but maybe it is more about a best practice, because it is tricky to get this right for everyone. LoD and scale / zoom level are somewhat overlapping, but different. Maybe we need more experience with this and we should leave this out of draft.1?
• When data is simplified to reduce the data volume, it is valuable to state this somehow in the JSON document. What metadata would we need to include in the document to make it useful (in addition to zoom level/scale). For example, what other zoom levels are available for the data (e.g. from an API that supports the future OGC API Features extension)?
• We will continue to work on this - also in the context of the work on OGC APIs, to be consistent. For now we will not include it in the JSON-FG draft, but if the stabilizes we will consider inclusion in Part 1.

[cportele]

Meeting 2022-03-07: Wait with this topic until the Features API SWG has a draft of the Geometry Simplification part.