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