New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MVT Tile Boundary Issue not lining up #5578

itbeyond opened this Issue Apr 6, 2018 · 8 comments


None yet
3 participants

itbeyond commented Apr 6, 2018

I have been doing extensive testing with mvt support against a very large (10K lines) map file and converting the png output to mvt with mixed results. Of course there are heaps of DB changes and updates I am applying however I have just started working with Polyline and cannot get the alignment between tiles to work - I have looked at and tried the EDGE_BUFFER from values of 0 to 50 and still see the same type of alignment issues my OUTPUTFORMAT statement is as follows:

    NAME "mvt"
    MIMETYPE "application/x-protobuf"
    DRIVER "mvt"
    EXTENSION "pbf"

I am using mode=tile and pulling a road layer from postgres. The png output is fine and is cut in the right place - so using the same mapserve cmd and only changing the outputformat from png to mvt (mvt rendered in inspect mode on Maputnik, shows the same in mapbox gl) produes the images attached. NOTE the mvt layer is only showing major roads hence there is less visible in the mvt output than the png. The errors in the mvt are visible centre left and down - there is a 4 way tile join.
I just booted the mvt-demo provided by @sdlime in the pull #5376 and zooming in shows the error exists in this output also as per the attached screenshot. You can see it in the road line and river line.


This comment has been minimized.

itbeyond commented Apr 9, 2018

A little more research yields this from Mapbox in relation to MVT format: All geometric coordinates in vector tiles must be between -1 * extent and (extent * 2) - 1 inclusive. Is this how mapserver sets the tile extent in mode=tile?

Additionally for mvt using Mapbox-gl all vector tiles must be sized at 512 pixels (trying to manually adjust this in mapbox-gl gives this error: Error: vector tile sources must have a tileSize of 512. The MapServer documentation for mode=tile states tile size will be 256 - I wonder if this conflict is what is causing the issue as I have noted that the output using the vector tiles seems to render a 256x256 tile in a 512x512 area - ie: the map looks twice as large rendered in gl using a vector source than the same raster source settings producing a png. In fact the png vs vector output images I uploaded above show this double up in size (I first thought the png was being reduced in github render) both set of images from the tile zoom 11 and rendering the same 4 tiles.

EDIT: I have looked more and can see that mapserver has a factor of 4096 in the vector tile scale extent formula however I am not sure how this interplays with the 256x256 vs 512x512 - generating a tile - but my above comment on vector rendering larger is actually backwards. I am getting confused I think but there is a problem with tile bounds and tile sizes.


This comment has been minimized.


sdlime commented Apr 10, 2018

I'll have to dig into this (just got back into town)... thanks for the testing - I think you're one of the first. Hopefully this is something simple...


This comment has been minimized.


fminuti commented Apr 13, 2018

I think the problem is


Lines 457 to 467 in b74a3f4

** Adjust the extents inwards by 1/2 pixel so they are from
** center-of-pixel to center-of-pixel, instead of edge-to-edge.
** This is the way mapserver does it.
dx = (map->extent.maxx - map->extent.minx) / map->width;
map->extent.minx += dx*0.5;
map->extent.maxx -= dx*0.5;
dy = (map->extent.maxy - map->extent.miny) / map->height;
map->extent.miny += dy*0.5;
map->extent.maxy -= dy*0.5;

In this code the extent is made "bigger" and so the calculation of the 4096 pixel scale become wrong.
If you comment out this code you should obtain the correct tile.

Maybe " This is the way mapserver does it." should be changed or taken into account in code.


This comment has been minimized.

itbeyond commented Apr 16, 2018

@fminuti Yes this is the problem - I commented out this section - recompiled the dll and presto. The tiles are now correctly aligned. So yes it appears that this case needs to be tested and a provision to turn off this re-calculation when tiles are being rendered in mvt. @sdlime - this does in fact resolve the problem as far as my testing goes - not sure how to put in the right test for this in code, hope you can sort this out in the base package easily. Thanks.


This comment has been minimized.


sdlime commented Apr 16, 2018

I don't think we want to change maptile.c since that would hose up regular use of mode=tile. It's more likely that the mvt code was also applying a similar extent transformation and it could/should be disabled there. Thomas' original mvt implementation was using WFS which had no extent manipulation so that would make sense. --Steve

sdlime added a commit that referenced this issue Apr 18, 2018

Fixed extent issue with MVT tiles. We assume the extent is given as a…
… MapServer extent (pixel center) and we need the edge-to-edge version to properly query and encode the tile. (#5578)

This comment has been minimized.


sdlime commented Apr 18, 2018

The MVT now code assumes the submitted extent is given in pixel center. I added a bit of code to transform by adding back the half pixel. That seems to fix the tile generation, at least in my MVT demo.

Please give it a try and let me know how it goes. We can always re-open if necessary.


@sdlime sdlime closed this Apr 18, 2018


This comment has been minimized.

itbeyond commented Apr 19, 2018

Will test asap thanks just out of the office for 10days. Will report when I get back.


This comment has been minimized.

itbeyond commented Apr 30, 2018

Confirm this has fixed the problem - thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment