I think most of the differences you've identified are differences between the various specs we try to follow.
The raw data uses the ODK notation. It uses lat/long based on ISO 6709 and common lay usage.
The OData standard states that locations should be represented as GeoJSON. The GeoJSON spec specifies lon, lat order.
It's not part of the GeoJSON or WKT standards. It is added as a property to the GeoJSON in the OData feed but PowerQuery wouldn't know what to do with it so I guess it doesn't display it. I can dig deeper into whether it can be retrieved by doing something like changing type and splitting if this is critical.
I'm not sure what this references, can you please show an example?
When points are placed manually, the mapping engine (Mapbox, OSM, GMaps) will divide up the screen and I guess give as many digits as they can represent. For device-captured points, the coordinates come from the Google Fused location provider. I believe that the number of decimal digits you get will depend on several factors including the version of Google Play Service and the sensors available (GPS, wifi). Collect passes on these raw values which I think is the best thing for it to do. This GIS StackExchange post has really good information about the meaning of these decimals and how they relate to accuracy.
We can't know anything about precision without following some kind of calibration protocol. Accuracy is defined in the docs.
Unfortunately, the SRID=4326
notation comes from the way PowerBI or Excel reads GeoJSON from the OData feed. See this PowerBI forum thread. I've done some mapping in PowerBI by splitting coordinates as suggested in that thread. It also loses the .0
.
Is there a tool that you'd like to use WKT values with but can't because of this? Will look into it.
I'm afraid I don't see a great alternative! My experience is that folks build their pipelines around one source. It is particularly annoying that some don't include accuracy. If there's a specific tool you're unable to use because of this we might be able to come up with a solution.
Here are the problems I've seen placement-map
used to solve:
- The environment means it's often not possible to get a high-accuracy point but the user can use points of interest to get closer to their actual location.
- The user is not exactly in the location they want to capture. E.g. they're standing in the street and want to capture the location of the door to a specific house. The zoom to location gets them close and then they can adjust.
It sounds like you're doing something like the second case and you never want the user's current location? This relates to the request for a manual-location-only question type here.
Indeed, those are only supported for geopoint
with no appearance. I think we should fix that and I like it as a way to address the issue above.
That's right. Those both have more complex configuration that's not exposed by the form definition currently. We'd have to expose at least collection interval in addition to accuracy, I believe. More at Geo: Setting an accuracy threshold and collection interval in the form definition.
That sounds like a documentation issue! allow-mock-accuracy=false
means the accuracy value for a point that comes from a mock provider (external app such as a spoofing app) will automatically get an accuracy of 0. That's the default. There's no external app involved in your workflow so it has no effect. The goal is to be able to detect in analysis that a user tried to use a location spoofing app.
I think the best answer here would be for the form to allow requesting manual collection and hide the auto collection option.