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 <[email protected]> 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 > <[email protected]> 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 > >> <[email protected]> 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 <[email protected]> > >>> 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 > >>>> [email protected] > >>>> https://lists.openstreetmap.org/listinfo/osrm-talk > >>> > >>> > >>> _______________________________________________ > >>> OSRM-talk mailing list > >>> [email protected] > >>> https://lists.openstreetmap.org/listinfo/osrm-talk > >> > >> > >> _______________________________________________ > >> OSRM-talk mailing list > >> [email protected] > >> https://lists.openstreetmap.org/listinfo/osrm-talk > >> > > > > > > _______________________________________________ > > OSRM-talk mailing list > > [email protected] > > https://lists.openstreetmap.org/listinfo/osrm-talk > > _______________________________________________ > OSRM-talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/osrm-talk >
_______________________________________________ OSRM-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/osrm-talk
