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

comments on paper #90

Closed
caimeng2 opened this issue Aug 2, 2024 · 3 comments · Fixed by #94
Closed

comments on paper #90

caimeng2 opened this issue Aug 2, 2024 · 3 comments · Fixed by #94
Assignees

Comments

@caimeng2
Copy link

caimeng2 commented Aug 2, 2024

The paper is well-written and presents its ideas with good organization. I have the following questions and comments for improvement.

  1. The paper defines a Superblock as "a set of adjacent urban blocks where vehicular through traffic is prevented or pacified, giving priority to people walking and cycling," however, how was this concept operationalized in the package? Did you quantify or measure "adjacent", "urban", "vehicular through traffic is prevented or pacified", and "giving priority to people walking and cycling"?

  2. Related to the previous question, is the package's delineation of Superblocks always accurate? By "accurate," I mean does the delineation always comply with the definition? What would be the limitations, if any, of this package?

  3. It is not clear to me whether the usage of this package is to detect existing Superblocks, or identify an area that is suitable for future Superblock planning. Or both?

    • The first use case seems to be for planning. It would be clearer if you could state your criteria for selecting a potential area and explain why you chose those criteria.
    • The second use case seems to be for existing Superblocks as you talk about the impacts. (Also the overall write-up sounds more like it is for existing Superblocks.) Could you be more specific about what the "valuable insights" are (line 51)?
  4. Line 70-74. Under what circumstances should users choose each partitioner?

  5. Figure 1.

    • Do the different colors mean anything? If no, it's better to make it clear in the legend.
    • What does "representative nodes" in the description mean? Representative of what? I don't get what the colored nodes are.
  6. The analysis feature could be better explained. Urban planners who are not familiar with the graph theory probably won't understand "global efficiency," "directness," etc. A short description of what each of the metrics means would be helpful.

Reference: openjournals/joss-reviews#6798

@cbueth
Copy link
Collaborator

cbueth commented Aug 2, 2024

Hey Meng, thank you for your valuable feedback on our paper and the compliments. Reading through your notes, we think they will improve the paper. Your feedback will be integrated coming week and we will notify you here about the changes and notes.

@cbueth
Copy link
Collaborator

cbueth commented Aug 8, 2024

Response Letter:

The authors would like to thank the reviewer for their constructive feedback to the paper and the further notes on the software package (#91, #92, #93).

Comment:
The paper is well-written and presents its ideas with good organization. I have the following questions and comments for improvement.

Response: We appreciate the reviewer's positive feedback on the paper's organization and writing. We have addressed the reviewer's questions and comments in the revised manuscript (commits: ab5c166, 65e8b37 and 5287061) as follows:

Comment: 1. The paper defines a Superblock as "a set of adjacent urban blocks where vehicular through traffic is prevented or pacified, giving priority to people walking and cycling," however, how was this concept operationalized in the package? Did you quantify or measure "adjacent", "urban", "vehicular through traffic is prevented or pacified", and "giving priority to people walking and cycling"?

Response: The concept of Superblocks is operationalized in the package by partitioning the street network into Superblock-like neighborhoods. Inspired by classical Superblocks as defined, we extend the concept to a computational approach. Cities usually only convert one neighborhood at a time into a Superblock, following a tedious and manual process.
Our package automatically produces a blueprint of potential Superblocks for an entire city. This way blocks are always "adjacent", while blocks usually are in an urban area, but the package can be used for any area with a street network. We do not quantify "urban". "vehicular through traffic" is measured by the betweenness centrality change of streets before and after partitioning. "giving priority to people walking and cycling" is not measured directly, but the package aims to create areas where walking and cycling are prioritized by reducing car traffic.
To summarize, the step aided by the package is only the first step in the planning process. Implementation details need to be decided for each case by urban planners.

Comment: 2. Related to the previous question, is the package's delineation of Superblocks always accurate? By "accurate," I mean does the delineation always comply with the definition? What would be the limitations, if any, of this package?

Response: We introduced formal requirements which are checked by the package to always be satisfied. Most importantly, there will be a number of Superblocks and a so-called sparse network that connects all Superblocks. It must be possible to reach any Superblock from any other Superblock without passing through a Superblock that is not in the starting or destination Superblock. Details can be found in the Partition Requirements section of the documentation and general information on the Transport Network Graph Representation. If one implements a new partitioner which does not satisfy the requirements, the package will raise warnings, pointing out the specific issues. Furthermore, there are helper functions to convert a rough blueprint of Superblocks into one satisfying the requirements.

Comment: 3. It is not clear to me whether the usage of this package is to detect existing Superblocks, or identify an area that is suitable for future Superblock planning. Or both?
- The first use case seems to be for planning. It would be clearer if you could state your criteria for selecting a potential area and explain why you chose those criteria.
- The second use case seems to be for existing Superblocks as you talk about the impacts. (Also the overall write-up sounds more like it is for existing Superblocks.) Could you be more specific about what the "valuable insights" are (line 51)?

Response: The package is designed to identify areas suitable for future Superblock planning. The package does not detect existing Superblocks, as this seems not possible from the OSM data alone.

We have revised the introduction to clarify the purpose of the package. Most prominently, the introductory sentence now reads:
"superblockify is a Python package designed to assist in planning future Superblock implementations by partitioning an urban street network into Superblock-like neighborhoods and providing tools for visualizing and analyzing these partition results."

Regarding the criteria for selecting potential areas (Superblocks), it's important to note that this package implements a framework for general approaches of partitioning. There is not one best solution. The two approaches we've implemented are explained in the 'Data access and partitioning' section. These serve as examples of how the framework can be used, but users can implement their own algorithms.

As for the "valuable insights" mentioned, these refer to various metrics that can help evaluate the potential impacts of implementing Superblocks. For example, one key insight is the increase in travel time when implementing the blueprint. These and other metrics are detailed in the 'Features' section of the paper, providing quantitative data to assess different Superblock configurations. Now it reads:
"[...] providing valuable insights into the potential impacts of Superblocks at a broader scale, e.g. travel time changes."

Comment: 4. Line 70-74. Under what circumstances should users choose each partitioner?

Response: When OSM data quality allows the use of the residential tag, we recommend using the residential approach, as this results in having Superblocks in already urban areas and is more likely to be in line with the existing urban structure. For areas where the residential tag is not well-defined, or when a more disruptive perspective is desired, the betweenness approach is suggested.

We added a phrase to the paper to clarify this:
"The choice between these two approaches depends on the data quality and the desired outcome.
The residential approach is appropriate for using residential data, if available and accurate.
The betweenness approach is an alternative based on traffic flow approximation."

Comment: 5. Figure 1.

  • Do the different colors mean anything? If no, it's better to make it clear in the legend.
  • What does "representative nodes" in the description mean? Representative of what? I don't get what the colored nodes are.

Response: Thank you for your observations. Regarding the colors: As already noted in the caption, the different colors are used to distinguish individual Superblocks. Each Superblock is assigned a unique color for visual differentiation. Concerning the "representative nodes": These are indeed central nodes, one per Superblock, plotted for visual aid. The caption already explains that these colored nodes are "for easier visual recognition" of each Superblock.
We have updated the caption to further clarify this:
"Automated generation of Superblocks. Athens (top row) and Baltimore (bottom row) Superblocks generated using the residential partitioner (left column) and the betweenness partitioner (right column). Each Superblock is plotted in a different color, the rest of the streets are black. For easier visual recognition, each Superblock is also highlighted by a representative node of the same color. Map data from OpenStreetMap."

Comment: 6. The analysis feature could be better explained. Urban planners who are not familiar with the graph theory probably won't understand "global efficiency," "directness," etc. A short description of what each of the metrics means would be helpful.

Response: Thank you for this valuable feedback. We agree that some of the graph theory terms may not be immediately clear to all urban planners. We added brief explanations of these metrics in the 'Analysis' section of the paper, relating them specifically to Superblock planning.
Here is how we expanded the section:
"For analysis, the package calculates various graph metrics of the street network, including:

  • Global efficiency [@latora2001]: In the context of Superblocks, this measures how the overall ease of vehicular movement across the city might change after implementation.
  • Directness [@szell2022]: This indicates how Superblock implementation might affect the directness of routes, potentially increasing or decreasing detours.
  • Betweenness centrality [@brandes2008]: Identifies which streets might bear increased traffic load after Superblock implementation.
  • Spatial clustering and anisotropy of high betweenness centrality nodes [@kirkley2018]: Describes how clustered and non-uniformly distributed the expected traffic bottlenecks are.
  • Street orientation-order [@boeing2019]: Quantifies how grid-like each Superblock is.
  • Average circuity [@boeing2019a]: Measures the length increase of routes on the street network compared to straight-line distances.

These metrics are calculated for the entire street network and for each Superblock
individually, providing insights into how the Superblock implementation might affect the
overall city structure and local neighborhood characteristics.
To facilitate further analysis, all of these metrics are included in the exportable
GeoPackage file."

We believe these brief explanations will make the analysis features more accessible to urban planners without a strong background in graph theory, while keeping the citations for those interested in further details.

We hope that these changes address your concerns and improve the clarity of the paper and are looking forward to hearing back from you. The changes can be found in the commits: ab5c166, 65e8b37 and 5287061.

@caimeng2
Copy link
Author

caimeng2 commented Aug 8, 2024

Wonderful. Thank you for your detailed response.

@caimeng2 caimeng2 closed this as completed Aug 8, 2024
@cbueth cbueth linked a pull request Aug 12, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants