[BUG] MapState methods do not support rotation

[Zverik]

While the _rotation field is stored in MapState, and recently we've got rotation support in MapController(#1115), core methods in MapState do not account for rotation anywhere. For example, layerPointToLatLng produces wrong results when the map is rotated.

Looks like fixing project and unproject would be enough.

Flutter_map 1.1.0.

[ibrierley]

A project/unproject shouldn't take into account rotation.

However, in your case, sure you aren't looking for pointToLatLng which does into account rotation ?

[Zverik]

Well yes, I meant that if we're not changing these two methods, then we would need to change ~5 other, including pointToLatLng.

[ibrierley]

I'd step back a bit and describe what you are trying to achieve and a minimal example. Not all methods should account for rotation, so it's hard to figure if there's any bug or not.

[JaffaKetchup]

@Zverik Any news? Please try and find a minimal reproducible example, that would help a lot :)

[Zverik]

I've looked over the MapState class, and these are the methods that I think need to take rotation into account:

• getBoundsZoom() (used in getBoundsCenterZoom() and fitBounds(), otherwise bounds don't fit when the map is rotated).
• getPixelBounds() (used in getBounds(), not sure about this, but might be incorrect when rotated).
• layerPointToLatLng() (basically same as MapControllerImpl.pointToLatLng, but for plugins).

I've personally encountered issues coming from the first and the last item: fitBounds does not work properly when the map is rotated, and obviously layerPointToLatLng also fails. I wonder why the latter method is different for MapState and MapController.

[ibrierley]

Yes, I think some of those may make sense for the bounds ones (or at least make sense to have an option there...it may depend if other code is making allowances elsewhere), needs a bit of digging.

I think the reason layerPoint is specifically called that, (rather than point), is probably that it's expected for it to be in layer coordinate space. I.e if the point came from a rotated layer, rotation shouldn't matter, and I suspect that would break (however as we only seem to use it directly on a center point, maybe that would work accidentally..I don't even know if we need it as it just does an unproject). However, we also have nonrotatedlayers now, just to add to the confusion there :D. I wonder if anyone actually uses that.

[ibrierley]

What may be useful is to create a minimal typical example that would use these methods, that we can test against, to make sure it works (and any future changes).

[JaffaKetchup]

nonRotatedLayers and nonRotatedChildren are essential for things like the attribution widget, and I think some plugins make use of it.

[Zverik]

Well I made a non-rotated map plugin (this one if you're curious) that adds an element to the map from an on-screen interaction, so I needed to have the transformation :)

[ibrierley]

And what about mapControllers pointToLatLng, does that not work ? As mentioned, a minimal example would be useful.

[Zverik]

Does a plugin layer have access to a map controller?

[ibrierley]

Ok sure, I think that maybe makes more sense then. Some of the methods available there should also probably be exposed to MapState (and there's a few exposed that maybe shouldn't be as well...).