Ability to render multiple maps with same options

[roelandwyns]

Hi,

We have the following use case:

• a background map where we pass an image with some boundaries.
• multiple feature maps that we render on the background.

Staticmaps calculates the bounds for displaying the map based on the features on that map individually on the render. This means that if we have features that are outside of the boundaries of the background map, the centerX, centerY and zoom are recalculated and this does not work very well when overlaying the maps on each other. (Misaligned features on the background image).

What we do now as a fix for this is getting the { centerX, centerY, zoom } out of the background map, and using them in the render of the feature maps. (after re-converting x with xToLon and y using yToLat). This works perfectly, however it is not the cleanest.

• We have to use the xToLon, yToLat out of staticmaps to re-convert as a conversion happens in staticmaps when passing the center to a map render. Converting back- and forth all the time might not be the cleanest. Export of this helper function is missing in the types.
• These 3 properties (centerX, centerY and Zoom) are not public on a map (and we need to use them). Would be nice if we could get this centerX, centerY already converted back as well.

If needed, we can also look into creating a PR if you tell me your thoughts on this idea :) .

Kind regards,

Roeland

[StephanGeorg]

Hi @roelandwyns

Ok, I understand your use case and needs. But what would be the perfect solution for that? In JS you can access map.zoom, map.center, map.centerX and map.centerY properties. So you could at them to the type definitions.

[EvertEt]

Using these properties would indeed help to solve this. But wouldn't there still be a problem needing to convert map.centerX and map.centerY back and forth, possibly introducing slight errors?

[StephanGeorg]

Maybe but I can't see any solution on staticmaps side or feature that could be included into this module.

[EvertEt]

Since xToLon, yToLat aren't exported in the default export, it might be easier for us to calculate the center ourselves. And render the first map with center + addBound (undocumented?) and let it calculate the zoom. Then we can use the calculated center and the map1.zoom for the second map.

[EvertEt]

1. Would having a centerLat and centerLon property on the map next to centerX and centerY be acceptable?
2. Would you be open for a PR documenting addBound?

[StephanGeorg]

Would having a centerLat and centerLon property on the map next to centerX and centerY be acceptable? Would you be open for a PR documenting addBound?

Sure.