-
Notifications
You must be signed in to change notification settings - Fork 120
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
Issues with 512px zoom 8 128/84 tile (Colchester, England) #1481
Comments
@Unigoge Are you generating the tiles locally or using the Nextzen endpoints or? It looks like the data is correct in that the TopoJSON format shows everything correctly, but GeoJSON and MVT show different levels of wrong. Is this what you're experiencing? /cc @zerebubuth as this smells like polygon validity funk. |
Yes, all tiles were generated on my server. It was built using 1.4.1 release (and corresponding to it tilequeue and tileserver releases). The database was populated by OSM planet data by the end of February. |
Have the same issue with 1.4.3 and did my import in march. This also happens on a tile to the right of Boston at zoom 9 155/189 |
Figured it out (or how to fix it at least). Found out tilequeue defaults to 256 size for non zipped meta tiles. So if you're just caching mvt's by themselves it uses the 256 size which I assume you're also doing since we had this same exact problem. I'm not really sure why this would cause the ocean to be missing entirely from some tiles though but it's definitely the cause of it. So to fix it without having to use the zipped meta tiles and tapacatal you can change the default tile size in tiles.py by changing the metatile default zoom from 0 to 1 in two functions at the bottom, metatile_zoom_from_str and metatile_zoom_from_size or see this commit: apollo-mapping/tilequeue@b2d1ca2 Since everyone uses 512 kinda seems like the default should be 512 for the single tiles without having to do that yourself though |
The 512px and 256px tiles have different coordinate transformations for MVT and GeoJSON formats. Both of these are truncating the coordinates in different ways, which can cause polygons to become invalid. There is a lot of code in our Using a different tile size (i.e: 512px vs 256px) could help, but it's likely that you'll find similar errors - just in different places. We did a little proof-of-concept to try and fix it 🤞, but haven't got back around to the due diligence necessary before we can use it in
If you want to change the tile size without needing code changes, you can use URLs like As for why it's the default... it's just historical reasons. When we launched the Tilezen service, the tile size was fixed at 256px. When we added the ability to request different tile sizes, we needed to be backwards-compatible with the previous URL structure so that we didn't create problems for existing users. |
Gotcha But changing url to http://your.tile.server/mapzen/vector/v1/512/all/z/x/y.mvt won't fix tilequeue defaulting to 512 for the cache created by tilequeue that gets hit first before it hits tileserver |
Or more clear, theres no option to change the tile size when you're storing plain mvts vs the zipped 512+256 ones so a code change is necessary for those too time deficiant to setup tapacatl as well. And which is why at the top where he says he's using 512 ones and probabley going to the /512/ url he's actually using 256 ones. |
Closing for lack of activity. |
What did you see?
Ocean coastline is missing on MVT tile
Ocean coastline includes at least one wrong polygon on JSON tile (probably a result of polygons unification)
What did you expect to see?
an Ocean coastline - it is getting rendered properly on TopoJSON tile :)
What map location are you having problems with?
512px zoom 8 128/84 tile (Colchester, England)
Screenshot? Props for animated gifs.
good TopoJSON:
bad JSON:
bad MVT:
The text was updated successfully, but these errors were encountered: