-
Notifications
You must be signed in to change notification settings - Fork 3
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
Comments
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. |
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: 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. 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: 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: 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: 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. 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.
These metrics are calculated for the entire street network and for each Superblock 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. |
Wonderful. Thank you for your detailed response. |
The paper is well-written and presents its ideas with good organization. I have the following questions and comments for improvement.
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"?
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?
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?
Line 70-74. Under what circumstances should users choose each partitioner?
Figure 1.
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
The text was updated successfully, but these errors were encountered: