[BUG] Should polygon bounding box cache never be reset ?

[ibrierley]

What is the bug?

When investigating a problem updating flutter_map_line_editor I noted that polygons no longer display ibrierley/flutter_map_line_editor#47

I'm fairly sure the issue is this line...

LatLngBounds get boundingBox =>
      _boundingBox ??= LatLngBounds.fromPoints(points);

Where a poly bounding box is cached, which makes perfect sense. In the line_editors case, typically points are added/modified, rather than created anew (which is a possible workaround I've noted in the other issue).

So the bounding box needs to be updated in this case one way or another. Like I said, this can be forced by creating a new poly each time (which I keep fluctuating between it making perfect sense and other times not). However, it also made me think if this is quite correct on flutter_maps side.

If the poly has checks for equality for example (not sure where this is used), or needs a repaint as the points are changed, if it's not equal, then should the bbox cache be updated...or in general should the bbox ever be updated ?

It won't be an issue in flutter_map for most cases as the points rarely change, but wanted to double check for any further thoughts.

How can we reproduce it?

Run flutter_map_line_editor, but code has been highlighted in question.

Do you have a potential solution?

There is a possible workaround to recreate the polygon rather than amend it's points.

Platforms

All

Severity

Minimum: Allows normal functioning

[dannejosefsson]

Are there any discussions with regards to this issue? I'm utilising both these awesome libraries in a project and it would be neat to get it up to v7.

Could a tradeoff be to expose a setter to update the cache?

I'm happy to conduct some research if needed.

[JaffaKetchup]

I'm not sure tbh. I would suggest that it may not be correct usage to update the points of Polygons/Polylines, as this is more imperative than declarative, which is what the other changes in v7 push toward/require for performance.

[ibrierley]

Going to close as have a workaround.