support different coordinate reference systems like EPSG:4326

[ChristianBeilschmidt]

Is it possible to use Maritn to output vector tiles in EPSG:4326 coordinate reference system?

[sharkAndshark]

Try Function Source mabe.
Define a database function which take x y z as argument and output tile byte .This function should clip tiles based on 4326， TMS/XYZ schema

[sharkAndshark]

Is there a plan for tile schema not 3857? @stepankuzmin

[stepankuzmin]

Not at the moment, but we might consider this in the future. Is there a real need for this?

[ChristianBeilschmidt]

For us, at least 4326 would be relevant.
For local data, in theory, UTM zones could also be relevant.

Even MapTiler started selling 4326 tiles: https://documentation.maptiler.com/hc/en-us/articles/4405462253073-OpenStreetMap-in-WGS84-EPSG-4326-

So this should have also relevance for others.

[sharkAndshark]

For us, at least 4326 would be relevant. For local data, in theory, UTM zones could also be relevant.

Even MapTiler started selling 4326 tiles: https://documentation.maptiler.com/hc/en-us/articles/4405462253073-OpenStreetMap-in-WGS84-EPSG-4326-

So this should have also relevance for others.

We use a lot 4490,4544 by a lightweight tile server based on PostGIS.

[jlaura]

This is particularly relevant for us. We work on non-terrestrial bodies (Moon, Mars, etc.). In fact, coupling to the EPSG authority is problematic. The authority for planetary projection codes is the International Astronomical Union (IAU). Being able to define a custom tile matrix set allows us to use appropriate body radii, etc. If and when this work is undertaken, I would strong advise considering non-EPSG authorities.

[nyurik]

I will be happy to accept any PRs for this capability. If anyone is interested, please comment on your proposed solution, i.e. how the code should be restructured to support such cases. I would advise looking at the upcoming new code structure that I'm hacking on in #456 and partially described in the #430 discussion. The goal is to support any data backends, including multiple postgress connections, mbtiles, etc.

[exotfboy]

ASFAIK, the tile bounds generated for a given tile coordinate(z,x,y) is the key, then it is the same for encoding the data clipped from the source to MVT.

For PostGIS source, martin use ST_TileEnvelope for the tiles bounds calculating. While ST_Envelope supports tile envelope other than 3857.

By default, the tile envelope is in the Web Mercator coordinate system (SRID:3857) using the standard range of the Web Mercator system (-20037508.342789, 20037508.342789). This is the most common coordinate system used for MVT tiles. The optional bounds parameter can be used to generate tiles in any coordinate system. It is a geometry that has the SRID and extent of the "Zoom Level zero" square within which the XYZ tile system is inscribed.

Also there is an example for tile envelope in 4326:

SELECT ST_AsText( ST_TileEnvelope(3, 1, 1, ST_MakeEnvelope(-180, -90, 180, 90, 4326) ) );

Then the next job is how to expose the optional bounds parameter to user in martin.

For MBTiles, I have no idea at the moment.

[nyurik]

Technically, the ST_TileEnvelope accepts a SRID parameter, but i am not certain it is implemented yet. In theory, the best path may be to implement needed srid support in postgis directly, but in the mean time, Martin could be modified to use the ST_Envelope when non-3857 is needed.

The functions source could be made to produce anything at all, but there will need to be a way to tell Martin that the SRID is non-standard so it produces the correct TileJSON.

For the sources that already contain/produce data in the 3857, we could in theory decode those tiles and re-encode them on the fly. Lots of funky math, but a worthy project nevertheless.

[exotfboy]

1. the ST_TileEnvelope accepts a bounds parameter instead of a SRID parameter,and sounds like PostGIS support thats already from the docs.

2. For sources that already contain/produce data in the 3857 I'd prefer to keep that without any re-projection.

[nyurik]

Apparently morecantile project defines non-web-mercator projections for tiles. Moreover, @pka 's https://crates.io/crates/tile-grid seems to be using some of that. Perhaps we should rely on that crate more, or at least adapt some of the ideas? This might also be useful for #1676 by @sharkAndshark ?

Moreover, OGC TileMatrixSet standard might be useful for this effort - see also https://github.com/developmentseed/titiler and https://github.com/developmentseed/tipg

[sharkAndshark]

I was thinking this these days. A very naive draft here. Let's talk and read more references like the titiler tipg ,even the ogc tiles api to make a decision.

the configuration

# tile schema would be default to xyz, no option for this for now, PR is welcome
tilegrid:
  custom_1:
    srid: 4326
    # min_zoom: 0 should we allow the user set minzoom/maxzoom in custom tile grid either?
    # max_zoom: 30
    bounds:
      - -180.0
      - -90.0
      - 180.0
      - 90.0
    tilesize: 4096 # optional. Default to 4096, would be used in the ST_AsMVTGeom function
  custom_2:
    srid: 4326
    bounds:
      - -180.0
      - -90.0
      - 180.0
      - 90.0
    tilesize: 4096

postgres:
  connection_string: 'postgresql://postgres@localhost:5432/db'
  tile_grid: custom_1
  auto_publish:
    from_schemas:
      - public
      - my_schema
    tables:
      tile_grid: custom2
      from_schemas: my_other_schema
      extent: 4096 # if custom2 is set, should we rewrite the custom2.tilesize? 
  tables:
    table_source_id:
      tile_grid: custom2
      minzoom: 0 # should we allow the user set minzoom/maxzoom in custom tile grid either?
      maxzoom:
      extent: 4096 # if custom2 is set, should we ignore this? Guess no?

the catalog

There would be a tilegrid in /catalog.

"tiles": {
  "table1":{
    "tileGrid": "custom_1",
  }
},
tile_grid: {
    "some_custom_grid": {
        "extent": [
            1620750.2508,
            4271892.7153,
            1625870.2508,
            4277012.7153
        ],
        "maxZoom": 3,
        "minZoom": 0,
        "origin": [
          1620750.2508,
          4277012.7153
        ],
        "tileSize": [
          4096,
          4096
        ]
    },
    "some_custom_grid_2": {
        ...
    },
    "a tile grid parsed from COG file woude be added here automatically by martin": { // to make things simpler and step by step, maybe talk about cog later. Just focus on the custom tile grid things.
        ...
    },
}