Open jidanni opened 3 years ago
For instance, we are walking around the perimeter of an ancient fortress. At the foot of each wall there's a different cell tower reception.
If this were a flat field of wheat, the automatic mode would be suitable. But in this case with the fortress we want a manual mode.
Yes, at the top of the screen there should be a big red warning that we are in manual mode.
Indeed, this would allow the user to be
before he saved a point. It would be all under his control!
Or say we want to save a point at,
Yes, we will end up with approximately the same density of points as in the current automatic mode, but we will be able to save them exactly where we want instead!
Almost like a professional surveying tool!
I don't see a difference between this and #144 . Can you explain?
They are very different. One is to have a button to save a point unconditionally, even when automatically collecting.
The other is to turn off automatic collecting completely.
And of course once it is turned off, then the only way to collect is with my new manual button.
One could say a workaround for all this is who just push the stop collecting button. Walk to your favorite spot and then push the start collecting button, upon which the point will be saved. The disadvantage to this is one has no control the accuracy. The app will be happy with a 25m accuracy, not giving a chance for it to settle down before collecting the point.
Also we don't want to have to start and stop the app each time we want to collect a point.
The disadvantage to this is one has no control the accuracy. The app will be happy with a 25m accuracy, not giving a chance for it to settle down before collecting the point.
A technique I use is to have the GNSS receiver perma-enabled (while out & about, not 24/7) by using a small (memory-footprint) app which has a toggle function. Examples:
Lock G[NS]S
) (has other useful features, including the ability to query UnifiedNLP backends)Start G[NS]S
, which is distinct from starting to record a track)The idea of these seems to be exactly that of allowing the receiver time to stabilise, achieve good position fix accuracy, before actually recording any data. When recording a track, for example, this avoids the familiar ‘squiglies’ seen when track-recording starts at the same moment that GNSS does. 🙂
I'll start it several minutes before I'm due to head out. By then I'll have 5m (or less) uncertainty of position. This becomes especially necessary when using carrier-phase (particularly without dual-frequency reception), or when lacking ephemeris (orbital, Augmented-GPS) data; then it can take on the order of 15 minutes to stabilise.
However, for context;
Besides starting data-collection with good accuracy, I can switch apps with carefree abandon, and otherwise always have a good fix immediately available. Anything which uses the passive
location provider also benefits from readily available fixes as I'm on the move (think of the likes of weather apps & automation tools).
The benefits of this POSIX-philosophy approach (each app doing one job, in order to do it well) is that other apps can remain simpler, and not have to be concerned with ‘warning up’ the receiver first. Each app need only set sensible (for its own needs) parameters for receiving position updates from the GPS
provider (like Tower Collector does, with min-distance of some 20+ metres). Plus, granular control over when it's enabled (instead of each app guessing); defining my own trade-off between performance versus energy-saving.
Like #144, say we are in a special geography that isn't compatible with the automatic saving mode. In other words the grid of 25 M per point is not exactly suitable. Therefore it would be great if there was in mode where every point would require the user to manually save it.