Unexpected y tile values in request from Docker image

[bob-gray]

I'm trying out the docker image using docker run --rm -p 8080:80 consbio/mbgl-renderer

When sending a request using values from a map that is successfully rendered using Mapbox GL JS in the browser, the service fails when making requests for tiles. It requests tiles outside the range of my tileset. The y values are different than the values requested by the browser and seem to be calculated incorrectly. I get similar results using either center or bounds.

width: 1920
height: 977
zoom: 14
bounds: -93.43098873048935,41.922703599964336,-93.3485912695486,41.95389258663502

In the browser the y values range from 6084-6086. In the mbgl-render container the y values range from 10297-10299.

Thanks

[brendan-ward]

@bob-gray Can you please tell us more about the map service you are using for this example (if possible, include link to it).

Some map services vary in the origin point of their y-values (bottom or top), which could cause us to be requesting different y values than are displayed in your browser.

Also - what scheme (more info) are you using in your style in the browser vs when you call mbgl-renderer?

[bob-gray]

The service is a simple proof of concept. I created it by wrapping an .mbtiles db created by Tilemaker in a simple Node.js service using @mapbox/mbtiles.

I'm not specifying the scheme in the browser, so it looks like it would be using the default "xyz"

[bob-gray]

I've done a little research into xyz vs tms. It looks like this is the issue and it appears that the tile services is tms.

(2 ^ 14) - 10298 - 1 =‬ 6086.

I tried to set the scheme in the browser and got an error that you can't set the scheme and use a URL for the style. I'm thinking that the browser is reading the scheme from the service (tms) and working correctly.

[brendan-ward]

@bob-gray using a simple style file, I was unable to reproduce this issue with either the CLI or the server version of mbgl-renderer:

test.json:

{
    "version": 8,
    "sources": {
        "test": {
            "type": "vector",
            "tiles": ["https://dev-www.iceasb.org/services/tiles/osm/data/{z}/{x}/{y}"],
            "tileSize": 256
        }
    },
    "layers": [
        {
            "id": "water",
            "type": "fill",
            "source": "test",
            "source-layer": "water",
            "paint": {
                "fill-color": "blue",
                "fill-opacity": 1
            }
        }
    ]
}

When I have it log out the tiles it is requesting, they match what I see requested in the browser (from basemap tiles) for the same location, e.g.,
https://dev-www.iceasb.org/services/tiles/osm/data/14/3942/6086
which matches your correct range above.

Command line call:

dist/cli.js /tmp/test.json /tmp/test.png 1920 977 -b -93.43098873048935,41.922703599964336,-93.3485912695486,41.95389258663502

API call (using HTTPIE):

http :8080/render width=1920 height=977 bounds=-93.43098873048935,41.922703599964336,-93.3485912695486,41.95389258663502 style:=@/tmp/test.json > /tmp/test.png

When I do the same thing against the server running in the docker container, I get the same output image as above where I know the requests are correct.

For the above tests, I get this image - which means that the tile requests are not failing:

[brendan-ward]

@bob-gray when I set scheme to "tms" in the above test.json file, the requests fail, and have the same tile ranges you report above.

If I set it to xyz (the default) or leave it blank, it works fine.

Your service is xyz.

Is it possible you have the scheme set to tms in your style file used for mbgl-renderer? That is my best guess at this point.

[bob-gray]

I'm using the same style file for both.

The response says the scheme for the tileset is tms. This is what is stored in the .mbtiles db that was created by Tilemaker

[brendan-ward]

@bob-gray I wonder if the tileset itself is created as TMS (suggested by this thread), but that @mapbox/mbtiles is presenting it with XYZ scheme instead of TMS?

That is suggested here, where the Y coordinate is being flipped as part of getting the tile from the mbtiles file.

Since scheme is part of the tile metadata, it may be getting turned into tileJSON without being updated - which means that the service is reporting this incorrectly.

I'm not sure why Mapbox GL JS appears to be ignoring the scheme in your tileJSON whereas the Mapbox GL Node (as used by mbgl-renderer) is using it.

As a simple test, what happens if you alter the value of scheme in your mbtiles file to xyz and republish that service?

[bob-gray]

@brendan-ward Yep. That did it. Thanks for the help! It's strange that Mapbox GL JS ignores the scheme. I don't understand how the mbtiles file works. If the data is created as TMS, I wonder why @mapbox/mbtiles #getTile works with the xyz scheme?

Any recommendation whether generating tiles (Tilemaker) and serving them this way (@mapbox/mbtiles) would be a good approach or not? Any suggestions are greatly appreciated. Thanks again.

[brendan-ward]

@bob-gray 🎉

@mapbox/mbtiles directly decodes xyz incoming requests to TMS scheme before querying the underlying tiles.

Recommendations depend a lot on what you are trying to accomplish (DM me at [email protected]).

I don't have any experience using Tilemaker or @mapbox/mbtiles. We use a different server (built using Golang) for serving mbtiles - mbtileserver - and we deploy it to tiny AWS instances since we don't need the NodeJS runtime or other complexities.

For my work, where I'm often creating vector tilesets from CSV files of lat / long data or shapefiles, I use ogr2ogr and tippecanoe - and then host them with mbtileserver.