Score mode

[dabreegster]

• Make much more configurable
• Popups cover up routes
• Display all parking, to sanity check results
• Some routes aren't shown
• Improve handling of positions along a road

[XioNoX]

Thanks That's awesome and already useful. Some more suggestions.

• In "Make much more configurable":
  • Add a toggle to hide POIs with good score
  • Customize the distance thresholds
  • (optionally) Customize the POIs to display
• Add more POIs types (at least shop=*, more amenities, like what's in Isochrone mode)
  • Later on, once customization is possible maybe even office=*, and building=apartments
• Cluster POIs, for example with a size circle, to show areas needing parking the most
• Bugs (maybe similar to your last 2 points)
  • https://www.openstreetmap.org/node/7801227489 doesn't seem to find the nearby parking https://www.openstreetmap.org/node/11673319730
  • Routing is sometime odd

[dabreegster]

For the first bug with the missing parking, it's just because the OSM data in the built-in example areas is old, before that parking was added:

If you import from Overpass, it sees the new parking:

The route preview isn't shown because the pub and parking are on the same edge. That's also why it's a huge 169 seconds; it's just crossing the entirety of that road.

So, one of the next big improvements to fix this and other problems is handling more precise positions along a road

[dabreegster]

(And a good TODO would be to capture the latest timestamp in the input OSM data and display it somewhere for clarity; this kind of problem has come up a few times. I could also think about regularly updating the OSM extract)

[XioNoX]

Thanks for the quick turnaround ! The tool is already proven useful !
In the "Pick types of amenity to search from" dialog, it would be useful to have a "select all" option. Maybe hide the bicycle_parking option, even though it's probably useful for troubleshooting by showing how far bike parking is from itself :)

[XioNoX]

Annoter useful feature would be to be able to export the POIs (or generate the matching Overpass query) that are too far from any bike parking (while specifying a cut-off distance).

[dabreegster]

Annoter useful feature would be to be able to export the POIs (or generate the matching Overpass query) that are too far from any bike parking (while specifying a cut-off distance).

I added a download button at the bottom of the sidebar. You get a geojson file with points for each amenity you selected, with:

• poi as the name/description of the amenity
• cost in seconds to the nearest bike parking
• closest_lat and closest_lon of that parking

[dabreegster]

Rethinking the purpose of the score mode... people want to see how far different sources (chosen POIs) are from the nearest destination (bike parking for now, but could be configurable). What about a different way of showing this -- drawing isochrones around every bike parking, and highlighting the chosen POIs? Some will be within the isochrone, nice and close, but if you want to find gaps in coverage with lots of demand, that seems like it'd be intuitive? There's a whole complex space of "where is it optimal to place the new grocery store" analysis that also makes sure a destination has enough capacity to meet all the demand nearby, but the multi-isochrones is a simple start.

[dabreegster]

I started this (hardcoded to parking as the sources), but not sure how useful it'll be. Next step would be letting you pick the kind of destination you care about and showing those, to find the gaps. Depending on the use case here, it gets harder -- for cycle parking, the max time away is one or two minutes. But the algorithm is starting the search from the nearest intersection, not exactly where the parking point is. In dense cities it's fine, but if there's a point in the middle of a long road, it loses some detail.

Anyway, let me know if this idea seems potentially useful and I'll whittle away at it as I have time!

[XioNoX]

I worry that the multi-isochrone becomes more difficult (less precise) to read, especially as we're dealing with small distances (bike parking should be a few meters walking away from POIs to be useful). But if there is no nearby POIs there is no need for a street to be "covered".
The current score "many-to-many" mode could also be useful to city staff to figure out placement for collective compost or recycling based on distance from housing.

I can also imagine use-cases for the "coverage" mode (eg. "which areas of the city are further than 20min walk from daycare/supermarket/bar") so to me it's serving a different purpose than the "score mode".

Thinking out loud, I'm wondering if the source/target could be something customizable, where in "advnanced mode" the user enters a list of OSM tags, or a overpass-like query terms. So you don't have to implement every possible source/destination types ?

Also in addition to the "foot/car/bike/PT" profiles, maybe a "bird" could be useful, that just looks at a straight line (and a distance instead of time?)