Multimodal access egress script

[KasiaKoz]

Adds a script that finds a link of mode X in the nearest neighbourhood of a PT stop (the stops can, but need not be filtered based on PT modes using the stops).

Works with a single mode in the network.xml graph, e.g. car. This results in new, additional attributes for relevant PT stops

'accessLinkId_car'
'carAccessible'
'distance_catchment'

following convention started in the multimodal access egress test data here. The param distance_catchment retains information about how far the link is (though it's not the exact distance to link).

Method:

Each stop of interest grows by step_size (metres) until it intersects with a link of specified mode, or until the distance_threshold is reached (if this parameter is set). Often there are multiple choices for links intersecting with stop neighbourhood. Right now we select the first link on the list, one day we might be more discerning about which link is the access/egress point of a mode to/from a stop.

Test:

Tested with a Matesto pipeline for Londinium [PR] which generates the network from osm and gtfs inputs with puma, simplifies with genet and (the new thing we're testing here) uses genet to find nearest car links to rail stops. This then gets run using MATSim with appropriate configuration.

MATSim outputs show an agent driving to a PT stop and using a PT service:

[fredshone]

what's the motivation for stepping? Is it much faster than finding the closest and it's distance for every stop?

[ana-kop]

Just to confirm I understand this correctly, re question by @fredshone : you build a SpatialTree of all the links of a particular mode X, within a distance threshold for that step, and then you convert it to a gdf, and then you do a spatial join with a gdf of all the PT stop node locations; if some of the PT stop nodes remain unmatched, you increase the step, build a bigger tree and do the join again... until all the PT stop nodes are matched (or distance threshold is exceeded).

So since you probably end up matching multiple PT stop nodes with their closest link at every step iteration, you end up having to build the tree and do the spatial join fewer times than if you did it separately for every PT stop node, and so it should be faster? (I'm assuming building a tree + doing spatial join is slower than just doing a spatial join with a larger data frame)

[ana-kop]

this is really sleek! 👍

[KasiaKoz]

@fredshone I see it as the first step to finding a closest link (LineString) to a point. One day when we want to be more precise and find the closest link we can extend this by first: point-ising the links (split the linestring into series of points) and then: finding which point is the closest (be able to get the precise distance then) and what link it belongs to for snapping.

It's the least effort approach, using what have already been built for PT snapping with genet. We have a pretty snappy method for finding point - point closest neighbour and distance that would work well with the extras I described above. (cc @ana-kop for your reference: this is the snappy method I mean)

[KasiaKoz]

@ana-kop the spatial tree is built only once as it's the most expensive process. The stops grow their neighbourhoods by step_size until they hit some links.
BTW, the spatial tree has more functionality that is not being used here. Most notably, it's used for routing when snapping PT with genet.

[KasiaKoz]

Added some extras to this script and renamed it.

• handling multiple modes - you can snap multiple modes to the PT stops of given modes
• handling teleport modes - adds accessible tag only for the defined modes

e.g.

<stopFacility id="910GCLPHMJ1" x="527206.6904087012" y="175500.35337682866" name="Clapham Junction" linkRefId="5221366977632357115_5221366977632357115">
    <attributes>
        <attribute name="accessLinkId_car" class="java.lang.String">5221366976716902339_5221366976715137595</attribute>
        <attribute name="carAccessible" class="java.lang.String">true</attribute>
        <attribute name="car_distance_catchment_tag" class="java.lang.String">100.0</attribute>
        <attribute name="accessLinkId_bike" class="java.lang.String">5221366976716902339_5221366976715137595</attribute>
        <attribute name="bikeAccessible" class="java.lang.String">true</attribute>
        <attribute name="bike_distance_catchment_tag" class="java.lang.String">100.0</attribute>
        <attribute name="walkAccessible" class="java.lang.String">true</attribute>
    </attributes>
</stopFacility>

Re-ran an updated matesto test pipeline:

Update:

- id: genet-pt-rail-car-bike-walk-access-egress
  uses: docker://758645626094.dkr.ecr.eu-west-1.amazonaws.com/genet:KasiaKoz-multimodal_access_egress
  args: [
    "intermodal_access_egress_network.py",
    "--network", "working-dir/londinium/2_genet_simplified/network.xml",
    "--schedule", "working-dir/londinium/2_genet_simplified/schedule.xml",
    "--vehicles", "working-dir/londinium/2_genet_simplified/vehicles.xml",
    "--projection", "epsg:27700",
    "--pt_modes", "rail",
    "--network_snap_modes", "car,bike",
    "--teleport_modes", "walk",
    "--step_size", "50",
    "--distance_threshold", "200",
    "--output_dir", "working-dir/londinium/3_genet_mm_access_egress"
  ]
  dir: /

Success:

[ana-kop]

Great stuff!