[BUG] tileSize parameter is broken

[bramp]

What is the bug?

The TileProvider(tileSize: ) argument does not seem to produce desired maps when set to a value different than 256.

JaffaKetchup did testing in #1668 (comment) here are the appropriate screenshots that show the issues:

These maps are all meant to be centered on England, and you can see that wrapping around the global does not work correctly.

If we also look at MapBox's Static API, a 512 tile, is the same as the 256 tile with the same x, y and z, just at a higher resolution.

How can we reproduce it?

Checkout the example Retina/TileSize page: #1668 or create a map with

TileLayer(
   tileSize: 512
)

Do you have a potential solution?

Sorry no.

Platforms

Chrome

Severity

Erroneous: Prevents normal functioning and causes errors in the console

[JaffaKetchup]

Just to note, they are not all necessarily supposed to be centered on England. However, when changing the FM tile size setting, the map does just 'jump' to a different location, which is incorrect.

[V3ntus]

Having this issue as well. Another thing is that this changes where markers or polylines for example are rendered. When using a 512 tile server and setting the tileSize to 512, my polylines are rendered in the middle of a sea:

In comparison to their correct location when using 256 (default):

[readyiman]

I have same issue. Tile request for 256 is 4x of 512 btw, which will affect cost.

[JaffaKetchup]

The issue occurs because of these lines:

flutter_map/lib/src/geo/crs.dart

Lines 62 to 66 in 6170df9

	/// Zoom to Scale function.
	double scale(double zoom) => 256.0 * math.pow(2, zoom);
	/// Scale to Zoom function.
	double zoom(double scale) => math.log(scale / 256) / math.ln2;

These assume a tile size of 256. Manually changing these to 512 when using tileSize 512 restores correct functionality.

However, fixing this is likely to be a little difficult, because the Crs is completely seperate to any TileLayer. Although we sometimes have requests to support a different Crs per TileLayer, this comment - #890 (comment) - covers why that's possibly a bad idea.

Therefore, there is an issue here of overall structure - the Crs should not really depend on a value from the TileLayer, but neither should the other layers if we move the multiplication out (or add an argument). I'm really not sure what the best way to solve this is.

[JaffaKetchup]

To fix this issue, use zoomOffset: -1. There's not really much we can do (as described above), and it was also the fix recommended on Leaflet: Leaflet/Leaflet#4391.
I'll add this to the documentation.

[readyiman]

To fix this issue, use zoomOffset: -1.

I can confirm this solution does work.