-
Notifications
You must be signed in to change notification settings - Fork 0
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
Height correction for (Temperature) local effects #32
Comments
yes, the temperature values Robert provided for the heat wave events are based on the EURO-CORDEX data (~12 x 12km), which use an average height for each 12 x12 km grid cell (H_avg). I have copied the respective orography file (average height for the input cells) to the ftp server (/clarityftp/europe/EURO-CORDEX_orography/SMHI/orog_EUR-11_SMHI_r0i0p0_v1_fx.nc). |
I am dealing with this:
I am assuming there is only need of having mean altitude of a cell as long as it is a cell of an available city in the system, am I right with this? |
I believe so. As the local effect can only be calculated where city data is available, the effect of cell-height is thus only relevant for these cases. |
Thank you @RobAndGo Mean altitude data logic is already set. I am currently updating cities currently in the system in order to generate cell mean altitudes for those grid cells belonging to any of those cities which are: Napoli Data is in layer 'land_use_grid' under column 'altitude'. |
Question to @RobAndGo and @negroscuro How can I access the height of the Euro-Cordex Grid cell (12kmx12km)? |
There is an issue when loading mean altitude so data is not stable, I am deleting and generating it while finding out what is the problem with it, I am getting erroros:
It looks like DEM raster and cells are not matching for some reason. |
Hi @humerh. Which heights did you use for the 'characteristic events'? I seem to remember that @claudiahahn may have already uploaded some height information from EURO-CORDEX, possibly for that task which you mentioned. |
I have copied the respective file (average height for each 12 x12 km grid cell) to the ftp server (/clarityftp/europe/EURO-CORDEX_orography/SMHI/orog_EUR-11_SMHI_r0i0p0_v1_fx.nc). |
You are right, the migration is still not done. If you need us to add it to our geoserver we can do that but it will need to be taken into account by ATOS (@negroscuro ) when the migration is done. |
@ghilbrae : |
This is more complicated @negroscuro and @DanielRodera Requests for new publications can be frequent and this leads to changes in several Geoserver directories (not only the one that stores the file, but also the style directory etc). Your current version is no longer updated as I indicated previously when I processed new ZAMG hazard index. We need to discuss a proper way to do the MTG-ATOS geoserver migration before continuing to duplicate efforts. I think it can be discussed during the next developers meeting. |
@DanielRodera If you need help with the setup of GeoServer as Docker container, you can have a look at our docker-geoserver repo. Accessing the data volume from dockerized GeoServer is not as obvious as it should be. Some thoughts on that in this issue: clarity-h2020/docker-geonode#4 |
I said Geoserver folder because as far as I understood from Laura everything published in Geoserver is within Geoserver folder, that means styles, raster data sources, etc... Until we have anything stable keep working on Meteogrid and add there anything you need. |
@p-a-s-c-a-l |
Yes, but the latest version is changing several times. Well, I propose the following: However, please consider that this process is not feasible for every new layer. |
Forget about updating ATOS FTP for now, it is better for everybody if we ask you once our bug is fixed, this way you will do it just once. |
Thank you @negroscuro , that's good. Tomorrow I'll inform you of Tomcat's version. and |
@negroscuro
GEOSERVER
|
Finally I fixed the error and mean height per 500m cell is generated for current cities in the system. I have to let you know that this could be a slow process, it cant take minutes or hours, the slowest of the 18 cities was Stockholm which took 11 hours to generate mean altitude per cell (I am using 25 meters DEM data in order to generate the mean). Not joking... anyway I am exploring an alternative way to do this using GDAL instead of postgres. |
I need the "12x12km average height (H_avg) from the EURO-CORDEX", which is used also for defining the "characteristic events". These heights are the starting points for the height-corrections, because all of the current calculations of temperatures and impact are based on this (event) height. Additionally I (will) access the "clarity:altitude" from the layer "land use grid" for getting the height/altitude of each grid cell. With this both heights I will make the temperature correction. I do not understand, what 's the problem? |
@humerh There is no problem, my fault, I misunderstood a previous message here, so I just want to confirm you use both altitude data sources. Thank you for clarification. |
@humerh and @stefanon It would be ok for you to find null values? |
@negroscuro well, if no data are available or can be generated, the only choice I think is to have null values, and then no data in -> no data out... can you show an example? |
The thing is avoid any problem in later uses of the data I am generating, but from my side is more confortabe and easy if I set to null all those four columns and then set the value when calculated, the thing is that the value could be 0 so that will be confusing if default value for those columns would also be 0... that is why I want to use null but I do not know if it is a problem for any of you. |
What is the reason for having NULL values?
Which replacement value can I use, which strategy should I apply?
As a conclusion: My algorithms will be very depended on the background, why the values are missing. |
@humerh look at this. As you may notice in the picture the are situations where some of the cells (for stockholm 1022 out of 32509 cells) have no altitude value because there is no DEM intersection to calculate it. In the above example you are looking at DEM and Urban Atlas trees. So there is land usage but not DEM in the cell so I cannot calculate altitude but the cell is there and exists so I have to set an altitude value for it. My proposal? to use null since other cells could have an altitude 0 assigned since it is a correct value for it and we can have confusion with this kind of situations. Or look at this other grup or cells which have water land usage values but no DEM. |
Can you show a satellite picture for such areas? What is real situation for such an area?? |
Mmmmh I do not find satelllite imagery WMS services to connect to, do you know any? |
This area should be covered by Google / Bing satellite at least. What DEM source are you using? |
I need a WMS URL to use from QGIS. |
you can use XYZ Tiles for Google & c. or install Quick Map Services plugin |
@negroscuro From EU-DEM 1.1 metadata can be read that the dataset is at 25m resolution with vertical accuracy: +/- 7 meters RMSE : so it's not improbable that in very mixed ground / water zones due to the vertical accuracy of the DEM areas that are classified for their landuse are instead shown as water bodies in the DEM. |
How is the resampling done? An average for reducing the dem resolution shouldn't make a big difference on the result that needs to be calculated on a 500x500m grid
I agree you set the values to NULL where you've no data for the info you list, starting from DTM height, as a 0 value means something different. |
Bilinear.
Nice, lets see if @humerh agrees this. |
From my side height calculation is done and correct, let me know if you have any issue. |
Thanks! 👍 |
Now there is an style for cell mean altitudes in layer land use grid: |
For the full discussion, please see: #28
Conclusion: height correction should be implemented for the temperature local effect indices. According to @RobAndGo, the correction should be 1°C per 100m up to 1000m height and 0.65°C above it:
The way to implement this in EMIKAT is by calculating the difference between the average heights of the 500x500 output cells and the average height between 12x12km^2 CORDIS input cells. Thus, we need the following:
@mattia-leone , @claudiahahn , please confirm that this is correct.
@humerh : please estimate the work needed to implement this once the heights layers are available.
The text was updated successfully, but these errors were encountered: