HI all,
I've ported my application to osrm 5.1 and added the travel distance
from village to road to my results using osrm.nearest and assuming that
the resulting waypoint is the same as the source point osrm.table is
using for its calculations.The percentage of the population that could
reach a hospital in 60 minutes dropped from 95.8% to 92.3% when assuming
a 5km/h speed and further down to 68.8% when assuming a 1km/h speed for
the source to road distance. This is definitely an improvement in
accuracy over the previous result, though if this could somehow be
incorporated with the osrm.tables function that would be even better,
since the source -to-road traveltime is a big part of the total
traveltime here. Obviously the same situation might apply to the
destination points (in my case they are on or close by the road so it
doesn't matter that much, but that doesn't need to be the case in other
situations).
Cheers,
Steven
BTW the osrm.nearest syntax is a bit weird; the documentation states
"Where|coordinates|only supports a single|{longitude},{latitude}|entry."
which apparently meant { coordinates: [ [ lon,lat ] ] } in stead of {
coordinates: [ lon, lat] } but that might be me reading it wrong.
On 4/19/2016 6:00 PM, Steven M. Ottens wrote:
Hi Daniel,
Your idea is pretty much what I used for my travel time map:
http://stvno.github.io/page/bartholomap/ though N was easier to
determine: nearest non-stop airport, nearest one stop airport etc.
For overland speed: I like the wiggle factor Bjorn was suggesting,
however it supposes we know the landuse, which as far as I know OSRM
doesn't take into account
For N if we can have a default of 4 on separate roads that would
probably help a lot already without too high a cost. (separate roads
being at least one fork in the road away) Does that sound reasonable?
I guess the strategy to determine the N points could be made
configurable, different use cases require different strategies I'd say.
Steven
On 4/19/2016 4:44 PM, Daniel Patterson wrote:
Hi Steve,
I was thinking about exactly this just the other day when
considering https://github.com/Project-OSRM/osrm-backend/issues/2277
What I came up with was roughly:
Find N nearest neighbours, and calculate the walking duration to each
Insert all neighbours into the search heap, and set the initial
cost to the walk duration
Route as normal, but include the walk duration in the total time
at the end
The question is, how big do we make N, and how do we determine the
overland speed? Overland speed I suppose could be a profile
parameter, and it feels like walking speed would usually be the most
appropriate thing. But I'm not sure how many possible start points
we should reasonably consider. Everything within a radius? Closest
N points?
daniel
On Tue, Apr 19, 2016 at 12:39 PM, Steven M. Ottens <[email protected]>
wrote:
Hi all,
I am working on a tool that will calculate the travel time from
villages to for instance the nearest hospital for rural
accessibility analysis. So far I have build a tool which will
calculate this for 215.000 villages in a few minutes, thanks to
the help of Daniel P. However I realized that not all villages
are on a road, actually quite a few are at least an hour walk
from the nearest drivable road see:
http://stvno.github.io/img/OSRM-snapping.png
The villages are typically connected to the roads by informal
trails, which I do not have as a road network. So I was wondering
if it would be possible to add a basic penalty to the distance of
the point to the nearest road.
I am aware that the nearest service will provide me with the
distance:
https://github.com/Project-OSRM/osrm-backend/wiki/New-Server-api#service-nearest
but before I am going to calculate the extra traveltime for each
village, I was wondering if it is possible to integrate this with
an osrm.table request. I am aware this opens quite a can of
worms: if there is a penalty to snapping, it might be worth it to
snap to a road which is further away, but in the end quicker to
get to the destination. But for the moment I'm happy with just
the added traveltime for nearest road snapping.
Any suggestions on how to handle this?
Steven
_______________________________________________
OSRM-talk mailing list
[email protected] <mailto:[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
