I have recently created a couple of Survey123 surveys for biological recording. Both have the same basic format, where generic information about the site being surveyed are entered first, then a repeat loop is used to record sample locations within the site and various other data entered at each sample location.
The first app used a geopoint at the site level and then another within the loop and this worked as expected. For the second survey I omitted the first geopoint (because I reasoned that I could find the site location from the samples recorded). This also worked pretty well and produced a feature layer with two layers, one for the site and one for the samples.
Within the site layer the locations are still georeferenced, despite there being no site-level geopoint employed. On the survey’s first field outing 15 out of 18 sites appear, georeferenced correctly on the sites layer, within the area where the sample locations are (how did it do this?)
However at three of the sites the data point is located at lat/long 0,0, in the Atlantic ocean (why did this happen for some, not all locations?)
Just trying to bottom this out to avoid it happening again.
Thanks for answering Gary, but as I said, the app worked as expected on 15 out of 18 sites, on a number of different devices. All returned geolocation correctly numerous times during the same session, so that cannot be the answer.
What device were you using to capture data in the field? Also, which version of the Survey123 Field App were you using during collection?
As mentioned above, the 0,0 location is caused by the inability or prevention of the app gaining access to the location sensor of the collecting device. This is mentioned here as well...Frequently asked questions—Survey123 for ArcGIS | ArcGIS
The devices were all iPads (maybe various models, but none more than two years old) and all would have been using app version 3.0.132 I think (or probably whatever the latest version was in September/October this year).
Looking at the data, the problem is not specific to any one device, or date, nor does it relate to how many samples were recorded within the loop.
Its not a problem which requires a fix as such, because I could just put a geopoint into the section of the form which collects the site data, forcing the user to click to fix the location (as I did in the other app). However, this is an unnecessary action for the user, in a fairly click-heavy survey.
What I hoped to achieve was two tables, one of site information (but not georeferenced) and one of samples (georeferenced).
What I have learned is:
a. that the app automatically assigns a georeference to the site information, without being instructed to do so by the user (I am unable to check whether this is the location where the site data gathering was started, or where it was finished, though I suspect the latter is more likely. As it happens, the latter would also be the less useful option, from my perspective) and
b. that the app sometimes fails to do this correctly.
I probably should add that the users were instructed, that when fixing the geolocation for a sample, they should persist until they achieved better than 10m precision. Of course this was not possible for the site-level georefs, since the user did not see that happening.