opengeos / lidar

A Python package for delineating nested surface depressions from digital elevation data.
https://lidar.gishub.org
MIT License
244 stars 52 forks source link

ID mismatch between depressions / regions in depressions_info #26

Open geotom opened 2 years ago

geotom commented 2 years ago

Description

The following image shows the mismatch in the depressions_info.csv after executing

sink_path = ExtractSinks(
    dem_raster,
    2,
    out_dir
)
DelineateDepressions(
    sink_path,
    2,
    0,
    0.2,
    out_dir,
    True
)

mismatch

The depressions_info.csv references the region_id 143 for depression 163 while a look at the map show that actually region 173 spatially matches the depression 163. I tested in another region and here everything was correct and the region/depression IDs matched as they should. I expect this to be a bug. Any other suggestions?

PS: I attached the SRTM image to test srtm_dem.zip

giswqs commented 2 years ago

Can you also check the raster files to see if the IDs match? Sometimes the raster-to-vector conversion can cause the issue

geotom commented 2 years ago

I have added the corresponding region and depression_id raster and they have identical IDs. Also none of the other raster files here have the value 143.

So far I have never seen any pixel to shape conversion issues. The same with the depression which all got the ID 1 (See #23)

image

giswqs commented 2 years ago

The algorithm is well suited for high-resolution LiDAR data. You used a coarse-resolution srtm without projection. I don't think the algorithm will generate meaningful results for this.

image image

geotom commented 2 years ago

Thanks for the feedback. I unterstand that by using SRTM data, I cannot expect too meaningful results, especially in flat lands like the example above (Netherlands). That is clear, and SRTM is only our fallback data. But I would still assume that the ID referencing should work correctly. Or would you say the correct ID reference between output pixels and the CSV is resolution dependant? For me this looks more like a bug, when the CSV is created.

PS: The data is in EPSG:4326 projection. To what degree does the projection play any role in your algorithm?