Asymmetric cellSizes

[ebremer]

Most of the time my images/spatial data has a symmetric size/scaling, but some of my data has asymmetric cell sizes. This can be seen in some image formats like TIFF: XResolution, YResolution XResolution and YResolution not always being equal.

Any thoughts to supporting asymmetric cell Sizes in this spec as I see the multiplicity is currently one (Table 7 - Parts of TileMatrix data structure)?

[jerstlouis]

@ebremer That would likely require a major revision and be incompatible with various things (e.g., WMTS, GeoPackage?).

All Common 2D Tile Matrix Sets are defined in a particular CRS, with symmetric cell sizes.

What would be the use case? In general, using common 2D tile matrices (those regisered in the 2DTMS register) are preferable for interoperability.

Would the use case be to use a common 2DTMS in the same CRS (e.g., WorldCRS84Quad) as the source image and avoid resampling? There likely would still be resampling needed anyways to match the zoom level of the tile matrices.

Or is the use case more specific to tiling a particular image and defining a custom 2DTMS strictly for this image? In this case, perhaps a custom CRS can also be defined that applies a scale factor so that both resolutions become equal in that custom CRS space.

[ebremer]

Actually, more the latter. The use case is the extraction of Morphological features derived from Pathology Whole Slide Images (WSI). The images usually in the range of 100,000x100,000 pixels (with corresponding 1/4 scale image pyramids). Deep learning AI pipelines are trained to extract labeled regions of interest (cancer, necrotic regions, individual nuclei, etc). Spatial querying across this image and other sets of derived features (all relating to the same WSI) from different pipelines are then performed. In some cases, the additional features could be from a variant of the same image (but now captured with a symmetric cellsize) and then registered over the original image so all of the spatial data gels together for querying. Personally, I would love it if all of the data used a symmetric cellSize, but I don't control the functioning of various vendor's scanners and related equipment. Re scaling the images to fix the asymmetries would be possible but avoided to avoid changes to the image data. Further, WSI are sometimes stacked and registered forming a 2.5D/3D image volumes, introducing a Z scale need. I would say the CRS are always defined to the particular reference image (or image set).

[jerstlouis]

@ebremer Though we could consider support for assymetric cellSize for a 2DTMS 3.0, there is no current plan for a 3.0, and no guarantee that the idea would fly. In the meantime, I think the easiest solution is defining a CRS taking into account the assymetry.

It is not the cellSize alone that maps the pixel size to real-world units, but the cellSize + the definition of the CRS dimensions. The tiles can also either have equal width and height or not.

So I think setting up the pixel -> real-world units scale factor per dimension in a custom CRS would be is the easiest solution.

[ebremer]

Ah, I see. I actually like that better. Do custom CRS have to be registered or can they be part of the overall data "package"?

I specifically have been trying to use GeoSPARQL RDF to represent my data, but struggling with how OGC specifies grid information. My data is down at the sub-micron scale, I would need some extra layers on WorldCRS84Quad which only goes down to 147.792 microns per pixel.

Would Ontology-CRS be of any help here?

[jerstlouis]

@ebremer technically WorldCRS84Quad is infinite -- you can add as many levels as you like (well, until you reach the Planck length ;)).

But unless the data being scanned is perfectly draped on the surface of the Earth, you probably should not be using the CRS84 CRS on which this 2DTMS is based at all.

You can define a custom CRS directly in the 2DTMS definition. However the "official" format for doing this is still work in progress at https://github.com/opengeospatial/CRS-JSON-Encoding/ .

Until then, you can use a PROJJSON object .

I'm not sure how you would spatially reference your data however. This probably falls in the "Engineering CRS" category (see https://docs.ogc.org/is/18-010r7/18-010r7.html#60).

[ebremer]

Following the engineering CRS, I'm guessing something like this for a simple 2D Cartesian CRS for an image with 0.43 micron xresolution and 0.42 micron YResolution:

CS[Cartesian,2],
    AXIS["x", right, ORDER[1]],
    AXIS["y", down, ORDER[2]],
    LENGTHUNIT["micrometer", 1.0],
    SCALE["x", 0.43],
    SCALE["y", 0.42]

[jerstlouis]

@ebremer I'm not familiar enough with the engineering CRSs to confirm, but you would want to use the new CRS JSON or PROJJSON encodings rather than this WKT2 encoding.

Unfortunately I think PROJJSON does not yet support engineering CRSs, so you way want to present your use case and reference this issue in https://github.com/opengeospatial/CRS-JSON-Encoding/issues/27 .

[ebremer]

@jerstlouis thanks for all of the feedback. An Engineering CRS (I also read referred to as a Local CRS) seems to be appropriate for my data. Unfortunately, not really supported in GeoSPARQL to which I have been trying to express all of my data.