Hey hi, love your program. Just been playing around with it for about a week now. I'm in the midst of finding good "best practices" uses for it before a lightning talk in my area about NextCloud.
Today I thought of recording personal business mileage for American tax reporting purposes. Most apps that try to address this suck. What I did (and I'm using GPSLogger for no particular reason) was to add a second session on my NextCloud, then reserve names for Commuting and Deductible in that session. On my mobile device, I added 2 new profiles in GPSLogger to accommodate the two types of mileage. I set my device into the Commute profile and went to the first stop. Before leaving the first stop I switched the device's profile to Deductible, then drove to 2 more locations. At the second location, I switched back to the Commute profile and drove home.
When I displayed the days driving, something unexpected happened in the displayed data in PhoneTrack on my NextCloud server. The PhoneTrack software spuriously made a linear connection between the end of the first commute segment and the start of the second commute segment. If I use your stats tool to get summary reporting on my mileage, that extra line boosted my commute by 4.2 kilometers; 10.17 instead of 5.97.
I can easily think of a way around this for daily stats, but it's still a problem for multi-day aggregate statistics. Perhaps a software solution would be a warp speed test function? Like if the line it is going to draw isn't possible for human transportation methods, it doesn't draw the line? Or maybe a timeout test, like the time gap it was connecting was from 14:23 to 15:05.
PhoneTrack does not make connections between different devices points. What's happening to you is caused by the logging app which is probably not waiting for the GPS fix to log a point. So the first point of the second segment is on same location than last point of first segment. Then, when the GPS fix is done, the location of next point logged is correct.
I can't tell if the issue is related to your phone's system providing a bad location or to GpsLogger using the last location it got.
Anyway, according to me, it can't be related to PhoneTrack.
You can dirty-fix this by manually deleting the first point of second segment. For the future, you could try another logger. I think none of the others can set different profiles, you still can use two logging apps to quickly switch from a profile to another, from a 'device' to another (in PhoneTrack terms).
Since it was all just experimentation data, I tried your dirty-fix. It didn't seem to break the named device's track into two segments. I tried the first point of the second segment with no luck then tried the last point of the first segment and still, the connecting line remained. I'm going to try adding a third named device so there are two distinct commutes, then see if they connect across multi-day filters. It will be a while before I try that. I'll let you know how that goes.
I also wondered if I would have tapped the Stop Logging before switching profiles each time that I wouldn't have had the problem.
What changes between your two GpsLogger profiles ?
If the two profiles use the same device name in logging URL, they will log as the same device and it's normal the positions of one device are linked forming one stroke.
Could you give me a dump of oc_phonetrack_points table ? In private or public, as you wish.
I have three Tracking sessions in my NextCloud PhoneTrack right now. The reserved device name's called Nexus 7, Nexus 6p and Nexus 5 are all in one called Mikes devs. The reserved device names Commute and Deductible are in a session called Business Miles. All the rest are in a session called Health & Fitness.
The "GpsLogger GET and POST URL" is unique for each session and is properly put into the GPSLogger app's section for Logging Details -> Log to custom URL. I didn't meddle with the defaults for the URL, just relied on the interface in PhoneTrack. The "yourname" part was meticulously replaced by the appropriate code for the reserved name of the device.
Attached are what I think you wanted, but if I can find a private messaging to you, I'll get you the public share link for the session we are talking about.
So the goal was to get finite paths that can be aggregated for distance in the summary statistics table. Today I tried the stop logging when I wasn't moving and switched profiles in GPSLogger while the logging was stopped. I would restart logging right as I was about to move again. I still have the unwanted connections from one session to the next and it does connect one day's path to another day's path for a reserved name if the filter lets it display multi-day. The day crossover means there isn't a way to get IRS reporting data from PhoneTracker as it is, except for manually transposing a day's summary table to another calculating method.
Ok now i understand your problem. I thought your devices were all connected and displayed as one line.
Correct me if i'm wrong :
You expect to see two tracks for the same device when there was an interruption in logging.
If it's the case, i'm afraid PhoneTrack is not designed to manage points like that. From PhoneTrack's point of view, positions are all independent from each other. It does not see if there was a logging interruption, it just stores new positions.
You could change the device name to a new one each time your change from one state to another. This way you would have one device (in PhoneTrack's terms) per logging period. You could then add all stats of "commuting" devices and those of "deductibles" devices. It's not a very satisfying solution...
I'll think about how to improve this. I don't know if it's possible as i probably won't change the way "devices" are defined. To be continued.
There could be an option to set a distance (or time) threshold to cut device line into multiple ones. This can be easily done for the stats computation but is is little bit tougher for the display. Still thinking...
Correct me if i'm wrong : You expect to see two tracks for the same device when there was an interruption in logging.
Well the same physical device, but two different logical devices because they were different reserved names.
I expected to have the track segments disjoint because they were intentionally interrupted. I can see how the data has no definitive way to recognize that a given point is the end of a single track or the start of the next track. In the sample data you got, there are a few places where the long line segment connecting points are correct because the app or device had stuttered in it's logging when I was driving and didn't want it to stop logging. Obviously, PhoneTrack can't tell if I shut off the app or if I'm in a tunnel.
If PhoneTrack relies on modular choice for the GPS logging app, then special features won't be possible like an end-of-track marker. Well, unless you get the standards to change and all GPS logging apps can send a start and end of track marker. Or just have a track ID numbering happen.
Hey, maybe if you were going to modify your NextCloud application, you could add a field to number the tracks. The default is a Track ID number never changes, but a user can click on a line linking the point-before to the point-after, and select "Break Track" which would ++ increment the number for all subsequent data bearing that device ID. If it's easy, it would be good to have a track setting somewhere, like a checkbox, that effectively said, change/break tracks by day's; data naturally increments between 23:59:59.999999999999999999999 & 0:00:00. And on your super cool points editor thing, you could have a "Join Visible Tracks" where two visible tracks matching reserved name ID's and track numbers differ by 1, it would -- decrement all track numbers greater than the lowest one on the screen. (I can see how that can get sketchy)
Also, also, also, if an aggregation of track data was to be feasible, the attempt to render that many GPS points would have to come with a, "Are you insane?," warning and allow a non-render option where only statistics were available.
Well the same physical device, but two different logical devices because they were different reserved names.
Two different logical devices (PhoneTrack device) are never going to be displayed as one line. One PhoneTrack device is displayed as one line, whatever interruption there were during logging.
I don't like the idea of having "track ID" very much. As it's not a generic feature provided by all loggers, it wouldn't make it intuitive to understand on what information tracks are based. It would involve a trick on PhoneTrack's side like automatic or manual track making which seems too complicated to me. It would make the interface and the code more complicated...
In my opinion, tracks should be a "display-only" concept. It would not affect the data but just the way it's displayed.
I'm currently making a proof-of-concept implementation of the thresholds i mentioned before.
@eneiluj Oh, I changed concepts too fast in my last post. This following section:
Hey, maybe if you were going to modify your NextCloud application, you could add a field to number the tracks. The default is a Track ID number never changes, but a user can click on a line linking the point-before to the point-after, and select "Break Track" which would ++ increment the number for all subsequent data bearing that device ID. If it's easy, it would be good to have a track setting somewhere, like a checkbox, that effectively said, change/break tracks by day's; data naturally increments between 23:59:59.999999999999999999999 & 0:00:00. And on your super cool points editor thing, you could have a "Join Visible Tracks" where two visible tracks matching reserved name ID's and track numbers differ by 1, it would -- decrement all track numbers greater than the lowest one on the screen. (I can see how that can get sketchy)
Also, also, also, if an aggregation of track data was to be feasible, the attempt to render that many GPS points would have to come with a, "Are you insane?," warning and allow a non-render option where only statistics were available.
was all intended as a suggested change to the oc_phonetrack_points table. That way it's allowing all the loggers to remain generic.
I just pushed in master branch. There are now two new options to cut lines when points are too far. It affects the lines on the map and the stat table.
Could you try it ? Here is how to install dev version.
Now that i implemented the segmentation system i can think about your idea of just adding a new field in oc_phonetrack_points. It could be complementary with the freshly added options...
It took me a bit of time to guess which way to adjust the limiters to get what I wanted, but it was really cool seeing it do that. As of my current data, 240 seconds did the trick. Trying the distance was sketchy cause one data set had lousy GPS data to work from, but 500m was close to ideal. I cleared the distance setting, relying on only the 4 minute time cut-off, and then I used Google Maps to approximate the mileage to compare to the statistics tab in PhoneTrack and it was really great. The distance-traveled variance I saw was solely due to my GPS wander, from my Nexus 6p's inaccuracy, and Google Maps giving me the ideal route restricted to roadways. I tested it across a multi-day filter and it aggregated perfectly. Really great work.
While testing it I thought I would try that Add a point button in the Settings and extra actions section but I couldn't get it to work. I did select the correct session and used copy/paste to transpose the deviceName. My intentions were to recreate the deleted points from the earlier test that we were calling a "dirty-fix". Instead, I just moved existing points to make the distances more correct.
Thanks for your enthusiasm, for sharing your problem and your thoughts and for testing this new feature !
I think the point you're trying to add is actually added but you don't see it in the line because it's too far in distance or in time from the previous point. When manually adding a point, its date is set to "now", so it's not directly inserted were you want it to be.
My advice : unset the cut thresholds and disable filters to see thing how they really are, then edit the points you manually added to change their date to a correct value (between the two existing points around the gap). Normally, after edition, the device line should include them correctly.
This enhancement further off-sets some of the issues in #63 (closed).
I don't want to fiddle with my phone logger and the filters plus this enhancement allows neat display of tracks from whatever timespan. Thanks! Works well for me.
Occurs to me that the distance and time-span really are filters and perhaps best moved with the others?
Julien Veyssierchanged title from Unexpected behavior comment to Unexpected behavior comment (handle gaps in logging data)
changed title from Unexpected behavior comment to Unexpected behavior comment (handle gaps in logging data)
@roydenyates I agree, those threshold can be interpreted as filters. However, they do not filter points but "lines" between points. I think it could be confusing to place those threshold in filters tab.
Thanks a lot @WNYmathGuy for giving the idea and helping to elaborate a solution. Let's consider this issue solved.
Feel free to reopen it if you find a bug or whatever.