Elevation data #82
Comments
|
http://brouter.de/brouter/elevation.html for reference |
|
All those references to better lidar data for washington, thanks to Michael Patrick from CUGOS:
|
|
Seattle only and old data, but looks detailed: https://data-seattlecitygis.opendata.arcgis.com/datasets/contour-lines-1993 |
|
There's an R package that takes OSM data and calculates gradients in the surrounding area that can provide ideas/inspiration for this: https://github.com/ITSLeeds/slopes The main computational tasks are quite generally applicable so I would suggest splitting this out as a separate cargo crate, either within this repo (or perhaps better?) as a separate repo. Vested interest: I want the functionality in the slopes package to be faster. Thinking of eventually using the Rust implementation as a back-end via the libR-sys crate https://github.com/extendr/libR-sys . Another advantage of this approach: Rust is a solid and future-proof language with interfaces to many lanuages so a Rust implementation could help make the awesome functionality in slopes available for more communities, beyond the small (but highly active and rapidly growing #rspatial community). |
|
In terms of Rust/R integration it's early days but I just ran the following commands from the extendr/libR-sys repo and it works fine: |
|
Good news: it seems the approach is fast. Faster than R's very mature C++ bindings according to a small benchmark here: extendr/rextendr#11 (comment) |
|
Reproducible example on a machine that has R and Rust installed. Not 100% sure what's going on here, imagine @dabreegster you'll have a better idea if you can reproduce it... library(rextendr)
# create a Rust function
rust_function("fn add(a:f64, b:f64) -> f64 { a + b }")
#> build directory: /tmp/RtmphEpi9F/file6a284aec7f99
# call it from R
add(2.5, 4.7)
#> [1] 7.2Created on 2021-01-09 by the reprex package (v0.3.0) |
|
And with regard to the question of which elevation data source to use... SRTM has been superseded I think, some countries (and cities) have higher res data but for the purposes of this package (which should be able to use custom DEM data) I think globally available datasets as a default will be sufficient and most useful. In the |
|
The Mapbox API is quite convenient. Did you hit any licensing or API limit issues with caching data from them? For a general purpose crate, having a method that winds up making a Mapbox request would be very useful. For the A/B Street case, we likely want to use some kind of bulk API or to find and operate on a DEM file. I'd be a little surprised if Mapbox just lets you dump elevation data for a huge reason, cache it on your end, redistribute it, etc. |
Not yet, I have an unpaid mapbox API key that is quite generous and not even sure if you need one for the terrain data. |
|
Huh, https://www.mapbox.com/legal/tos/ doesn't mention anything against redistributing data from their APIs. Nice! |
|
But to be fair haven't been bulk downloading data in a way that I have been doing for OSM/STATS19 data. I'm sure lack of DEM data will not be a limiting factor for this issue in any case! |
|
https://valhalla.readthedocs.io/en/latest/sif/elevation_costing/ reference for how to use elevation data for cycle routing |
…evation from importer config; the new approach will detect the right data source to use automatically using the bbox. #82
So far, just call it for Seattle maps. Store the data sources in S3. Note this'll only run on my machine right now, unless you also build the Docker image locally. Failures in elevation should be skipped for now.
…tersections. #82 Not regenerating all maps yet.
… the inclines we're assigning to roads, but also, I realized a problem with how the elevation lookup not matching the trimmed roads. #82
to the elevation measured at the original intersection point. #82 Upload montlake, downtown, and phinney with elevation data, as an initial demo.
This is simpler to reason about, allows the penalty for entering a zone or taking an unprotected turn to be expressed in terms of a time penalty, and is a step towards adjusting bike/foot routing for elevation data. When we later add things like "safety/quietness" for cycling, maybe we can switch to using a (time, quietness) tuple, and transform into a single number with a linear combination parameterized by that agent's preference for time/safety. This change is compatible with that future idea. There are behavior changes here, particularly for zones and unprotected turns. Impact on gridlock TBD... Broadmoor proposal TBD...
This is simpler to reason about, allows the penalty for entering a zone or taking an unprotected turn to be expressed in terms of a time penalty, and is a step towards adjusting bike/foot routing for elevation data. When we later add things like "safety/quietness" for cycling, maybe we can switch to using a (time, quietness) tuple, and transform into a single number with a linear combination parameterized by that agent's preference for time/safety. This change is compatible with that future idea. There are behavior changes here, particularly for zones and unprotected turns. No new maps start gridlocking, and in fact, Rainier starts working again.
This is simpler to reason about, allows the penalty for entering a zone or taking an unprotected turn to be expressed in terms of a time penalty, and is a step towards adjusting bike/foot routing for elevation data. When we later add things like "safety/quietness" for cycling, maybe we can switch to using a (time, quietness) tuple, and transform into a single number with a linear combination parameterized by that agent's preference for time/safety. This change is compatible with that future idea. There are behavior changes here, particularly for zones and unprotected turns. No new maps start gridlocking, and in fact, Rainier starts working again.
…ts, which import synthetic maps with strange coordinates. #82
…thfinding, using calcultions from Valhalla. #82 Not regenerating data yet.
…thfinding, using calcultions from Valhalla. #82 Not regenerating data yet.
It was always using the current directory, which breaks when running the UI map importer from game/. [rebuild] [release]
…biking trips. It's just noise to see it for somebody walking to their car. #82
… import can work on any Linux machine with docker. #82
|
SRTM has been superseded by NASADEM: |
|
Thanks, good to know! We could try hooking up NASDEM with https://github.com/eldang/elevation_lookups#raster-elevation-data pretty easily. If GDAL can read it, should be easy. |
|
Summarizing how things work currently.
Future work / help needed:
|
…keep an SRTM test case). Running everywhere slows down map regeneration on my current laptop, and doesn't add much benefit, since the SRTM support is unfinished. #82
…keep an SRTM test case). Running everywhere slows down map regeneration on my current laptop, and doesn't add much benefit, since the SRTM support is unfinished. #82
…ation yet; the results there aren't good enough to justify keeping the logic for this. #82 (Also the huge and unused Seattle contours geojson)
|
Keeping my eye on https://github.com/pka/georaster as another pure-Rust geotiff reader. Instead of memmap or similar for handling massive files, we could split the big UK and Seattle files into tiles (or possibly even download them that way to begin with) |
This is a big project, but with small steps. Roughly:
Get better elevation data, either fixing the bugs in the
srtm.rsimpl or preferably using the better LIDAR data around Seattle. I have some pointers for that in an email somewhere; remind me to post themFigure out how elevation change affects the standard bicyclist speed. Incorporate that in the simulation and pathfinding cost function
Render the elevation layer much more understandably. Isochrones are the thing people are familiar with, probably should give that a shot
I can give pointers to relevant code when needed
The text was updated successfully, but these errors were encountered: