stefanfluck / palmpy Goto Github PK

Currently, each new dialect requires 1) a dialect.py file in the dicts folder and 2) a couple of lines in the make_static routine. automate that with exec('command as string'). Therefore, any kind of string can be supplied in the namelist, and just the file can be supplied in the dicts folder.

alternative: make path of dicts folder/file also an input in the namelist. if none provided -> use current path as it is now.

I installed the palmpy but while executing the make_static.py it shows an error as shown below.

START CREATING DOMAIN 0
Origin before cutting: 682917.4999999999/247513.50000000105. Resolution: 0.5000000000002621 m.
Origin after cutting: 682924.9999999999/247288.00000000093. Resolution: 4.0 m.
Raster Size: X: 192 Y: 192
Shifted the input array downwards by 404.31 meters.
Traceback (most recent call last):

File "/home/thirurrp/Downloads/palmpy-master/examples/tutorial_example/make_static.py", line 604, in
for m in range(len(zlad)):

NameError: name 'zlad' is not defined

if buildings are taller than zmax of domain, too large z-dimension is created leading to abort im palm simulation. limit z variable of building creation process (3d) to max z.

do not filter by lad z=0, instead do a reduce along the z axis and if != 9999, then set vegtype to 3. right now, if lad starts above z=0, the soil is not changed to veg_type to 3. this is not alright.

where ladarr and buildings_2/3d == True, set lad to fillvalue

use the following information.

caution: not all are named the same! e.g. latitude of origin is not there in 21781.

check effect on whole process - so far it has been rather crs independent (provided rectangular data has been used as input)

in the namelist, create a field containing the names for the probes to be implemented. then, when the final parameters.txt file is created, serve the names with the corresponding coordinates.

I have a bulk veggetation parameter, but also in the dict, unclassified stuff is set to grass. resolve it

if sql possible in gdal_rasterize, do it with that.
if not possible, work in 2 steps with street_types: first create array with important streets: highways, links, hauptstrassen, etc. create seconda array with not so important roads. Then numpy.minimum().reduce(arr1,arr2) them to the lower value (assuming lower values are better).

check how bridges are represented in the 2.5d zurich buildings file. how is the lower limit defined?
how have i done it in the zrh example, was it supplied with a shp or raster?
should buildings only be made available as shp? probably no: but only allow raster input for upper limit, lower limit could come from shp with attribute.

take it out of mapbb function, create own function. put it to end of crops/streets modifications.
must be nonzero where vegetation or pavement is present.

llx/lly all need to be provided regarding root domain. revice checks. also change SUCCESS string to beginning of line, easier to read then.

currently, AV data needs to be split by category as pavementareas and bb shapefiles. This can be simplified. idea: Download Amtliche Vermessungsdaten as shapefile in Format DM.01-AV-CH (or -ZH etc), and provide list which categories belong to which. Include variable that says which datastandard AV data are in (e.g dm01avch or dm01avzh, containing list bbcats = 5,10,etc and pavcats = 19,40,39 etc).

have input source as an option (tlm, osm, corine, usgs) and appropriate mpd. should be taken then.

distinguish for streets, for bodenbedeckung,(+ for pavement).

regarding grid definition.

having belagsart as a separate feature in the paved surfaces shapefile is not really practicable. in all other files it's OBJEKTART, and in the zurich standard it is included in the ART attribute anyway.

currently all forests, tree lines and single trees have the same leaf area index. having it as shapefile attribute could create a more realistic tree repressentation.

in geodatatools.py, function rasterandcuttlm() creates tmp.tif in the make_static.py location, which is bad.
create the tmp.tif file in the tmp folder of the case.

vegetation should be able to be imported from a raster.
city of zurich defines lower height of tree crowns to be 3m (Fachplanung Stadtbäume), implement like that.
for LAI... have general value for now, find something for the future.

update code cells (introduced by #%%) to contain intelligible descriptions and provide logical hierarchy with using #%% and #%%%, where three % is of one lower hierarchy than two %s.

right now it is assumed that the vegetation albedo is changed. adding a flag, it could modify any pars array. either with a flag this can be done, or multiple implementations with pavpars or watpars instead of vegpars int he function call. the latter may be cleaner.

when a shp is rastered and then resampled, info is maybe lost (e.g. roads that are narrow).
check what is done now (nn?) and check if bilin is better.

right now, cropfields shp sets vegetation to 2. this can be exploited -> rename to individuallanduse.
then, assign objektart 1001, 1003, ... for individually set vegetation types, 1101... for crop types. 2001, 2002... for individual water types and 3001 for individual pavement types.

then in script, make individlanduse array. make a np.where, filter for values between 1000 and 1999, change vegarr based on it. filter between 2000-2999 and change watarr based on it. filter between 3000-3999 and change pavarr based on it (after dopavedbb, because pave is added ontop).

when implementing it into the script, check for following np.where(x == -9999.) statements, as that was the hardcoded fillvalue in the rasteradndcuttlm() function.

could be the better ways since updating the markdown/output to html is tedious.

make the llx/lly sections ready for copying already as output of palmpy.

give a hint to the user, otherwise false impression of it working.

it gets out of hand with the first section in the script

right now, the path to the module is to be provided.

modules are imported from the paths when running in python sys.path. the palmpy folder can be copied to one of those locations, then its importable with palmpy.staticcreation.geodatatools as gdt etc and the if-check is not needed and the adding of the modulepath to the sys.path.

cleaner would be to have the user
-create the palm environment
-copy the palmpy folder to one of the locations in sys.path (probably .../env/palm/lib/.)
and then import palmpy in a normal way.

now, some treelines are defined as vegetation_type and reslved trees.
solve with np.where -> lad != 0, vegarr[:,:]=3, or somehting.

If two buildings, that are spatially separated, have the same ID, their height will be defined by one of the polygons terrain height plus the building height. the same terrain height will also be used for the other building, which could lead to a very high building (or it just does not appear, depending on the relative terrain altitude).

having to specify a tmp path is not really necessary. make it optional: if empty, use same path + \tmp\ as default. then one can give another path if one needs a tailored solution

child lower left corner needs to coincide with a grid node of the parent domain. this is annoying to compute sometimes. have palmpy do that for the user.

currently, 3d vegetation is split in forest, tree lines and single trees/bushes.
however, they are all polygons, for which LAI and shape parameters could be contained as an attribute in the file itself. This simplifies the required files significantly.

make detection of building_type (gebtyp) values present in the shapefile and make the np.isin() check according to these values. now as a workaround np.arange(0,21,1) is set to allow for 20 building_types.

when trying to use street types funcitonality of palmpy, the tutorial dictionary file cannot readily be used as two lines are commented out (majroads and minroads at line 96 and 97). Due to lack of time, this is not a top priority but will be fixed eventually, there is no impact on regular usage of the tutorial.

maybe lad needs to be same density for wide and smaller trees