Paper Archive - Retrieve Images tab

[isedwards]

The Retrieve Images tab allows the user to choose a particular station, form and data and View Image for their selection if it exists.

There is also the option to Delete the image.

[stteem]

Assuming Form ID is unique, being able to select random year, month, and day seems to negate that uniqueness, and assumes there is another entry with that ID at another date, else It would always return nothing if Form ID is indeed unique. If that is the case, would you consider taking the year, month, and day fields out?

[isedwards]

In Climsoft, the fields shown are actually a composite key made up of Station, FormID and the date... (the corresponding fields in the database's paperarchive table are called belongsTo (station), classifiedInto (form id) and formDatetime).

So you can have multiple versions of the same FormID depending on which station and date you are entering...

Paper Archives and Paper Archive Definitions are available in the demo api - but the tables in the test database are currently empty: https://api.opencdms.org/climsoft/docs#/Paper%20Archives

---

It looks like the FormIDs are not values from the database's data_forms table (e.g. 61001) but are instead created by the user for their purposes (e.g. MLY, HLYPR, TCM, ...) and stored in the paperachivedefintiontable (which contains formId and description).

[stteem]

From the video, it seems data for all fields but year field(which might accept user input, kindly verify) is gotten from the GET Paper Archives API, you could see the explainer clicking through page 2 of 5, same number of data seen on the Archival List tab.

Also, the dropdown "Select options" input type by default only has prepopulated data, data from an API in this case.

[stteem]

I'd like to understand why there are Year, Month, Day, and Hour fields when the formDatetime property of the API response has a single dateTime string.

I can extract each field from the formDatetime property of the response if need be.

And if that is the case, i assume you want a user to be able to input a year, month, or day, other than what came from the API, and still get results.

If that is not the intended user behavior, we could have just a single date field.

[isedwards]

Climsoft usually has separate fields for year, month and day because users can select partial dates (e.g. the month "December 2021" without a day or hour).

In this case the user could be uploading an image containing all the daily summary data for a particular month - so the day and hour fields would be empty.

Often there are separate year, month and day and hour fields in the database - but in this case they have chosen to implement a single formDateTime. This makes it difficult - because it means we will have to always store a day and hour - and these will be displayed to the user even though they are meaningless...

For our first version I suggest we don't worry about whether day and hour are showing useful (correct) information - but let's try to duplicate the same experience as they have in the old software with the separate fields for Y M D and H.

[stteem]

To effect an update, I guess a user should have the ability to update accompanying image. I might pop up a modal for that. In the context of climsoft, Is that necessary or not?