Directions zooms to route extent

[michaelpnelson]

When a route is first displayed, or its waypoints change, the map extent doesn't change, and users often need to zoom in to the route to see it clearly. This change gets a bounding box for all route segments and zooms to the corners of the bounding box (plus some padding).

[dgboss]

If the goal is to make the entire route visible I think the padding values could use some tweaking. For example, I created a route from 500 W Broadway, Vancouver to Abbotsford and saw the following:

It's good that I can see the route, but I still have to scroll/zoom to see the start and end points.

The trick is figuring out what the padding values should be. If you want to go with static values, I think you could safely go with something like self.map.flyToBounds(latLngBounds, {paddingTopLeft: [325,100], paddingBottomRight: [225,100]});
This should prevent overlap of the panel in the top left corner and the legend in the bottom right (if present).

You could also add some logic to detect if the legend control is enabled or not and adjust the bottom-right padding values accordingly. Such an approach might help maximize the use of screen space across SMK apps. If you wanted to get really fancy, you might be able to detect when a start/end point overlaps a panel/tool and adjust dynamically, though this might be a lot of effort for not a lot of reward.

[dgboss]

Approved as the user experience is definitely much better, but you might want to take my comment under consideration.

[michaelpnelson]

If the goal is to make the entire route visible I think the padding values could use some tweaking. For example, I created a route from 500 W Broadway, Vancouver to Abbotsford and saw the following:

It's good that I can see the route, but I still have to scroll/zoom to see the start and end points.

The trick is figuring out what the padding values should be. If you want to go with static values, I think you could safely go with something like self.map.flyToBounds(latLngBounds, {paddingTopLeft: [325,100], paddingBottomRight: [225,100]}); This should prevent overlap of the panel in the top left corner and the legend in the bottom right (if present).

You could also add some logic to detect if the legend control is enabled or not and adjust the bottom-right padding values accordingly. Such an approach might help maximize the use of screen space across SMK apps. If you wanted to get really fancy, you might be able to detect when a start/end point overlaps a panel/tool and adjust dynamically, though this might be a lot of effort for not a lot of reward.

Yeah, I punted on accounting for panels because of the complexity of determining which tools are active and the width/height calculations. I'll try out your suggestion.

UPDATE: I did some further testing and found that larger padding values don't work well with smaller screens (phones). For example, using Chrome's Developer Tools to simulate the view on an iPhone SE (with a width of 375), padding of 200 results in weirdness (it zooms waaaaaay in).

I'm leaning towards keeping the padding at 100 as it works reasonably well. I don't think any particular padding value will work well for all screen sizes and tool combinations, and I think it's acceptable for the user to do a bit of zooming in the minority cases when ends of zoomed segments are under a tool - it's less zooming than before.