Skip to content
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

City-specific tolerance parameters for cleaning/consolidating intersections should be allowed #138

Closed
carlhiggs opened this issue Sep 2, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@carlhiggs
Copy link
Collaborator

Currently, the intersection cleaning/consolidation process uses a single tolerance parameter across the entire project, with a default of 12 metres. This is used to ensure that representation of features such as roundabouts don't bias estimates for street connectivity upwards due to excessive node artifacts; instead, the network is simplified by some tolerance value.

The current default of 12m was used following review of networks in different contexts (e.g. dense inner city laneways, and sprawling outer suburban neighbourhoods with cul-de-sacs) in the Australian context, and appeared to perform adequately in our preliminary 25-city study.

However, when this was applied to Helsinki (by @VuokkoH, see https://github.com/VuokkoH/osmnx-intersection-tuning/blob/main/osmnx-intersection-tuning-helsinki.ipynb ), it was found that a 5m tolerance was more appropriate due to the dense and detailed way that OpenStreetMap had been used to represent urban features in that context.

This means that we should consider allowing some city-specific tuning of the tolerance parameter, to ensure the representation of cleaned intersections best represents the reality on the ground. The risk is that street connectivity would be evaluated in a different way in different cities, causing problems for comparability. However, as Vuokko's investigations demonstrate, in the Helsinki context the 12m tolerance leads to visibly apparent over-cleaning and hence under-estimation of true connectivity. As such, allowing city-specific tuning appears the most sensible option.

This will involve modifying the pre-process script _project_setup.py to read a city-specific parameter defined in region_settings instead of project_settings of the project configuration file _project_configuration.xls.

This should be straightforward to implement; i'll aim to do this in the coming week.

carlhiggs added a commit that referenced this issue Sep 2, 2022
… parameter to being a local (city-specific) parameter; this addresses #138
@carlhiggs carlhiggs added the enhancement New feature or request label Sep 2, 2022
@carlhiggs
Copy link
Collaborator Author

I just pushed up a change in the _project_configuration.xls file as described above, which achieved the above amendment! @VuokkoH this means that if Helsinki were added as a city, it could have a network_tolerance parameter defined as 5 (if that is what has been determined as most appropriate) in the region_settings worksheet. I'll close this issue now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant