[OSRM-talk] Road speeds and profile restrictions

Daniel Hofmann hofmann at mapbox.com
Mon Sep 21 12:15:37 UTC 2015


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20150921/79ef5e4e/attachment.html>


More information about the OSRM-talk mailing list