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

Impossible to use fwdet #24

Open
jeremyEudaric opened this issue May 30, 2024 · 39 comments
Open

Impossible to use fwdet #24

jeremyEudaric opened this issue May 30, 2024 · 39 comments

Comments

@jeremyEudaric
Copy link

Dear Team after many tried for more than 1month l still can not use fwdet.

We observed a potential mismatch between my polygon and my DEM. Even with the same projection, maps from two different sources (remote sensing and DEM) are never perfectly aligned. So to fix this l used the same project for the DEM and the polygon l assured that the spatial alignment issue and the resolution between the flood map and DEM are the same. l used QGIS to and l used " aligned raster" this should align my both raster layers and then l could convert my polygon raster in order to get the water depth.

Screenshot from 2024-05-30 18-29-23

l tried all your advises (Thank you for this) and the advises of Sagy Cohen but its still not working. l am a bit desperate because l am doing it for more than one month now and its still not working l can no reproduce the results with my own data.

Do you think its possible to have more explanations about the process you followed to create the flood map and align it with the DEM ?

Thanks a lot best

Best,

Jeremy

@cefect
Copy link
Collaborator

cefect commented May 30, 2024

Hi Jeremy, sorry to hear you are still struggling. Estimating realistic event flood depths can be challenging --- or even impossible --- with poor data. Even the most robust analysis can not solve this problem, and FwDET is far from the most robust method. All floods are not equal, so it is unsurprising that repeating a calculation for a different event from different data has a different outcome. Like I mentioned before, if you've played with the parameters a bit and are still unsatisfied I suggest pursuing higher quality data... both DEM (e.g., LiDAR derived) and water mask. For example, here is the first link when I google 'LiDAR dem Greece' that has some discussion on such DEMs. I would also try and improve your water mask, for example by manually correcting it against some imagery (e.g., Planet's data). @roescob faced some similar challenges for a Canadian flood and might have some more advice.

Good luck,

@roescob
Copy link

roescob commented May 30, 2024

Hi Jeremy,

Can you share your input data and parameters you are using?

I suspect you are using fwdet v2.1 qgis plugin. Is that correct?

Best,
Roberto

@jeremyEudaric
Copy link
Author

Hi thanks for your reply DEM lidar data is not available for Greece. l am using fwdet v2.1
Please find attached my data one DEM and 2 polygons:

https://drive.google.com/drive/folders/13gtmPWW-31DYnOJrahrdA9qKae_fyOvd?usp=sharing

thank you for your help l tried everything to make it work but no success regarding the paper a DEM of 30 m and 60 m should be enough.

Best,

Eudaric Jeremy

@jeremyEudaric
Copy link
Author

Hi Jeremy, sorry to hear you are still struggling. Estimating realistic event flood depths can be challenging --- or even impossible --- with poor data. Even the most robust analysis can not solve this problem, and FwDET is far from the most robust method. All floods are not equal, so it is unsurprising that repeating a calculation for a different event from different data has a different outcome. Like I mentioned before, if you've played with the parameters a bit and are still unsatisfied I suggest pursuing higher quality data... both DEM (e.g., LiDAR derived) and water mask. For example, here is the first link when I google 'LiDAR dem Greece' that has some discussion on such DEMs. I would also try and improve your water mask, for example by manually correcting it against some imagery (e.g., Planet's data). @roescob faced some similar challenges for a Canadian flood and might have some more advice.

Good luck,

"Greece does not provide public LiDAR data." :/

@roescob
Copy link

roescob commented May 30, 2024

Hi thanks for your reply DEM lidar data is not available for Greece. l am using fwdet v2.1 Please find attached my data one DEM and 2 polygons:

https://drive.google.com/drive/folders/13gtmPWW-31DYnOJrahrdA9qKae_fyOvd?usp=sharing

thank you for your help l tried everything to make it work but no success regarding the paper a DEM of 30 m and 60 m should be enough.

Best,

Eudaric Jeremy

Any non-default parameters on FwDET?

@jeremyEudaric
Copy link
Author

Hi thanks for your reply DEM lidar data is not available for Greece. l am using fwdet v2.1 Please find attached my data one DEM and 2 polygons:
https://drive.google.com/drive/folders/13gtmPWW-31DYnOJrahrdA9qKae_fyOvd?usp=sharing
thank you for your help l tried everything to make it work but no success regarding the paper a DEM of 30 m and 60 m should be enough.
Best,
Eudaric Jeremy

Any non-default parameters on FwDET?

no l used FwDET without any parameters like that
Screenshot from 2024-05-31 01-15-05
Thanks a lot for your help

@roescob
Copy link

roescob commented May 30, 2024

That is high likely your issue @jeremyEudaric. Try to play with the parameters, they highly influence your final output. Maybe read FwDET v2.1 paper and look for its newest parameter integration. The lazy route would be to trial and error the parameters and see how it goes...

Best,
R

@jeremyEudaric
Copy link
Author

That is high likely your issue @jeremyEudaric. Try to play with the parameters, they highly influence your final output. Maybe read FwDET v2.1 paper and look for its newest parameter integration. The lazy route would be to trial and error the parameters and see how it goes...

Best, R

Thanks a lot . which parameters are you using ?

@roescob
Copy link

roescob commented May 30, 2024

Try a slope filter of 3%. if that does not work let me know, there might be an algorithm issue...

@jeremyEudaric
Copy link
Author

Unfortunately l still have the same issue. l am wondering if this could influence the result "ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF format."

@roescob
Copy link

roescob commented May 30, 2024

@jeremyEudaric can you apply this update to your algorithm and try again with the same parameters?

@jeremyEudaric
Copy link
Author

@jeremyEudaric can you apply this update to your algorithm and try again with the same parameters?

Thanks a lot a tried with a slope filter of 3% and the new code its still not working
Screenshot from 2024-05-31 02-13-43
Screenshot from 2024-05-31 02-14-01

@roescob
Copy link

roescob commented May 31, 2024

Are you sure the flood extent delineation is accurate? Maybe lower your study area using a revised flood extent @jeremyEudaric

@jeremyEudaric
Copy link
Author

jeremyEudaric commented May 31, 2024

l tried with a smaller flood Polygon the water depth value is better but the water depth extension is still not good. l used a slope of 3%
Screenshot from 2024-05-31 02-28-55

Screenshot from 2024-05-31 02-29-15

@jeremyEudaric
Copy link
Author

Good morning did success to run my 2 Polygons with my DEM ? The same errors ? Can l ask you how are you doing your polygon and if you have a code to do it with satellites pre and post disaster ? Can you share your code and method for a better reproducibility ?

Thanks a lot for your amazing help

@jeremyEudaric
Copy link
Author

jeremyEudaric commented May 31, 2024

l think they are an algorithm issue the first picture is the water depth provided by Sagy Cohen
Screenshot from 2024-05-31 09-18-44
Then l tried to do the same with my Algorithm and l have an issue the same as me you can see it
Screenshot from 2024-05-31 09-20-51
And l did the same with your data and l have the same issue
Screenshot from 2024-05-31 09-25-32

the water depth can not get clearly the flood extension- its an Algorithm issue @cefect @roescob @sagycohen @awickert . If we can obverse the issue on your data then its make sens to see the same issue on my data at a bigger scale on my big flood map. Do you think you can fix this issue? Because l have a deadline in 1 week.

May be this is the issue in the Algo "ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF format.
"

Thank you for your help and support on this topic

@roescob
Copy link

roescob commented May 31, 2024

What parameters and FwDET version did you use for your run? I worked on the Fort McMurray case study using the same layers you present on your second picture and did not encounter any issues. Try calibrating your parameters. As for the first case study, it was likely generated with the non-QGIS version of the algorithm so it wont be the same... @jeremyEudaric

@jeremyEudaric
Copy link
Author

jeremyEudaric commented May 31, 2024

Thank you for your reply used fwdet_21.py with a slope of 3% as you told me. To be honest l am trying to fix this issue for more than one month and l have the feeling to turn around...

May l should use FWDET version 1 ? The parameters calibration is not changing the issue unfortunately on my data and on the Fort Murray data. Did you try with my data provided ? l think they are a code issue with fwdet_21.py as you mentioned

Thank you for an amazing help and support. :)

Best,

Jeremy

@roescob
Copy link

roescob commented May 31, 2024

I ran it under a previews version of QGIS. Try downgrading QGIS (v3.22.8 for example) and dependencies such as GRASS

@jeremyEudaric
Copy link
Author

The mean issue is to to run my data .... but l l did it already for your data with a old and a new version and with GRASS your college told me this one month ago... as l said l have the feelling to turn around.... it really hard to reproduce the results because they are a lack of in formations which parameters are using for the examples, how your got your results and how you create the flood polygon without those in-formations reproduce the results are difficult and near impossible. For more than one month l tried everything and l sent my data as well. l did everything... as l said its a algorithm issue , have you tried to run my data and your data with fwdet_21.py ? Can you show me please maybe its a QGIS issue

Thank you for your help

@roescob
Copy link

roescob commented May 31, 2024

Are you sure your flood extent polygon is accurate? I drew my flood polygon manually to increase accuracy. @jeremyEudaric

@jeremyEudaric
Copy link
Author

jeremyEudaric commented May 31, 2024

yes l did as in the paper i used Sentinel 1with pre and post disaster images. l not sure that drawing a polygon is realistic in order to asses the water depth. What do you mean by accurate ? :) However as l said l think the issue is the algorithm because l have the same issue with the data provided.
Do you have this error message ? ERROR 6: /tmp/processing_kVtRnf/5c09db64599a477ea334bdd51ae0760b/output.tif, band 1: SetColorTable() only supported for Byte or UInt16 bands in TIFF format.
2.
Could you please tried with my data provided. l will tries again but for the moment my opinion is that FEWDET is not working and difficult to reproduce the results.

Thanks a lot for your help

@roescob
Copy link

roescob commented May 31, 2024

"SetColorTable() is a function used in geospatial data processing libraries, such as GDAL (Geospatial Data Abstraction Library), to assign a color table (or color palette) to a raster dataset". That is not the issue...

The FwDET v2.1 QGIS plugin worked with QGIS dependencies of 2023-06.

Proof it worked on my end by then:
image

Good luck with your work!

@jeremyEudaric
Copy link
Author

jeremyEudaric commented May 31, 2024

Thanks a lot can you tried to run my data please @roescob @cefect ? To get this result which parameters did you used ?

https://drive.google.com/drive/folders/13gtmPWW-31DYnOJrahrdA9qKae_fyOvd?usp=drive_link

Thanks a lot for your support

@cefect
Copy link
Collaborator

cefect commented Jun 1, 2024

@jeremyEudaric I suspect your problem is not with the parameters but with your input data. Like I said a few times now, there is only so much that is possible with bad data.

You keep referring to some other paper that maybe used similar data sets to what you have. This does not mean the same datasets will work for your project. All floods are not equal. I hope you are able to find some better quality data to proceed with your analysis.

@jeremyEudaric
Copy link
Author

jeremyEudaric commented Jun 1, 2024

Thank you for your time @cefect and considertation l understood this point. However as you can see here we found an issue in the Algorithm #24 (comment). As you can see above here #24 (comment) l tried with the exemple data that you provided on github and l got some issues as well ( with high quality data). So l am guesing its an algorithm issue or software :
#24 (comment)

Capture

Can you tried with my data please ? That will help a lot to be clear on the issue, thanks a lot for this

https://drive.google.com/drive/folders/13gtmPWW-31DYnOJrahrdA9qKae_fyOvd?usp=drive_link

Best,

Jeremy

@jeremyEudaric
Copy link
Author

jeremyEudaric commented Jun 1, 2024

Dear @roescob thank you for your help l updated my QGIS with the version 3.34 ( with GRASS) as you can see l get an error message from the Alorigthm
Capture
l think they are something with the algorithm

@roescob
Copy link

roescob commented Jun 2, 2024

I am getting the same error on the latest versions of QGIS @jeremyEudaric

@cefect
Copy link
Collaborator

cefect commented Jun 3, 2024

Be sure to use the tested version (3.34.5) as described in the readme. If you're still experiencing the same problem, please provide the logs and your build info.

@jeremyEudaric
Copy link
Author

jeremyEudaric commented Jun 3, 2024

Dear @cefect and @roescob thank you for your reply l am using QGIS 3.34.5
Capture

if l am using QGIS 3.22 l am getting an error or the algorithm is not working well as you can see here #24 (comment)

l am getting an new error message with my data and your data the error is from the Algotirthm l guess as you can see here #24 (comment)

You will find the link to the log file qnd my data :

https://drive.google.com/drive/folders/13gtmPWW-31DYnOJrahrdA9qKae_fyOvd?usp=drive_link

As l said l think they are an issue in the Algorithm or update a library

@jeremyEudaric
Copy link
Author

jeremyEudaric commented Jun 3, 2024

I am getting the same error on the latest versions of QGIS @jeremyEudaric

in the Readme its explain QGIS (3.34.5) l used it and l got this even with QGIS 3.22.8 if l am using a old version of QGIS the algorithm is not working well as you can see here #24 (comment). I'm going round in circles .l think they are an issue in the code something to update . l tested both QGIS on linux and Windows

@jeremyEudaric
Copy link
Author

jeremyEudaric commented Jun 3, 2024

I am getting the same error on the latest versions of QGIS @jeremyEudaric

@cefect @sagycohen

@jeremyEudaric
Copy link
Author

jeremyEudaric commented Jun 3, 2024

I ran it under a previews version of QGIS. Try downgrading QGIS (v3.22.8 for example) and dependencies such as GRASS

l did it but still have the error message or its not working well :/

@jeremyEudaric
Copy link
Author

Good morning @sagycohen @cefect @roescob thank you for you help kindness and support on FWDET unfortunately after one month trying to use your software I am close to my project deadline next week. Please let me know if you could fix or update the Algorithm. #24 (comment)

You will find the link to the log file and my data :

https://drive.google.com/drive/folders/13gtmPWW-31DYnOJrahrdA9qKae_fyOvd?usp=drive_link

Thank you very much for you help ans support on this topic :)

Best

@cefect
Copy link
Collaborator

cefect commented Jun 4, 2024

If I understand, the problem is that you are not able to reproduce Sagy's results exactly? This is unsurprising as he is using the original ARCpy implementation. I understand you are using the QGIS port, so some differences should be expected.

@jeremyEudaric
Copy link
Author

jeremyEudaric commented Jun 4, 2024

If I understand, the problem is that you are not able to reproduce Sagy's results exactly? This is unsurprising as he is using the original ARCpy implementation. I understand you are using the QGIS port, so some differences should be expected.

Hi no the problem is that l have an issue with the Algorithm as you can see here #24 (comment) @roescob had the same problem also as you can see the issue is not only Sagy’s results but also @roescob results (with his data and he used QGIS) as you can see here #24 (comment) an my results. Then its makes sens that why my data its not working well... l am using the QGIS version that you mentioned in the Readme…

As I said few weeks ago and in the messages just above... overall l think they are some issues in fwdet v_2 as you can see in the all discussion. Do you think you can fix the Algorithm this week ? Please let me know
Thanks a lot for you help and support :)

@cefect
Copy link
Collaborator

cefect commented Jun 4, 2024

OK. I understand your problem is that the resulting depths are showing regions as dry that were shown as wet in your inundation polygon? This is not a software issue, but a limitation of the algorithm complex flat topography. You could try RICorDE, but I suspect you'll have the same problem. Sorry we can not be more helpful.

@jeremyEudaric
Copy link
Author

yes exactly :) Okey now l understand why the software is not perfectly working for my data and for the data from @roescob and @sagycohen. Any algorithm are perfects :) . Thank you for you time and kindness on this topic l hope all my questions will be useful for someone else ;)

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

3 participants