The paper by Lin et al. presents the new preprocessor tool GEO4PALM for the microscale Large Eddy Simulation (LES) model PALM. GEO4PALM derives the static surface, building and vegetation input data ("static driver") from freely available online data or user-supplied input data. Compared to the tool "palm_csd" supplied by the PALM model system, it mainly adds support of geo-referenced input data (geotiff) and its reprojection as well as the afore mentioned usage of online resources. Since the preparation of the static driver usually includes considerable effort, every tool that simplifies this process is highly welcome. The paper is well written, however, it lacks some discussion about the implemented online data sources and the comparison of the different PALM results when using the different static drivers is not useful. Thus, I recommend considering this paper for publication only after major revisions.

Major issues

One of the main features of GEO4PALM compared to palm_csd is the support of the automatic download and usage of freely available online data. Here, I miss a thorough discussion of the applicability of this data in the context of building-resolving LES simulations with grid-spacings down to 1m. For example, the authors mention that the used sea surface temperate data has a resolution of 0.01°. Is this resolution sufficient to derive water temperatures for rivers and lakes? Even with finer remote-sensing-based products, the clear identification of smaller water bodies is difficult. Another example is the building information, which can be downloaded from OpenStreetMap (OSM). For both exemplary domains, the building height is missing for most of the buildings and a default height of 3m is used. The authors state that this "represent(s) the simulated environment with reasonable details" (L277). I do not agree; for a building-resolving model, the building height is a crucial part of the input data.

In order the study the effect of the static drivers generated with different tools, the authors present PALM simulations using the respective static driver. Here, however, the description of the simulations is not sufficient enough. Which PALM model version was used (not only list it at the very end of the paper), what atmospheric forcing was applied, what were the most import model run parameters? Furthermore, the authors show only the results of the last time step of a 6 hour simulation. This approach is not useful because of the turbulent nature of the LES model. Even with very tiny modifications, the results of single time steps are expected to differ considerably. Thus, calculate appropriate temporal averages and compare these.

Minor issues and comments

palmpy[1] is another static driver tool that is freely available. In particular, it supports input of geo-referenced data as well. Include this in the paper.

L191: Add a reference for WRF4PALM.

L240: palm_csd modifies the terrain height of the child domains to follow the average values of the corresponding subdomain of its parent domain. Afterwards, it adjusted to the PALM levels.

L245: By default, palm_csd removes vegetation types with high vegetation independent of further input data (and normally replaces it with resolved vegetation). This is done to avoid numerical issues when using a high roughness length with small vertical grid spacing. Please add that.

L254: The missing building in Berlin is called Berlin Palace [2]. It was recently reconstructed and, thus, not included in the DLR data.

L271: In which way does palm_csd not support water bodies? Both the definition of the water body type and the water surface temperate is supported.

L349: Remove "6.0". PALM uses years as the version number now as also used in L351.

[1] https://github.com/stefanfluck/palmpy

[2] https://en.wikipedia.org/wiki/Berlin_Palace

## General comments

The authors present a tool for processing geospatial data to be used as input data for the PALM model system. The presented tool GEO4PALM aims to simplify the process of creating a so-called static driver for PALM, an input file which describes the geospacial setting of the simulation domain like land cover, buildings and vegetation. Compared to the PALM-internal tool palm_csd, GEO4PALM offers easy access to online sources for geospatial data. Also, the support of input data formats for GEO4PALM is enhanced compared to palm_csd.

However, the quality of the available online data used in GEO4PALM does not meet the requirements of a highly detailed simulation, which is usually the aim if someone utilizes PALM. The authors state that the online data are of coarse resolution. When focusing on urban simulations, the focus of many of the recent PALM applications, building-height information are rarely available. Missing this main information about the urban setup, no meaningful results can be expected from the PALM simulation. The free online data, however, could be a handy addition to coarse simulations of the surrounding areas of a focused region. The authors should bring out this aspect more clearly.

In the manuscript, the authors compare different approaches and data sources to create a static driver file for PALM. They compare their tool against PALM's own tool, palm_csd. palm_csd has different checks and modifications of input data included which are based on experience over many simulations (e.g., terrain-height modification for nested setups; adjustment of vegetation types below resolved plant canopies). These include, e.g., the replacement of forest in the land cover data with resolved plant volumes using the leaf-area density. This highly improves simulation results. Such checks are not (yet) implemented in GEO4PALM. This can lead to simulations suffering from already well-known mistakes in the input datasets and might delay research projects. GEO4PALM should therefore be extended by further checks of the input data. The authors are partly aware of this but should state this more clearly in the outlook.

The differences in the static drivers due to the missing adjustments in GEO4PALM compared to palm_csd are mentioned in the manuscript. However, a detailed analysis of the differences in the simulation results due to these differences is missing. 

Highlight more the benefits like online data sources, translation of land-cover classes, GUI.

## Specific comments

L5: PALM itself comes with palm_csd which is a tool to automatically convert spacial data to PALM input files. PALM also comes with a template to write one's own tool. Besides this, there is another tool called palmpy (available on github: https://github.com/stefanfluck/palmpy). Fraunhofer developed another tool named PALM-4U GUI that transforms geospacial data to PALM input files.

L41: palm_csd can be used for any set of data as long as the user provides the data in netCDF format. This is also stated by Heldens et al. (2020).

L46: The common static-driver preparation tool is palm_csd. This tool is part of PALM and available to every PALM user. The statement made that there is no common tool available is hence incorrect.

L46: Section 2 does not describe the PALM input data standard. It just references it and briefly explains what is covered by GEO4PALM.

L85: Wouldn't "configure file" or "config file" be a better name than "namelist" for the input file? The main executable is even called "run_config_static.py". A "namelist file" refers more to a file containing one or more Fortran namelists.

L92: "The geospacial input data are interpolated or extrapolated..." Are they really extrapolated? Don't you mean averaged? Same in line 93, Figure 2 and other places in the text.

L96: Does GEO4PALM automatically convert shapefiles to geotiffs or is this step down to the user? This is not made clear. If shapefiles are not automatically converted, then why not?

L116ff: The resolution of the SST dataset (0.01°) is quite coarse compared to the aimed resolution of PALM simulations (mostly in order of a few meters). What happens to grid points where there is no SST available? Are there any assumptions made in GEO4PALM? What happens to small rivers or even ponds and fountains?

L134: A reference to Table B2 is missing.

L143: A reference to Table B3 is missing.

L146: The reference comes to late.

L155: What happens to OSM data that contain land cover classified as vegetation types? Are those ignored? Why are those ignored?

L162: You already assume that the filter height for vegetation height might not be appropriate for all cases. Then why don't you introduce a configuration parameter that can easily be adjusted in the configuration/namelist file? Such a filter height would depend on the case. But changing the source code will introduce the change to all cases/jobs.

Eq.1: Use upright font for multi-letter variables (LAD). Variable *h* is not explained in the text.

L167: Should be LAD_m instead of L_m. z_m is the height where LAD = LAD_m. According to Lalic and Mihailovic (2004), n=0.5 for z ≥ zm.

L168: The original source of z_m being between 0.2h and 0.4h is Kolic (1978) "Forest Ecoclimatology", University of Belgrade, 295pp. as stated by Lalic and Mihailovic (2004). Please adjust the reference.

L170: Does the variable 'tree_lai_max' describe the value of LAD_m? Then, the naming is incorrect or misleading as it describes the maximum leaf-area density not the maximum index. See also Table 2.

L183: PALM's input and output files contain geospatial information. They are even part of the PALM input/output data standars PIDS and PODS.

L200: palm_csd only includes information about the coordinate reference system for a selection of projections. But the data processing of palm_csd does not depend on any projection. palm_csd handles any data independent of their projection. Therefore, it is totally capable of handling the input data of the Christchurch case.

L232: palm_csd can consider a high amount of information for vegetation processing. However, not everything is required. Assumptions can also be made if input data is not available. GEO4PALM, however, only supports the simplified method as stated in the text. Modifying the source code to meet the user's needs is of course also true for palm_csd. Please modify this part to better compare both tools.

L238: palm_csd does modifications of the terrain height based on recommendations for the internal nesting module. It removes differences of the terrain height between child and parent domain and allows for a smoother transition of the flow at the child's domain border. This modification, however, is optional and can be turned off in the configuration file. The modification of the terrain height in palm_csd is recommended because PALM itself does not do this. So, the statement in line 240 is incorrect. For a better comparison of the static driver from GEO4PALM and palm_csd, the terrain-height correction of palm_csd should have been turned off.

L248: If a forest area is represented in the static driver by the vegetation type and also by the leaf-area density, it will be over-represented in the PALM simulation. The drag of the forest is parameterized in the roughness length used for the vegetation type but also the resolved plant canopy introduces drag. Hence, the flow reduction is overestimated. This is why palm_csd alters the vegetation type below resolved plant canopies. These differences are not further investigated in detail when comparing the simulation results.

L254: should be "present" instead of "presented".

L254: The Humbold Forum was not yet constructed when the data were gathered by the DLR.

L256: I recommend to write θ_2m ("2m" in subscript) similar to T_sfc. The same goes for WS_10m (wind speed at 10 m height).

L271: palm_csd has an option to set the water surface temperature based on the water type. So, the statement made is incorrect. Besides this, the user is free to adjust palm_csd to also read water surface temperatures from an input raster file and output this to the static driver.

L281: palm_csd is not dependent on map projection. The tool does not use any map projection but treats input raster files as simple raster arrays. Therefore, the actual projection is irrelevant for palm_csd. The only thing that is assumed is a rectangle map projection where coordinates are measured in meter. Hence, the input files for Christchurch could have been handled by palm_csd. For a better comparison of GEO4PALM and the existing palm_csd tool, the Christchurch case should also be covered with palm_csd. 

L311f: What is the meaning of the last two sentences of this paragraph? What mismatch? Of course, if you use different data sources, data might not agree to each other, especially if the data sources refer to different points in time (e.g., newly constructed buildings in OSM, land-cover data still shows forest area). And in what way do the results agree with those shown by Heldens et al. (2020)?

L321: As noted above, palm_csd is widely applicable and also shipped with PALM. So, it is available to the entire PALM community. Besides this, there is another tool called palmpy (https://github.com/stefanfluck/palmpy) that is also capable to handle even vector data like ESRI shapefiles.

L330: Building-height information are often available from the local authorities. For research purposes, these datasets might also be free or at a discount compared to commercial uses.

L338ff: Apart from the coarse classification of settlement areas, the resolution also plays a crucial part. Even if you manage to distinguish settlement areas between highly dense built-up areas, medium dense and sparsely built areas, this is not enough for a PALM simulation with below 10 m resolution. In this case, you need to distinguish between sidewalks, streets, paved backyards, flowerbeds, private pools, etc. This is especially true if you want to analyze your simulation data at the street level or even want to compare your data with measurements. So, the data availability and data quality are a huge bottleneck for high-resolution urban simulations.

L349: Remove "6.0". You are using PALM 22.10.

L356: Why did you not include the input files for the Berlin case? 

L414: Should be "input for street type".

L419: "lad_max_height" describes the height where LAD = LAD_m

Table 1: Caption: The second sentence should read: "For more detailed descriptions of the variables refer to...".

Table 2: "dem" is described as topographical height. However, I guess you mean a digital terrain model, or DTM. A DEM, or digital elevation model, includes the terrain height but also buildings and vegetation. However, PALM specifically requires the terrain height to then place buildings and vegetation on top of that. Please also double-check the text.

Figure 2:

- Yes/no lines of first decision box do not start at the left/right corners.

- From the flowchart it seems that GEO4PALM either downloads all input files or only reads local tif files.

- Why does the box "start to process downloaded and/or user provided geospatial files" have round edges?

Figure 6: Are the shown output data instantaneous data or are they averaged over time? Non-averaged data are most likely to be different between the simulations. Due to the many small differences in the static drivers, the turbulence might most certainly develop differently in the simulations. So, differences in the instantaneous data are most certainly to occur. Time-averaged output, especially for the wind speed, should be a better measure to identify differences in simulation results than instantaneous data.

Figure 7: The terrain height for the Chch_OL case seems to include vegetation height. So, it might actually be a digital elevation model including the height of the trees. This is obvious when you compare the height information at the park location.

Figure 9: See comment on Figure 6.

Comment on the usage of the program (appendix A):

Why do you have to alter the source code (utils directory) when using a different lookup table for the landuse? It would be better if you could add a lookup table to the input directory and the tool uses this then. This way you do not have to change (or check) the utils directory every time you switch to another case study.

## Technical corrections

- The text, including the Figure and Table captions, often misses the articles "the" and "a", e.g. in Table 1, description of "building_type": Required for buildings in *the* urban surface model.

- Use hyphens for compound words like "land-surface characteristics" (l. 43).

- L63: "Here we describe and document and GEO4PALM toolkit". The second "and" should be "the".

- L104: The text goes past the end of the line.

- L117: "...which can have *an* impact on..."

- L165: "...is based on *an* equation..."

- Table 2: The writing "metres" is used, however, throughout most of the manuscript "meters" is used.

- L214: "...with *the* finest grid spacing at 3 m, while GEO4PALM can generate *a* static driver with grid *spacings* finer than..."

- L257: Use an upright font for multi-letter variables like "WS" (as you already did with LAD). Also, use an upright font for the subscript of T_sfc R_net etc.

- L260: Space missing: "2m"

- L324: text passes the end of line.

- L428: Should be "python" (lower case).