Modify Google Timeline/Maps track
We have been on summer holidays in the mountains and as always Google (my phone) tracked our excursions. More precisely it tried to track, but in the middle of high mountains the GPS signal is not available always and leads to missing or unprecise geo-locations in the Timeline that would be neccessary for smooth and realistic path matching.
I considered to optimize some of the paths to better match the real track that we drove or hiked.
As the simplest solution the software was planned to:
- load a kml file downloaded from my Google Map Timeline (of the selected day)
- graphically represent the data on a 2D surface, so to plot all LineString points in a GUI window
- the points should be movable by Drag&Drop method (left click on a selected point, holding the mouse left click pressed, dragging and moving the point... and then release the point/mouse at the required position)
- in case any point of the track is modified then the new path should be saved
- ... as a copy, in the simplest, but Google Map kml compatible format, not to overwrite the original data. The Google Map compatibility means that the resulting kml file should properly work when imported in a layer of Google My Maps service, meaning that the modified track should properly appear on the map.
- no map background is required as that would highly complicate the functionality, requiring a Google Map API key and a continuous internet connection to update the map after each modification. The original concept was to modify the track (files) offline.
Simple KML editor
The code was written in Python3 language, the graphical user interface and the interactivity were made by tkinter modules, while kml file was loaded and data were extracted with fastkml module (after failing with simplekml module that is not a proper module to modify only to create kml files).
The original path on the map shows unprecise points (off-the road), not required points (driving to the shop, the right part from Unterkrimml) and big jumps in space-and-time, due to missing GPS signal (see the horizontal line from most left point to Unterkrimml).
The same curve was stretched in a fix (800x600 px) sized software window in such a way as to have a 10 pixels padding around the curve. The software window colours were not modified as prettyfying was not planned this time.
I highlighted in yellow those points that were not required/precise and which of those I modified.
Note: colors were modified only in an image editor.
This software does not allow adding or removing points and as consequence off-road points may be precised in position (see the yellow point), missing points to avoid cut off hairpin turns cannot be added, finally not required points cannot be deleted, but I grouped them at our starting point (see the blue spots):
Note: colors were modified only in an image editor.
At that point the first kml file of the modified track was not properly compatible with Google map, in the second step the above points showed up on Google My Maps as individual geo-locations, not as part of an excursion track, but in the final version a <LineString>... </LineString> tag was inserted before the <coordinates>... </coordinates> wrapper in the kml file.
<?xml version="1.0" encoding="UTF-8"?><kml xmlns="http://www.opengis.net/kml/2.2"><Document><Placemark><LineString><coordinates>17.2012735,47.8064775,0 </coordinates></LineString></Placemark></Document></kml>
After modification the file was imported in a new layer of a newly created Google My Maps map:
Read more details in the KML editor - GITHUB readme.
- removing points would be a key point and easy-to-make option,
- in contrast adding track points is a bit more tricky because the points should be added at the right place in the order of points (LineString) to avoid dizzy lines,
- highlighting a point by clicking is an easy request but I consider it does not add much to the track modification functionality, rather it serves fanciness only,
- adding real maps (with continuous updates) in the background would be the best development as a positive outcome but has a high coding time demand, but either the software should use a common Google API key that due to economical reasons Google does not offer, or each user should use their own API key which I consider to be an overcomplication of the task and functionality.
