0

I'm using OpenLayers to display a large zoomable non-geographical map. So far, I've been using raster tiles. In order to improve the performance, I'm trying to switch to vector tiles. I've got the layers I want to slice into vector tiles as JSON files looking like this (example data, don't mind the geometry):

{
   "type":"FeatureCollection",
   "features":[
      {
         "type":"Feature",
         "id":"01",
         "properties":{
            "name":"Feature01",
            "name_de":"Bereich01",
            "size":1.2345
         },
         "geometry":{
            "type":"Polygon",
            "coordinates":[
               [
                  [
                     210.57,
                     -1195.01
                  ],
                  [
                     285.12,
                     -1182.00
                  ],
                  [
                     288.96,
                     -1195.01
                  ],
                  [
                     210.57,
                     -1195.01
                  ]
               ]
            ]
         }
      },
      {
         "type":"Feature",
         "id":"02",
         "properties":{
            "name":"Feature02",
            "name_de":"Bereich02",
            "size":0.345
         },
         "geometry":{
            "type":"Polygon",
            "coordinates":[
               [
                  [
                     300.10,
                     -1199.92
                  ],
                  [
                     0.12,
                     -0.23
                  ],
                  [
                     300.10,
                     -1199.92
                  ]
               ]
            ]
         }
      }
   ]
}

I was able to generate the vector tiles in .pbf format in tippecanoe like so (found here):

tippecanoe --no-feature-limit --no-tile-size-limit --no-tile-compression --output-to-directory directory layerName.json

The output is a directory similar to when using raster tiles and is given by directory/{z}/{x}/{y}.pbf. At last, I'm able to read these files using OpenLayers (cf. this):

var vtLayer = new VectorTileLayer({
  declutter: false,
  source: new VectorTileSource({
    format: new MVT({
      idProperty: 'id',
    }),
    url: 'directory/{z}/{x}/{y}.pbf'
  }),

var map = new Map({
  layers: [vtLayer],
  target: 'map',
  view: new View({
    center: [1024, -1024],
    extent: [0, -2048, 2048, 0],
    zoom: 2,
    multiWorld: true,
  }),
});

However, the map shown seems to be just black without any meaningful features (also when adjusting them with styles). As can be seen from the code snippet, the map view is limited to some arbitrary extent in a cartesian coordinate system. That's the area the geometry of the features in my non-geographical map might fall into. When reading (vector or raster) tiles into OpenLayers, this is no problem at all because the extent of the TileGrid can be easily defined for each tile source. However, the building of the tiles with tippecanoe seems to be the problem. I assume this is because the tiles are sliced with respect to EPSG:3857 coordinates. Therefore, the coordinates I actually need make up only a tiny fraction of the actual sliced tiles.

So I'm asking if it's possible to use tippecanoe to build the tiles relative to a given extent of coordinates (i. e. zoom level 0 <=> all features of the given extent in one tile). I can't change the zoom levels of my tiles and I'd like to avoid making an arbitrary conversion to EPSG:3857 as my features have no relation to the Earth's surface. I'm not fixed to using tippecanoe to build the vector tiles; however, from my research it seems to be the most promising way. Apart from non-geographical maps like mine, maps displaying only a small part of the Earth's surface also seem to be a use case for this.

4
  • You could try running tippecanoe with projection parameter --s projection EPSG:3857. – TomazicM Nov 27 '20 at 13:56
  • @TomazicM I've tried this and it certainly changed the way the tiles are sliced. The problem is that I'm using neither EPSG:3857 nor EPSG:4326. So I don't want the tiles sliced with respect to a plane between [-180, -90, 180, -90] (like it seems to be done with EPSG:4326) but to a custom extent [0, -2048, 2048, 0]. If that's not at all possible, I could probably convert my coordinates to lat/long. That wouldn't be very elegant, though, because my map has no meaningful connection to geographical coordinates. – Moehrengulasch Nov 27 '20 at 14:24
  • 1
    I think problem here is zoom. Your extent is [0, -2048, 2048, 0], but extent of projection EPSG:3857 is [-20026376.39, -20048966.10, 20026376.39 20048966.10], so at zoom level 0 your vector feature is so small it's practically invisible (2km x 2km). Try zoom levels above 10. – TomazicM Nov 27 '20 at 14:38
  • Unfortunately, I can't easily change the zoom level because it has certain semantics for my map (discussed here). I'm more flexible in changing the coordinates of my polygon features. The best solution would be to have the extent as a parameter when slicing the tiles. So I need to adapt my tiles to one of the supported projections (either by transforming the coordinates or the zoom level)? Not quite the answer I was hoping for but helpful still. – Moehrengulasch Nov 27 '20 at 14:52
1

I've managed to do this with GDAL rather than tippecanoe. It's possible to define a custom tiling scheme there. This works with EPSG:4326 as well, even if the coordinates aren't in the range of ±90° latitude and ±180° longitude. Therefore, this is a viable option also for non-geographic maps.

Tiling scheme can be given to the GDAL MVT driver with the dataset creation option EPSG_code,tile_origin_upper_left_x,tile_origin_upper_left_y, dimension_zoom_0 as described here. For instance, the slicing of feature geometries ranging from [0, 0] to [2048, -2048] into tiles can be done like this:

ogr2ogr -f MVT output_directory inputFeatures.json -dsco FORMAT=DIRECTORY -dsco COMPRESS=NO -dsco TILING_SCHEME="EPSG:4326,0,0,2048" -dsco MAXZOOM=5

Note: Tiling starts in the upper left corner, so the y-coordinates are expected to get smaller with increasing tile rows. Therefore, the y-coordinate might have to be inverted for all the features in the data, if they are assuming the origin of coordinates to be in the lower left corner (mathematical coordinates).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.