QuickCapture tracks, accuracy threshold met/exceeded

[Josef_Strobl]

In a QC project, required horizontal accuracy is set to x meters. When after successfully starting capture of a track for a period of time this limit is not met, the last and again first points within the limit are connected by a straight line, which of course does not correspond at all to the actual track. Any suggestions how to resolve this? Interrupting the track line would be adequate, this then would be a multipart feature ...? Any other ideas? Thanks!

[pjdohertygis]

I too have been hitting the straight line issue, however I believe there can be multiple causes aside from the one you stated. Sometimes the end user may not gave their location permissions setup properly. Also there may be issues with how some cell phones are connecting to geolocated wifi sources. I’m curious if you still see this issue when they are on airplane mode?

[Josef_Strobl]

Good to point out possible causes - thanks! In this case: all with GNSS only, and working well over large stretches of road, then seemingly (?) interrupted / degraded GNSS signal, after a while continuing ok. I think we understand the reason, but looking for adequate ways to handle the resulting trajectories.

[pjdohertygis]

Your scenario (GNSS Only) might be really helpful for troubleshooting and ruling out other causes!  iOS, Android, or Windows devices?

[JohnathanHasthorpe]

@Josef_Strobl - If you set a required error threshold for your project, you need to meet the threshold in order to capture a point, or start a line or polygon.

Once a line is started, any vertex that does not meet the threshold is discarded. However, when the user presses the project button to end the line, the app does not apply the threshold, so that it can get a vertex to end the line.

In your senario, your user would have had a valid vertex on start, but after that, all captured vertexes failed to meet the accuracy threshold. This resulted in a start and end vertex and a straight line in between.

So some things to consider:

- Is the required horizontal accuracy threshold for your project too strict, should you reduce it, so that you can capture more of the line?

- Could you make the accuracy threshold optional as opposed to required?

- If you have a high accuracy requirement, have you looked as using an external GNSS reciever that could provide higher accuracies.

- If QuickCapture captures a line with one valid vertex (at the start) and the user ends the line with a vertex that does not meet the threshold, would you want the option to discard the line? We could add this as an enhancement request.

Thanks

John

[Josef_Strobl · Accepted solution]

John, thank you for clarification, this is about what I had expected. Interrupting the track, or somehow labeling the out-of-threshold section would be nice, but likely will dig too deep into the data model. Long term, perhaps this could be handled like with tracker, when I can access accuracy when displaying - although this might not help with vertices missing altogether.

Right, I would support the enhancement request you mention - omitting 'degenerate' since-point lines altogether.

thanks again, Josef

[JohnathanHasthorpe]

Accuracy thresholds for a project can be required or optional:

If the optional threshold is not met, the user will see the following, but can still capture points or vertices:

If the required threshold is not met, the user will see the following, and can't capture points or vertices:

From your feedback, this could be made more clear. We will look into this.

Thanks

John

[Josef_Strobl]

thanks again, this I am aware of - my question is more about the handling of de facto interrupted lines due to degraded signal etc. Avoiding long straight connections across gaps in recording.