Update sync with repeated measures compatibility

[krfritz]

Hi, has there been any updates with this? We are still unable to sync with BrAPI to Breedbase when collecting repeated measures. Thanks!

[trife]

@lukasmueller @chaneylc @zrm22 What's the status of repeated measures compatibility with syncing and/or breedbase?

[zrm22]

@trife Right now its coded so if you are syncing down observations to field book it hard-codes rep to 1. I should be able to easily fix this, but I am not sure how the observations will look in the BrAPI response. We are having some trouble with our local breed base instances so I am having a hard time having a test bed to verify that things like this will work(I can pull obs out but we don't have any repeated measurements in). Hopefully on our end we get this fixed soon. That being said if I know what field in the BrAPI response I can use to do this I should be able to code it up and have it testable by users.

I am hoping to submit a PR for the issue we discussed last week in the next day or so to make the functionality work again. Repeated measurements will probably need to come after that

[trife]

Since all repeated measures are ascending by timestamp, you should be able to sort plot+trait combos by timestamp to assign rep. I could be thinking about this wrong, though.

We can see if @BrapiCoordinatorSelby has thoughts.

[BrapiCoordinatorSelby]

@trife is correct in concept. here are the specific BrAPI fields. Minimum Observation information you need from BrAPI is:

        {
            "observationDbId": "ef24b615",
            "observationTimeStamp": "2018-01-01T14:47:23-0600",
            "observationUnitDbId": "598111d4",
            "observationVariableDbId": "c403d107",
            "value": "2.3"
            ...
        }

Any repeated combination of observationUnitDbId and observationVariableDbId is a repeated measure. Sort by observationTimeStamp if you want them organized/displayed oldest to newest.

Other random thoughts

• If you see two observation entities that have matching unitDbId, variableDbId AND timestamp, that's probably bad data... but if each entity has distinct observationDbId we have to assume its valid. I would consider using observationDbId as a secondary sort parameter just in case.
• The timestamp in this example only displays seconds, but reading/storing milliseconds is totally fine and recommended. Use decimal format after the seconds ie ...47:23.567-0600