Longlat different in paradata vs data

I have noticed that the long lat displayed on our questionnaire and data export differs from the paradata



I trust the paradata because it shows the accuracy as 56.09999… and that is the reason the question is red(we validate against accuracy )

In the paradata it shows the captured location as LOCATION||-33.1402318,19.4323941[56.099998474121094]||
But on the interview the captured location is recorded exactly the same as the preloaded longlat field

Dear @daniedk ,
We seem to be seeing two different answers to the same question based on timestamps. Could you please share the scenario how them were collected.

Dear @vfedoseev ,
We have a preloaded variable Longlat on the coverpage that is prepopulated with the geo location where the interviewer is supposed to go:

And then again in the Dwelling unit information section where the interviewer needs to capture the location once he gets to the dwelling unit(this is used in the data to verify that the interviewer visited the correct sample DU)

Dear @daniedk ,
We are still a bit confused about the chain of evets and the point of issue, sorry for that.
Could you please provide us with the scenario and describe the issue. Lemme share an example.
A questionnaire with 2 GPS questions: “Longlat” on Cover page and “LOCATION”.

  1. Created assignment in browser.
  2. “Longlat” was answered via clicking on “Record GPS” button on " Create new assignment" page in Chrome browser by hq user.
  3. “LOCATION” was answered via clicking on “Record GPS” in the interview in Chrome browser by an interviewer. The answer was given in the same building and in the same wifi network.
  4. Export data and paradata files were generated after the described steps.

Latitude and Longitude coordinates are the same in the both answers and files (“LOCATION” “Longlat” questions).
“Longlat” Latitude -33.14023, Longitude 19.4323882 timestamp 2024-02-29T17:50:57 in Export Tab file.
“Longlat” Latitude -33.1402318, Longitude 19.432394 timestamp 2024-02-29T17:51:34.152 in Paradata file.

Assuming no transformation, distortion, rounding etc was done to the data when porting from Survey Solutions to other software used by @daniedk we see that:

From the paradata:

  • Block A has events of AnswerSet to a bynch of different questions (Q14, Q15) with all the same timestamps (up to milliseconds). As far as I understand this can only be done through preloading. So block A is the preloading group (we have to guess, because @daniedk has truncated the data selecting only bits and pieces).
  • 15 minutes later the tablet went to sleep (event B).
  • The interviewer has awakened the tablet a week later (event C).
  • Events D have new and unique timestamps, meaning they are the result of the interviewer’s actions:

From the description:

Well, apparently not. The variable is on the cover page, but if it is there and preloaded, the interviewer has no powers to revise that preloaded answer. Paradata provides evidence of the contrary. All preloading is recorded here before the first Resumed event.

This means that this interview stems from an assignment where the location on the cover page (LongLat as I understand) was left not preloaded. This is consistent with the rest of the description, then the interviewer can do the first measurement and then subsequently override it with another measurement (something that @vfedoseev has already mentioned above).

This is easily verified, by looking into the preloading file and checking what data was put into the LongLat variable.

Similarly, inspecting the rest of the paradata events for the same interview should reveal the events of revising the LOCATION variable (look around the time indicated in the exported data: 2024-02-23T11:25:28), which should be different from the one captured in event 59 of paradata (2024-02-23T11:00:28.109).

Somewhere later we expect to encounter the value -33.140233, 19.4323882.

Showing ALL paradata events for this interview would have eliminated a considerable amount of guesswork and make the response quicker.

Hope this helps, Sergiy Radyakin