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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[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 > > _______________________________________________ > 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
