search

Buzov / mytracks

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

Option to remove fractional seconds in exported GPX files #1311

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Record track.
2. Go to "Menu/Save to external storage"
3. Select "save as GPX"
4. Open file in a text editor and observe the time field

What is the expected output? What do you see instead?
Usually, an entry such as "22:35:55Z" is expected; however, I see 
"22:35:55.000Z". In about 2,400 records of a recently recorded track, only 6 
had the milliseconds field filled in, usually as "645", which could reflect a 
bug of sorts.

Inclusion of milliseconds confuses my software (@trip PC) causing problems with 
setting the time zone. If there is no bug and if the inclusion of milliseconds 
was intensional in the design of the software, please provide a "compatibility" 
option to not include milliseconds in exported GPX files. 

What version of MyTracks are you using? On what version of Android? On what 
phone?
My Tracks v. 2.0.4, Samsung Galaxy Note II (Verizon SCH-I605) running Android 
4.1.2.

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 njpienia...@gmail.com on 29 May 2013 at 6:45

GoogleCodeExporter commented 9 years ago 
milliseconds in time is a valid gpx time. Some users do want the extra 
precision.

Original comment by jshih@google.com on 8 Jun 2013 at 12:18

GoogleCodeExporter commented 9 years ago 
WontFix:
OK, see below:
1. Someone requested extra precision.
2. You implemented "extra precision" by adding .000 to each time reading. 
Bravo! This is superextra precision. Once in about 50 points you add .648 
instead .000. Super!
3. In effect, you screw-up the use of My Tracks tracks in software that doesn't 
like milliseconds.

Why not (before you solve the problem of the buggy implementation of your 
"extra precision") implement an option in Settings: Do you want Extra precision 
Yes or No.
Thanks for your consideration and your great work on My Tracks!
Norman

Original comment by njpienia...@gmail.com on 9 Jun 2013 at 6:16

GoogleCodeExporter commented 9 years ago 
The precision comes from your phone's gps chip. Some phones do provide higher 
precision. The gpx file output passes the gpx validation tool for compatibility.

http://www.topografix.com/gpx_validation.asp

Original comment by jshih@google.com on 10 Jun 2013 at 5:15

GoogleCodeExporter commented 9 years ago 
I understand that you will defend the set of features you programmed into
My Tracks, even if they satisfy only a minuscule of users. OK, OK, OK.

The story of how well is your generation of the gpx format validated holds
water only for a moment, see below:

I tried to load the My Tracks gpx file into several software packages and
failed. Some would not load it, others would load it, but have a problem
with time zone. In addition, RouteConverter protested that the format of
the KML does not follow the published format.

You may argue that all of these programs are wrong and your coding is
perfect. OK, OK, OK. I loaded My Tracks-generated gpx file into the newest
ExpertGPS software (v. 4.89) and it opened it OK, without any problems.

You score one point!!!!!

Next, I saved the My Tracks gpx file that I opened in ExpertGPS to the gpx
format. Please note that TopoGraphics, the makers of ExpertGPS, wrote the
rules of the gpx format.

Examining the output file I noticed that ExpertGPS removed all the
milliseconds @1#4% and possibly other ^&*#@( you write into gpx. In effect,
the gpx file can be opened in any software package on my computer. Bravo!

You lose one point!!!!!!!!!!!!!!!!!!!!!!!!!!

OK, just add an option to allow your favorite users to enter any &^#$% they
want into the KML or gpx file and generate a compatible gpx file to make
life simpler for other.

OK?

Original comment by njpienia...@gmail.com on 10 Jun 2013 at 8:55

GoogleCodeExporter commented 9 years ago

Original comment by jshih@google.com on 11 Jun 2013 at 4:55

GoogleCodeExporter commented 9 years ago 
I have the same issue. The exported GPX files crash a number of online or 
downloadable GPX analysis tools. And only a few points have the extra precision.

It'd be nice to have the option to exclude the extra precision rather than 
having to do it by hand in GPX editing tools.

Original comment by hugh.she...@gmail.com on 24 Jun 2013 at 3:13

GoogleCodeExporter commented 9 years ago 
Creator of a popular program that reads and writes GPX here, and part of the 
GPX development team.  Trailing milliseconds  - even .000 is completely valid.  
(OK, trailing zeros should probably be dropped for cosmetic/space conservation 
reasons.)   LOTS of devices record ten samples per second these days. If you 
have programs that won't read GPX with sub-second time, the bugreport should go 
to those programs.  That's the point of formal validation - to draw a line in 
the sand between the reader and the writer.  If it validates, it's valid.  If 
it's valid and can't be read by a certain program, that's a problem with that 
program.

The abusive tone above is also completely unnecessary and unlikely to endear 
your request with the developer.  I'd mark this "working as intended" and not 
clutter the UI and writer with an option to dumb down the GPX for broken 
readers.

Original comment by robertl...@gmail.com on 6 Jul 2013 at 10:47

GoogleCodeExporter commented 9 years ago 
Folks:
From my long experience as a programmer and official beta tester for several 
major software vendors (since 1974) I always have understood that the features 
of programs are client-driven. Of course, there are famous examples of "I did 
this my way" like the new Windows 8 interface that uniquely slowed down the 
sales of new PCs. Bravo Windows 8 UI designers!

Google is also a big offender. Just consider the user interface of Google Earth 
on different operating systems. There is no consistency. Strangely, the best 
Google Earth interface is, unexpectedly,  on Windows while the worst interface 
is on Google's own Android. I also wonder why Google programmers broke the idea 
behind the original UNIX flexibility of the mounting point for storage at /mnt? 
With microSD cards prices falling, Android 4.x doesn't allow installing 
programs on the microSD card creating instead the /mnt/sdcard folder in the 
vendor-installed internal memory. Only rooted devices allow creating symbolic 
links to the external memory folder /mnt/extSdCard and installing programs 
there. Isn't it a great example of "real" geniuses at work?

I would like to respectfully disagree with most of your statements and humbly 
ask for clarification of some statements. I really do not like stuff written by 
folks that seem not to know what they are talking about. I do not need to 
"endear" developers after the first developer (the won't fix guy) did not even 
try to understand my request. Take home message for jshih: "Never treat feature 
requesters as idiots. This may backfire. Try to understand the rationale of the 
request."

1. You wrote: "LOTS of devices record ten samples per second these days." 
Considering the fact that My Tracks is an application written specifically for 
Android devices, please name LOTS of Android devices that are capable to record 
at 10 Hz.

2. What are the GPS chipsets in the "LOTS of devices" that you mentioned? FYI, 
all semi-professional GPS trackers capable of recording at 5 or at 10 HZ use 
the fabulous MTK II chipset. The GPS trackers I know (and own for at least 4 
years – see below) are manufactured by the Taiwanese company QStarz.   For 
professional trackers see: http://racing.qstarz.com/, for semi-professional 
see:  http://www.qstarz.com/Qstarz-index.html. I have the semi-professional 
BT-Q1000eX 10 Hz model: 
http://www.qstarz.com/Products/GPS%20Products/BT-Q1000EX-10HZ-F.html  that 
costs about $180. It replaced my 1 Hz Q-1000X that I purchased in 2009, see my 
Amazon review at: 
http://www.amazon.com/review/R2NWJJGA0F8JYG/ref=cm_cr_dp_title?ie=UTF8&ASIN=B001
44PH1S&nodeID=172282&store=electronics published June 3, 2009. QStarz log is 
written in a variant of the NMEA format and QStarz sports/racing software is 
used to analyze logs. HOWEVER, WHEN YOU EXPORT THE TRACK LOGS CAPTURED BY 
QSTARZ PROFESSIONAL OR SEMI-PROFESSIONAL GPS TRACKING DEVICES TO THE GPX FORMAT 
FILE, NO MILLISECONDS ARE INCLUDED.

3. Please send me affidavits from users who use Android devices to record at a 
frequency higher than 1 Hz. Ask these users to specify in the affidavit the 
Android devices they installed My Tracks on and what software they use to 
analyze the tracks. I will compare the list of their devices with the the 
devices listed by you in the answer to #1.

4. Finally, please include a SWORN statement by the users mentioned in #3 that 
the software they use to analyze the log/track captured at 10 Hz precision will 
only work with the GPX file format. Please list this software. Thanks a lot!

It's really not an issue of the precision of recording of the track; however, 
if no one needs exported GPX files with milliseconds included, please include 
at least an option to limit the precision of exported GPX files to full 
seconds. Christian Pesch, the creator of an excellent utility for GPS tracks 
and for waypoint lists was able to create an option to limit precision of 
exported My Tracks gpx files in one day…

Original comment by njpienia...@gmail.com on 7 Jul 2013 at 3:24

GoogleCodeExporter commented 9 years ago 
As people have mentioned above, the timestamps in the GPX files are completely 
valid ISO 8601/RFC 3339 timestamps (see references below). If software has 
difficulty parsing them, it needs to be fixed. End of story. Standard are 
standards so things work well together. Problems only arise when they aren't 
properly implemented.

Also, this application is open source. If your software can't handle completely 
valid timestamps, feel free to fork the code and make the change yourself. 
Demanding that OSS developers put time and effort into making something 
complaint with your non-standards-compliant application is just rude.

As a side note, it's funny that you mention Christian Pesch. His RouteConverter 
program you're talking about uses the gpsbabel library to parse GPS data, 
which, incidentally, is developed by the guy you just finished demanding sworn 
affidavits from.

Voting for Close/WontFix

References:
[WC3 spec](http://www.w3.org/TR/NOTE-datetime)
[RFC 3339](http://tools.ietf.org/html/rfc3339#section-5.6)
[Microsoft Documentation](http://msdn.microsoft.com/en-us/library/ms190977.aspx)
[Stack 
Overflow](http://stackoverflow.com/questions/522251/whats-the-difference-between
-iso-8601-and-rfc-3339-date-formats)
[Wikipedia](http://en.wikipedia.org/wiki/ISO_8601)
[Relevant XKCD](http://xkcd.com/1179/)

Original comment by pr0ps...@gmail.com on 24 Jul 2013 at 4:28