Elevation / gradient source

dabreegster commented 1 year ago

Possible reference, https://www.liedman.net/2015/04/13/add-elevation-data-to-osrm/

dabreegster commented 9 months ago

The goal of this feature request is to incorporate elevation / steepness into od2net's route cost. I don't have time to tackle this directly, so I'm going to try and break down the steps and be around to help.

There's not one simple data source for elevation data. For now, I'm thinking people can specify their DEM file in config: https://github.com/Urban-Analytics-Technology-Platform/od2net/blob/ee269f4cf018248647c8b10135d184a8a27c8438/od2net/src/config.rs#L10
To start, let's just support GeoTIFF files that're projected in WGS84. That lets us use https://github.com/dabreegster/elevation and avoid the complication of GDAL and non-Rust dependencies. We could always revisit this later.
od2net creates a Network structure from OSM data. https://github.com/Urban-Analytics-Technology-Platform/od2net/blob/ee269f4cf018248647c8b10135d184a8a27c8438/od2net/src/network/mod.rs#L115 is the place we'd add elevation data. I'm not sure exactly what fields are useful -- maybe to start, just an optional steepness as a percent grade.
https://github.com/Urban-Analytics-Technology-Platform/od2net/blob/ee269f4cf018248647c8b10135d184a8a27c8438/od2net/src/network/create_from_osm.rs#L85 would be a good place to go calculate and store the steepness for every edge
Then we'd want to incorporate the steepness in the edge cost used. https://github.com/Urban-Analytics-Technology-Platform/od2net/blob/main/od2net/src/plugins/cost.rs is the code where that happens. I've had trouble in the past finding specific formulas of how to use steepness for cycle routing -- see https://github.com/a-b-street/abstreet/blob/b3982db88c6b342b78a82188cb823a25dbcfbf7e/map_model/src/traversable.rs#L258.
We'd want to plumb through steepness in the GeoJSON output and make the web app be able to color by it, optionally

Many many more notes at https://github.com/a-b-street/abstreet/issues/82 from an older project

KDKasonde commented 9 months ago

I can have a look at this issue!

dabreegster commented 9 months ago

Rosa pointed to https://github.com/U-Shift/Declives-RedeViaria/blob/main/SpeedSlopeFactor/SpeedSlopeFactor.md for how to use in cost functions

KDKasonde commented 8 months ago

I am looking at incorporating the steepness into the cost function now, but noticed the Edges do not directions attached (I could be wrong here). I am trying to think of a way to ensure the steepness is applied properly does anyone have any ideas?

Extra context: My plan so far is calculate the steepness for each edge from its start node to its end node, calculate a slope_factor then multiply the cost by the slope_factor to get an elevation adjusted cost. But the multiplication is dependent on either each edge having 2 representations (node1, node2) and (node2, node1). Or the cost augmentation adjusting the slope_factor if the traversal is the reverse of the edge.

Let me know if I have missed something or become misguided!

dabreegster commented 8 months ago

Very good questions! Right now, od2net mostly ignores direction -- the final counts of trips crossing a road are in either direction, and cyclists can route either way on an existing one-way. #19 is open to fix these. For the second part, this will become a user's choice -- respect current one-ways or ignore them. When planning possible extensions to a cycling network, something that's one-way for all traffic right now could maybe become contraflow for cycling. There are many successful examples of this in the UK (and a paper demonstrating the safety of it).

But I don't think we need to care about any of that here yet. Edge itself does not track the direction, but it is available: https://github.com/Urban-Analytics-Technology-Platform/od2net/blob/ee269f4cf018248647c8b10135d184a8a27c8438/od2net/src/network/mod.rs#L19 because the lookup for Edge is (node1, node2). So you could add slope_factor to Edge and define it as going from node1 to node2. When you're calculating it for every edge, the two nodes in order are available -- an example is https://github.com/Urban-Analytics-Technology-Platform/od2net/blob/ee269f4cf018248647c8b10135d184a8a27c8438/od2net/src/network/create_from_osm.rs#L94.

Then the second part would be using the slope in one direction or another during routing. Right now calculate_batch is only taking &Edge as input, so indeed we don't have enough info. We could either add node1 and node2 to the struct, or to keep the file serialization size smaller, just pass in the two nodes to this function as well. (I haven't done benchmarking to see if storing the nodes redundantly causes any issue. It's probably fine and something we could optimize later, if it's more convenient to just add the nodes.)

KDKasonde commented 8 months ago

Thank you, that makes sense. I will give passing in the node1 and node2 a go then! I will most likely check in again soon!

KDKasonde commented 8 months ago

anyone know where I can find tif files with elevation data? I have not been able to find any with elevation data inside!

dabreegster commented 8 months ago

https://play.abstreet.org/dev/data/input/shared/elevation/UK-dem-50m-4326.tif.gz This is one covering England. The od2net example configs for York (small area), Liverpool (medium), and England 2011 census (large) should be quick ways to start plugging this in somewhere