Skip to content
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

ID mismatch between depressions / regions in depressions_info #26

Open
geotom opened this issue May 19, 2022 · 4 comments
Open

ID mismatch between depressions / regions in depressions_info #26

geotom opened this issue May 19, 2022 · 4 comments

Comments

@geotom
Copy link

geotom commented May 19, 2022

  • lidar version: 0.6.1
  • Python version: 3.8
  • Operating System: Ubuntu

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
Copy link
Member

giswqs commented May 19, 2022

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

@geotom
Copy link
Author

geotom commented May 20, 2022

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
Copy link
Member

giswqs commented May 22, 2022

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
Copy link
Author

geotom commented May 23, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants