SW/NE fitBounds parameters in URL

[burritojustice]

leverage Leaflet's fitBounds so we can show a map of a predetermined area without having to worry about screen size (and leverage bounding boxes).

While we could pass two parameters:

https://tangrams.github.io/tangram-frame/?url=.../sw=40.712, -74.227/ne=40.774,-74125

maybe one is better?

https://tangrams.github.io/tangram-frame/?url=.../bbox=40.712, -74.227,40.774,-74125

that's SW lat/lon, NE lat/lon, as per leaflet fitbounds

http://leafletjs.com/reference.html#map-fitbounds

[burritojustice]

tried implementingfitbounds in #34 but rolled it back as it seemed to be conflicting with the lat/lon hash

[burritojustice]

how about this: if there are three numbers in the hash, assume /zoom/lat/lon, but if there are four numbers in the hash, assume /swLat/swLon/neLat/neLon for fitbounds?

[meetar]

Assuming that a fourth number implies totally different functionality could be confusing – but I think following the maxbounds convention could work, and be more transparent.

[meetar]

A counterproposal which seems to be working pretty well: how about a fitbounds parameter which, if included, runs map.fitBounds() with any included maxBounds parameter definition?

https://precog.mapzen.com/tangrams/tangram-frame/fitbounds/?maxbounds=8.073694229,68.162429718,33.232855536,97.176678&fitbounds&url=https://mapzen.com/api/scenes/22/17/resources/scene.yaml

[burritojustice]

Still can't see that in precog (🐴)) but this seems like a reasonable first step -- though would this also enforce maxBounds?

There's a difference between locking a users within an area, and setting an initial view that they can use as a starting point... (My initial concern with implementing fitbounds was that it was arguing with the URL hash.)