Rationalise transect recording between app and website

[JimBacon]

The recording of cloud cover by app and website are inconsistent and at risk of introducing errors in to the database, apart from creating work for administrators and confusion for recorders.

This issue follows on from https://github.com/BiologicalRecordsCentre/ABLE/issues/493#issuecomment-1609958724

At present the website records

• %Sun at the walk level - optional.
• %Sun and %Cloud at the section level - mandatory. Whichever value is entered, the other is calculated.

Meanwhile, the app records

• %Cloud at the walk level - optional. Recently it started calculating and submitting %Sun as well.
• %Cloud at the section level - optional. Recently it started calculating and submitting %Sun as well.

There is also a lesser issue with recording the Reliability for sections. This is optional on the app and mandatory on the website.

Both recording forms work independently but result in different data being stored which has to be resolved for analysis.

The most acute problems arise when you want to edit a record from the app on the website. You cannot see what walk-level %Cloud you recorded on older records, before %Sun was added, and you have to fabricate section-level values for cloud cover and reliability if they were omitted.

To overcome all of the issues I think we need to complete the following tasks:

• [x] Confirm how we want to record cloud cover and reliability
• [ ] Modify recording forms according to the preceeding decisions
• [ ] Store cloud cover in a just one of the existing attributes (which the forms could present as %Sun and/or %Cloud, as required)
• [ ] Update existing records to use a single cloud cover attribute
• [ ] Modify downloads to accommodate changes

Assigning to @DavidRoy to address the first task and to set priority.

[DavidRoy]

@CrisSevilleja can you liaise with eBMS partners using the online system (website or app) for transects.
The proposal is:

• no longer capture %sun or %cloud at the section level but to have single (mandatory) value at the walk (sample) level only
• capture %cloud only (with instructions that %sun = 100 - % cloud), i.e. not longer store both cloud and sun values

[JimBacon]

Thanks @DavidRoy. Do you also have a view on what we do with Reliability to ensure app and website are consistent?

[DavidRoy]

Reliability should be mandatory on website and app and default to value = reliable (or whatever the term is)

[szabadfalvi]

"Reliability" was always a mystery to me. If the weather parameters are out of specs (too early/late, too cold, raining, fully cloudy etc.), then, by default, it should be assumed unreliable. Is the purpose of selectable "reliability" value to override this default?

[DavidRoy]

Luxembourg BMS require the reliability information @xaviermestdagh

[szabadfalvi]

Thanks @DavidRoy

[CrisSevilleja]

Sorry for the silence. After discussing with some coordinators, I agree with the proposal of David: remove cloud/sun% from the section level, leave it to the average value for the walking survey and capture only cloud%

Regarding Reliability, it can be understood for suitable or unsuitable conditions. But this field can be important @szabadfalvi if the weather conditions are optimal for doing the transect and you are not able to enter one of the sections, there are animals, constructions or whatever reason. Then the reliability is unable to survey at the section level and I think is good to capture it.

[JimBacon]

The app and website need to modify recording forms for transect recording as described above.

In summary, for the app:

• [x] Remove % Cloud from the section level
• [x] Make Reliability mandatory and default to 'Suitable conditions'
• [x] Keep % Cloud at the top level but no longer send % Sun as well

[kazlauskis]

@JimBacon I've done these now.

Keep % Cloud at the top level but no longer send % Sun as well

So, just to clarify, does this requirement only apply to the transect survey? And should we still upload both values for the 15-minute surveys?

[JimBacon]

I was only considering the transect survey because that is where I could see website and app were inconsistent.

With regard to the 15-minute surveys, both app and website only have %cloud fields on the forms and the %sun attribute is not configured for those surveys. If you are uploading %sun for 15-minute surveys then you could stop as I presume it was an unintended consequence of https://github.com/BiologicalRecordsCentre/ABLE/issues/493#issuecomment-1538583858.

Apart from the Transect survey, %sun is also enabled on surveys

• EBMS Fixed points
• EBMS Other timed counts
• EBMS ad-hoc imports

I haven't seen these in use so I am ignoring them

[kazlauskis]

@CrisSevilleja do you want to keep both cloud and sun values for the 15min counts?

[JimBacon]

It was @DavidRoy whose comment a couple of months ago prompted you to start sending %sun in addition to %cloud for 15-minute counts. He should be able to confirm whether it was intentional and needed but it seems unlikely to me given that it was only the transect survey which was broken.

[CrisSevilleja]

Replying to the 15min count survey, it only needs the %clouds as it is like now. The %sun is not needed to be sent, anyway is the inverse of %clouds so it can be calculated easily. Thanks

[kazlauskis]

@DavidRoy are you also OK for me to remove the sun and upload only the cloud values for the 15min counts? I vaguely remember we are using both values because some countries are recording the sun instead, no?

[DavidRoy]

@kazlauskis yes, I've been convinced by Jim's view that we should simplify this area!

[kazlauskis]

@JimBacon I've removed the sun values from the 15min counts too. From app v1.22.0 there will be no more sun, and only clouds will be coming your way...

[Gary-van-Breda]

Drupal site Walk Data Entry form changed to show only Cloud on main page, and neither cloud nor sun on species grid.

[CrisSevilleja]

I think this issue is almost solved @JimBacon I am only thinking if the downloads were adapted to this.