Zoom Levels

Coordinator
Jan 29, 2009 at 6:42 AM
Doing the documentation and thinking about the fact that we are using the Virtual Earth Zoom Level system across the whole project.
I wonder if this is a good thing, should we be using something a little more generic like the MSI levels (where n is the whole world @ 2^n pixels) ?

I just notice that we have conversions at the generic TileSource level to convert this while this could be moved to where it actually matters, the veTileSource.
Coordinator
Jan 29, 2009 at 7:23 AM
To add to this we current have too things:
tile level - MSI 2^n thing
zoom level - where we pretty much hard code this to be tile level - 8 to equal the Virtual Earth system.

Why this is important is when you start configuring what zoom level you geometry is visible at do we really want this to be tied to a particular TileSource ZoomLevel, I don't the complexity of doing conversions.

Who thinks we don't need this complication and should just have one consistant level throughout the project? Personally I wouldn't care if street level was called "24" rather then "16".
Coordinator
Jan 29, 2009 at 4:21 PM
Edited Jan 29, 2009 at 4:50 PM

Couple of thoughts.  Tile providers such as Google, Microsoft, Yahoo, etc all use the same value for zooms (zoom^2 * tilesize).  This has been around long before the MSI.  Also, I am not sure when we started branding this as the "VETileSystem".  This suggests that this is something unique to MSFT.  However, this seems to be the generically accepted levels of many QuadTree based Tile Systems.  I think it would be the tail wagging the dog to change all our calculations to have all the zooms correspond to the MSI rather than the levels that a generally understood by the map tile providers.

It would be great if we could have one consistent level.  However, it is the MSI which is not in alignment with most GIS systems.  Perhaps you can ask MSFT to change the MSI levels. ;-)  Actually, I don't think it is a big deal.  The MSI, is obviously not designed to only work with GIS, and there is only a single adjustment at the point where MSI is involved, the GetTiles() API. 

Coordinator
Jan 29, 2009 at 9:21 PM
Except that Yahoo actually reverses their zoom level with level 1 being fully zoomed in. And Virtual Earth now offers tiles as 64px to suit mobile apps yet retains the old zoom level ;)
It seems to me that we make an adjustment per TileProvider anyway, just that we default it to (-8) as this suits VE and OSM.

The main bit for me is the complexity of having two different levels, tile and zoom. Is it really needed, could we not just use 2^n rather then (2^n + 2^8)?

Other side thing to think about is whether we will support other tilesizes, how if at all this will change the zoomlevel. My thought is this shouldn't change the level.
Anyway not something to rush into changing it all works at the moment.
Coordinator
Jan 29, 2009 at 9:48 PM
Edited Jan 29, 2009 at 10:20 PM
There is a mathmatical beauty in that all of our calculations are based on the simple notion that there is a direct mathmatical relationship between width and zoom.  You can always get one from the other since Width = 2^Zoom * PixelsPerTile.  So we do in fact account for Tile size changing.  There was a post not long ago of someone who is using our project for tiles that are 320x320.  If we were to remove this as you suggest with you (2^n, or 2^Zoom), it simply wouldn't work.  Sounds like a case of tile envy.  Tile size does matter. 

Thought more about what you are saying here.  We can default it to what is most commonly used.  Essentially that is already being done via the TileToZoom, ZoomToTile Adjustments.
Feb 6, 2009 at 7:21 PM
I think this is what is causing problems with creating an ESRI tile provider. If you look at one of the online services such as http://server.arcgisonline.com/ArcGIS/rest/services/ESRI_StreetMap_World_2D/MapServer you can see all of the zoom levels, resolutions, and scales. You can also see the differences in full extent, the ESRI services go from pole to pole and have their origin (tile 0,0) at -180,90.
Feb 16, 2009 at 7:37 PM
Another option is taking a dependency on GDAL and warping the tiles from EPSG:4236 to Spherical Mercator after you request them. We used this in WorldWind so we could accept all other projections and it didn't slow things down much at all, especial since we were caching the tiles afterwards. 

Or, if someone was so inclined you could do the projections manually.