Comments (3)
Thanks @kuanb yes that is the intent of those lines. What you suggest is a clearer and cleaner way of doing that. You are correct, this would bring us one step closer to allowing custom parameterization of the connector cost.
One issue is that all the functions in urbanaccess assume travel cost in terms of time not distance so more work would have to go into making time a optional weight parameter throughout the tool so that raw distance could be used throughout. Distance is calculated throughout its just not exposed to the user via parameters.
I will close this issue as the headways are being calculated correctly as intended but feel free to post in this open issue: #36 the details on how to achieve the parameterization.
from urbanaccess.
Hi @kuanb thanks for the report. I have quickly looked into it and I cannot replicate the issue it all looks like it should be correct to me.
What is happening is:
The mean headway gets calculated for each route stop pair then it gets joined to the connector edge table by using only the to
edge id where in this case only ids that match the route stop ids in the two tables are joined - the osm ids are not joined on as these are not route stop ids thus resulting in nans for the mean. This results in the df below that eventually turns into the connector edge table:
Note the osm to transit edges have a value in the mean column and that value has divided by 2 and been added to the weight column and the transit to osm edges have nans and the weight column for those is just the walking time. When the mean is applied to the weight column only the mean values that are not nan are added to the weight which in this case are only the osm to transit edges.
I hope that makes it clear, let me know if you are seeing something different. If so, please send a script of the full workflow so that we can replicate it and highlight the values in the df table of interest. If you cannot replicate and this explanation makes sense also let me know and I will close this issue.
from urbanaccess.
Thanks Sam.
Given your above message, it sounds like the intent of these lines:
urbanaccess/urbanaccess/network.py
Lines 269 to 270 in 84478b7
Is to replace the NaN values with just the original calculated walk time.
If that is the case, then we may want to make that explicit and enforce it as only on that direction by updating using a Pandas .loc[]
lookup to replace just those values.
In addition, we’ll want to make that explicit in the parameters, too:
Parameters
----------
ped_to_transit_edges_df : pandas.DataFrame
DataFrame of the osm to transit connectors
Should acknowledge that what is being input is the combined (bi-directional) edges and then a add’tl kwargs could be edge_tag_to_add_headway=‘osm_to_transit’
and then we can .loc
by all tags that are not that and make their weighting just the value of distance.
This is also an opportunity to parameterize how distance/cost for the connector is calculated. For example, one could defensibly argue for no-cost (weight 0) connectors from transit to OSM network (plus headway cost). Parameterization would enable this customization.
from urbanaccess.
Related Issues (20)
- Hi,
- Hi,
- GTFS feed won't load to df (calendar_dates file instead of calendar file) HOT 3
- Kernel appears to have died when saving h5 HOT 3
- Saving network to shapefile HOT 1
- Unicode decode error when trying to load gtfs of buses in Buenos Aires HOT 1
- Needs updating to assure Pandas v.0.23 compatibility HOT 2
- pyrosm for network download HOT 2
- `geopy` 2.0 does not support ` vincenty HOT 1
- integrate_network returning floats instead of ints HOT 10
- gtfs import fails if `calendar_dates.txt` is missing HOT 3
- 403 error with certain transit providers due to missing headers in request HOT 5
- Workflow bug: Destinations for accessibility queries should be linked only to the base network
- Mean wait time vs. mean headway HOT 1
- Multiple networks in memory at once
- Routing that's sensitive to departure time
- Trying to read utf-8 file on cp1252 system HOT 5
- Two feeds not passed into network HOT 3
- Plot does not render title/axis titles
- OSM download function broken HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from urbanaccess.