Isochrones reachability using too high maxspeeds

[TimMcCauley]

The reachability factor for isochrones is too low due to maxSpeeds being too high for every profile. I assume it has got do with with

https://github.com/GIScience/openrouteservice/blob/master/openrouteservice/src/main/java/heigit/ors/routing/graphhopper/extensions/flagencoders/nextgen/NextGenBikeCommonFlagEncoder.java#L147

Being used here:

https://github.com/GIScience/openrouteservice/blob/master/openrouteservice/src/main/java/heigit/ors/isochrones/Isochrone.java#L49

Example request:

http://localhost:8082/openrouteservice-4.7.0/isochrones?attributes=area|reachfactor&format=json&location_type=start&locations=8.684177,49.423034&profile=cycling-regular&range=100&range_type=time&units=m

with 50 km/h (it is using the downhill speeds I think) this will compute a reachability factor of only 0.1 as the maximum reach area is

(14m/s * 100s)squared * math.PI= 5.309.291 square meters

and the area reached on the network is

629.313 square meters

resulting in such a low reachability.

[TimMcCauley]

Minor patch in #333 which doesn't consider elevation now by default for cycling-regular|cycling-road|cycling-mountain.

The impact of consider_elevation to true has yet to be examined (#334).

[marq24]

ok - after just few minutes of investigation ->

making use of _searchContext.getEncoder().getMaxSpeed(); in order to calculate the ConcaveBallsIsochroneMapBuilder is IMHO not wise...

When I understand this correct, then this assumes, that I can always travel with MAX speed... which is IMHO not correct...

the FlagEncoder.getMaxSpeed() is used in just few places - one it the ConcaveBallsIsochroneMapBuilder - another one the GridBasedIsochroneMapBuilder (but there the maxSpeed value is not used (at least that's what I have understood)

Another one is the HiddenMarkovMapMatcher, TrafficAvoidWeighting and in the ExtraInfoProcessor...

While in the ExtraInfoProcessor it seams to be that way speed will be compared to the max speed - the HiddenMarkovMapMatcher is IMHO also worth investigating

[rabidllama]

When I have been looking into the issue relating to smaller isochrone distances, I found that this max speed value (in the case of pedestrian at least) is actually the maximum possible speed that can be stored on the graph. For pedestrians that is 15km/h which obviously is "wrong". There is a mean speed value in the GH code (4km/h for pedestrian), but unfortunately this is never made available outside of the package.

I think that in the case of vehicles hte speeds on the road is taken into account, but it needs to be double checked as I think that is when you explicitly provide the way into the method to check rather than the generic getSpeed() method

[nilsnolde]

I'll take this on if noone else is working on this currently.

[nilsnolde]

So, I looked at this and I think it's fairly straight forward.

As @marq24 mentions, setting the speed to maxSpeed() for all flag encoders is really wrong. Apparently people started to define their own speed depending on the flag encoder. We can either do this for bike profiles as well. If so, I'd rather do it like @rabidllama and define a 'MEAN_SPEED' in the encoders directly (not possible for foot-* since GH core). Question: what will the mean speeds be?;) cycling-electric > cycling-road > cycling-regular = cycling-mountain? Are there any reference values I can adhere to?

I didn't look into driving-* profiles yet at all. If it's true that waytype specific speeds are are taken into account I wonder why not for biking..

[marq24]

concerning the "avg speeds" I would say (from my personal riding experience)

cycling-road (30-25km/h) > cycling-electric (24-20km/h) > cycling-regular (19-15km/h) > cycling-mountain (14-10km/h)

[nilsnolde]

Nope, for vehicles it's also max_speed. In Berlin down-town (highly accessible), a driving-car accessibility is around 0.03 for 10 mins ranges. For higher ranges, it increases (mostly bcs primary and motorway can be used for routing). On the other hand, rural highways give higher reachability for the same ranges, which is counter-intuitive..

Adjusting speeds to mean speeds won't do much good here I fear. At least for profiles with a huge speed range, like driving-*, where residential and rural reachability will differ. I'll see if I can implement a weighted median of waytype speeds of the precomputed edge maps for the different profiles (not so urgent for cycling-* & foot-*).

EDIT

Thinking a little more: what is reachability really? Does it have ANY meaning for driving-* profiles? It's generally the difference between the area I reach on the street network and the area I'd reach crossing open space using the same maximum range (the way I understand it). In that way, it's really meaningless for driving-* at least. Any opinions how to handle those profiles are welcome.

[marq24]

for any emergency service it's a really valuable information what is the Xmin-Range (X=2-15) operation Radius/Area... But therefor it will not help at all to calculate the radius with an mean speed.

Of course for hospitals and fire-stations this can be calculated in advance - but in any disaster scenario the location/start point can be random + the fact that there are possible inaccessible areas as well...

I "thought" that was/is the main use case of the Isochrones? So I am very surprised that OSM-way tags like maxspeed per way will be simply ignored... Does this base on the assumption that an emergency vehicle can violate any speed regulations?

[nilsnolde]

Oh sorry @marq24, this might be a bit confusing. The whole thing is actually only about the attributes=reachfactor option for isochrones. It estimates reachability, i.e. what is the accessed area of a profile on a street network vs. accessibility in open space (as-the-crow-flies) for a given range, e.g. 5 km or 10 mins. So, it gives back a factor in 0.0 - 1.0. For the open-space, we need to define some mean speed for each profile and that's where I'm struggling for driving-*. Two options (that I see):

• hard-coded mean speed per profile (static)
• weighted average of waytype speeds within the isochrone range for each profile (dynamic)

The latter option is maybe contradictory to actual reachability, since waytype speeds are part of the restriction imposed by the street network compared to open space crossing. It would still make driving-* a lot more meaningful.

p.s.: isochrones use dijkstra as well for routing:) the reason why it's so slow..

[rabidllama]

Fixed in Release 5.0.2