search

FPS-URB-RCC / CORDEX-CORE-WG

This repository is dedicated to the CORDEX-CORE data analysis WG
0 stars 0 forks source link

Misaligned urban fraction data for RegCM #8

Open jesusff opened 1 year ago

jesusff commented 1 year ago

There is a problem with the alignment of urban and land fraction. The hypothesis used to remove equal number of gridcells from the borders of the domains (see #7) seems wrong in this case. See last plot in this notebook. It is likely that there is a problem with the projection, since the same files look aligned over Tokyo.

jesusff commented 1 year ago

Projections are definitely different in the urban fraction on nextcloud and the orog and land fraction files on ESGF. On ESGF (orog_EAS-22_NCC-NorESM1-M_historical_r1i1p1_ICTP-RegCM4-4_v0_fx.nc), it is Lambert conformal:

int crs ;
        crs:longitude_of_central_meridian = 115. ;
        crs:semi_major_axis = 6371229. ;
        crs:inverse_flattening = 0. ;
        crs:grid_mapping_name = "lambert_conformal_conic" ;
        crs:standard_parallel = 20., 50. ;
        crs:latitude_of_projection_origin = 35. ;
        crs:false_easting = -12500. ;
        crs:false_northing = -12500. ;

Nextcloud files (data/RegCM/urbanfraction/orig/EAS-22.nc) are in rotated Mercator:

        :projection = "ROTMER" ;
        :grid_size_in_meters = 25000. ;
        :latitude_of_projection_origin = 35. ;
        :longitude_of_projection_origin = 116. ;
        :grid_north_pole_latitude = 35. ;
        :grid_north_pole_longitude = 116. ;

These must come from different simulations. Likely, the evaluation runs (not on ESGF) are not on the same computational grid as scenario runs. Features are now well located, but clearly on different grids: image

jesusff commented 11 months ago

A fixed UF file for EAS-22 has been provided by @graziano-giuliani, thanks! The same problem arises for NAM-22 simulations, which were carried out by ISU but the UF provided from ICTP does not match the geographical projection. ISU simulations are on

    char oblique_mercator ;
        oblique_mercator:grid_mapping_name = "oblique_mercator" ;
        oblique_mercator:azimuth_of_central_line = 90. ;
        oblique_mercator:latitude_of_projection_origin = 46.5 ;
        oblique_mercator:longitude_of_projection_origin = 263. ;
        oblique_mercator:scale_factor_at_projection_origin = 1. ;
        oblique_mercator:false_easting = 0. ;
        oblique_mercator:false_northing = 0. ;

while our current UF file has:

// global attributes:
        :experiment = "NACOR" ;
        :projection = "ROTMER" ;
        :grid_size_in_meters = 25000. ;
        :latitude_of_projection_origin = 47.28 ;
        :longitude_of_projection_origin = 263. ;
        :grid_north_pole_latitude = 47.28 ;
        :grid_north_pole_longitude = 263. ;
        :grid_factor = 0. ;
jesusff commented 1 month ago

This is currently being "fixed" by overwritting the geographical information from other variable (orog) in https://github.com/FPS-URB-RCC/CORDEX-CORE-WG/blob/13f1c3f5592359cec2a69ac68ea9dbb8ee7a0932/uhi/urban_areas.py#L155

However, a half-cell shift still exists and needs to be fixed in the original data.