Hi,

As a follow up to this, I wanted to report some progress.

Using Tools/simpleclient.cpp as a model, it was pretty easy to create a class that mimic that code for our limited needs. We connect via shared memory and we are able to get response times from viaroute requests of 11-20 ms where they used to be about 500 ms.

And this is still passing json documents in the response so some of this time is spend encoding and decoding the json.

If you need to do something similar, I recommend looking at Tools/simpleclient.cpp and then wrapping those ideas into a class as you require.

Thank you everyone that offered ideas and suggests.

-Steve

On 11/7/2014 2:42 PM, Stephen Woodbridge wrote:
I'll answer a bunch of the reply's here:

1. we do pre-compute a distance matrix and use that already but if you
have a situation like:

o----------t----------u--------v----->
            |          |        |
            B          C        |
            |          |        |
A----------x----------y--------z---D---->

and you want the route A-B-C-D if you use a precomputed distance matrix
you get a path A-x-B-x-y-C-y-z-D (depending on where B and C are in
those segments (ie: the vehicle makes a u-turn at B and C) when we want
a route like A-x-B-t-u-C-y-z-D. OSRM will generate the later route if
you ask for the route A,B,C,D with via points. So a simple distance
matrix does not work well.

2. The performance issue is not with the C++, we get basically the same
performance using Perl (GET) or curl at the command line, or curl from C
or from c++.

3. I will look at the node-osrm code. I remember seeing that posted, but
had forgotten. Thanks for the reminder of that.

4. I am some what stuck on an older version of the source code because
I'm not in a position to upgrade my server OS and packages. :( So this
is somewhat problematic for me at the moment.

Anyway, lots of great ideas. I appreciate them all and will be digging
into them over the weekend.

Best regards,
   -Steve

On 11/7/2014 12:46 PM, John Firebaugh wrote:
Hi Steve,

Recent versions of osrm-backend build a library which you can link
against. See https://github.com/Project-OSRM/node-osrm/ for an example.

cheers,
John

On Fri, Nov 7, 2014 at 7:13 AM, Stephen Woodbridge
<wood...@swoodbridge.com <mailto:wood...@swoodbridge.com>> wrote:

    Hi,

    I seem to remember a while back that there was a discussion about
    the possibility to embed the OSRM routing engine at the code level
    rather than doing HTTP requests to a server.

    I now find myself in a position that this would be desirable to do.
    I have a small coverage area like a city, but I'm getting killed by
    the overhead of formatting requests as strings, making a socket
    connection to osrm-routed, parsing the responses, etc. Making local
    requests my server this is taking 4-500 ms per request.

    Basically, I'm doing viaroute requests with 2-100 via points. 99% of
    the time all I need to know is the travel time.

    Since I'm developing in C++, I thought it might be easy and much
    faster to instantiate the routing engine and then have a simple
    interface where I can pass a container of points and get back the
    travel time for that route and/or the path coordinates. But I could
    live without the coordinates if I had to.

    Has anyone done this already? Can you share?

    I have started digging through the source to see if I can do this,
    but working my way in from osrm-routed or Tools/simpleclient.cpp the
    code is very entangled with all the http request/response stuff that
    I would ideally like to avoid. So far the most promising path looks
    like using some variant of the simpleclient, but its not obvious if
    or how to untangle all the json stuff and simply return a struct or
    class to the caller without that. I spent most of yesterday, digging
    through this and made a lot of progress just understanding
    simpleclient and getting ti to compile and work and get it to actual
    return results using a shared memory connection.

    A little help in this direction would be appreciated.

    Thanks,
       -Steve

    _________________________________________________
    OSRM-talk mailing list
    OSRM-talk@openstreetmap.org <mailto:OSRM-talk@openstreetmap.org>
    https://lists.openstreetmap.__org/listinfo/osrm-talk
    <https://lists.openstreetmap.org/listinfo/osrm-talk>




_______________________________________________
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk



_______________________________________________
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk


_______________________________________________
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Reply via email to