What is the bug?
I have discovered a couple of edge cases where having a bounding box:
class OverlayImage extends BaseOverlayImage {
final LatLngBounds bounds;
// ...
... in addition to the bounding box I added to support polar projections:
Positioned buildPositionedForOverlay(FlutterMapState map) {
// northWest is not necessarily upperLeft depending on projection
final bounds = Bounds<num>(
map.project(this.bounds.northWest) - map.pixelOrigin,
map.project(this.bounds.southEast) - map.pixelOrigin,
);
// ...
... will create a bounding box of incorrect size / incorrect position. Not way off, but noticeably.
What is the expected behaviour?
Image positioning issues should not occur.
How can we reproduce this issue?
Trying the EPSG:3413 example reprojected in EPSG:3996
Do you have a potential solution?
In my fork I solved this by changing bounds to a List<LatLng>. This would be a breaking API change. Should I make a PR for 3.0.0?
Can you provide any other information?
No response
Platforms Affected
MacOS
Severity
Obtrusive: Prevents normal functioning but causes no errors in the console
Frequency
Consistently: Always occurs at the same time and location
Requirements
What is the bug?
I have discovered a couple of edge cases where having a bounding box:
... in addition to the bounding box I added to support polar projections:
... will create a bounding box of incorrect size / incorrect position. Not way off, but noticeably.
What is the expected behaviour?
Image positioning issues should not occur.
How can we reproduce this issue?
Do you have a potential solution?
In my fork I solved this by changing
boundsto aList<LatLng>. This would be a breaking API change. Should I make a PR for3.0.0?Can you provide any other information?
No response
Platforms Affected
MacOS
Severity
Obtrusive: Prevents normal functioning but causes no errors in the console
Frequency
Consistently: Always occurs at the same time and location
Requirements
flutter doctorfinds no relevant issues