Problem with Isochrones

[Marcus Young]

Hi,

Ive used the isochrone API to create a 10 minute drive-time isochrone. This is shown in the attached image (after conversion from geojson to shapefile using the ogr2ogr web client).

There are two issues. The first is the orphaned polygons. E.g. on the far west of the image. How can it be possible to reach this section of the road within 10 minutes but not other parts of the road that are nearer the start point?

I've also noticed, that this is more like a 5 minute isochrone. If I plan drive routes using the OTP web interface, I can travel substantially further in ten minutes than is shown in this isochrone. The isochone is more like a 5 minute one. This is the URL I used:

http://192.168.0.38:8080/otp/routers/2015/isochrone?&fromPlace=50.796815,-3.186896&mode=CAR&cutoffSec=600

Any ideas why these issues are occurring?

Thanks

Marcus

[Andrew Byrd]

Hi Marcus and Jay,

I see that both of you spotted these islands in driving isochrones in the last few days. 

The essence of the problem is that OTP is indeed using the driving speed to find travel times throughout the network, but the end result of this operation is driving times to all street intersections in the network. The final step is finding travel times to intermediate points along roads and off the sides of roads, and in this step OTP is always applying the walking speed.

The source of this problem can be seen in the Sample.eval() method at https://github.com/opentripplanner/OpenTripPlanner/blob/master/src/main/java/org/opentripplanner/analyst/core/Sample.java#L49

where distances are divided by walkSpeed rather than carSpeed or bikeSpeed. This is because this isochrone code was originally only used for pedestrian+transit searches. When you use it for a car search, the car speed should be applied in the eval() methods.

There is a org.opentripplanner.routing.core.RoutingRequest#getSpeed(TraverseMode) method that could be useful here.

Andrew

--
You received this message because you are subscribed to the Google Groups "OpenTripPlanner Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<2017-01-18 17_42_36-QGIS 2.18.1.png>

[Laurent Grégoire]

Le mercredi 18 janvier 2017 18:49:59 UTC+1, Marcus Young a écrit :

There are two issues. The first is the orphaned polygons. E.g. on the far west of the image. How can it be possible to reach this section of the road within 10 minutes but not other parts of the road that are nearer the start point?

OTP isochrones has been designed for transit + walk, and rely on a speed assumed to be a "walk" speed to determine the accessible points. In your situation what I suspect is that the location at vertices do have the correct times; but as the isochrone generation process interpolate the missing times along edges (which are not available directly from the SPT, the result of the path computation), it uses a "default" walk speed for that computation. What you see on your result are probably small islands around vertices, and holes alongside long edges.

For your second issue, it may be also related to that, but I'm not sure. You have to know that OTP isochrones have never been tested for CAR mode.

To solve this, you can first try if modifying the walk speed taken by the isochrone generation process works (try changing the default walkspeed of the request). If this works, you can solve this properly by setting the speed along edge depending on the current travel mode at both ends of the edge (see SPTWalker.java L108, "double speedAlongEdge = spt.getOptions().walkSpeed;").

HTH,

--Laurent

[Andrew Byrd]

> On 19 Jan 2017, at 02:18, Laurent Grégoire <laurent....@gmail.com> wrote:
> To solve this, you can first try if modifying the walk speed taken by the isochrone generation process works (try changing the default walkspeed of the request). If this works, you can solve this properly by setting the speed along edge depending on the current travel mode at both ends of the edge (see SPTWalker.java L108, "double speedAlongEdge = spt.getOptions().walkSpeed;”).

Thanks, Laurent. I just realized these are vector isochrones, so Laurent’s line indication is more relevant. The one I cited is perhaps only used in raster isochrone tiles.

-Andrew

[Laurent Grégoire]

Le mercredi 18 janvier 2017 19:22:29 UTC+1, Andrew Byrd a écrit :

Thanks, Laurent. I just realized these are vector isochrones, so Laurent’s line indication is more relevant. The one I cited is perhaps only used in raster isochrone tiles.

Both codes do have the issue then. But both are relevant, I think the first post was about the raster isochrone.

[Marcus Young]

Hi Andrew and Laurent,

Thanks very much for the information, I see why the problem is happening now. I wasn't aware that this was only intended for walk+transit.

I tried changing the walkSpeed to 50mph and their was a noticeable reduction in the number of orphaned polygons. Though this did not increase the extent of the isochrone.

Adjustments to the code to resolve this is, I suspect, beyond my abilities.

Marcus

[Jay D]

Thank you for pointing on where the issue in the code is Andrew and Laurent.

I made another attempt an producing the raster isochrone with the code below, which sets the walkspeed to the biking speed. I am still experiencing the issue (see attached). Not sure why, following the code you linked to Andrew it should traverse the edges between the nodes at the "walking" speed..

def getSurface(date,time,mode,latlng):

    query = {

            'batch' : 'true',

            'layers' : 'traveltime',

            'styles' : 'color30',

            'time' : time,

            'date' : date,

            'mode' : mode,

            'maxWalkDistance' : '800',

            'arriveBy' : 'false',

            'fromPlace' : latlng,

            'toPlace' : latlng,

            'crs':'EPSG:26910',

            'walkspeed':6.7,

            

        }

    otpURL = 'http://localhost:8080/otp/surfaces'

    r = requests.post(otpURL, params=query)

    if r.ok:

        rastURL = 'http://localhost:8080/otp/surfaces/'+str(r.json()['id'])+'/raster'

        rimg=requests.get(rastURL)

        if rimg.ok:

            return rimg.content

            

            

    else: print("Surface creation error")

[pesar...@gmail.com]

Dear Andrew,

I have encountered the same issue for isochrone polygons. I noticed that the isochrones are usually smaller than they should be. For example, I created a 10-min walking isochrone from a point in Manchester (attached). I set the walking speed to 1.35m/s (which is very close to the default value 5mile/h) and the mode to "walk" only. As you can see in the picture the edge of the isochrone is even smaller than 8mins walk. Note that, If I increase the walking speed, the isochrone extends. 

 

To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner-users+unsub...@googlegroups.com.