Create the diagram representing tiles in columns.

[joanma747]

To introduce more dimensions we can think on 3 levels: 1.- Columns on top of a 2dTles (CDB uses this) 2.- Columns divided in "blocks" on topo fo 2d tiles that will be described by a 3Dtilematrix 3.- Columns that changes the number of divisions in the same way as the 2D in each scale change (and consider this also more dimensions for time and ...)

Jerome's version.

1. Extend in other dimension; Use TMS as is, reduce content with level
2. Add slices in other dimension (but overviews still based only on other dimensions)
3. Change the number of slices in other dimension as well at lower levels (turning into octree or hyperoctree) hexadecitree

We could to add a comment on the relation with 3DTiles and what they do with their "boxes"

[joanma747]

[joanma747]

Let's generate a better diagram for the 3 cases:

This diagrams need an explanation because the representation of the xy dimension varies in size (scale) in the diagram but the z direction does not. But I believe this "trick" is actually good to communicate the idea.

Case 1: 1.- Columns on top of a 2dTles (CDB uses this) (Extend in other dimension; Use TMS as is, reduce content with level)

Case 2: Add slices in other dimension (but overviews still based only on other dimensions)

Case 3: Change the number of slices in other dimension as well at lower levels (turning into octree or hyperoctree) hexadecitree

Can I suggest to use tileWidth, tileHeight tileElevation tileTime... tileExtraDim1... for the names of an nD model? In the document, we could give some clues on how to extend the model and encodings to add extra dimensions without actually doing it. A possibility is to have a an annex to discuss a nD extension.

[jerstlouis]

@joanma747 Awesome diagrams!!! Thank you!

Actually I think we may not need to specify tile* at all for the extra dimensions, since those are strictly concerned with the resolution of the data from a 2D map perspective, not the tiling / division. Actually, I was discussing with Carl about that yesterday (in the context of drafting the CDB X specifications and referencing TMS), and we could potentially split the concepts of tiling and resolution/scale/Level of Detail in TMS: e.g. you could instantiate the GNOSISGlobalGrid with 256 tileMatrixWidth x 256 tileMatrixHeight, but the exact same tiling could be used with 512 tileMatrixWidth x 512 tileMatrixHeight (see #29).

I think there are better ways to define the vertical or temporal (or other kind of dimension) resolution than specifying a number of pixels, in fact it would make very little sense for temporal.

What we should define though is the lower/upper bound for the whole range, and into how many blocks we're dividing (i.e. the matrix* values). And maybe we could use a map/dictionary if the association can be strictly by name at the TMS definition level, or otherwise use an ordered array, e.g.:

      {
         "identifier" : "0",
         "scaleDenominator" : 139770566.0071794390678,
         "matrixWidth" : 4,
         "matrixHeight" : 2,
         "tileWidth" : 256,
         "tileHeight" : 256,
         "pointOfOrigin" : [
            90,
            -180
         ],
         "matrixExtraDimensions" :
         {
            "elevation" : {
               "min" : -12000, "max" : 12000,
               "uom" : "http://www.opengis.net/def/uom/SI/metre",
               "divisions" : 2,
               "resolution" : 1000
            },
            "time" : {
               "min" : "2021-01-01", "max" : "2021-12-31",
               "uom" :  "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian",
               "divisions" : 1,
               "temporalDivision" : "year",
               "temporalResolution" : "month"
            }
         }
      },

This example big picture tile matrix would feature 4 x 2 x 2 x 1 (16) tiles, each containing e.g. a 4D+ coverage (a tile could always contain additional dimensions beyond what is specified in the TMS) with 256 x 256 x 12 x 12 values (or i.e. 144 2D lat/lon slices, equivalent to 144 regular 2D tiles). Assuming a compact 32-bit float format for, say, daily temperature or relative humidity, (at this level monthly average), everywhere on Earth (at this level ~39.1km resolution) for a year, from -12km to 12km from WGS84 spheroid elevation (at this level 1km resolution), each tile would take ~36 mb uncompressed, assuming a 3x compression factor: ~12mb tiles, for a total of 192mb at this low-resolution.

So with this idea for matrixExtraDimensions, for each dimension:

• The map key is the name
• min is the minimum value
• max is the maximum value
• uom is the unit of measure used for defining min, max and resolution
• divisions is in how many blocks (trims in Coverages term) the space between min & max is divided at this particular tile matrix
• resolution is the resolution of the data in that dimension. For a coverage, this would be separate slices at that resolution interval, where the number of slices is equal to (max - min) / divisions / resolution, (+1 for points rather than area coverage). For 3D models, point clouds, vector features, the resolution would represent the average accuracy level at which you will find distinct coordinates.

For temporal, I suggest temporalDivision and temporalResolution to allow dividing by month or years, which have unequal number of days (even days have unequal number of seconds with leap seconds), and similarly specify the resolution using these not-so-equally-spread units. If these are not used, then divisions would divide the temporal range equally, and (potentially fractional) seconds would be assumed as the resolution unit.

I believe that is all that is required to fully support case 2 & 3, and full nD coverage, point clouds, 3D models (space-centric, i.e. irrespective of content) tiles. Case 2 is the special case where divisions is 1 (which should be the default if not specified). Case 1 is already supported by the current schema.

Any of these approaches 1-3 can also be used to generate a multi-resolution 3D Tiles tileset (Bounding Volume Hierarchy). However, 3D Tiles BVHs "tiles" are not required to relate to each other in any particular way -- each tile is explicitly defined with its own min and max for each dimension. So while a TMSnD can be used to generate a 3D Tiles BVH, many 3D Tiles BVH cannot be described using TMS (such as those splitting the content based on local data density, or otherwise not fitting the TMS model).

3D Tiles also has an extension allowing to define such implicit tiling scheme as they call it, like this proposed TMSnD. I am not sure though whether that extension is part of the currently approved OGC community standard.

I think we should also allow implementers to either:

1. Define a a TileMatrixSet already built-in with this nD capability, or
2. Define these extra dimensions as part of a TileSet using a 2D-only TileMatrixSet, by defining this matrixExtraDimensions for each tile matrix

Then in the Tiles API, we will only need to establish how those nD dimensions map to the different conformance classes to support identifying a specific nD tile (i.e. building the URL to the tile). I believe that would be quite straightforward based on how they are organized.

Note: the tiles are still nD if any extra dimension has a divisions > 1.

[jerstlouis]

Maybe we should rename resolution and temporalResolution to cellSize and temporalCellSize.

We could also consider merging cellSize and temporalCellSize, and divisions and temporalDivision (specifying "month" for divisions, and the number of divisions would be based on how many months are covered by the range).

[joanma747]

I agree with having a generic structure for the extra dimensions.

In order to make the notation more symmetric witht he 2D dimensions, I propose:

{
         "identifier" : "0",
         "scaleDenominator" : 139770566.0071794390678,
         "cellSize": 0.3515625,
         "matrixWidth" : 4,
         "matrixHeight" : 2,
         "tileWidth" : 256,
         "tileHeight" : 256,
         "pointOfOrigin" : [
            90,
            -180
         ],
         "extraDimensions" :
         {
            "elevation" : {
               "origin" : -12000,
               //"end" : 10000, optional
               "uom" : "http://www.opengis.net/def/uom/SI/metre",
               "matrixAcross" : 22,
               "tileAcross" : 1000
            },
            "time" : {
               "origin" : "2021-01-01", 
               "uom" :  "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian",
               "matrixAcross" : "monthsInAYear*2",
               "tileAcross" : "daysInAMonth"
            }
         }
   }

The word "Across" comes from the TIFF tiles and it is a bit more dimension agnostic than "width" or "height".

[jerstlouis]

@joanma747

I had originally thought of using something like tileAcross and had called it slices, from the Coverages terminology. The reason I went away from that, is that just like with vector data we get a lot of pushback about these 256 pixels being meaningless, with 3D point clouds or models, there is no fixed number of elements across -- the points or mesh vertices are not equally spaced. That's why I suggested resolution instead.

For temporal, years, months, weeks, days, hours, minutes can all correspond to a different number of seconds. daysInAMonth by itself is confusing since not all months have the same number of days. The matrixAcross in particular should be a clear value (which works in your example because monthsInAYear is one thing that is fixed). I also thought it was nice to be able to easily see and easier to specify what is the temporal resolution at a particular tile matrix (e.g. hourly, daily, monthly, yearly...), rather than the number of elements which is always wobbly.

[joanma747]

The diagrams works for projected spaces but in an sphere, the columns are not columns are wider at the top. [Carl's comment] We can add this discussion as an annex only. This consolidated in the marked now and it will confuse people [Jeff Harrison] Can we remove 2D from the classes to allow extensibility? [Jerome] (and the title).

[jerstlouis]

I volunteer to create an annex for this, and remove the 2D suffixes throughout the class names.

[jerstlouis]

We now have Annex K: Extending TileMatrixSets for additional dimensions (Informative)!

[joanma747]

The annex is considered done.