[OSRM-talk] Road speeds and profile restrictions

Richard Marsden winwaed at gmail.com
Mon Sep 21 20:45:27 UTC 2015


Thanks - yes the visitor initally looked a bit complicated, but I
think your example will help.

C++: not necessarily, but I don't particularly like Javascript, so
I've never taken to Node.js! Javascript is a necessary evil on the
client, but speaking generally, I think there are usually many better
choices for the server. Granted, C++ probably wouldn't be one of
those.


Richard

On Mon, Sep 21, 2015 at 3:12 PM, Patrick Niklaus
<patrick.niklaus at student.kit.edu> wrote:
> 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
>
> _______________________________________________
> OSRM-talk mailing list
> OSRM-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk



More information about the OSRM-talk mailing list