search

fmierlo / mytracks

Automatically exported from code.google.com/p/mytracks
1 stars 0 forks source link

MyTracks KML doesn't import correctly into MEL #1545

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. export MyTracks track to KML
2. transfer KMZ file to computer; Unzip resulting KMZ to KML file
3. upload KML file to MEL

What is the expected output? What do you see instead?
Uploading the KML file to Maps Engine Lite only results in the waypoint markers 
being imported; the track itself does not show up.  This is different behavior 
than what you get if you export directly to Google Maps Engine (where the 
waypoints show up in one layer and the track in another).  I don't know what 
would happen if you tried to import a KML that was just track & no waypoints.  

What version of MyTracks are you using? On what version of Android? On what 
phone?
MyTracks 2.0.7; Android 4.4.2; Samsung GalaxyS3

If possible please provide a log by uploading here.
Detailed instructions can be found here:
http://code.google.com/p/mytracks/wiki/HowToReportErrors

Please provide any additional information here:

Original issue reported on code.google.com by charles....@gmail.com on 27 Jun 2014 at 4:20

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
+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