Don't overzoom large (city-sized) POIs #161
Conversation
Previously we zoomed to the "point" of any POI to a zoom level that seemed optimized for building-sized points. For large features, like an entire city, this meant zooming way in to some seemingly random part of the city. Now we prefer the bbox whenever available instead of the point. With this commit, zooming works reasonably for city-sized objects and the node-based POIs, which have no bbox such as: e.g. Overcast Coffee Company - "id": "node/4349270303", But some small venues are defined as an osm way, and thus have a Bbox. With this change we're now zooming a little too close (IMO). An example of a too-close zoom: e.g. Victrola Coffee Roasters - "id": "way/206623301"
Some building POI's are stored as OSM ways, this means they have a bbox, but using that bbox for zoom results in feeling a bit too close - losing the valuable context of the surround block. An example of a too-close bbox zoom that this commit fixes: Victrola Coffee Roasters - "id": "way/206623301",
michaelkirk
force-pushed
the
mkirk/poi-zooms-to-bounds
branch
from
647278e to
64e348b
Compare
There was a problem hiding this comment.
Looks great, I'm going to test this just to make sure it behaves smoothly though. I might get to it in the next hour or so but otherwise it'll be tomorrow sometime. In the future it would be really cool to draw a polyline around admin areas but I'm not sure pelias exposes admin area shapes so that could be hard.
Yeah I agree. The existing "pin" UI seems inappropriate for a big 2-D entity like a city. (edit) I created an issue here: #163 |
|
Running a build to test this now. |
|
Looks great, but I noticed during testing that I think I broke URL rewriting when you search >1 thing back-to-back without pressing the "x" button in the search bar. |
|
I need to think a bit harder about how to structure the BaseMap API. I tried to rewrite it partially and I think I made everything worse. 😅 |
This is a followup to #153. Now that you can select localities, the zoom feature feels a little off.
before:
So now, when available, we prefer to use the bbox for fitting rather than the coordinate. This works much better for large POIs (e.g. "Seattle").
after zooming to bbox (first commit):
So zooming in/out to Seattle looks good with the first commit, but zooming into Victrolla loses valuable context of the surrounding neighborhood. This is because, while many small venues are represented as OSM.Nodes, thus lacking a bbox, some (like Vitctrolla) are actually stored as OSM.Ways and thus have a bbox.
So the second commit introduces a maxZoom, ensuring that if we are zooming to a Bbox we never zoom too close.
before second commit (too close to small osm ways)
after second commit (with max zoom)