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.