There is already a way to integrate arbitrary raster data (e.g. SRTM elevation data). Take a look at:
https://github.com/Project-OSRM/osrm-backend/wiki/Integrating-third-party-raster-data The Lua way_function gets a "way" as argument; this is a osmium::Way registered with the Lua environment here: https://github.com/Project-OSRM/osrm-backend/blob/a6aa0a4cb0d104569a84fb018a15af32671c6361/src/extractor/scripting_environment.cpp#L106-L109 and here's the osmium::Way documentation: http://docs.osmcode.org/libosmium/latest/classosmium_1_1Way.html You could register its .nodes() function and the osmium::WayNodeList type it returns for iterating over all osmium::NodeRefs in a osmium::WayNodeList: http://docs.osmcode.org/libosmium/latest/classosmium_1_1NodeRef.html You then have access to locations in the Lua environment. Cheers, Daniel J H On Thu, Mar 17, 2016 at 3:57 PM, Christian Helbling <helbl...@search.ch> wrote: > Hi Daniel, Hi List > > On 08.03.2016 19:15, Daniel Patterson wrote: > > Hi Christian, > > > > One the oldest tickets: > > > > https://github.com/Project-OSRM/osrm-backend/issues/77 > > > > is all about this. Your observation is correct, there is currently no > separation > > between durations and "routing weight". We've been discussing > implementing > > this recently (at Mapbox), but no definite plans yet. It will > increase the > > memory usage. > > > Would be really cool to have this at least as a build option. > As we don't operate on planet-scale, memory is not that important. > > > > If you take your second option, you can consider encoding the extra > metadata > > you need in the "name" attribute, and split it out again when you > receive your > > route results. Note that OSRM emits a turn instruction every time the > "name" changes, > > so you'd need to cater for that if you're displaying turn-by-turn > instructions to users. > > Well this might be a hacky solution for storing some duration to > routing-factor. > However, when I want to push elevation data through for some elevation > profile, this seems to be the wrong > place. > > I tried adding 'int ele' to QueryNode and FixedPointCoordinate. > After some hacking around it seemd to work, except I got "Restriction > references invalid node/way" warnings. > Is there some bit-magic going on there? > Also I think that this additional int might end up in all kinds of > data-structures where it's not needed at all. > In principle, additional per-node data should just be stored somewhere > during extraction, and retreived by node-id > after the algorithm ran. > > Are there any forks around that already save additional data per node and > per way? > Or is there an easy way to add that (I don't mind writing some C++)? > > > Another question: > Is there a way to get to the coordinates in way_function? > This could be used for less frequent elevation queries (for example only > once every 10m). > > > Cheers > Christian > > > > >> On Mar 8, 2016, at 10:05 AM, Christian Helbling <helbl...@search.ch > <mailto:helbl...@search.ch>> wrote: > >> > >> Hello > >> > >> I'm about to write a bicycle route planner and I'd like to use OSRM for > that. > >> However, there are some things I don't understand yet. > >> > >> From what I read in the code and documentation it seems that OSRM > optimizes by speed/time only. > >> What I would like to do in my config is to have a penalty on big roads > but still have a normal > >> speed there when it is used anyway (for lack of alternative). > >> > >> Is such a config possible? > >> And if so, how would I do that? > >> > >> If it's not, then i'm tempted to run OSRM with fake speeds representing > the actual speeds plus penalties. > >> Then when I got the result I would go through the result and > recalculate the actual time needed. > >> For that I would need to have access to some properties (road type, > elevation data, ..) when I get the result. > >> Is it possible to pipe additional data through OSRM? > >> > >> Elevation data would be interesting in particular as I need that to > draw an elevation profile anyway. > >> > >> > >> Thanks in advance > >> Christian > >> > >> _______________________________________________ > >> OSRM-talk mailing list > >> OSRM-talk@openstreetmap.org <mailto:OSRM-talk@openstreetmap.org> > >> https://lists.openstreetmap.org/listinfo/osrm-talk > > > > > > > > _______________________________________________ > > OSRM-talk mailing list > > OSRM-talk@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/osrm-talk > > > > > _______________________________________________ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk >
_______________________________________________ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
