-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Select Link custom modification #924
base: dev
Are you sure you want to change the base?
Conversation
this can be used as an experimental worker version with a custom modification of r5type select-link adresses #913
report their quantity as a scenario application info message
the result of applying this modification is transient so this wont' work
these should be the ones created by other modification in the scenario. also factor out long reference chain as final List variable.
report route name in totals row report proportions out of total iterations reaching destination provide constituent rows below summary rows
In response to testing and feedback, the output format has been modified as follows:
There is still one summary line (indicated by ALL in several columns) for each unique O-D pair that has paths passing through the select link. But now, below that row are the rows that were combined to create it. In the summary rows, the lists of all routes now include the route name, not just the ID, as routes created by scenario modifications have random IDs. Perhaps most importantly, the iterations column is now expressed as a decimal proportion out of the total number of iterations that reached the destination from the origin. This resolves one known issue mentioned above. It would probably be preferable to show this number of iterations that successfully reached the destination, or to show the proportion of total iterations that reached or did not reach the destination. But this did not fit into the existing columns, and changing the column headings or column count will requirer greater changes to the backend. We can potentially make those changes later, for now this is just a custom worker that must adhere to the existing backend expectations. |
@@ -170,7 +171,8 @@ public List<PixelWeight> getPixelWeights (Geometry geometry, boolean relativeToP | |||
|
|||
double area = geometry.getArea(); | |||
if (area < 1e-12) { | |||
throw new IllegalArgumentException("Feature geometry is too small"); | |||
LOG.warn("Discarding feature. Its area is too small to serve as a denominator ({} square degrees).", area); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also added names as in path-route-names branch
there is still no selected-link label on the detailed iterations/paths. They are just ordered immediately below the summary including them.
always store nUnfilteredIterationsReachingDestination
For future use (see #924, for example)
* Write feedIds as separate column feedIds are derived from boarding stops * Add "group" column in CSV path results For future use (see #924, for example)
This can be used as an experimental worker version with a custom modification of r5type select-link.
Adresses #913.
Modification format:
This will find all stop-to-stop segments on all routes passing through the area defined by lat/lon/radiusMeters. When a regional analysis is run with freeform point sets and "record paths" enabled, each path is then checked to see if it contains one of these segments, and only the ones passing through the zone are kept.
The selection point in the example modification is near a transit stop, so it grabs one segment of a few patterns in one direction, and two segments (on either side of the stop) in the other direction. This is indicated in the worker logs and returned as scenario application info for display.
Below is an example of the output CSV. I used a set of 10 randomly placed points as origins and destinations, so there are 100 total origin-destination pairs. The output CSV has one single line per unique O-D pair, and only these 15 O-D pairs have any itineraries passing through the selected area. All the separate paths for that O-D pair are condensed into one (this is done in a self-contained post-processing step, and could conceivably be disabled).
The routes column shows all bus routes used in any itinerary that passes through the selected area. The totalTime column is the average door-to-door time of all itineraries passing through the selected area. The nIterations column is the number of times (out of 120 total) that an itinerary passed through the selected area.
A known issue is that this single iteration count may not allow deducing the proportion of trips on this OD passing through the selected link, because some of the iterations may have no paths (the destination may be unreachable on some of the iterations and not others). One solution would be to include a second line for each OD present, where the routes field is also ALL, as a denominator.
I have only tested on smaller data sets (Portland, Oregon) but it seems to work as expected.
I implemented this as a custom scenario modification type. It doesn't really modify the network so it's a bit odd to think of it as a modification, but it has the following good characteristics:
a) Can be used as a custom worker version on the standard production system (without re-deploying the whole system)
b) Retains and reuses geographic intersection calculations to make it faster (the link selection step is a bit slow, making it part of the scenario means it's reused)
c) Doesn't require rebuilding the transportation network files, can be used on existing networks and scenarios by just adding one modification
d) Doesn't change the CSV output format, just removes all rows that do not pass through the selected area