NERDSITU / superblockify

Source code for superblockify
https://superblockify.city
GNU Affero General Public License v3.0
21 stars 3 forks source link

comments on paper #90

Closed caimeng2 closed 1 month ago

caimeng2 commented 1 month ago

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: https://github.com/openjournals/joss-reviews/issues/6798

cbueth commented 1 month ago

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 commented 1 month ago

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 (https://github.com/NERDSITU/superblockify/issues/91, https://github.com/NERDSITU/superblockify/issues/92, https://github.com/NERDSITU/superblockify/issues/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: ab5c1665cdf204fdaf169a3f92ef83abb9a32c63, 65e8b378a168e1b0193640ef09524ad31b85b83b and 5287061894677bba1ecac7ebc8e63069f5355e8d) 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?

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.

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:

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: ab5c1665cdf204fdaf169a3f92ef83abb9a32c63, 65e8b378a168e1b0193640ef09524ad31b85b83b and 5287061894677bba1ecac7ebc8e63069f5355e8d.

caimeng2 commented 1 month ago

Wonderful. Thank you for your detailed response.