the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 29 Sep 2026
Mapping urban fabric for enhanced urban climate modelling based on a historical building classification
Abstract. The urban climate conditions are heavily influenced by the morphological and thermal properties of buildings. Recent studies have been focussed on the representation of urban morphology using standardised Local Climate Zones (LCZs) whereas relatively little research has been performed on the impact of thermal properties of buildings. Though useful for categorising and modelling urban climates, generic LCZ classes can have a low representativeness for local spatial heterogeneity while also not accounting for variations in building thermal properties.
Using Amsterdam (the Netherlands) as a case study, we develop an alternative classification of urban fabric based on construction period, historical construction practices and regulations. This HERITAGE classification consists of 10 distinct classes which we combine with 3D building model data, the Dutch cadastre and previous studies using GIS to derive their accompanying morphological traits. This approach offers a new method to create literature- and data-based urban classes with customised spatially varying morphological and thermal parameter values which are more representative of the real world compared to the LCZ approach. The HERITAGE-classes contain all necessary variables for conducting thermal and energy assessments as well as numerical modelling of the urban climate using for example the Weather Research and Forecasting (WRF) model.
- Preprint
(1977 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 24 Nov 2026)
-
CEC1: 'Comment on egusphere-2026-5628 - No compliance with the policy of the journal and peer review stop', Juan Antonio Añel, 26 Oct 2026
reply
-
AC1: 'Reply on CEC1', Bianca Eline Sandvik, 10 Nov 2026
reply
Dear Juan A. Añel,
I hereby officially address your recent comments.
First of all I would like to bring to your attention that your topic editor changed the manuscript type from “Model description paper” to "Development and Technical Paper”. The paper also outlines the generation of a conceptual framework and exemplifies its implementation in WRF. This framework is not limited to one single model. Some minor changes to section 2.3 has been added to highlight this.
The implementation of this work has been tried and tested for WRF version 4.6.1 and works without any code alterations. The few technical implementations are outlined in Appendix D and are alterations at the preprocessing level (WPS). These implementations are not limited to this version of WRF, but needed to implement an alternative raster in the model.
Upon later testing of the model we realised that some additional code adjustments were needed in WRF for a fair comparison between HERITAGE-classes. The WRF source code was minimally adjusted but a full copy of the modified version has been added to the original repository. Since these adjustment may or may not be relevant to other models these adjustments are described in the new Appendix E. The “Code and data availability” section has been adjusted accordingly.
Regarding the data repository link:
Upon initial contact with your editorial support I explicitly asked about the possibility to provide the data initially under a private link for the review process before enabling public access once the paper was published. Based on their response I was under the impression this was allowed.
As the chosen data repository (4TU.ResearchData) is operated by an external party with version control, implementing any changes to the repository takes some time. Due to a security issue their data portal was down between 21. October until 4. November. In this timeframe no access was available and this also affected the repository links.
When the paper was submitted the links were working as intended (aka. the public link with embargo still in place and the private link working). The data provided in the repository was originally: the HERITAGE-raster.tif and the matching binary files, the modified URBPARM_LCZ.TBL and a README.md file outlining the content. After gaining access again it now additionally contains our modified WRFv4.6.1 code and GEOGRID.TBL. Unfortunately the old private link points to the previous repository version. I will provide a new private link for the reviewers through your support staff so the reviewers can access also the modified WRF code and GEOGRID.TBL.
Please find the new version attached.
Hope this addresses your comments adequately.
Best regards,
Bianca E. Sandvik
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 11 Nov 2026
reply
Dear authors,
Thanks for your reply. Unfortunately, it does not address the outstanding issues pointed out in my previous comment, and your manuscript remains non-compliant with the policy of the journal. I have checked the repository you shared again (please note that the hyperlink in the manuscript is broken, and you should fix it in any reviewed version). The repository is not accessible and is under embargo. We can not accept this.I must insist that you reply to this comment with an open repository that contains all the code and data used for your work, and produced in it. Sharing only modified parts of code is not acceptable, as the goal is to ensure the long-term accessibility to all the assets related to your submitted work and its scientific reproducibility. Private links shared only with editors and formally assigned reviewers are only acceptable in cases where you clearly justify that there exists a legal restriction that forbids you from sharing assets (code or data), which I do not think is the case for your work.Also, I would like to apologize for any perceived contradictory information regarding the editorial process. The Topical Editor should have sent the manuscript back to you before accepting it for peer review or into Discussions to solve the pending issues that I mentioned in my comment. However, oversights happen, and this is why we continuously check all the manuscripts under consideration in the journal to spot potential errors and ensure that all the works under consideration comply with the policies of the journal and undergo adequate peer review.Therefore, you must reply to this comment with a new title for your manuscript and the open repositories containing all the assets as soon as possible. We can not accept replies with expressions of future compliance in the revised version, but the mentioned issues must be addressed now during Discussions. Otherwise, the peer review process would not comply with the requirements of the journal, which mandate that all the material is available to anyone wanting to comment on your submitted work.I must insist that if you do not address these outstanding issues, we can not accept your manuscript for peer review, Discussions or publication in the journal.Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-5628-CEC2 -
EC1: 'Reply on AC1', Chenghao Wang, 11 Nov 2026
reply
Dear Bianca and co-authors,
Thank you for explaining the repository issues. As the handling topic editor, I acknowledge that I changed the manuscript type from “Model description paper” to “Development and Technical Paper” to better reflect the contribution of this paper, and I should have checked compliance with the journal’s code and data policy before the manuscript proceeded to public discussion. I apologize for the conflicting expectations this created.
Please provide the repository link and DOI for the precise revised versions of the WRF and WPS code bases used in the study, including the modifications described in the manuscript, relevant configuration files, processing scripts, and associated data. I have not yet seen the private repository link you mentioned. But once I have access, I will check the code and data provided. If you prefer to keep the repository confidential before acceptance, please arrange access through editorial support so that reviewer anonymity can be maintained.
In addition, please revise the title to comply with the journal’s requirements. Note that both Model Description and Development and Technical papers must include the model name and version number in the title. Since the manuscript describes its implementation in WRF version 4.6.1, please include the applicable model name and version in the revised title.
Once the repository information, access arrangements, title, and manuscript section have been updated, I can continue handling the manuscript in coordination with the executive editor.
Best regards,
Chenghao Wang
Citation: https://doi.org/10.5194/egusphere-2026-5628-EC1 -
CEC3: 'Reply on EC1', Juan Antonio Añel, 11 Nov 2026
reply
Dear all,
Just to clarify, because the wording used by my colleague Dr. Wang could lead to misunderstandings (at least translated in my Spanish mind, and maybe in English) . Keeping a repository private until acceptance is not acceptable and it is against the policy of the journal unless you provide clear documentation and evidence that you are forbidden to share it. Otherwise, all the data and code must be shared publicly here, and it should be public before submitting the manuscript to the journal. Therefore the "prefer" exposed by Dr. Wang refers only to the exception in which you are forbidden to share the assets, not to your personal preference, which we can not accept.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-5628-CEC3
-
CEC3: 'Reply on EC1', Juan Antonio Añel, 11 Nov 2026
reply
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 11 Nov 2026
reply
-
AC1: 'Reply on CEC1', Bianca Eline Sandvik, 10 Nov 2026
reply
-
RC1: 'Comment on egusphere-2026-5628', Anonymous Referee #1, 07 Nov 2026
reply
General comments
This paper combines literature-based information on building year and construction practice to derive a thermal-property-based classification of buildings in Amsterdam, and compares it with the default Local Climate Zone classification. I am not an expert in urban climate modelling, and I review this paper from the perspective of an atmospheric modeller.
- My main concern is data scarcity when applying this approach to other regions worldwide. Even for Amsterdam, the authors relied on an extensive literature review for building years and construction practices, and the building height distributions and roof widths were still derived only from the inner city. The historical lack of studies on building thermal properties in urban climate modelling seems to reflect a lack of data more than a lack of methods. The novel methodological contribution of this paper is therefore not clear to me.
- The results show limited variability in surface albedo and emissivity, but larger variability in thermal conductivity and urban fraction. Could the authors discuss the consequences of this for urban climate modelling? This is particularly important because the research question (L122-123) concerns the impact on local meteorology and climate, yet no model simulations are presented. They are deferred to a follow-up paper (L564-565). Similarly, the claim that the HERITAGE classes are “more representative of the real world” (L21, L550) is not yet supported. I suggest either adding at least a simple sensitivity test, or rephrasing the research question and claims to match the scope of this paper.
- L138-141 and L482-486: The claim that the thermal properties (Table 2) can be transferred to other Dutch cities, while the morphological parameters cannot, is asserted rather than demonstrated. The thermal values are single literature-based values per class, so they show no between-city variability by construction. Some inputs also appear to be Amsterdam-specific (e.g. the window coverage fraction from Dang et al., 2024). Could the authors indicate which inputs are national and which are Amsterdam-specific, and provide supporting evidence or an uncertainty range for applying these values elsewhere?
Minor comments
- L421-433 and L561-562 contradict each other. L561-562 states that the HCs have higher thermal conductivity and heat capacity than the LCZs, whereas L421-433 states that they are lower. Please check.
Citation: https://doi.org/10.5194/egusphere-2026-5628-RC1
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 291 | 138 | 50 | 479 | 40 | 53 |
- HTML: 291
- PDF: 138
- XML: 50
- Total: 479
- BibTeX: 40
- EndNote: 53
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Dear authors,
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".
https://www.geoscientific-model-development.net/policies/code_and_data_policy.html
In your "Code and Data Availability" statement you do not provide a repository for the code used to produce your work. This includes scripts and the full WRF code and configuration used in your study. Moreover, you do not provide an open repository for all the data used in your work, which is mandatory when submitting a manuscript to the journal. The only link to a repository that you provide does not work (the web address does not seem to resolve).
I am sorry to have to be so outspoken, but this is something unacceptable, forbidden by our policy, and your manuscript should have never been accepted for Discussions given such lack of compliance with the code and data policy, so the current situation is irregular. The policy clearly states that all the code and data necessary to replicate a manuscript must be published openly and freely to anyone before submission.
Therefore, we are granting you a short time to solve this situation. You have to reply to this comment in a prompt manner with the information for the repositories containing all the models, code and data that you use to produce and replicate your manuscript (a new Code and Data Availability section that complies with the policy). The reply must include the link and permanent identifier (e.g. DOI). Also, any future version of your manuscript must include the modified section with the new information.
Additionally, you have submitted a "Development and Technical Paper", and the policies of the journal state that this kind of manuscript must include the model name and model version number in the title when it refers to a single model. This needs to be fixed too. Therefore, please, reply to this comment with the new title containing the model version number.
Note that if you do not fix these problems as requested, we can not continue with the peer review process for your manuscript or consider it for publication in Geoscientific Model Development.
Juan A. Añel
Geosci. Model Dev. Executive Editor