MapMyTracks issues

[JavaJens]

Hi,



I noticed some strange things when running MapMyTracks logging against my own implementation of their API.

First of all the privacy setting is transferred as a "privicity"=>"private" value, but should be "privacy".

Secondly it seems that when internet connection is lost or not present at some point, the next update to the server is of type "start_activity", although it should be "update_activity".



Lastly I noticed that when using the export GPX Track option, the track is sent to the mapmytracks.com server, but I think it should honour the setting for the mapmytracks Url in the preferences.



Looking forward to your feedback and many thanks for this great application!

Cheers

[martijn]

I have also been looking at the stuff OruxMaps sends to the server when MapMyTracks live logging is active, and I really wonder why it sends what it sends.



I have taken the 'start_activity' and all the 'update_activity' requests from a walk I took the other day, and put the values from the 'points' parameter in a spreadsheet. See here for the result: https://www.grendelman.net/files/screenshot-mapmytracks-oruxmaps.png">https://www.grendelman.net/files/screen ... uxmaps.png">https://www.grendelman.net/files/screenshot-mapmytracks-oruxmaps.png



https://www.grendelman.net/files/screenshot-mapmytracks-oruxmaps.png">



There are a couple of things that I think are strange.

• In total, OruxMaps made 32 requests, but there were only 14 unique ones, the others were duplicates.

• Column A is 'start_activity'. Those points are sent only once and never repeated.

• The highest number of points in any request is 49

• In column E, some points are dropped, apparently because otherwise there would be too many, but only 31 points remain

• In column J, all of a sudden OLD points are logged that have never been logged before. Those are the ones in red.

• In column N this happens again.

• In column J, also older trackpoints are sent, that weren't sent the 5 requests before that, so points first appearing in C or D, then NOT logged in E through I, and coming back in J through M, but not N.

The last observation I'm sure is due to the way OruxMaps decides which points to drop, to get the number down to an acceptable level (< 50?). However, the end result seems quite arbitrary. Some points get logged only once, others maybe 3 times and some even 13 times. The algorithm also seems to drop points from the set that have never been logged. It just doesn't make sense.



First question: why send points more than once in the first place? To cater for failed connections? OK. Then why not just send the last 50 points? That way, all points will get the same treatment and the server has lots of opportunities to catch everything. But that is not very bandwidth- or battery-efficient and neither is sending requests to the server when there is no new data.



I would suggest to send ONLY new data, and maybe when the number of new points accumulates to 40 or something, send one extra request with all those points, just for safety. But that shouldn't be necessary, because OruxMaps can know by the HTTP status code and the XML response whether the server has processed the request correctly. Failed requests could be queued and retried.



I think I read somewhere, that if OruxMaps can't reach the server, it will queue the points, but if more than 50 points get queued, the list is shortened with the same algorithm. In that case of course it does not make sense to send the last 50 points, since you want to log from the start of the trip. But in that case, why trim the list down to 50? Why not send all points and divide them over as many requests as necessary (assuming the limit of 50 points is somehow imposed by MapMyTracks and not an arbitrary choice in OruxMaps)? That shouldn't be hard to do. It's just a bit strange that the end result in your online tracklog should be different just because your connection was out for some time.



And two last questions: OruxMaps sends a request every two minutes. Could that be a configurable parameter? I don't know anything about the limits of the MapMyTracks service, but since I am implementing my own server, I would like more frequent updates. And would it be possible to send a 'start_activity' a little sooner, like directly when starting the log? I'm not sure what the added value is of saving up locations for two minutes before sending the 'start_activity'.



I hope this helps. Outside the things mentioned in this post, I really like OruxMaps, so I hope I can help to improve it.



Best regards,

Martijn.

[orux]

I have also been looking at the stuff OruxMaps sends to the server when MapMyTracks live logging is active, and I really wonder why it sends what it sends.



I have taken the 'start_activity' and all the 'update_activity' requests from a walk I took the other day, and put the values from the 'points' parameter in a spreadsheet. See here for the result: https://www.grendelman.net/files/screenshot-mapmytracks-oruxmaps.png">https://www.grendelman.net/files/screen ... uxmaps.png">https://www.grendelman.net/files/screenshot-mapmytracks-oruxmaps.png



There are a couple of things that I think are strange.

• In total, OruxMaps made 32 requests, but there were only 14 unique ones, the others were duplicates.

• Column A is 'start_activity'. Those points are sent only once and never repeated.

• The highest number of points in any request is 49

• In column E, some points are dropped, apparently because otherwise there would be too many, but only 31 points remain

• In column J, all of a sudden OLD points are logged that have never been logged before. Those are the ones in red.

• In column N this happens again.

• In column J, also older trackpoints are sent, that weren't sent the 5 requests before that, so points first appearing in C or D, then NOT logged in E through I, and coming back in J through M, but not N.

The last observation I'm sure is due to the way OruxMaps decides which points to drop, to get the number down to an acceptable level (< 50?). However, the end result seems quite arbitrary. Some points get logged only once, others maybe 3 times and some even 13 times. The algorithm also seems to drop points from the set that have never been logged. It just doesn't make sense.



First question: why send points more than once in the first place? To cater for failed connections? OK. Then why not just send the last 50 points? That way, all points will get the same treatment and the server has lots of opportunities to catch everything. But that is not very bandwidth- or battery-efficient and neither is sending requests to the server when there is no new data.



I would suggest to send ONLY new data, and maybe when the number of new points accumulates to 40 or something, send one extra request with all those points, just for safety. But that shouldn't be necessary, because OruxMaps can know by the HTTP status code and the XML response whether the server has processed the request correctly. Failed requests could be queued and retried.



I think I read somewhere, that if OruxMaps can't reach the server, it will queue the points, but if more than 50 points get queued, the list is shortened with the same algorithm. In that case of course it does not make sense to send the last 50 points, since you want to log from the start of the trip. But in that case, why trim the list down to 50? Why not send all points and divide them over as many requests as necessary (assuming the limit of 50 points is somehow imposed by MapMyTracks and not an arbitrary choice in OruxMaps)? That shouldn't be hard to do. It's just a bit strange that the end result in your online tracklog should be different just because your connection was out for some time.



And two last questions: OruxMaps sends a request every two minutes. Could that be a configurable parameter? I don't know anything about the limits of the MapMyTracks service, but since I am implementing my own server, I would like more frequent updates. And would it be possible to send a 'start_activity' a little sooner, like directly when starting the log? I'm not sure what the added value is of saving up locations for two minutes before sending the 'start_activity'.



I hope this helps. Outside the things mentioned in this post, I really like OruxMaps, so I hope I can help to improve it.



Best regards,

Martijn.

Hi,







Because of external limitations, OruxMaps sends no more than 50 coordinates each 2 minutes.



If it can't send a set of coordinates, after 2 minutes will try again, selecting no more than 50 coordinates from the last track point sent. The algorithm is easy; the app takes one each 'step', when step = (size of array of don't sent coordinates)/50 + 1. Because of the saved coordinates array is longer each 2 minutes, the set of coordinates is different.



If the update is successful, the next set of coordinates will start from the last track point sent. What you see in your spreadsheet is because OruxMaps doesn't receive the right value from the server after the 'update' operation, and always tries to send the track points starting from the last point sent in the starting set (successfully received).



BUT I am working in my own API, similar but less restricted; and need a server side developer, If some of you want, we can talk about it.





orux

[martijn]

Hi,



I am sorry, indeed my test server did not reply with a correct XML response to 'update_activity', like it does for 'start_activity'. Sorry for the confusion.



If you need help with the server side of something, please let me know what you have in mind. If it's Python or PHP I may be able to help out.



Best regards,

Martijn,