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

Issues with 512px zoom 8 128/84 tile (Colchester, England) #1481

Closed
Unigoge opened this issue Mar 28, 2018 · 8 comments
Closed

Issues with 512px zoom 8 128/84 tile (Colchester, England) #1481

Unigoge opened this issue Mar 28, 2018 · 8 comments
Labels

Comments

@Unigoge
Copy link

Unigoge commented Mar 28, 2018

  • 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:
    screen shot 2018-03-28 at 3 01 31 pm

bad JSON:
bad JSON

bad MVT:
bad MVT

@nvkelso
Copy link
Member

nvkelso commented Mar 29, 2018

@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.

@Unigoge
Copy link
Author

Unigoge commented Mar 29, 2018

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.

@m-abboud
Copy link
Contributor

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

@m-abboud
Copy link
Contributor

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

@zerebubuth
Copy link
Member

zerebubuth commented Apr 23, 2018

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.

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 mapbox-vector-tile library which tries to make the polygons valid and sensible, but there are many known issues with it.

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 tilequeue.

kinda seems like the default should be 512 for the single tiles without having to do that yourself though

If you want to change the tile size without needing code changes, you can use URLs like http://your.tile.server/mapzen/vector/v1/512/all/z/x/y.mvt (note the /512/ between /v1 and /all, which is the {tilesize} parameter in the docs).

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.

@m-abboud
Copy link
Contributor

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

@m-abboud
Copy link
Contributor

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.

@nvkelso
Copy link
Member

nvkelso commented Sep 25, 2018

Closing for lack of activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants