Thanks @maxcollombin !

A few questions / suggestions:

• Is this 2DTMS already in use by Swiss Topo?
• The orderedAxes should probably say E,N rather than X,Y because those are the axes abbreviations in the CRS
• Could we perhaps name it something more descriptive than Swiss2DTMS? How about something like SwissLV95CellSizes, to highlight the projection and the fact that the levels have been chosen based on round cellSizes (as opposed to round scale denominators, or a quad tree division)?

Thanks for your review @jerstlouis!

As far as I know, this 2DTMS is not yet used by swisstopo, but it will soon be included in the eCH-0056 standard once it has been finalised.
I agree with your proposal for the orderedAxes, but I'd like to let @p1d1d1 confirm as for the name of the TMS.

We also wondered whether the ScaleDenominators should be rounded or not (e.g 14285714.0 or 14285714.285714284 for <tmsc:Identifier>0</tmsc:Identifier>).

@maxcollombin Only one of the scaleDenonimators or the cellSize can be rounded -- one (either of them) is derived from the other. You should keep all the decimal digits for the scale denominators.

These days, with the focus on Web mapping, most of the preferred 2DTMSs use quad trees, and neither of them is rounded in this case.

For example (all geographic CRS in this case):

https://maps.gnosis.earth/ogcapi/tileMatrixSets/GlobalCRS84Pixel -- this uses round cellSizes like this one
https://maps.gnosis.earth/ogcapi/tileMatrixSets/GlobalCRS84Scale -- this uses round scales
https://maps.gnosis.earth/ogcapi/tileMatrixSets/WorldCRS84Quad -- this is a quad tree (round 2.0 multiplier between levels)

Use of GlobalCRS84Pixel or GlobalCRS84Scale is a lot more rare (at least for Web mapping).

For cartographic products there might still be value in rounded scales and/or cell sizes.
This is why having a more descriptive names would make it easier to register e.g., a SwissLV95Quad which may work better for web mapping applications.

@jerstlouis @maxcollombin this TMS is to some extent used in the current WMTS of the Swiss Federal SDI. With the new version of the eCH-0056 Standard we want to standardize it for all tiling services in LV95 (EPSG:2056). The levels in the TMS are not always in the power of 2, therefore "SwissLV95CellSizes" as suggested by @jerstlouis would make sense as name.... and yes, the axes order should be E,N.
@maxcollombin could you please adapt your pull request?

@maxcollombin It is the default and the field is not required, but you might want to add to each TileMatrix:

"cornerOfOrigin" : "topLeft"

just for clarity, since with 2DTMS 2.0 the corner could also be bottomLeft instead.

@jerstlouis , do you mean something like:

{
   "id": "0",
   "scaleDenominator": 14285714.285714284,
   "cellSize": 4000,
   "cornerOfOrigin": "topLeft",
   "pointOfOrigin": [2419995.75, 1350004.29],
   "tileWidth": 256,
   "tileHeight": 256,
   "matrixWidth": 1,
   "matrixHeight": 1
}

for the json definition and

<TileMatrix>
   <tmsc:Identifier>0</tmsc:Identifier>
   <ScaleDenominator>14285714.285714284</ScaleDenominator>
   <CellSize>4000</CellSize>
   <CornerOfOrigin>TopLeft</CornerOfOrigin>
   <PointOfOrigin>2419995.75 1350004.29</PointOfOrigin>
   <TileWidth>256</TileWidth>
   <TileHeight>256</TileHeight>
   <MatrixWidth>1</MatrixWidth>
   <MatrixHeight>1</MatrixHeight>
</TileMatrix>

for the xml definition?

That way I can adapt the PR.

By the way, should the cornerOfOrigin/CornerOfOrigin of all 2DTMS in the registry be set to topLeft/ TopLeft?
Would you like a hand with that?

do you mean something like:

Yes, exactly.

By the way, should the cornerOfOrigin/CornerOfOrigin of all 2DTMS in the registry be set to topLeft/ TopLeft?

Probably.

Would you like a hand with that?

Sure, thank you :) But it's not really important, since that is the default anyways.

@p1d1d1 @maxcollombin

this TMS is to some extent used in the current WMTS of the Swiss Federal SDI.

Would you please have a link to that WMTS? That would help reviewing/validating the 2DTMS and testing it in client implementations.

@jerstlouis the wmts can get accessed here.

It is worth mentionning that it defines 29 different tilematrices (cf L18267-L18531) although we wanted to specify only 16 mandatory tilematrices in the SwissLV95CellSizes 2DTMS. Other levels can be added but are optional.

Here is the detail of the calculation:

cell_sizes = [4000, 2000, 1000, 500, 250, 100, 50, 20, 10, 5, 2.5, 1, 0.5, 0.25, 0.1, 0.05]
tile_width = 256
tile_height = 256
bbox = [2419995.7488073637, 1030006.663199476, 2900009.727428728, 1350004.292478851]
point_of_origin = [round(bbox[0], 2), round(bbox[3], 2)]
scale_denominator = [round(cell_size / (0.28 * 10**-3), 0) for cell_size in cell_sizes]
matrix_width = [round((bbox[2] - bbox[0]) / (cell_size * tile_width), 0) for cell_size in cell_sizes]
matrix_height = [round((bbox[3] - bbox[1]) / (cell_size * tile_height), 0) for cell_size in cell_sizes]

Thanks @maxcollombin , that is very useful. Looking at this, the point of origin should probably have more than 2 decimals -- otherwise you only have centimeter accuracy. Probably that should be the same number of decimals as the bbox?

I imagine you remove that round() for the scale_denominator in the latest version?

Regarding the additional 13 tile matrices, if there are plans to ever use them, I would include them as well in the 2DTMS definition. When the 2DTMS follow a regular pattern like a quad-tree, you only need to include a few levels and the 2DTMS can easily be extended as needed. But in this case since the pattern is not regular, there would be no way to extend it consistently.

All tile matrices of a 2DTMS are always optional -- any contiguous set of tile matrices can be selected. A particular dataset deployment can advertise in the TileMatrix Limits (which is now part of the tileset metadata with 2DTMS 2.0) which zoom levels are available.

The recommendation for any deployment is always to support up to the resolution / scale supported by the dataset, and to include all tile matrices up to the coarsest ones (it makes it easier to find find the data when it doesn't disappear when zoomed out, and the overhead for the smaller overviews is tiny).

So the 2DTMS have been adapted to contain the tileMatrices with the following cellSizes: 4000, 3750, 3500, 3250, 3000, 2750, 2500, 2250, 2000, 1750, 1500, 1250, 1000, 750, 650, 500, 250, 100, 50, 20, 10, 5, 2.5, 2, 1.5, 1, 0.5, 0.25, 0.1, 0.05.

Thanks @maxcollombin .

I noticed a few things:

• You changed the URI to http://www.opengis.net/def/tilematrixset/OGC/1.0/cellSize -- that should match what it gets registered to e.g., SwissLV95CellSizes
• You also changed the id -- that could technically be anything, but for the registry should also match that
• You changed the TileMatrices to numbers rather than strings. They should be strings (a TileMatrix identifier most often is, but is not required to be, a number)

@jerstlouis some recursive change errors, sorry.😣

It should be fixed now.

@maxcollombin please wait a bit. We cannot add any additional tile matrix to those defined in the standard. You need to revert this back.... and as suggested by @jerstlouis remove the rounding of the point of origin coordinates

@jerstlouis , @p1d1d1

I've reversed the last 2 commits because for internal reasons we don't want to define additional matrices.
@jerstlouis would that be possible to publish two different 2DTMS? One with the limited tilematrices and one with them all (e.g. SwissLV95CellSizesExtended)?

What do you think of it @p1d1d1?

Also, do we really need to define the point of origin with all its decimal places? It doesn't play a part in matrix calculations...

@maxcollombin

Also, do we really need to define the point of origin with all its decimal places?

Yes!

It doesn't play a part in matrix calculations...

That's not correct. It DOES play a part in matrix calculations. That is what determines the position of the tiles.

would that be possible to publish two different 2DTMS?

That would be possible but I don't see why?

As I mentioned, all tile matrices are always optional.
The Limits can list the tile matrices that are supported.
If you want to register one 2DTMS that only contains a subset of the other, I would say just register the one with all of them.
You could add a note / recommendation about which ones should be supported if you don't want to support them all.

Looking at all the cell sizes with a 1.0833 factor between 3000 and 3250 etc. though, I do understand why you would not want to include them all.

It really depends how often the intermediate ones get used.

What is the main purpose of this 2DTMS? Is it for Web mapping, or for printed cartographic products / repository with data sources at specific cell sizes?

If it is mainly intended for Web mapping, I suggest to define a SwissLV95Quad 2DTMS instead and go for a simple and consistent 2x between tile matrices.

@jerstlouis

As mentioned in the following comment, the point of origin is not included in the calculation, but the coordinates of the bbox are.

But I'll update once we've agreed on the tile matrices to use.

The purpose of this 2DTMS is mainly for web mapping and secondarily for printing, but its definition is linked to historical reasons (i.e. printed national maps).

I'll let @p1d1d1 answer you about the final decision and I'll make the adaptations accordingly.

@maxcollombin

As mentioned in the following #93 (comment), the point of origin is not included in the calculation, but the coordinates of the bbox are.

That is in your calculations to compute the matrix width and height (the number of tiles across each dimension), but producers and consumers of tiles in that 2DTMS will rely on the pointOfOrigin to georeference data, so it needs to be as accurate as possible. Considering you used a bounding box with greater precision to set up the 2DTMS, it is not correct to round it (but of course the error is only 1cm).

The purpose of this 2DTMS is mainly for web mapping and secondarily for printing, but its definition is linked to historical reasons (i.e. printed national maps).

It might be worth considering whether the Web mapping use cases would be better suited by a SwissLV95Quad.

@jerstlouis many thanks for the many inputs you're providing here.
@maxcollombin thanks for your support. Could you please put this on standby? We need to better analyse and understand all details before continuing this process.

I've just stagged this PR as WIP (draft).