[OSRM-talk] Road speeds and profile restrictions

Mon Sep 21 20:12:12 UTC 2015

For an example on how to use the visitor:

https://github.com/Project-OSRM/node-osrm/blob/master/src/json_v8_renderer.hpp

This is what directly transforms our on variant in the v8 object
model. You can use it to transform it back to any data structure that
you need.

BTW. Is using the C++ interface a requirement for you? Using the node
bindings is in general much more convenient. The speed is close to
what you would get with C++ and is generally more suited for
server-side code.

On Mon, Sep 21, 2015 at 6:50 PM, Richard Marsden <winwaed at gmail.com> wrote:
> Thanks, yes that got it working with mapbox::util::get, eg:
>
>     double v = mapbox::util::get<osrm::json::Number>( (it->second) ).value;
>
> Okay this is for the status which is an integer, so it should be
> rounded (and should be either 0 or 207).
>
> dusting off my C++, I've already upgraded my Stroustrup from a
> battered 2nd edition to the latest 4th edition. Seems like I need to
> catch up on boost, as well :-)
>
> Richard
>
>
> On Mon, Sep 21, 2015 at 10:14 AM, Richard Marsden <winwaed at gmail.com> wrote:
>> Thanks - yes, I'd found the definition of osrm::json::Object and
>> osrm::json::Value, and went through quite a few variations. I'll have
>> a look at the boost variant definition.
>>
>> I didn't know my C++ was so rusty until I tried working with OSRM! I
>> used to use it a lot, but it was before boost came along.
>>
>> richard
>>
>> On Mon, Sep 21, 2015 at 7:15 AM, Daniel Hofmann <hofmann at mapbox.com> wrote:
>>> First of all, don't use C-style casts, a la `(int)myObject;` as this will
>>> (in the worst case) degrade to a `reinterpret_cast` and you really don't
>>> want this behavior.
>>>
>>> Now take a look here:
>>>>
>>>> https://github.com/Project-OSRM/osrm-backend/blob/e1ac1c4fdc062a0e5c017d268d0a7fcb25bbbab1/include/osrm/json_container.hpp#L84-L87
>>>
>>> This is the definition of `osrm::json::Object`. Above it you find the
>>> definition of `osrm::json::Value`, which is a heterogeneous sum type, making
>>> use of the following implementation:
>>>> https://github.com/mapbox/variant
>>>
>>> And here is the basic hello world example for the variant implementation:
>>>>
>>>> https://github.com/mapbox/variant/blob/bf485dfb59aef26f3ef2183d7c8c1111ad97062b/test/variant_hello_world.cpp
>>>
>>> Because it mimics Boost.Variant, please have a look at the detailed tutorial
>>> here:
>>>> http://www.boost.org/doc/libs/1_59_0/doc/html/variant/tutorial.html
>>>
>>> It shows you among other things how to use the double dispatch visitor
>>> pattern for extracting values from a variant.
>>>
>>> Hope that helps,
>>> Daniel
>>>
>>> On Sun, Sep 20, 2015 at 8:20 PM, Richard Marsden <winwaed at gmail.com> wrote:
>>>>
>>>> Steve how did you extract information from the osrm::json::Object
>>>> returned object?
>>>> I could covert the Object to string, and then parse it with a 3rd
>>>> party JSON library, but that seems long-winded.
>>>> I've already asked this question on the OSM Q&A site but no anwers yet:
>>>>
>>>>
>>>> https://help.openstreetmap.org/questions/45342/extracting-data-values-from-osrms-osrmjsonobject-using-c
>>>>
>>>> Text of question:
>>>>
>>>> I can receive the JSON result successfully and printing it to the
>>>> console (as per the online samples), but I am have problems extracting
>>>> actual field data. How can I extract individual fields as numbers,
>>>> string, etc?
>>>>
>>>> I've tried various forms of casting, but this is what I have at the
>>>> moment (trying to extract the status value):
>>>>
>>>> const int gr_result_code = routing_machine.RunQuery(route_parameters,
>>>> json_result);
>>>> std::string sStat("status");
>>>> auto it = json_result.values.find(sStat);
>>>> osrm::json::Number vv =  (osrm::json::Number) ((*it).second); // doesn't
>>>> compile
>>>> int v = (int) (vv.value); // probably some dodgy rounding here
>>>>
>>>> The Number casting is producing compiler errors. I guess I could
>>>> convert the object to a string, and then using a third party JSON
>>>> parser to extract individual fields, but this seems very wasteful.
>>>>
>>>>
>>>> --------------------
>>>> Richard
>>>>
>>>> On Thu, Sep 17, 2015 at 8:20 PM, Stephen Woodbridge
>>>> <woodbri at swoodbridge.com> wrote:
>>>> > Richard,
>>>> >
>>>> > I have already imbedded OSRM into a C++ application and in fact wrapped
>>>> > that
>>>> > application into a postgresql database extension. I my case I only need
>>>> > data
>>>> > for a city but I was making literally billions of calls to osrm.
>>>> >
>>>> > As Patrick said, OSRM makes random access calls to memory and there are
>>>> > a
>>>> > lot of variables that come into play like how well the data is clustered
>>>> > in
>>>> > memory pages, how many page faults you hit, etc. For your specific use
>>>> > case
>>>> > no one will have a good answer for you and you really need to do some
>>>> > performance testing using the product the way you intend it to be used
>>>> > and
>>>> > see what the performance issues are. Maybe you use case is fine. The
>>>> > OSRM
>>>> > public service uses lots of memory because it has to support multiple
>>>> > random
>>>> > requests anywhere in the world and it can not afford to get stuck page
>>>> > in
>>>> > swap. Using swap and an SSD might be fine in your application, and may
>>>> > be it
>>>> > won't, but we do not have enough information to consider the problem
>>>> > more
>>>> > than to give the standard answer - more memory is faster more swapping
>>>> > is
>>>> > slower.
>>>> >
>>>> > -Steve
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On 9/17/2015 8:45 PM, Richard Marsden wrote:
>>>> >>
>>>> >> Thanks for the quick reply Patrick.
>>>> >>
>>>> >>> Presumably I could do the same for world preparation & routing? Have,
>>>> >>> perhaps a 100GB+ swap file, ideally on an SSD.
>>>> >>
>>>> >>
>>>> >>> This will fall apart when you have some actual load pressure on the
>>>> >>> system. We need random access to memory, which will create a lot of
>>>> >>> page faults (== slow). Even an SSD is not even close to memory speed.
>>>> >>
>>>> >>
>>>> >>> You have two options:
>>>> >>> split the datasets
>>>> >>> get a bigger server
>>>> >>
>>>> >>
>>>> >>
>>>> >> I would imagine that is the case for the standard http server. I was
>>>> >> thinking of using it as a linked library from a C++ program. Splitting
>>>> >> the datasets by continent is a possibility though.
>>>> >>
>>>> >> (writing a C# interface was another thought, but that would be a
>>>> >> different use case and definitely with smaller datasets)
>>>> >>
>>>> >> Cheers,
>>>> >>
>>>> >> Richard
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Thu, Sep 17, 2015 at 4:37 PM, Patrick Niklaus
>>>> >> <patrick.niklaus at student.kit.edu> wrote:
>>>> >>>
>>>> >>> W.r.t. the pre-preprocessing you are correct.
>>>> >>>
>>>> >>>> What is that extra power used for?
>>>> >>>
>>>> >>>
>>>> >>> Including all sorts of external data sources. Also the logic in the
>>>> >>> lua profiles is not just replaceable by simple key-value pairs, OSM
>>>> >>> requires you to handle a lot of special cases.
>>>> >>>
>>>> >>>> Presumably I could do the same for world preparation & routing? Have,
>>>> >>>> perhaps a 100GB+ swap file, ideally on an SSD.
>>>> >>>
>>>> >>>
>>>> >>> This will fall apart when you have some actual load pressure on the
>>>> >>> system. We need random access to memory, which will create a lot of
>>>> >>> page faults (== slow). Even an SSD is not even close to memory speed.
>>>> >>>
>>>> >>> You have two options:
>>>> >>> - split the datasets
>>>> >>> - get a bigger server
>>>> >>>
>>>> >>> Cheers,
>>>> >>> Patrick
>>>> >>>
>>>> >>>
>>>> >>> On Thu, Sep 17, 2015 at 10:06 PM, Richard Marsden <winwaed at gmail.com>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> I've been evaluating OSRM, using it primarily as a library from C++.
>>>> >>>>
>>>> >>>> I believe I've determined the answer to most of the questions, but
>>>> >>>> I'm
>>>> >>>> also looking for confirmation.
>>>> >>>> (I understand the reason for these constraints - the trade-off of
>>>> >>>> speed vs flexibility)
>>>> >>>>
>>>> >>>> First, road speeds are set with 'profile.lua' at the osrm-extract
>>>> >>>> stage. This filters out unnecessary roads (eg. foot paths for car
>>>> >>>> routing), but also applies the road speeds.
>>>> >>>> If I wish to change the speed profile, I need to regenerate the road
>>>> >>>> network with osrm-extract and osrm-routed.
>>>> >>>> Correct?
>>>> >>>>
>>>> >>>> If I wanted different speeds for the final distance/time
>>>> >>>> calculations,
>>>> >>>> I could use the returned route, and apply my own speed table
>>>> >>>> according
>>>> >>>> to the road type of each road segment. This would not, of course,
>>>> >>>> change the route geometry is calculated.
>>>> >>>>
>>>> >>>> If I want a shortest route (distance optimized) instead of a quickest
>>>> >>>> route (time optimized), I need to set all the road speeds to the same
>>>> >>>> speed and regenerate the network. I.e. osrm does not directly support
>>>> >>>> the concept of a "shortest route".
>>>> >>>>
>>>> >>>> The profile is provided with a LUA file. I had to look this one up
>>>> >>>> :-)
>>>> >>>> Looks a useful scripting language, but why is this profile a script
>>>> >>>> file, and not a simple configuration file of constants (eg. key-value
>>>> >>>> pairs)?
>>>> >>>> Seems like an unnecessary complexity - I'd like to understand the
>>>> >>>> perceived advantages. What is that extra power used for?
>>>> >>>>
>>>> >>>> Finally, the memory usage... I saw a reference to the server
>>>> >>>> requiring
>>>> >>>> 40GB of memory for pan-European routing. Presumably that could be
>>>> >>>> offset with a large swap file(?)
>>>> >>>> A large swap file has worked well when I was testing the US-South
>>>> >>>> region on an 8GB machine.
>>>> >>>> Presumably I could do the same for world preparation & routing? Have,
>>>> >>>> perhaps a 100GB+ swap file, ideally on an SSD.
>>>> >>>>
>>>> >>>>
>>>> >>>> Cheers,
>>>> >>>>
>>>> >>>> Richard Marsden
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> OSRM-talk mailing list
>>>> >>>> OSRM-talk at openstreetmap.org
>>>> >>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>> >>>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> OSRM-talk mailing list
>>>> >>> OSRM-talk at openstreetmap.org
>>>> >>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> OSRM-talk mailing list
>>>> >> OSRM-talk at openstreetmap.org
>>>> >> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > OSRM-talk mailing list
>>>> > OSRM-talk at openstreetmap.org
>>>> > https://lists.openstreetmap.org/listinfo/osrm-talk
>>>>
>>>> _______________________________________________
>>>> OSRM-talk mailing list
>>>> OSRM-talk at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>
>>>
>>>
>>> _______________________________________________
>>> OSRM-talk mailing list
>>> OSRM-talk at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>
>
> _______________________________________________
> OSRM-talk mailing list
> OSRM-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk