Using external data (elevation, polution, traffic...) in lua profiles

[emiltin]

What would be the most elegant way to support the use of various external data when pre-processing data?

Data types could include:

• Elevation maps: speed would be lower when going uphill
• Statistical traffic data: prefer streets with less traffic
• Pollution data: avoid areas with a lot of pollution
• Green areas: prefer walking/biking in green areas

It might be possible to create a common way to handle all these cases, since it seems they all involve sampling an external data set, and translating it into modified cost/speed of the individual way segments.

• What are the use cases?
• How would the data be imported?
• How would the data be sampled?
• How should the lua interface look like?
• What, if any, changes would be needed to osrm internals?
• What's the best way for people to help out?
• Should the data be displayed in the route sumamry/instructions? If so, how?

The issue #271 has a discussion on elevation data.

@prozessor13

[robertoferraz]

I am very interested on this feature too, I want to include traffic data, anyone knows how to support it?

[emiltin]

i think traffic data comes in several flavours: statstical data about traffic amounts, roadwords, and situational data about congestion, accidents, etc.

osrm is probably less well suited to handle situational data, since osrm can only process the entire dataset, not local areas. if you're working with a large area, this in impractical or impossible. but roadworks, statistical data and other semi-static data could well be handled, there's just no way yet to do it. we need a system where the lua profiles can access the data when processing each way segment.

[karme]

If segment processing using elevation data works, one could do the same with other raster data.

[emiltin]

elevation might be special, since it causes speed/cost to be different for each direction of a segment?

[karme]

Emil Tin notifications@github.com writes:

elevation might be special, since it causes speed/cost to be different for each direction of a segment?

well yes, but you can of course just return the same value for both forward and backward direction

see also: commit aeb79271039166cf64948d88198ab52ccd74b9a9 Extractor/ExtractionContainers.cpp bool oneway = (weight[0]!=weight[1]) ...

[emiltin]

if i understand your code correctly, your approach to elevation is:

• add a segment_function to the lua script, which is called twice for each segment (forward/backward)
• the lua script uses curl to query heigh data from an external service, and calculates the cost/speed for each segment and returns it to osrm

wouldn't it be much faster if osrm had a c++ utility to sample a raster file on disk? using http to query every node must incur a lot of overhead.

[karme]

Emil Tin notifications@github.com writes:

if i understand your code correctly, your approach to elevation is:

• add a segment_function to the lua script, which is called twice for each segment (forward/backward)

it isn't called twice anymore

it is called once

• the lua script uses curl to query heigh data from an external service, and calculates the cost/speed for each segment and returns it to osrm

there are 2 implementations of the same api: one using http (slow) one using tcp (faster) yes there is room for improvement

wouldn't it be much faster if osrm had a c++ utility to sample a raster file on disk? using http to query every node must incur a lot of overhead.

the elevation profile service has some features i don't want to miss from the README: "

• seamless stacking of multiple DEMs (it is really simple to add another DEM dataset if the format is supported by gdal [3])
• upsample polyline (keeping original input points and inserting equidistant additional points if needed)
• wgs84 spheroid distance calculations "

for me the bigger question is the overall approach - especially wether to use the segment callback approach - see also #271

Slow parts can be improved / replaced / have alternative implementations later.

[karme]

edited last comment because i refered to "above" (i answered by mail and thought it was a different issue)

[emiltin]

i agree that it's important to figure out the osrm internals. regarding performance, perhaps osmr could cache the elevation samples requested via http/tcp? in effect building a big hash of coord->elevation that could be reused next time data is reprocessed

[karme]

Emil Tin notifications@github.com writes:

i agree that it's important to figure out the osrm internals. regarding performance, perhaps osmr could cache the elevation samples requested via http/tcp? in effect building a big hash of coord->elevation that could be reused next time data i reprocessed

for me the most important point is: segment vs edge vs way-based processing

[prozessor13]

hello. i think pre-generate the elevation data would be a good idea. you can download various elevation sources (e.g. ciat/cgiar - viewfinder_parnoramo). to combine these datasources into small binary tiles i have made a perl-script:

foreach my $x (-12 .. 48) {
   my $x1 = $x + 1;
   foreach my $y (32 .. 72) {
      my $y1 = $y + 1;
      my $bbox = "$x $y1 $x1 $y";
      my $fname = "$y1\_$x1\_$y\_$x";
      print "$fname\n";

      `gdal_merge.py -n -32768 -o $fname.tmp1.tif -ul_lr $bbox ../dem/ciat_cgiar/*.tif`;
      `gdal_translate -of GTiff -outsize 3600 3600 -co "TILED=YES" -a_srs EPSG:4326 $fname.tmp1.tif $fname.merged1.tif`;
      `gdal_merge.py -n -32768 -o $fname.tmp2.tif -ul_lr $bbox ../dem/viewfinder_panorama/*.tif`;
      `gdal_translate -of GTiff -outsize 3600 3600 -co "TILED=YES" -a_srs EPSG:4326 $fname.tmp2.tif $fname.merged2.tif`;
      `gdal_merge.py -o $fname.tif $fname.merged*.tif`;
      `gdal_translate -of AAIGrid $fname.tif $fname.ascii`;

      open (my $in, "$fname.ascii") or die "Unable to open: $!";
      open(my $out, '>:raw', "$fname.bin") or die "Unable to open: $!";

      # read header
      <$in> foreach (1 .. 5);
      # read data
      while (my $line = <$in>) {
         @values = map 0+$_, split /\s+/, substr $line, 1;
         print $out pack('s<*', @values);
      }

      close($in);
      close($out);

      `rm $fname*.tif $fname.prj $fname.ascii.aux.xml $fname.ascii`;
   }
}

this script first creates Arc/Info ASCII files (because gdal has no ArcGis binary write support), and convert these files into binary files. each file holds data for a 1x1 degree tile (3600x3600 elevation values (eg. every 30m)). each file has about 25MB. so europe needs around 100GB and the world 1TB. this format should be easy parsable by a small lua library (i will make such a library soon).

max

[emiltin]

i'm sure @DennisOSRM can say more about this, but i would think that performance will be limited by disk access, since such a huge dataset cannot be kept in ram. how efficient are archgis binary files when it comes to file size and speed of random access?

[emiltin]

@ prozessor13 how many of these elavation tiles do you end up with?

[prozessor13]

i think the performance will be very good, because:

i would keep (may) the last used 5 or 10 tiles in RAM, and i think there will be a lot of requests to the same tile before another one is needed (because the edge data is sorted in the osrm array). i saw, dennis had alredy programmed some nasagrid code in OSRM (in c++), and this code works very simmilar. my intention for this logic ist:

• the nasagrid data (which i know) contains holes
• the nasagrid binary file is also not writable via gdal tools
• and i dont know another easy parsable standard GIS format
• and the above binary data is as simple as possible

drawback of implementing this in lua instead of C++ is maybe the speed, and that i dont know how to implement an library which will be shared over all the parsing threads.

pseudocode would something like this:

lat = 50.5
lng = 10.5

filename = int(lat) + int(lng) + ".bin"
f = open(filename, "rb")
data = unpack "s<*", f.read(3600 x 3600 x 2) // unsigned int values

x = int((lng - int(lng)) * 3600)
y = int((lat - int(lat)) * 3600)

altitude = data[posx * 3600 + posy]

ps: europe needs exactly 65GB and 2501 files

[emiltin]

but actually you would only need to store elevation for node locations, not all the other possible locations? maybe osrm could just cache those when they're requested from an external service. this should be far less data that the entire elevation map?

[emiltin]

@karme regarding segment vs edge vs way-based processing - i might not be entirely clear about the distinctions, but -

at least i think we need two values for each way, to handle uphill/downhill. btw this is also needed to handle pushing bikes against oneways streets, since this means you have different speeds in each direction.

segment vs. edge - i suppose the question here is that each edge between two nodes can consist of several segments, and we could either process each segment, or only the edge?

[karme]

max wukits notifications@github.com writes:

hello. i think pre-generate the elevation data would be a good idea. you can download various elevation sources (e.g. ciat/cgiar - viewfinder_parnoramo). to combine these datasources into small binary tiles i have made a perl-script:

those are not really free datasets

i have put together a stack of free datasets here: http://karme.de/freedem/

[karme]

Emil Tin notifications@github.com writes:

@karme regarding segment vs edge vs way-based processing - i might not be entirely clear about the distinctions, but -

with segment i mean a line segment between 2 osm nodes with edge i mean a polyline between two crossings way is osm way

at least i think we need two values for each way, to handle uphill/downhill. btw this is also needed to handle pushing bikes against oneways streets, since this means you have different speeds in each direction.

ack

segment vs. edge - i suppose the question here is that each edge between two nodes can consist of several segments, and we could either process each segment, or only the edge?

yes

there are of course much less edges than segments

the other reason to think into that direction is what i meant with ugliness in the other issue

if you seperate the processing into a way and segment stage, you often want to have access to the complete way information in the segment stage you can see this in the diff with maxspeed

[emiltin]

osrm routing is edge-based, and i suppose changing this is not an option.

if we process edges in lua, we have only the elevation of the end points, and thus the difference. if we process segments, we also know how it's going uphill/downhill between the crossing. a parallel use case of working with segments would be to prefer straight roads over winding roads.

perhaps it would be possible to only process edges, not segments, but then in addition sample elevation of the start and end points, since they're usually somewhere in the middle of an edge.

anthor idea - what about processing each edge by providing lua with an array of the segments it contains? (@karme, i didn't yet look into your code, is this what you do?)

[karme]

Emil Tin notifications@github.com writes:

osrm routing is edge-based, and i suppose changing this is not an option.

it uses the segments as edges no?

if we process edges in lua, we have only the elevation of the end points, and thus the difference. if we process segments, we also know how it's going uphill/downhill between the crossing

at the moment i do upsample the segments anyway segments are in fact quite long sometimes

if the processing would be edged based (where the edges are polylines between real crossings) that part would be completely identical

. a parallel use case of working with segments would be to prefer straight roads over winding roads.

hmm - maybe we still mean different things?

in my view this would be another case for working with polyline-based edges because if you look at one line segment it is always straight

another one: the speed formula i use at the moment only depends on the gradient of one line segment, especially for cycling this isn't very realistic

perhaps it would be possible to only process edges, not segments,

ack

but then in addition sample elevation of the start and end points, since they're usually somewhere in the middle of an edge. in effect addin on the other hand,

don't understand

anthor idea - what about processing each edge by providing lua with an array of the segments it contains? (@karme, i didn't yet look into your code, is this what you do?)

really looks like we use the same words with differnt meanings :(

but yes, the idea was to use only nodes and polyline-based edges in the lua preprocessing

this doesn't mean that the osrm routing must use polylines as edges internally (it can still use segments) - only in the preprocessing

[emiltin]

i think you got a point. i've added a wiki page to try to get a common definition of these concepts: https://github.com/DennisOSRM/Project-OSRM/wiki/Graph-representation

[DennisOSRM]

There is two areas in OSRM where you want to factor in elevation.

• In the underlying data to avoid elevation, and
• In the output to generate a height profile.

The first one needs to be handled during the preprocessing chain. And the height must be modeled as a penalty to the travel time. The rationale behind this is that uphill takes longer than downhill. This way the computed path is still a fastest one, but also considers elevation.

Now, the best way to do this is to compute a penalty for each segment, when the graph is expanded, i.e. here: https://github.com/DennisOSRM/Project-OSRM/blob/master/Contractor/EdgeBasedGraphFactory.cpp#L254.

The second area is the computation of a height profile. It is probably best to query either an external or external data source with the computed path. For this scenario, I would query some external visualization, i.e. a web service or something similar, that takes the geometry of the route at once and returns some image or similar representation of the elevation profile.

[emiltin]

I'm still wrapping my head around all this, but i see two options:

1. Handle elevation like turn penalty is handled in the lua_turn_penalty branch at https://github.com/DennisOSRM/Project-OSRM/blob/21c535a277cc8b53ecfbeefaebaea594d58ec139/Contractor/EdgeBasedGraphFactory.cpp#L282. It seems this is very similar to what Dennis suggested above.

This would involve calling out to a lua segment_function for each segment, passing in its geometry. Lua can the use elevation data to return some weight, which OSRM uses to adjust the speed of the segment.

This approach could perhaps be generalized, so that the segment_function would process both turn penalty, height penalty, and perhaps other things related to the segment. If I understand things correctly, each turn (which includes moving from one segment to the next on a straight way) is processed by OSRM.

Segment processing would happen after the extraction process, in the step where the OSM data is transformed to an edge-expanded graph.

The drawback of this approach might be that way processing and segment processing is separated, and you might need way info when processing the segment. (What concrete examples of this exist?)

2. Combine way and segment processing during extraction. For each way, call out to a lua way_function like we do now, but in addition to the way, pass an array of the segments that it consists of. Lua can then do the normal way processing, but in addition, it can loop over the segments, and use elevation data to set two speed factors for each segment (forward/backback), or nothing if there's no elevation

OSRM would then combine the way weight with the segment weight when building the edge-expanded graph.

[prozessor13]

hello. yesterday i finished my work, which does currently:

• extend _Node with osmID and altitude
• extend _Edge with speedBackward
• fetch altitude values in node_function (from my binary DEM files)
• priorize bike-road relations in way_function (with a pregenerated *.networks file)
• create a segment_function (based on karmes patch), which takes
  • segment (= _Edge), startCoord, targedCoord, distance as arguments
  • and modify the segment speed and speedbackward parameters
• add a simple push-bike logic for oneways
  • set segment to bidirectional
  • and set speedBackward

i use the berlin.osm.pbf file for testing and this takes:

./osrm-extract: 55sec instead of 41sec berlin.osrm: 18MB instead of 14MB

i think the penalties are quite good for the extra-logic. (mainly for the elevation stuff).

the files created by ./osrm-prepare are nearly the same size (590k edges instead of 560k edges). some of the edges are for the push bike logic and some are for climbing/falling. i ignore climbings/fallings for less than 1 percent, and so there are not so much extra edges.

the next steps are:

• integrate emils turn-penalty patch
• test the code

some words about the segment_function callback: first i wanted to integrate the lua-fkt into the EdgeBasedGraphFactory class. but that was to complicated for me, as i didnt know the osrm internals as good. as well in this case it is necessary to change the osrm file format (at least with the speedBackward parameter). i dont know if i had done all right, but the first tests looks very good.

https://github.com/prozessor13/Project-OSRM/commits/master

[emiltin]

Thanks for sharing your work prozessor13. In relation to elevation, what are the differences from karmes code?

[prozessor13]

the diffeneces are mainly:

• store altitude to a node (= extend coordinate struct), instead of calculating it in the segment_function every time
• read altitudes from local files (= much more speed). i read the data with fopen and fseek, so there is no ram used. i have a laptop with ssd disk, so the lookup is really fast.
• extend _Edge with speedBackward instead of maxspeed. maxspeed is not needed in my setup, because the segment_function gets much more information than karmes one, so all the maxspeed logic can be done in this function
• speedBackward will only be defined if climbing/falling is above a threshold of 1percent, so the osrm file will not double with a lot of oneway segments.
• the logic of ExtractionContainers::PrepareData is a little bit different than karmes (more like the original logic)

pseudocode

distance = calcDistance(edge->startCoord, edge->endCoord)
luabind("segment_function", edge, edge->startCoord, edge->endCoord, distance)
weight = calcWeight(edge->speed, distance)
weightBackward = calcWeight(edge->speedBackward or edge->speed, distance)
if (weight != weighBackward and edge->is_bidirectional) {
    edge->direction = oneway
    // write forward edge
    writeEdgeToOSRMFile(edge, weight)
    // write backward edge
    swap(edge->startNode, edge->endNode)
    writeEdgeToOSRMFile(edge, weightBackward)
} else {
    writeEdgeToOSRMFile(edge, weight)
}

[karme]

max wukits notifications@github.com writes:

the diffeneces are mainly:

• store altitude to a node (= extend coordinate struct), instead of calculating it in the segment_function every time

the problem with that approach is that you can't upsample the line segments then

• read altitudes from local files (= much more speed). i read the data with fopen and fseek, so there is no ram used. i have a laptop with ssd disk, so the lookup is really fast.

started with a similar approach, nothing wrong with it. If you are after raw performance you might consider using mmap and organizing your data into tiles internally (assuming spatial access locality)

But there are some good reasons to use a library like gdal:

• get support for commonly used data formats
• support for metadata (projection, georeferencing, nodata, ...)
• using geotiff you also get: internal tiles (the freedem dataset uses that), compression

good reasons to use something like the elevation-profile service:

• seamless stacking of multiple DEMs (it is really simple to add another DEM dataset if the format is supported by gdal [3]) interpolation between raster datasets with different resolution (typically you will not have a good one for your complete area)
• upsample polyline (keeping original input points and inserting equidistant additional points if needed)
• wgs84 spheroid distance calculations

regarding performance: the service really should be installed locally on your server or at least in a local network

but in the end I don't think we should have an overly long discussion about the implemention of DEM services. The only point I really care about is the API / how to use any DEM service in the osrm importer.

• extend _Edge with speedBackward instead of maxspeed. maxspeed is not needed in my setup, because the segment_function gets much more information than karmes one, so all the maxspeed logic can be done in this function

i think there is a typo here, maybe you mean way_function instead of segment_function?

this is really a consequence of the point above:

because you don't do upsampling you can calculate the speed in the way function => no need for maxspeed in the segment function

but looking at: https://github.com/prozessor13/Project-OSRM/blob/master/profiles/mtk.lua i think your segment function might increase the speed above maxspeed, no?

• speedBackward will only be defined if climbing/falling is above a threshold of 1percent, so the osrm file will not double with a lot of oneway segments.

good one

while taking a look at this, i noticed that my old patch did compare the weight doubles and not the int doubles to decide wether they are the same. fixed that (thought about adding an additional nearly_same test but decided to stay with the int test for now)

• the logic of ExtractionContainers::PrepareData is a little bit different than karmes (more like the original logic)

only real differences i see there: my version:

• gets the distance from lua (=> possibly from the elevation profile service)
• expects the *10 scaling to be done in lua
• uses a for loop (to not have 3 versions of nearly the same code)

Greetings, karme

[karme]

Project OSRM notifications@github.com writes:

Now, the best way to do this is to compute a penalty for each segment, when the graph is expanded, i.e. here: https://github.com/DennisOSRM/Project-OSRM/blob/master/Contractor/EdgeBasedGraphFactory.cpp#L254.

nearly missed that one will take a look

[karme]

Just some additional comments regarding this one (nothing really new):

Project OSRM notifications@github.com writes:

There is two areas in OSRM where you want to factor in elevation.

• In the underlying data to avoid elevation, and
• In the output to generate a height profile.

The first one needs to be handled during the preprocessing chain. And the height must be modeled as a penalty to the travel time. The rationale behind this is that uphill takes longer than downhill. This way the computed path is still a fastest one, but also considers elevation.

there is also the case where you may want to perfer a flat way even if it is slower => penalty is not neccesarily based on time => at some point time and cost/weight must be seperated anyway see also issue #77 (and the lua_weights branch)

The second area is the computation of a height profile. It is probably best to query either an external or external data source with the computed path. For this scenario, I would query some external visualization, i.e. a web service or something similar, that takes the geometry of the route at once and returns some image or similar representation of the elevation profile.

of course it would be nicer if the the profile would be readily available in the routing result

[prozessor13]

hello

the problem with that approach is that you can't upsample the line segments then

what do you mean with upsampling in this case?

• read altitudes from local files (= much more speed). i read the data with fopen and fseek, so there is no ram used. i have a laptop with ssd disk, so the lookup is really fast.

i agree with you, that my custom implementation ist not the best one for an open-source project, but i works really well in my case. the preprocessing is done also via gdal, and it was important for me, that access elevation data is as simple and fast as possible, without coding it in C++.

• extend _Edge with speedBackward instead of maxspeed. maxspeed is not needed in my setup, because the segment_function gets much more information than karmes one, so all the maxspeed logic can be done in this function

we do only bicycle-routing, and in this case a maxspeed-setting is not needed. and you are right, a correct maxspeed calculation cannot be done on this point.

and in our case we dont calculate routing-time based on the speed settings. we use speed only as a segment-weight value. cycling-time is calculated afterwards by distance / average_speed, because cycling-speed is a very personal value (e.g. a grandma != 18old boy)

i think there is a typo here, maybe you mean way_function instead of segment_function?

this is really a consequence of the point above:

because you don't do upsampling you can calculate the speed in the way function => no need for maxspeed in the segment function

hmm. i dont understand what you mean with upsampling. but the speed of a way is not the same as the speed of a segment, because a way can be very long (e.g. a mountain pass). how would you calculate in this case the correct speed/backward_speed? is this possible? maybe yes, i really dont know.

but looking at: https://github.com/prozessor13/Project-OSRM/blob/master/profiles/mtk.lua i think your segment function might increase the speed above maxspeed, no?

yes thats right, but doesnt matter in our scenario.

my version:

• gets the distance from lua (=> possibly from the elevation profile service)
• expects the *10 scaling to be done in lua
• uses a for loop (to not have 3 versions of nearly the same code)

you are right.

and thanks for your code. it was a gread basis to implement our needs :)

ps: i know that my code is not generally usable, i didnt made tests and so on. but i really had not much time to do it. i only want to share it, and maybe someone can use parts of it.

[emiltin]

it might be better to continue the discussion on the mailinglist https://github.com/DennisOSRM/Project-OSRM/wiki/Mailing-list

[karme]

max wukits notifications@github.com writes:

hello

the problem with that approach is that you can't upsample the line segments then

what do you mean with upsampling in this case?

line segments might be long (there might be a mountain or valley between start and end-point)

=> with upsampling i mean taking elevation samples between start and end-point

[...]

ps: i know that my code is not generally usable, i didnt made tests and so on. but i really had not much time to do it. i only want to share it, and maybe someone can use parts of it.

no problem - i only wanted to make clear where the problems are

my solution now is to split the osm ways at intersections and adding elevation profiles to the splited ways in an additional preprocessing step (see also my waysplit branch [0])

karme

[0] https://github.com/karme/Project-OSRM/tree/waysplit

[emiltin]

A digital elevation model for Denmark was recently released to the public. It uses a 1.6m grid. Supplied in ESRI ASCII Raster format, Denmark is about 25GB. A 10m grid is also available.

We would like to use this datasets to avoid hills. (Yes hills are tiny in Denmark, but people are used to flat roads :-))

Free download (just need to create an account): http://download.kortforsyningen.dk/content/dhmterr%C3%A6n-16-m-grid

[karme]

Emil Tin notifications@github.com writes:

A digital elevation model for Denmark was recently released to the public. It uses a 1.6m grid. Supplied in ESRI ASCII Raster format, Denmark is about 25GB. A 10m grid is also available.

sounds great do you have a link? is the data dfsg-free [0] so i could add it to the freedem stack[1]?

We would like to use this datasets to avoid hills. (Yes hills are tiny in Denmark, but people are used to flat roads :-))

some time ago was cycling from fensburg north, there were quite some hills, unfortunately can't remember where we have been

[0] http://en.wikipedia.org/wiki/DFSG [1] http://karme.de/freedem/

[emiltin]

Free download (just need to create an account): http://download.kortforsyningen.dk/content/dhmterr%C3%A6n-16-m-grid. I'm not familiar with DFSG. You can read about the license for the data at http://download.kortforsyningen.dk/content/vilk%C3%A5r-og-betingelser (in danish).

[karme]

Emil Tin notifications@github.com writes:

Free download (just need to create an account): http://download.kortforsyningen.dk/content/dhmterr%C3%A6n-16-m-grid. I'm not familiar with DFSG. You can read about the license for the data at http://download.kortforsyningen.dk/content/vilk%C3%A5r-og-betingelser (in danish).

via google translate it looks quite good

i think i also found an english version at: http://www.gst.dk/NR/rdonlyres/AD386601-C92E-479F-8BE8-FD9878B193A7/0/Conditionsforuseofopenpublicgeographicdata.pdf

will take a look

[karme]

got an account, downloaded 10m sample

is there a way to directly download all the tiles without manually clicking in the web-frontend?

[emiltin]

i don't think so. it's from a time when you paid for each tile.

[systemed]

To generate elevation profiles from an OSRM-computed route, I'm currently using Redis with Lua. My Redis store contains SRTM tiles for the UK, plus a Lua script (loaded with SCRIPT LOAD) which takes a polyline and returns an elevation profile. It's fast and easy to understand.

It strikes me that this would be a very easy and flexible way to provide support for external data in OSRM: allow the user to register Redis-stored Lua scripts (which are identified with a SHA1 value) to be called at certain points in the processing with a defined interface. These scripts could then be capable of assessing elevation, traffic, pollution etc. as per Emil's original issue.

[karme]

Richard Fairhurst notifications@github.com writes:

To generate elevation profiles from an OSRM-computed route, I'm currently using Redis with Lua. My Redis store contains SRTM tiles for the UK, plus a Lua script (loaded with SCRIPT LOAD) which takes a polyline and returns an elevation profile. It's fast and easy to understand.

did you try elevation-profile [0]?

It strikes me that this would be a very easy and flexible way to provide support for external data in OSRM: allow the user to register Redis-stored Lua scripts (which are identified with a SHA1 value) to be called at certain points in the processing with a defined interface. These scripts could then be capable of assessing elevation, traffic, pollution etc. as per Emil's original issue.

did you test my waysplit approach? s.a. https://github.com/Alpstein/Project-OSRM/tree/test20130508

greetings, karme

[0] http://karme.de/elevation-profile/

[systemed]

I'd rather not run a further preprocessing step if possible. I have looked at the elevation-profile code but it seemed easier for me to hack something up in Lua, rather than try and integrate a lot of code with lots of dependencies (always a problem on OS X) and in a language I don't understand. :)

[karme]

Richard Fairhurst notifications@github.com writes:

I'd rather not run a further preprocessing step if possible.

imho at the moment there is no other solution if you want "correct" results regarding elevation

I have looked at the elevation-profile code but it seemed easier for me to hack something up in Lua, rather than try and integrate a lot of code with lots of dependencies (always a problem on OS X)

I see

maybe I should provide preprocessed osm/pbf files? (but at the moment I only preprocess europe regularly)

and in a language I don't understand. :)

don't be afraid of scheme (it is really simple) (after all lua is just another not quite lisp/scheme: http://www.lua.org/ddj.html ;-)

[systemed]

I've now implemented (in a quick and dirty fashion) the Redis+Lua approach. There's a fairly significant slowdown but that's fairly inevitable when interpolating from SRTM data anyway. Works fine with a single-county extract; just about to leave it to churn overnight on the UK .pbf!

[emiltin]

possible by querying postgis from lua. this example avoids landusages=industrial: https://github.com/DennisOSRM/Project-OSRM/blob/develop/profiles/examples/postgis.lua

[kaligrafy]

Is it really real-time or the postgis query is made before preparing the routable network?

[emiltin]

postgis is queried during the OSRM data preparation. during routing postgis is not accessed.

[eleu]

Hi, earlier in this issue, @DennisOSRM discussed two parts of integrating external data:

There is two areas in OSRM where you want to factor in elevation.

• In the underlying data to avoid elevation, and
• In the output to generate a height profile.

We are interested about the second point, as we have elevation data in the source (so each vertex in the source has height information). Since it's vector data, we want to avoid calling a second Webservice, as it would involve heavy geometry comparison.

So we are rather thinking about the possibilities to implement it into OSRM. What are the chances that elevation data will be available in the output? What do you estimate regarding the complexity to implement it? Would a contribution for this feature be considered?

Thanks for any hints and thoughts about that!

[TheMarex]

Raster support has landed in develop.

[daniel-j-h]

@georgbachmann here's the example profile postgis.lua --- in theory it should still work, not sure if anyone tested it with all the recent changes, though.

[georgbachmann]

Thanks... I already found it... looks very promising! nice! Btw. is the IRC the best place to ask questions? There is no Slack channel, right?