Show satellites and time elapsed in geopoint dialog

What is the general goal of the feature?
Provide more feedback when capturing geopoints to help troubleshoot issues getting GPS lock. Possibly improve the accuracy of collected points.

What are some example use cases for this feature?
On recent field visits I got a lot of questions from enumerators about GPS and many reported occasionally having trouble getting lock or getting points of high enough accuracy.

What can you contribute to making this feature a reality?
Project management, code.

In Collect geotrace and geoshape improvements we started exploring improvements that could be made to the geo questions. I've realized it would be helpful to consider geopoint separately from geotrace and geoshape since it is more widely used and shares less code with the other two.

Currently the geopoint dialog displays the Android location provider being used (e.g. fused). I don't think this is very helpful to most users and it seems it could be removed. Any reason to keep it?

I would also like to add both the number of satellites available and the number of satellites actually seen as well as the time elapsed since the geopoint activity was started. These values will help provide a sense that progress is being made and help with troubleshooting in cases where getting lock may take a long time. I currently use the app GPS Status & Toolbox to get that information and I find it helpful.

The revised geopoint dialog would have the following information next to the progress marker:

Accuracy: 96m

Satellites: 2/20
Time elapsed: 8s

Is there anything else that would be helpful to include?

Additionally, @Ivangayton and @zestyping, you have been working with the following dialog:
58 PM

Can you say more about the benefits of giving the user control over the required accuracy?

Do you have a sense of the impact of averaging multiple points? This thread suggests it may help with precision. I know we have some geo experts around and it would be helpful to hear their thoughts on that.


Hi LN,

I strongly support your suggestion to add number of satellites connected/expected.

Time to fix would be nice if it worked well, but I suspect it'll be hard to make that estimate realistic, and I'd just as soon not have it than have an estimated time to fix that's usually wrong. I'd be interested to see how well it can be made to work, but I'm not optimistic!

As you say, often our surveyors in the field find themselves staring at a Waiting for GPS fix dialogue, which is frustrating and uninformative; there's no real way to know if there's progress being made or not. Our field workers do as you describe above; they exit ODK, open another application (GPS Essentials, OSMAND, or the like) that provides at least a number of satellites connected/expected, if not a skyplot etc. Once they have a fix, they return to ODK. If not - if they are seeing 0/0 for a few minutes - they know to troubleshoot or request help. This app-switching works, but of course it would be far nicer to have the information right in ODK.

Yes, @zestyping implemented an averaged-point system with a variable filter at our request, which our field team is using here in Tanzania.

We allow users to control the required accuracy simply because they can then select the lowest threshold at which they can practically collect an adequate number of points! For example, if the threshold is fixed at 4.0 m, and the GPS is sitting at 5.6 for 30 minutes, it is probably not reasonable to continue waiting; in our case it's more sensible to raise the threshold to 6, accept the points (and maybe collect a higher number to average), and move on. If, on the other hand, your GPS has a really tight fix, you might as well lower the filter threshold to keep only the most accurate points. So user control of the threshold works well for us in the field.

This filtering could, of course, be done in post-processing, but only if we kept all of the points (which would be a pretty major change to the way ODK stores information). Alternately, we could weight the lower-precision points less in the average, but this still leaves us with a conundrum when we have a location where we just can't get very good precision. We'd rather the user make a (hopefully informed) decision about whether to collect the point or not than hide the details behind some kind of weighting.

I haven't got a lot of empirical evidence that averaging points improves accuracy, but I suspect it does based on experience, some reading, and some mathematical reasoning. When I have time, I'm going to run some proper tests on this to determine if it improves accuracy in real-world African surveying conditions.

I was in Canadian forestry back in the late Pleistocene (well, the 1990's), and we used what were at the time very expensive Trimble survey-grade GPS machines (giant pole-mounted overhead antenna sticking out of a backpack and a vest full of lead-acid battery packs; ah, the good old days). These GPS machines actually used point averaging by default; when setting up a survey you could specify a number of points required for a given type of feature; I seem to recall that the default setting was something like 10 points. If you wanted more accuracy, you added more points to the pool to average. Government clients would specify a number of averaged fixes per location in their contracts with surveyors. I have no idea if that was actually evidence-based, but it was certainly the standard practice, and someone must have thought it improved accuracy.

Reasoning from first principles, it seems as though averaging points should reduce any error resulting from stochastic atmospheric diffraction and timing slop in the receiver; those will follow a Gaussian normal distribution. It won't help for multipath error or poor satellite geometry (persistent diffraction where one or more birds are low on the horizon and their signals are passing through a lot of air); those errors are biased, not Gaussian, and the only mitigation I'm aware of is Differential GPS correction. DGPS itself is far out of scope, though it's possibly worth considering if logging satellite information for each point someday in the future would be very expensive; it would enable us to play with DGPS possibilities). I'd guess that if you waited long enough at each point, even those errors would eventually approach a Gaussian distribution (as the satellite constellation changes); there are occasional use-cases for which you actually do want to leave the phone at a single location for the whole day to get a really precise point.

This seems to be the general consensus on the thread you posted, LN, as well as most of the reading I've done (I've read a lot about this since I've long been mildly obsessed with using smartphones for the highest-possible-precision surveying so that we can scale mapping and health activities in Africa using local devices).

I'd be keen indeed to hear more from the geo experts!



That can be a great feature.

Thank you for the helpful context, @Ivangayton and for the feedback, @Vincent_Mkandawire!

When I wrote "time to fix," I meant more like "time elapsed since first trying to get a fix" -- just a simple count up. Sometimes it can feel like a really long time but on verification it hasn't been so bad. It would also be helpful to have more concrete evidence when capturing a point really does take an unusually long time.

I understand the ability to change the target accuracy now. Previously, I've told people to tap the "Save GeoPoint" button if at some point they got to the best accuracy they were likely to get. With the averaging it could indeed make sense to continue collecting points to get a better accuracy. Thanks for sharing your experience!

@freddycoal you posted ODK and Rinex GNSS Capture, would the averaging described here address your needs or would you really prefer the raw data?

To be clear, our fix doesn't come close to the accuracy that could be achieved by Differential GPS (DGPS). @freddycoal is asking for Rinex data, which would make it possible to implement DGPS , and possibly even Real-Time Kinematic (RTK) in some cases - depending on hardware.

DGPS would be amazing - it would probably allow us to get to sub-meter accuracy (which in turn would get us to the point of doing cadastral surveying in Africa), but it's not simple! If someone wants to work on it, I'd be keen to support, and indeed the first thing to do would be to log Rinex data. But for the moment I don't have bandwidth to lead on such a project.

1 Like

I think there's a clear win with satellites and time elapsed, so I'd be a +1 there.

The averaging, I'd say we hold off on pulling into Collect. My gut is that we might be able to put a different spin on that.

For example, we could store the best accuracy seen during the period the dialog is shown. And then when you save the point, it stores that one (and not the current reading).

Another +1 on having satellites showing.

Having that showing will mean enumerators have some idea of whether they should do:

  • growing number of sats - just wait a few seconds longer
  • staying at zero - rather cancel (e.g. if the GPS has problems)
  • 1 or 2 but not increasing - try moving to outside the dwelling or away from trees

I'd expand the text for clarity to say 2 out of 20 instead of 2/20, so that less prior knowledge is needed to understand what is meant.

1 Like

+1 from my side.
This will be a great feature for all Managers who are working in survey which took Geo Points.

1 Like

Just wanted to confirm that we'll certainly be adding satellites and elapsed this as part of Collect geotrace and geoshape improvements. @jknightco will be doing a refactor of the geo code first, then this will be easy to add.

1 Like

Could time spent waiting for a fix be reduced by having some way to have the phone start actively looking for a GPS signal before the geopoint question is reached in a survey with a number of other questions before it? The phone doesn't update it's location until an app asks for it? And the more time that has elapsed since the last request means the longer to wait for a good fix? There are differences in the time for a decent fix between when Collect is the only app running and when another app is actively communicating with the phone's GPS hardware?

1 Like

I believe the challenge of GPS "cold start" that you're describing @danbjoseph is what @Badrun_Nahar and @iamnarendrasingh are discussing in Geopoint problem. I like the suggestion in that thread of using a dedicated app with configurable settings but we should also investigate what kind of impact on lock speed and battery life "warming" the GPS on form launch could have. Good idea.

1 Like

Thanks for including me in this discussion. To give you a bit of my background I have been a GIS user/administrator/practitioner for the last 10 years, so this has a lot to do with the wheelhouse I work in.

There is a lot to consider here with features and I will give my 2 cents for what it's worth. I see a few discussions in this thread and I am trying to address them.

Averaging discussion: so I know it may be semantics but the averaging does not increase accuracy, it increases precision. In terms of GIS data collection, these are two very different things. The reason Trimble devices collect many points is because while they generally start off as more accurate receivers and antenna, but they normally use post processing Differential Correction. This is not something most devices are capable of because this requires raw gnss receivers. However precision is a good thing as well, and one widely used and accepted approach is CEP(Circular Error Probability). Instead of averaging points this gives the location as the center and the size of the circle as the area where 50% of the points fall within. (Further reading:

Submeter Discussion: Most devices cannot access the full raw GNSS data that the GPS receivers see and only are able to access the interpreted NMEA sentences or only portions of the GNSS data. So submeter accurate data is probably limited to using a submeter capable unit (sorry @Ivangayton), like a Mesa 2, or an external Bluetooth gnss receiver like the trimble R1. This has more to do with the hardware chip in the device and the properties of the Antenna than anything that software can overcome. All of these devices (that I know of) have software that runs in the background that uses mock locations to report the high accuracy GPS locations in standard Android formats (NMEA sentences).

From a GIS admin side reported accuracy is important but PDOP values are helpful in assessing the recording quality. Often accuracy and precision gets worse with a higher PDOP.

Troubleshooting: +1 for satellite count, (this tells the user the gps is working and trying to get a lock) and adjustable reported accuracy threshold. Ideally PDOP would be able to be adjusted as well because this actually has more to do with where the satellites are in relation to you and the confidence one can have in both the accuracy and the precision vs. just the device reported accuracy number. The problem I have seen is that most users don't understand this number, however this could possibly be remedied by using the table near the bottom of the page on the link above to give the user an idea of the point quality such as "Ideal", "Excellent", "Good", etc. I'm not sure if PDOP is a readily accessible value that is available so we might need to just use accuracy



Thanks @John_Ellis, that's some really useful feedback!

I love the idea of the CEP rather than averaging.

Very recently Google has announced support for raw gnss data access; they've even published a list of devices that support it.

Are you saying that this is only a portion of the full gnss data? If so, are you sure that there's not enough there to perform at least some basic differential correction?

Very interesting! As long as these devices can receive SBAS signals (which is a given in all of the receivers I mentioned before) then the differential correction is possible to some degree. Basically it works by looking at the difference between the reported location of a fixed base station near you and the actual known location of that base station at the exact time that the recording was taken. The signals from those base stations are transmitted as SBAS signals. The app referenced in your post does look for those signals. The accuracy is improved but I would be still be skeptical if any normal consumer devices were capable of sub-meter accurate locations. I think getting sub 3m is likely though.

Satellites and time elapsed are now shown in the geopoint dialog as of Collect v1.15.0.

1 Like

Hi Helene,

I've been reading this old thread and some of the discussions around geo-focused changes in ODK with interest. With the new inclusion of "number of satellites" in geopoint, is there any way to record the number of satellites for later review or analysis in the office? Our goal is to understand variation in GPS accuracy better, and to troubleshoot accuracy problems.

Of course, a user can watch the number of satellites in the dialog and then record this in a separate question. But they often update quickly and then the number disappears after a geopoint is recorded/saved. Is this information stored anywhere that we could access as part of a calculate field or something similar?


Hi everyone!

Just want to let you know that this has been added as an issue in Github:

Feel free to continue discussion here!

1 Like