Multiple isochrones

[Alain L'Hostis]

I want to produce a big set (hundreds) of isochrones of 10 minutes cycling around railway stations, and several isochrones overlap. Instead of splitting isochrones in QGIS is there a way to generate from OTP the isochrones separated by trip time measurement and not geometrically?
I have a python script that for the moment just produces the isochrones one by one, from a csv files with lat and lon coordinates, without considering the others. How could I produce nicely split isochrones from inside OTP?

[Laurent Grégoire]

Hello Alain,

You mean that you would like the isochrone from different origins that overlap to be merged together in OTP directly?

Currently that's not implemented. In theory, that would be feasible, but it would be much more complex (and would probably not gain anything time-wise) compared to merging the result using a standard geometry library. IMHO the simplest solution would be to do it in python directly using an appropriate geometry library, if that exists (returned data is geojson or shapefile).

Le mardi 21 février 2017 15:59:51 UTC+1, Alain L'Hostis a écrit :

I want to produce a big set (hundreds) of isochrones of 10 minutes cycling around railway stations, and several isochrones overlap. Instead of splitting isochrones in QGIS is there a way to generate from OTP the isochrones separated by trip time measurement and not geometrically?

HTH,

--Laurent 

[Alain L'Hostis]

Dear Laurent,
thank you for your quick reply. Yes you understood correctly my issue.
It is unfortunate because the separation of isochrones is not purely  a matter of geometry and it would be nice to have some minimum time computation to trace the border between isochrones, this is something worth to be developed, in my sense.
Best,
Alain

[Laurent Grégoire]

What do you mean exactly by it's not purely a matter of geometry? If the isochrone computation is correct then it should, or I'm missing something?

[Alain L'Hostis]

take for instance two overlapping bike isochrones on a terrain with a constant slope
"pure geometry", for instance Voronoi polygon around stations, imply that the border between isochrones is midway, ant mid-distance while, on the terrain with slope, the border should be located closer to the down station, and not completely balanced
So what matters is real travel times and not pure geometry, this is what I meant.
I hope it is clear for you now

[Alain L'Hostis]

a solution would be that OTP output as network measurement as opposed to isochrones, or maybe shaded isochrones of the Analyst? and then find the GIS splitting procedure along equal values? (but I do not know how this could be done)

[Andrew Byrd]

Hi Alain,

At first I interpreted your question the same way Laurent did. It seemed like you just wanted to simply merge isochrones, which is logically an “or” operation: give me all points that are within 10 minutes of stop A, or within 10 minutes of stop B, or within 10 minutes of stop C… Such an “or” operation is equivalent to a union of sets, so it’s the union of the isochrone geometries around all the stations, which is indeed a purely geometric operation. 

But if I understand correctly from your later messages, what you really want to do is partition space into disjoint subsets (https://en.wikipedia.org/wiki/Space_partitioning), meaning you want every point in space to be associated with exactly one transport station (the closest station), or with no transport station if it is more than 10 minutes from any station.

Internally most of our analysis capabilities are raster operations, including the isochrones. For isochrone tiles, we find the travel time to every pixel in the tile and color them accordingly. For vector isochrones we calculate the travel times to a grid of points and build the vector shapes from that.

Your problem could also be solved with a raster approach: Establish a grid over the whole study region. For every transit station, compute the travel time to all reachable grid cells. All these grids can be reduced into a single final grid, maintaining for each cell a closest station and a best travel time. There is no need to save all the individual grids, as the reduce operation is associative and can be done progressively, applying each newly generated grid to the partial result grid.

Another way to do this would be to start a graph search from all the transit stations simultaneously, by placing one initial state at each station. For each grid cell (pixel) in the output, using the existing raster isochrone classes, you should be able to reconstruct a path and trace it back to its origin point, which will be the closest station.

Both of these approaches are going to require some custom code though.

Regards,

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.