Ditch TileLayer zoomOffset

[mourner]

@jfirebaugh suggested an API change that would make using tiles with non-256 tile sizes MUCH more intuitive:

• Map-wide "base tile size" option that controls "how big z0 is" on screen
• Per-layer tileSize option
• No per-layer zoomOffset option. The appropriate zoom offset for a given tile layer can be calculated based on the ratio of map tileSize to layer tileSize.

The current hack of specifying both tileSize and zoomOffset cause confusion very often. I think it would be good timing to get the change into master soon so that it's in 1.0 final, if everyone agrees on it.

We could make this an option of Map, but it really belongs to CRS. 256 as the base width on z0 is currently hardcoded in CRS. We could make it a property of CRS and then use it for figuring out the right zoom offset in the tile layer. It would be used like this:

L.map('map', {
    crs: L.extend({}, L.CRS.EPSG3857, {baseSize: 256})
});

This is a bit cumbersome though, so maybe we would just introduce a baseTileSize Map option that would change the CRS one under the hood. What do you think? Is there a better approach?

@perliedman also, would a potential change like this possibly cause problems with Proj4Leaflet and custom projections?

cc @IvanSanchez @yohanboniface @perliedman @patrickarlt @hyperknot

[jfirebaugh]

I like the idea of having a baseTileSize map option that sets the CRS one under the hood.

For reference, there are a couple past issues relating to zoomOffset that we may need to take into consideration:

• 3793 (not sure if this use case would still be supported if we remove zoomOffset)

• 3817

[perliedman]

@mourner it does indeed sound elegant for spherical mercator and similar projections that cover the whole world, but I have a bit of a hard time grasping how it would work for the local projections that Proj4Leaflet support.

My main problem is the terminology "how big z0 is on screen", because it seems to assume there's some hard definition what should fit into z0. For most local projections, what fits into z0 is rather arbitrary. For example, most local projections I've come across cover more than one tile even at z0. z0 is usually chosen as "smallest scale that visually makes sense" rather than "covers the whole area in one tile".

I agree that zoomOffset and tileSize are indeed easy to mess up and get confused by (I know I'm confused every time I look at the retina code), but they are pretty straight forward when working with local projections and adapting to some weird tiling service.

Maybe I just haven't got my head around how your suggestion would work, but it feels a bit unintuitive from the perspective of local projections.

[patrickarlt]

Personally I haven't run into this (probably becuase I don't use non-256 tiles) but zoomOffset was very easy to get my head around. What is the use case for non-265 AND zoomOffset? Is this something that people really need to do all that often?

If this solves issues that people have thats great but if it causes problems downstream in Proj4Leaflet, it might not worth the effort and maybe just make some better docs for non-265 tile users.