other_landings_n and other_landings_kg

[elfunesto]

The view landings in the db includes both other_landings in weight (typ_id 32) and number (typ_id 33). This is fine since in the Rmarkdown automatic_tables_graphs.Rmd, we show diagram in number (typ_id 33). The issue is that in shiny_dv, in Table -> Landings, we summed all types of landings (commercial, recreational and other landings) from this landing view, so we sum number and kg as far as I understand. To find the best fix, I see several questions

• why do you collect other_landings in both numbers and kg while commercial and recreational landings are only in kg?
• in the db landings view, should we have both other_landings_n and other_landings_kg? Related questions: in the Rmarkdown, why do we plot other_landings_n and not other_landings_kg, while we plot com_landings_kg and rec_landings_kg?
• if there are good reasons for doing this, I would suggest that the function filter_data remove eel_typ_id 33 in the shiny_dv to prevent summing kg and n

[cedricbriandgithub]

because release are in both number and weight and we wanted the correspondance ? Or maybe because for small eels it makes more sense to report in number. For the markdown I think it is because it's related to restocking. We plot everything if I remember well but only select some plots; Yes for the shiny_dv we should remove one or the other.

[elfunesto]

yes, that makes sens. The only issue then in that shiny_dv Table -> Landings display values in tons, so we should exclude other_landings_n from the sum, isn't it?

[elfunesto]

Just by curiosity, I run: select eel_year,eel_value,eel_emu_nameshort,eel_lfs_code,eel_hty_code from datawg.t_eelstock_eel tss1 where eel_qal_id in (1,3,4) and eel_typ_id=33 and not exists (select * from datawg.t_eelstock_eel tss2 where tss2.eel_typ_id=32 and tss2.eel_qal_id in (1,3,4) and tss1.eel_lfs_code=tss2.eel_lfs_code and tss1.eel_hty_code=tss2.eel_hty_code and tss1.eel_emu_nameshort=tss2.eel_emu_nameshort) which proves that as soon as other_landings_n have been reported, a value for other_landings_kg have also been reported. But the other way around is not true select eel_year,eel_value,eel_emu_nameshort,eel_lfs_code,eel_hty_code from datawg.t_eelstock_eel tss1 where eel_qal_id in (1,3,4) and eel_typ_id=32 and not exists (select * from datawg.t_eelstock_eel tss2 where tss2.eel_typ_id=33 and tss2.eel_qal_id in (1,3,4) and tss1.eel_lfs_code=tss2.eel_lfs_code and tss1.eel_hty_code=tss2.eel_hty_code and tss1.eel_emu_nameshort=tss2.eel_emu_nameshort)

As such, it seems that other_landings_kg is more complete than other_landings_n. So in shiny_dv, I will fix by filtering for other_landings_kg and we have to be aware that the figure of other_landings_n in the report are slightly underestimated

[elfunesto]

this lead to quite substantial change for some countries: e.g. IE in 2022

• with eel_typ_id 4, 6 and 32

• as it was before

[cedricbriandgithub]

Just by curiosity, I run: select eel_year,eel_value,eel_emu_nameshort,eel_lfs_code,eel_hty_code from datawg.t_eelstock_eel tss1 where eel_qal_id in (1,3,4) and eel_typ_id=33 and not exists (select * from datawg.t_eelstock_eel tss2 where tss2.eel_typ_id=32 and tss2.eel_qal_id in (1,3,4) and tss1.eel_lfs_code=tss2.eel_lfs_code and tss1.eel_hty_code=tss2.eel_hty_code and tss1.eel_emu_nameshort=tss2.eel_emu_nameshort) which proves that as soon as other_landings_n have been reported, a value for other_landings_kg have also been reported. But the other way around is not true select eel_year,eel_value,eel_emu_nameshort,eel_lfs_code,eel_hty_code from datawg.t_eelstock_eel tss1 where eel_qal_id in (1,3,4) and eel_typ_id=32 and not exists (select * from datawg.t_eelstock_eel tss2 where tss2.eel_typ_id=33 and tss2.eel_qal_id in (1,3,4) and tss1.eel_lfs_code=tss2.eel_lfs_code and tss1.eel_hty_code=tss2.eel_hty_code and tss1.eel_emu_nameshort=tss2.eel_emu_nameshort)

As such, it seems that other_landings_kg is more complete than other_landings_n. So in shiny_dv, I will fix by filtering for other_landings_kg and we have to be aware that the figure of other_landings_n in the report are slightly underestimated

Yes that can be the case, unlike releases where we force to use both kg and n here it is free (one line in the table for each)

[cedricbriandgithub]

Currently no longer showing