Skip to content
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 edge alignment issue (still) #5596

Closed
itbeyond opened this Issue May 25, 2018 · 25 comments

Comments

Projects
None yet
4 participants
@itbeyond
Copy link

itbeyond commented May 25, 2018

Team the issue I reported previously that was related to the tile extent .5 pixel (fixed by @sdlime in #5578) has not fully resolved the tile edge alignment see this image of a set of polylines that cross a tile edge:
capture
I have noticed this issue for several days but was not sure - however I have now done more work on this and it is apparent that there is still an issue. The best way to reproduce this is the set the source limit to say level 14 and then zoom in to 15 or beyond as this will exaggerate the edge alignment. The image above was captured at level 14 on a source level 14 setup so it can be seen at the non over-zoomed level in the right set of circumstances.

Just to be sure I setup the @sdlime provided demo and set the maxzoom to 7 for the style and was able to capture this at level 8 from the demo data:
capture1

There may be a buffer issue that is causing this and I cannot workout how to use the buffer increase/decrease function the is provided - any help on this would be appreciated.

@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented May 25, 2018

Will have to see if I can replicate. I don't think it's a buffer issue but I need to check and see how that's being applied relative to the extent. It's possible that extent and buffer corrections are being applied in the wrong order or wrong place.

This could also be related to the tile size I suppose. The MapBox client expects 512x512 and my demo is doing 256x256. I have another setup that uses the mapcache (with my pull request for MVT support applied) and sets 512x512 tiles and that seemed perfect in testing but I need to confirm that.

Can you confirm you're running 7.2-beta1?

--Steve

@itbeyond

This comment has been minimized.

Copy link
Author

itbeyond commented May 26, 2018

Steve,

Thanks for the detail I was using 7.1-dev so got the latest and now at 7.3-dev and the issue is still occurring:
capture2
capture3
I was wondering about the tile size and 512 vs 256 - is this a problem for me I am using the CGI to build my tiles - I have not used mapcache. Is there a way to adjust the tilemode to support 512x512? I was wondering if the tile size was being stretched in the mapbox-gl/maputnik clients I am using.

David

@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented May 29, 2018

My understanding is that the tile extent is the same - so the tile addressing scheme is identical for both raster and vector tiles. So it's the resolution of the encoded feature that is affected by the tile size. The MVT code actually doesn't use width/height.

I'm now thinking the error might be in mvtTransformShape (in mapmvt.c) where there's an off-by-one problem, probably in the computations for scale_x and scale_y. It will be a few days before I can look into this again - more next week.

We'll get there!

@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented May 29, 2018

Something about that first paragraph in my last message is bugging me. Need to verity if that assumption is actually correct. Much of the testing during was over the top of existing raster tile sets to verify registration... What I haven't tried is displaying two independent sets of vector tiles.

@alexandreleroux

This comment was marked as off-topic.

Copy link

alexandreleroux commented Jun 5, 2018

Not certain if this is related or not, but we do observe in MapServer 7.0.7 some similar broken lines in WMS for contours. See attached screenshot (the broken lines are best seen at full resolution on this screenshot, but the issue shows up at any zoom level). Hope this helps?

contour_labelsissue0

@sdlime

This comment was marked as off-topic.

Copy link
Member

sdlime commented Jun 5, 2018

Is that screenshot assembled from WMS-based tiles or is that the result of a single WMS call? Could you post a 7.0.6 result too (or wherever things last looked normal)? It would be nice to compare. The regression tests should catch these sorts of issues though... --Steve

@alexandreleroux

This comment was marked as off-topic.

Copy link

alexandreleroux commented Jun 5, 2018

Hi Steve, that's a single WMS call displayed in QGIS 2. Unfortunately, we don't have access to a 7.0.6 installation at the moment.

@sdlime

This comment was marked as off-topic.

Copy link
Member

sdlime commented Jun 5, 2018

Any chance you could whip up a test case (data + mapfile)? I have a bunch of versions here to test with.

@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented Jun 6, 2018

Ok, I refreshed my memory on this stuff - been awhile. The MapBox GL client actually overlays vector tiles from one zoom level higher than a corresponding raster tile layer. So if the raster tiles are from zoom level 13 the vector tiles will be from level 14 - effectively 512x512 vector tiles over the 256x256 raster tiles. So that's not the issue.

With 7.2-beta1 I'm not really able to re-create the issue with #5578 in place. @itbeyond, can you somehow tell me where in the demo you see the issue? Even a screenshot zoomed out from the area mentioned would provide something to go on.

It's possible you're just seeing rendering issues with the MapBox GL client...

--Steve

@alexandreleroux

This comment was marked as off-topic.

Copy link

alexandreleroux commented Jun 6, 2018

@sdlime We did more digging on our end, and the current conclusion is that my colleague whom reported this issue with contours display is not related to MapServer at all. It's apparently a defect in a very old QGIS version when loading WMS tiles (QGIS Linux 2.0.1 Dufour).

@sdlime

This comment was marked as off-topic.

Copy link
Member

sdlime commented Jun 6, 2018

@alexandreleroux, whew... I'm going to hide that bit of the thread.

@sdlime sdlime self-assigned this Jun 6, 2018

@itbeyond

This comment has been minimized.

Copy link
Author

itbeyond commented Jun 7, 2018

@sdlime I am working to uploading some test data for you from my system. I am not convinced it is a MapGL client issue but will get a test case uploaded for you and we can confirm one way or another.

@norac89

This comment has been minimized.

Copy link

norac89 commented Jan 4, 2019

I have encountered a similar problem that is only present when using mapcache. The tiles are correctly aligned using mapserver alone. But when using mapcache (with mapserver/mapcache#166) I get the same kind of misalignment as mentioned in this issue.

@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented Jan 8, 2019

@norac89 can you confirm which version of MapServer you're using? Can you share a test case? I've not been able to reproduce using my test data but it's possible it's not useful for demonstrating the issue at hand...

--Steve

@norac89

This comment has been minimized.

Copy link

norac89 commented Jan 8, 2019

I am using Mapserver built from branch-7-2 and Mapcache built from master with pull request 166.
Both are in Docker containers.

Here is a repo with an example using docker-compose:
https://github.com/norac89/test_mapserver
The mapfiles are in /maps and mapcache config file is in /mapcache.

While zooming around, you should see the tile junctions showing only when using mapcache.

@itbeyond

This comment has been minimized.

Copy link
Author

itbeyond commented Jan 9, 2019

@sdlime I am also seeing this issue still in CGI use but not sure if it is Mapbox-gl. If I generate a tileset with maxzoom 14 and then go in past this to 16 or more I can see errors on many tile junctions. I thought I should be able to produce tiles to 14 and then zoom way past without this error. If I load the same data into the MB Studio and setup sourxes maxzoom 14 I can zoom to 22 without seeing the same problem. The tiles where built with 7.3-dev at the time as these are all cached but cached using cgi access to the mapserv process.

Examples: https://www.exploroz.com/eotopo/mapboxgl1.html#17/-31.806253/115.753463 - See the error around the Nimrod Place park and on the street lines below - if you zoom this out to 14 the error will go away. If you move around the map you will see the error appear all over the place at maxzoom 14 they seem fine. (Another/better location on the map- https://www.exploroz.com/eotopo/mapboxgl1.html#17.95/-31.770715/115.75282)

@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented Jan 9, 2019

Thanks @itbeyond, I'm looking into it again. I wonder (wish) if there is a reference data set (data/computed tiles/app). --Steve

@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented Jan 11, 2019

I re-setup the demo locally with tiles sourced from mapcache/WMS and mapserver native tile mode and I can confirm there is a subtle difference. It has to be an extent-related issue, hopefully just an off by one error. --Steve

sdlime added a commit to sdlime/mapserver that referenced this issue Jan 14, 2019

Identified difference between WMS and mode=tile sourced MVT output. W…
…MS doesn't set a cellsize so the half-pixel offset computation is off by a pixel (mapserver#5596).
@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented Jan 14, 2019

@itbeyond, are you using MapCache? I found the issue between mode=tile and WMS sourced images. WMS, with potentially non-square cells doesn't set map->cellsize. So much like with a scale denominator it needs to be computed at the top of msMVTWriteTile()...

@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented Jan 14, 2019

I commited a fix to mapmvt.c to branch-7-2. @itbeyond and @norac89, any chance you can test on your end? --Steve

@norac89

This comment has been minimized.

Copy link

norac89 commented Jan 15, 2019

I just tested it and everything seems to be working fine for me. I cannot see any tile junctions anymore.
Thank you Steve!

@itbeyond

This comment has been minimized.

Copy link
Author

itbeyond commented Jan 15, 2019

@norac89 you were using MapCache I assume, Are you able to set your tile source maxzoom to a lower number and zoom in past this and check your boundaries - I have maxzoom set to 14 and when I get to 15 or 16 it goes out of alignement - it is not every boundary (due I think to line direction/orientation but is easy to see if you have a line or poly that crosses a boundary at 45deg).

@sdlime my tiles have been generated using mode=tile from the cgi and cached using my own code. I have been wanting to implement MapCache for a while but just not gotten to it. I will load down the latest versions and test again using mode=tile and report shortly.

@norac89

This comment has been minimized.

Copy link

norac89 commented Jan 15, 2019

I have tested Mapcache until zoom of 18 (the default grid are defined from zoom 0 to 18) and I don't see any boundary on my layer.
While testing at those zoom levels I spotted another problem. When I go beyond zoom 18, Mapcache crashes (using spawn-fcgi and multiwatch behind nginx).

mapcache_1_82d9d5dd000b | Child[0] died, respawn
mapcache_1_82d9d5dd000b | Spawning child[0] failed, next try
mapcache_1_82d9d5dd000b | Spawning child[0] failed, next try
mapcache_1_82d9d5dd000b | Spawning child[0] failed, next try
mapcache_1_82d9d5dd000b | Spawning child[0] failed, next try
mapcache_1_82d9d5dd000b | Child[0] died to often, not forking again

Going back at zooms under 18, Mapcache seems to be working fine.
But this is a totally different issue...

EduardoCastanho added a commit to EduardoCastanho/mapserver that referenced this issue Jan 16, 2019

Identified difference between WMS and mode=tile sourced MVT output. W…
…MS doesn't set a cellsize so the half-pixel offset computation is off by a pixel (mapserver#5596).

@tbonfort tbonfort referenced this issue Jan 18, 2019

Merged

Vector tiles #166

@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented Feb 13, 2019

@norac89, @tbonfort identified issues in my MapCache pull request that may explain the crashes you saw. I've hopefully fixed those and the pull request has been updated if you'd like to give it a shot.

--Steve

@sdlime

This comment has been minimized.

Copy link
Member

sdlime commented Feb 19, 2019

I'm going to close this. If there are new or related issues let's create new, concise tickets for them. --Steve

@sdlime sdlime closed this Feb 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.