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

What is range and zoom really doing? #50

Closed
Naphier opened this issue May 3, 2017 · 7 comments
Closed

What is range and zoom really doing? #50

Naphier opened this issue May 3, 2017 · 7 comments

Comments

@Naphier
Copy link

Naphier commented May 3, 2017

I've tried a few settings for these to get an idea, but they still seem to be a bit of a mystery and I cannot find a reference for them in the documentation. Is there an explanation I'm missing (maybe the API calls it something different)?

As a Unity developer I really need 2 things:

  • A calculation of the overall scale in world units
  • A unity world unit to meters ratio

With those 2 things I can easily design my requests to get the tiles I need.

@david-rhodes
Copy link

@Naphier Apologies, the documentation is sort of nested: https://www.mapbox.com/mapbox-unity-sdk/docs/03-examples.html#mesh-generation-basics (documentation is still WIP).

Range essentially describes how many tiles you would like to load in each direction from the center tile. 1 x 1 x 1 x 1 will load a 3 x 3 grid of tiles. We could name this better 😏.

Zoom describes which zoom level you would like to request for each tile. See:

Regarding the calculations and conversions, the world scale factor is recorded in MapController as WorldScaleFactor. This is also what the local scale of the root object is set to. Our conversions.cs class contains a bunch of methods that might help you.

Alternatively, you may want to write your own implementation of MapController that uses TileCover. This makes it easy to get all the tiles in a geographic bounds.

Can you share more about what sort of map you're trying to build?

@Naphier
Copy link
Author

Naphier commented May 4, 2017

That description of range helps it to make sense.

So if I have a tile size of say, 100 and range of 1,1,1,1 I would expect a 300m square. But that's also dependent on zoom level. According to documentation I can request zoom level of 0 - 22 (would be good if you guys limited this with a Range attribute in the Unity inspector). If I request less than 5 all I get are black textures (sometimes ? mark textures). If I request higher than 18 then the snap y to zero doesn't seem to work properly (tiles are maybe out of range of the raycast?). If I request higher than 19 then not only does the snap to y no longer work, but I also get ? mark textures. This is using mapbox://styles/mapbox/satellite-streets-v9.

.

It seems that a zoom level of 17 is close to 1:1 when I'm using:

  • Tile size: 200
  • Zoom 17
  • Range 5,5,5,5

Ultimately, I think it would be more useful to Unity devs to be able to simply define a Unity world unit to map meters ratio, overall map size in Unity units (i.e. meters for most), and pixel density for images. I'm less concerned with entering a geographic bounds than just having control over the map unit to Unity world unit ratio. Does this make sense?

@david-rhodes
Copy link

So if I have a tile size of say, 100 and range of 1,1,1,1 I would expect a 300m square. But that's also dependent on zoom level.

This is not quite true. 100 represents how many units in unity each tile is. Zoom level plays no factor in this.

If I request less than 5 all I get are black textures

Known issue: #42, apparently due to crazy scale values.

If I request higher than 19 then not only does the snap to y no longer work, but I also get ? mark textures.

@brnkhy can you look into this snapping issue? Please note that zoom > 19 is technically only supported in certain locations.

Ultimately, I think it would be more useful to Unity devs to be able to simply define a Unity world unit to map meters ratio, overall map size in Unity units (i.e. meters for most), and pixel density for images. I'm less concerned with entering a geographic bounds than just having control over the map unit to Unity world unit ratio. Does this make sense?

If you ensure the localScale of worldRoot is 1, you will have a 1:1 scale with the real world (and now TileSize is a non-factor. Using this as your basis, you should easily be able to decide your own relative scale.

That said, it might make sense to create another implementation of MapController to perform the conversions you mentioned above (or maybe a different editor implementation).

@david-rhodes
Copy link

@Naphier develop now has an ITileProvider and AbstractMap (which is not quite abstract yet 😏 ). Using these abstractions, you should be able to create your own implementations much easier. Let me know if I can help clarify or point you in the right direction.

@janovrom
Copy link

Is there any reason for specifying the size of tile? It can be quite easily computed based on zoom. Each zoom has some specific resolution in meters per pixel of heightmap. Since we know the size of tile, which is 256, then given latitude, it is easily computed as 156543.03 meters/pixel * cos(latitude) / (2 ^ zoom).
For further reference: http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames#Resolution_and_Scale

@david-rhodes
Copy link

@janovrom

Is there any reason for specifying the size of tile?

Yes. We figure some developers will want control over the "scale" of their world. Gigantic worlds can cause all sorts of bugs. However, this is just one implementation (which is why we're in the middle of abstracting maps and tile providers). Most of these are application specific, and many developers have different needs.

Also:

public static float GetTileScaleInMeters(float latitude, int zoom)

@david-rhodes
Copy link

Since we have added ITileProvider (and AbstractTileProvider), you can now easily create your own system for requesting/disposing of tiles.

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

No branches or pull requests

3 participants