I would like to use tippecanoe to create .pbf vector tiles from polygons in a non-geographic map. However, in my use case, coordinates of the polygons are in the range of [0, 0], [910, 1880] rather than [-180.0, -90.0], [180.0, 90.0]. Therefore, slicing my features into tiles doesn't work correctly.
When using GDAL, it is possible to provide a customized starting point (x, y) and the map dimension at zoom level 0 (source):
ogr2ogr -f MVT output_directory inputFeatures.json -dsco FORMAT=DIRECTORY -dsco COMPRESS=NO -dsco TILING_SCHEME="EPSG:4326,0,0,1880" -dsco MAXZOOM=5
(In this example, the vector data is sliced on the basis of a [0, 0] to [1880, 1880] map).
I would like to use tippecanoe in the same way in order to benefit from the neat simplification features this library offers. The problem here doesn't seem to be projection: I'm not projecting anything, the "source" is rectangular, e. g. like a huge wallpaper that happens to have coordinates. Therefore, I think, this would be much simpler to implement than custom projections (like the similar request #770) but very useful for use cases such as mine.
I would like to use tippecanoe to create .pbf vector tiles from polygons in a non-geographic map. However, in my use case, coordinates of the polygons are in the range of
[0, 0], [910, 1880]
rather than[-180.0, -90.0], [180.0, 90.0]
. Therefore, slicing my features into tiles doesn't work correctly.When using GDAL, it is possible to provide a customized starting point (x, y) and the map dimension at zoom level 0 (source):
ogr2ogr -f MVT output_directory inputFeatures.json -dsco FORMAT=DIRECTORY -dsco COMPRESS=NO -dsco TILING_SCHEME="EPSG:4326,0,0,1880" -dsco MAXZOOM=5
(In this example, the vector data is sliced on the basis of a [0, 0] to [1880, 1880] map).I would like to use tippecanoe in the same way in order to benefit from the neat simplification features this library offers. The problem here doesn't seem to be projection: I'm not projecting anything, the "source" is rectangular, e. g. like a huge wallpaper that happens to have coordinates. Therefore, I think, this would be much simpler to implement than custom projections (like the similar request #770) but very useful for use cases such as mine.