Location Tracking - Cleaning Up The Unwanted Track Lines

[tiztrain]

Hey community,

I have been needing to prepare the results of surveys completed by our field teams. Looking at the results of the location tracking service, the Track Lines have a lot of extra straight long lines that are not part of the survey. The image below is an example and has been filtered to only one user. I have made the point 'Tracks' layer transparent so you can see the 'Track Lines' underneath.

Looking into the data, I initially thought that these extra track lines are due to the location of a device always adjusting and bouncing around and each of these get recorded as a point, as is evident in the table below:

But that would mean that the line would just continue going and there would not be these random extra lines showing up. At certain locations I see that multiple points get created with the only difference being the altitude. 

Then it spurs off multiple different lines that don't follow the correct path and start connecting to other points and creating incorrect lines:

Anyone know what is going on here? Is it a BUG?

Secondly, is the best solution to create my own line layer after cleaning up the point layer?

My thoughts are remove the duplicate points with the exact same coord but have different vertical accuracy then maybe all is fixed?

Has anybody done something like this? Was thinking Data Interoperability be the best tool to action this in a standardised repeatable way?

[ColinLawrence]

Hey @tiztrain , there will be some changes and improvements made with how the track lines are generated in the future. Sometimes this happens as a result of a bad GPS signal on the device but also sometimes there are other factors. Unfortunately you cannot remove the track lines individually. 

[tiztrain]

@ColinLawrence ok that makes sense. If it was just bad GPS data, I would be able to create my own lines easily but the problem is where multiple points are created at that one point and it continues creating more.

I have noticed that users also forget to turn off the tracking and then we have a whole bunch of extra capture. Would be good if somehow this for not occur

[tiztrain]

Also have noticed situations where points are not captured for a hour or so creating these long straight lines as can be seen in the example highlighted below. Is this an issue with some timeout settings of the phone OS? Not allowing Field Maps to capture a user's location or something along those lines?

[ColinLawrence]

Do you know what devices are being used when you see this behavior? What are the red lines in your example generated from? @tiztrain 

[tiztrain]

@ColinLawrence in this example above, it is an iPhone. I just checked a user with an Android and same thing happens too.
With a previous company I worked for, I noticed the same issue so it has been an ongoing issue for a while now.

[ColinLawrence]

The team has been investigating issues on Android that we suspect are at least partially caused by OS battery/app management. For iOS there have not been reports of the same issues but I would note that you cannot force close Field Maps have Location Sharing continue interrupted as iOS will not re-launch the app until a significant location change is detected by the OS which can take some time. Not sure if that is a workflow you are doing or not. Putting the app in the background should be fine. If you notice a reproducible case with this behavior please do let us know. 

[tiztrain]

The previous organisation I worked for was only iOS and we had problems @Tilley__AlexTilley  can comment further if it is still a problem but I believe so. He had also developed a Data Interoperability workspace to help alleviate the issue for the lines.

In my current organisation, the android track capture might actually look a bit better than the iOS but I would need to look more closely at this. There are also too many people out in the field so I think the majority of them would be leaving it in the background to run.

[Tilley__AlexTilley]

The location tracking functionality hasn't been used in our organisation for the past few months but prior to this I can confirm it was still a consistent issue so I can't imagine much has changed since. As mentioned we also have a similar data interoperability workspace that uses certain thresholds such as distance between tracking points and point GPS accuracy that alleviates this. 

[tiztrain]

I am building a Data Interoperability workspace that is working pretty well. I have assigned a lineID to the points based on the time difference between adjacent points and if it falls outside a defined time difference, increase the lineID count by 1. Does mean I have lots of lines instead but it looks much more accurate.

Also filtered out points with the exact same x,y coord, removing the points with low accuracy.