abrensch / brouter

configurable OSM offline router with elevation awareness, Java + Android
MIT License
490 stars 118 forks source link

Consider surroundings #258

Open nrenner opened 4 years ago

nrenner commented 4 years ago

Beside the tags on a way itself, more useful information could be derived from the OpenStreetMap features around it, in order to get more pleasant, quiet and safe routes for example.

Some examples:

Link collection (non-exhaustive, feel free to edit): Consider surroundings (brouter-web Wiki)

One potential approach might be: A parallel/separate process to the BRouter map-creator pipeline (that builds the rd5 segment files):

  1. filter and generate geometries from the OSM planet file and incremental updates using Osmium, which is probably one of the most advanced tools for multipolygon handling
  2. use the JTS Topology Suite (Eclipse Public or Distribution License) with geometry operations like buffer and intersect to find nearby and enclosing objects
  3. add properties of surrounding objects as pseudo tags to the way, either through a plugin to the BRouter pipeline or as a post-process for segment files
polyscias commented 4 years ago

I read earlier about this either in one of the issues or in the OSM Andriod bikerouting group.

There a link to Generating Customized Pleasant Pedestrian Routes Based on OpenStreetMap Data was posted and I downloaded the paper but that has not fine details on how exactly greenness is calculated. I remember emailing them but never got a response.

They write they have plans to integrate it into openrouteservice, but this issue suggests that is not done (yet).

This article, Finding Pleasant Routes Using GIS, list apart from the paper above also some cycling related research that looks good but that brings the point if openstreetmap data is enough to make a good estimate on how pleasant it is to cycle.

In the Netherlands the cyclists lobby club has an own route planner, https://routeplanner.fietsersbond.nl/. When you select under "meer opties" Natuurroute you get a route that remains outside built-up areas as much as possible and goes through nature as much as possible. Outside of 'real' nature, you cycle as much as possible through open countryside, and within built-up areas as much as possible along parks or via cycle paths or roads with lots of greenery and few cars.

The fietsersbond can offer this as they have their own map-data that includes attributes that are needed for this.

zossebart commented 4 years ago

This guy implemented something similar for foot-routing (different routing engine): https://trailrouter.com/blog/how-trail-router-works/

Maybe this could help to implement this feature for brouter as well?

usrusr commented 4 years ago

When baking custom rd5 tiles is an option, a generic approach could consist of sampling a bitmap value for arbitrary "attractivity metrics" during network preparation. Similar to how elevation is baked into the rd5, just with simpler evaluation (consider absolutes instead of relative change). Filling those bitmaps could be left as an exercise outside of brouter, like a plugin interface. Generic bitmap tagging support.

Metrics could be usage heatmaps (strava, garmin, ridewithgps are doing that in their routing engines), proximity to major roads and industry vs scenery (render a map of industry and major highways in black, parks and rivers white, on a grey background, apply blur like there's no tomorrow) or something else entirely (a map of avalanche risk areas for winter hiking?)

utagawal commented 2 years ago

Feeding data coming from Strava heatmaps, Garmin Data or a collection of activity files his would something very interesting to improve the routing capabilities for Mountain Biking in BRouter.

Any possibility to leverage from the tool mentioned from the post above ?

This guy implemented something similar for foot-routing (different routing engine): https://trailrouter.com/blog/how-trail-router-works/ Maybe this could help to implement this feature for brouter as well?

nrenner commented 2 years ago

Metrics could be usage heatmaps (strava, garmin, ridewithgps are doing that in their routing engines) [...]

Feeding data coming from Strava heatmaps, Garmin Data or a collection of activity files [...]

Deriving data from proprietary heatmaps like Strava would most probably violate their terms. I'm not aware of any open activity data, except a bunch of tracks donated to OSM traces by ex-gpsies.com users. And we currently don't have the means to collect our own.

Any possibility to leverage from the tool mentioned from the post above ?

trailrouter.com is not open source, so not really. The blog post is a nice insight, but not the only one, I'm collecting such posts and papers in the linked wiki: https://github.com/nrenner/brouter-web/wiki/Consider-surroundings

So always interested in more infos and ideas like this.

I guess the most common approach and my idea for this is to check intersection of ways with (OSM) landuse polygons (park, forest) and buffer + intersect/Intersection for nearby objects (river, lake, busy road).

utagawal commented 2 years ago

Indeed. I'm in charge of https://www.UtagawaVTT.com and keen to use the 15 000+ MTB tracks we have to improve routing specificaly for Mountain biking, so if you have suggestions on how we could leverage for the data (without necessary having them imported in OSM) let me know.

nrenner commented 2 years ago

One idea might be to match GPS tracks to the road network (requires #222), count the number of tracks per way and somehow encode that as (MTB-)"popularity" in the routing data files (.rd5), maybe similar to estimated_traffic_class.

Another idea is to improve the elevation model with barometric measurements from GPS tracks (Strava, GIScience poster).

Would be great if such results could be shared somehow, but the development would probably need to be done by someone with access to tracks like you.