inasafe/inasafe-realtime

BUG: EQ report- fatalities

Closed this issue · 9 comments

Hi @lucernae
In the recent Java EQ (I think you probably felt them) - EQ realtime reported 100 - 1000 fatalities for both the events
image

However, when I run in the desktop I get different range results:
for the 7.3 event the range is 100 - 1000
but for the 6.9 event the range is 0 - 100.

Could you please check the rounding and reporting of ranges in realtime to see that it is the same as in Desktop?

cc

@gubuntu @timlinux @ivanbusthomi @ismailsunni

hi @lucernae
Grateful if you can review this as a high priority as I we are getting questions about why the InaSAFE estimate was so large.

@RikkiWeber

Sorry, can I have more context. When you said 'in the Desktop' does that mean InaSAFE v 3.5 Desktop version?

No - I take the hazard data from realtime and run in desktop InaSAFE v 4.3 and get different results.
I think the IF for eq on population has not changed since 3.5 (Pidie)

I've checked the code and the number of fatalities were returned directly from impact function (the number is 180), the rounding is as the rule goes: 100 - 1000.
I think this issue is related with another that I have raised previously: #30.
The current number 180 doesn't have the same meaning with the old ITBFatalityFunction which only produce an expected value. The current one uses ITBBayesianFatalityFunction which returned a range of probability. So, I suspect the inconsistencies were coming from the algorithm itself. Maybe I need help from @ismailsunni or @Gustry whoever handled migrating this algorithm to InaSAFE version 4, so we can spot the exact problem in InaSAFE v3.5.

Btw, I understand that running in InaSAFE v3.5 vs InaSAFE v4.3 will yield different result. But, I just want to make sure that the algorithm in InaSAFE v3.5 itself is correct.

Hi @lucernae - thank you for checking. Can you please confirm the event number that you are looking at for this comment I've checked the code and the number of fatalities were returned directly from impact function (the number is 180), the rounding is as the rule goes: 100 - 1000.

Hi @lucernae - thank you for checking. Can you please confirm the event number that you are looking at for this comment I've checked the code and the number of fatalities were returned directly from impact function (the number is 180), the rounding is as the rule goes: 100 - 1000.

The event id is: 20171216000321

Hi @Charlotte-Morgan @timlinux @lucernae @Gustry

After investigating it, I am affraid I don't get any solution for the problem. It's more or less like what @lucernae said above:

  1. The rounding is correct, 180 will get 100 - 1000. I am re-run the analysis in QGIS using the same InaSAFE version in the realtime, I got fatalities = 177.
  2. The result between 4.3 and 3.5/realtime is different. I think it's not a surprise since we use different approach to calculate the fatality. It's also stated in this comment by @wonder-sk inasafe/inasafe#3559 (comment) (CMIIW, in 3.5 we took the median after sum the fatality, but in 4.3 we use the median of the CSV file, to make it have the same interface (one value per one mmi).
  3. For the 20171216000321 event (the 6.9 one), the raw value of fatality is 69 in InaSAFE 4.3 desktop. Again, the range is expected 0 - 100.

But, I just want to make sure that the algorithm in InaSAFE v3.5 itself is correct.

I have re-check the fatality part, it looks like nothing is wrong in the algorithm.

@ismailsunni - thankyou for checking this and for the clear explanation.
I think this is related to another ticket #30 and will be resolved when we migrate to version 4.x for all platforms.
For now the plan is to update the disclaimer and about page and roll on with the migration plan, preferably with no large earthquakes before we can implement

cc @RikkiWeber @hadighasemi @gubuntu

Closed. Solution is to update Disclaimer. Algorithm were not migrated.