Closed GoogleCodeExporter closed 9 years ago
This is a bug on Google Maps Engine.
My Tracks outputs a valid kml file, I suspect Google Maps Engine kml import
only supports certain kml tags and not others.
Original comment by jshih@google.com
on 27 Jun 2014 at 6:17
this same issue occurs if the file is loaded into various other programs, such
as gpsprune. Just the start and end waypoint are available and the track itself
is missing. This is relatively new behavior as i have been using gpsprune to
trim tracks for years, and now it fails to load the track something about the
way My Tracks stores the track ( layer, format, ?, I dont know) has changed in
the My tracks program itself, or all of the programs I have tried call the
same dll, add-in, plug-in, engine, etc, and that has changed. Seems more
likely a small change to My Tracks, as files recorded from previous versions of
My Tracks still load fine.
Original comment by mikechar...@gmail.com
on 14 Jul 2014 at 3:18
Do you remember which version of My Tracks still loaded fine? Thanks.
Original comment by jshih@google.com
on 14 Jul 2014 at 6:08
Unfortunately I cannot say for sure. Seems like this started in mid to
early june. I have however identified a difference in the file structure.
When looking at kml files that load and those that don't, My Tracks files
that load correctly always seem to have 2 <gx:track></gx:track> segments,
the first of which seems to be just two points. If I add just the
<gx:track></gx:track> in front of the gx:track data, the file now loads
fine into GPSprune, and will be readable in google earth after cropping the
file. One thing that I haven't figured out is when is load one of these
modified files back into My Tracks to view, the speed data is now wrong
because the total time is always some random number of hours usually in the
thousands, despite all of the time stamps in the file being within a period
of a few hours.
Original comment by mikechar...@gmail.com
on 14 Jul 2014 at 10:05
related possibly too this is just the simple fact the My Tracks does not play
nicely with the desktop version of Google Earth. If A track from My Tracks is
opened and saved in desktop Google Earth without making any changes. The
resulting file will show a random duration of thousands of hours inside of My
Tracks thereby voiding any speed related data. The track is there in My
tracks, but essentially unusable in android Google Earth. The random duration
of the saved track does not seem to be related to its initial start time to the
current save time either. I cannot figure out how the duration is arrived at
from any data or timestamp in kml coding either. I have attached The saved
file as an example (test.kmz), as well as the original.
Original comment by mikechar...@gmail.com
on 15 Jul 2014 at 8:17
Attachments:
Also wierdly, the android Google earth reports a duration of 502 hours, while
My Tracks reports 3013. The slider in android google earth cannot play the
track.
Original comment by mikechar...@gmail.com
on 15 Jul 2014 at 8:26
I believe I may have some insight into this problem, and certainly into a
incompatibility between Google Earth for desktop (and perhaps Maps Engine as
well) and My Tracks, so here it is. There is an incompatibility is in the
file output structure of the KML. Google Earth can open any kml/kmz from my
tracks of earth, etc, but once that file has been saved in Earth, the file will
not open correctly in My Tracks ever again. Here is why: The output of Kml
from My Tracks stores the track in the <gx:track> segment by writing the <when>
immediately followed by the <gx:coord>, then the next <when> <gx:coord> set,
etc. When the file is opened up in Earth (and perhaps maps engine does the
same), it understands this, but it writes the file back out with all the time
data first (all the <when>s) and then all the coordinate data (<gs:coord>s).
Earth interpret either format correctly. Once the Kml is reopened in My
Tracks, My Tracks sees the first <when> and expects a <gx:coord> to follow,
which it does not, so it moves on the the next <when> where the same thing
happens and so on. finally at the last <when> (the supposed end to the
timeline), there actually is a <gx:coord> next (which should have been the
coord the the start of the track), so it creates that point). So now we have
one point with a correct starting location, but occurring at the ending time.
Then My Tracks reads in the rest of the <gx:coord> data, but there is no
remaining time (<when>) statements, so it assumes and assigns the current
instant time. This means all the rest of the track has the same time
coordinate. What you end up with is a track that shows starting at the end
time, and displays the rest of the track for only an instant that corresponds
to the time at which the file was read into My tracks. If you did all of this
from within Google Drive, It has now obliterated the original time data
irretrievably from the file (hope you made a backup). This is also the reason
that speed calculations are now junk, because the whole tack occurs in an
instant. It seems like the likely fix would be just to make My Tracks
Understand how the read both formats of Kml, perhaps by having the code look
for the first <gx:coord> upon reading the first <when>, then returning to read
the second <when> and then looking for a second <gx:coord>, etc. I am not sure
what the source code does when trying to read the file now. The <when> and
<gx:coord> data could also be read as arrays, and scan the file for the
matching data statements. I hope I am not hijacking the OP's thread.
Original comment by mikechar...@gmail.com
on 18 Jul 2014 at 3:10
This is such a pain, as tracks written by MyTracks now won't be read by
gpsbabel, gpsprune, JGPSTrackEdit, etc.
Can we sit down the MyTracks and GE developers and talk about how to interpret
KML?
Original comment by uspoerl...@gmail.com
on 5 Oct 2014 at 2:48
Mike is correct: MyTracks now uses the TrackType element of the Google
Extensions for OGC KML 2.2. See
http://code.google.com/apis/kml/schema/kml22gx.xsd for the XML Schema.
<shameless plug>
You might want to try my RouteConverter tool, which reads the examples above.
And if you save as "Google Earth 4.2 Compressed (*.kmz)" you get the previous
<Placemark> format that gpsbabel, gpsprune, JGPSTrackEdit, etc. should be able
to read.
</shameless plug>
Original comment by cpe...@gmail.com
on 6 Oct 2014 at 8:31
Attachments:
We don't plan to change the My Tracks KML format for now. As a workaround, you
can export to Google My Maps directly.
Original comment by jshih@google.com
on 13 Oct 2014 at 10:46
The export from My Tracks to My Maps works for the tracks and waypoints only,
but it does not transfer the pictures. Seems a bit of a shame...
Original comment by MGKittri...@gmail.com
on 23 Feb 2015 at 7:07
+1 for RouteConverter! ... opens the files fine, and way nicer to use that
GPSPrune. Sidesteps this unfortunate issue.
Original comment by damien.n...@peeppl.com
on 1 Jun 2015 at 6:17
Original issue reported on code.google.com by
charles....@gmail.com
on 27 Jun 2014 at 4:20