Address Issue-574.

[markpbaggett]

What Does This Do

This attempts to address ISSUE-574, but my logic is a little different than I originally suggested. Instead:

1. If we only have 1 point, setView at configured zoom like before, because a single point has no meaningful extent to fit into a view.
2. If we encounter anything else: a polygon, a line, multipolygons, or multiple points and need a MarkerClusterGroup, we use fitBounds to fit all geometry.

In other words:

1. We now calculated bounds via geojsonLayer instead of marker cluster groups. This means polygons, multipolygons, and lines would contribute to the viewport calculation as well.
2. Single features now only apply to actual points and we detect by checking if NE and SW corners of the bounds are identical, i.e. zero area.

Also, I added an isValid() guard so the map doesn't attempt to zoom on invalid data.

Here is a single marker:

Here is a rushed together polygon:

[DiegoPino]

Small performance review/check

[DiegoPino]

Hi. Small performance idea here

geojsonLayer.getBounds() can be expensive if we have many points and polygons and the method/class does not cache calculated version. So every call re-calculates. You have two calls. So I would suggest you do the following instead

const bounds = geojsonLayer.getBounds();
if (bounds.isValid()) {

then you don't need to re-call get bounds again or assign to a var bounds at all.

One feature (will an open issue, this one can go in anyways) I would love to preserve via a formatter setting/override is the idea of having still a way of setting a fixed zoom, or at least one that respects one issue we have found. Some tile sources don't have enough detail for certain zoom levels. So, if your polygon is very small, the automatic map.fitBounds(bounds) might respect the desired need of fitting it into the map, but might (for certain users that want the "context" basically render nothing as tile. I know its a fine grained need so will follow up with a different ISSUE that can wait until next release and won't affect by default this one at all

[DiegoPino]

@markpbaggett I tagged you a few weeks ago. All looks good but the const v/s var change request would be great for performance needs. Let me know if you have any questions about it. Thanks for your contributions!

[DiegoPino]

Ok, did not get a response. Will merge as it is BC if not I will start adding code over it and then we will have to rebase. I will do on top later on the performance optimizations