[OSRM-talk] Add costs on route sections.
Pedro Luiz Cumino
pedro.cumino at gmail.com
Thu Oct 6 04:13:57 UTC 2016
"*For this you need to map from your sensor's location to OSM ids in order
to update edge weights.*"
This is what is coming to my mind:
1) What's the relationship between the OSM IDs and a geolocation (latitude,
longitude)? Is there any relationship? I don't think it is feasible to use
the nearest street engine with the sensors location in order to get the IDs
of the nearest street segment for each sensor and then edit
the update-speed file to finally run the route engine. Is there any method
to get the street segment ID once I have the position I want?
2) I understand that changing the speed would be costly when choosing a
way. However, I don't see it's useful for pedestrians once the foot speed
is much lower than the maximum speed of every street. So, from where should
I start to implement something other than the speed route?
After some reading:
3) What I understand until now is that I should edit the OSM file in order
to add some reference or tag information about the segment/way condition
(pollution, segment barrier, etc). Afterwards, create a *Lua* profile and
use those added tags in order to implement a logic to avoid some
segments/ways. Something like described here
<https://www.mapbox.com/blog/osrm-using-external-data/> and already
So the final questions are:
Is there any documentation about how edit an OSM data in order to add third
Am I thinking reasonably to solve this problem?
Is there any documentation about how lua shall be used in this context?
Should I use the built profiles as a reference instead of checking an
already existent documentation about Lua for OSRM?
On Fri, Sep 30, 2016 at 7:17 AM, Daniel Hofmann <hofmann at mapbox.com> wrote:
> There are two features you could make use of.
> 1/ The Traffic feature for continuously updating edge weights depending on
> live traffic feeds:
> For this you need to map from your sensor's location to OSM ids in order
> to update edge weights.
> 2/ The Raster feature: similar to elevation data you can use your sensor's
> reading to adapt the cost for routing over certain segments:
> Note: at the moment both approaches will change your ETAs until
> https://github.com/Project-OSRM/osrm-backend/pull/2399 lands.
> If all you want is to discard certain ways where pollution is to high, you
> can do this already in the car.lua profile's way_function.
> Changes there require re-running the osrm pipeline, but this may be
> feasible depending on your region's size and how often you want to change
> Daniel J H
> On Fri, Sep 30, 2016 at 3:25 AM, Stephen Woodbridge <
> woodbri at swoodbridge.com> wrote:
>> Hi Pedro,
>> The way OSRM works is that you have to prepare the data before generating
>> the route. You can probably modify the prepare process by writing additions
>> to the LUA scripts it calls. But for large coverage areas the prepare step
>> takes a lot of time.
>> You also mentioned that this is a web based application, so typically all
>> web clients have to use the same routing instance which may be ok if you
>> application does not expect each web user to be able to have their own
>> privately modified graph for routing. For example if the route modification
>> is a server process and all web client use the same modified graph then you
>> would be ok.
>> But is each web client can modify the the graph based on their input and
>> then expects to solve the graph for a route based on their local
>> modifications, you probably don't want to use OSRM, something like
>> pgRouting might be more appropriate.
>> Others on the list can probably offer more detailed suggestions on where
>> to look for examples of code to change the graph prepare process. I believe
>> some work has been done to support traffic feeds and this sounds like it is
>> very similar to that.
>> On 9/29/2016 8:19 PM, Pedro Luiz Cumino wrote:
>>> Hello all,
>>> I'm a new user of the ORSM engine. I can run the basic setup and the
>>> I'm working in build a route engine for web purpose in order to avoid
>>> certain areas.
>>> I'm wondering if it's possible to add costs to a certain group of route
>>> sections. This costs must be considered during the route
>>> calculation. The idea is better explained below:
>>> I have the report coming from an external service, which comes as a JSON
>>> object. It informs me the location where a sensor is present and must be
>>> considered when calculating the route, like a cost to the lane stretch
>>> pointed by the latitude and longitude from the sensors JSON object. The
>>> sensors classify the region as *high*, *medium* or *low* level of
>>> pollution. I need to set this cost to the lane stretch and then compare
>>> if it's worthwhile to select the lane stretch where the issue is present
>>> or if select another route is a better decision.
>>> How open is the route solver service in order to implement this kind of
>>> cost over a route? The idea at the end is to select the lower cost route
>>> by comparing the issue level, the time travelling and the travelled
>>> distance using my own algorithm.
>>> The Figures 1 and 2 illustrate what I'm looking for. Figure 1 shows the
>>> route A as the best one to be chosen, even with an issue place on it
>>> (the issue with the lowest level). The route B is the worst since it has
>>> the highest issue level/cost. The route D is possible to reach the end,
>>> but the cost would be too high to be chosen, what makes it the worst
>>> route. Figure 2 shows the route B as the best route to be chosen because
>>> the cost of the issue on B is lower than the cost that the total
>>> distance of D represents.
>>> Figure 1
>>> Figure 2
>>> In summary, I need a way to insert a cost to certain routes (using the
>>> information from coming from another service) and then calculate the
>>> route considering such costs. At the end, the algorithm to be
>>> implemented will consider both issues and route distances.
>>> Which files should I modify in order to accomplish it? Where can I find
>>> the routing algorithm used by the engine?
>>> Thanks in advance!
>>> Kind regards,
>>> Pedro Luiz Cumino.
>>> OSRM-talk mailing list
>>> OSRM-talk at openstreetmap.org
>> This email has been checked for viruses by Avast antivirus software.
>> OSRM-talk mailing list
>> OSRM-talk at openstreetmap.org
> OSRM-talk mailing list
> OSRM-talk at openstreetmap.org
Pedro Luiz Cumino.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OSRM-talk