GEDI L2A/B and CopGLO30

[dakini]

Hello,

I am trying to compare RH98 from GEDI L2A with the 30m Copernicus DEM. I'm adding up RH98 (in m) and elev_lowestmode for an absolute height, converting the dataset to a raster (with the CopDEM as a "snap raster"), and subtracting the DEM. I am getting mean/median differences of about 50 m consistently over multiple orbits, with the range varying between -20 and 120 m. This seems somewhat far off. Am I missing something here?

I am looking at a 3 x 3 km forested area in Italy (Central Pixel: 46.4021, 11.5748).

Cheers

[LP DAACx - dgolon]

Hello @dakini Thanks for writing in. We will have one of our data experts take a look at what you are seeing and we'll write back when we have more information. Thanks -- Danielle

[dakini]

Hello @LP DAAC - dgolon, thank you for the answer. Is there any way of knowing how long a response from a data expert might take?
Cheers

[kristianbodolai]

Hi @dakini , I believe this could be because GEDI provides height about the WGS84 reference ellipsoid and the ESA DEM provides the height above the EGM2008 geoid.

I think the accepted reply in this link: https://gis.stackexchange.com/questions/442454/is-egm2008-different-to-wgs84-ellipsoid has a figure that shows the difference well.

Another thing to consider (but that wouldn't affect the whole orbit) is how you're filtering out your GEDI shots, using quality flags, etc. Depending on the selected algorithm, sometimes GEDI misses the ground (particularly in very dense forests), and would therefore provide an erroneous height. Although I believe the main issue is what I mentioned before.

I hope it helps!

[dakini]

That was it! Thank you very much, applying the correction helped significantly.
I've come across another thing, if by chance you have an idea here too: I have filtered my dataset to group Orbits into subsets by using the orbit number (first five digits of the shot number). When i convert those orbit sets to .tif files and inspect them in qgis, most seem just fine however in some cases the distance between the beams is very small (250 m) when it should be 600 m. The shot numbers are the same besides the shot index and the acquisition data also matches, indicating that they are in fact part of the same orbit.
Do you have any idea where my mistake may be or what to look into?
Thanks

[LP DAAC - afriesz]

Hi @@dakini,

Would you be able to share the code or process you're using to convert your GEDI data to .tif files?

[dakini]

Hi, thanks for the interest!
I'll try to share my process as detailed as i can:
I am downloading GEDI L2A and L2B data as .h5 from the CMR with a basic function.
These .h5 files are extracted using the extract_data function from this repo: https://github.com/maawoo/gedixr and afterwards merged into one Geodataframe. There was an issue where a leading "0" in the shot number got dropped during conversions, i have since implemented a check that adds a zero in the front if the shotnumber in the GDF is only 17 characters long.
I then extract the first five digits of the shot number which are supposed to represent the orbit and save them in a new column.
The function to convert the GEDI shots to .tif files looks like this:
dem_xarray = rioxarray.open_rasterio(dem_path)
dem_xarray = dem_xarray.squeeze()

# Drop rows with NaN in the measurement column
gdf = gdf.dropna(subset=[measurement])

# Create geocube
xr_ds = make_geocube(
vector_data=gdf,
measurements=[measurement],
like=dem_xarray
)

I am using a DEM (CopGlo30) as a "snap raster" and the measurement is either rh98 or anything needed at that moment since my target is to compare GEDI and DEM heights.

[maawoo]

>There was an issue where a leading "0" in the shot number got dropped during conversions, i have since implemented a check that adds a zero in the front if the shotnumber in the GDF is only 17 characters long.

Could you elaborate on this? Is this a bug you have encountered in the gedixr package? If yes, please create an issue there so it can be addressed. Are you sure that your solution of adding a zero is appropriate and doesn't lead to wrong orbit numbers and finally unexpected results in your per orbit raster files?

[simon727]

dakini wrote:
> That was it! Thank you very much, applying the correction helped
> significantly.
> I've come across another thing, if by chance you have an idea here too: I
> have filtered my dataset to group Orbits into subsets by using the orbit
> number (first five digits of the shot number). When i convert those orbit
> sets to .tif files and inspect them in qgis, most seem just fine however in
> some cases the distance between the beams is very small (250 m) when it
> should be 600 m. The shot numbers are the same besides the shot index and
> the acquisition data also matches, indicating that they are in fact part of
> the same orbit.
> Do you have any idea where my mistake may be or what to look into?
> Thanks
I agree!