Handle the case where the first track point does not have a time
without segfaulting. (issue #316, #192)
Don't throw an exception on a negative time change. It isn't the end
of the world, just put a warning in the log and move on (without
updating the speed, since we really don't have a clue now). (issue #186)
Reset the element content even when we aren't in a track element. GPX
can have elements outside of the <trk>. This was causing problems
such as content in a <metadata> element before the <trk> being
included in the track name.
There could still be weirdness in the stats if some of the points have
a time element while others don't. Hard to say what the best course
of action is in that case though, and may involve changes to the
TripStatisticsBuilder.
Instead of producing the comparison strings in the tester just as they
are produced in the tested code, use string literals, thus actually
testing that the formatting code is working as expected.
Instead of producing the comparison strings in the tester just as they
are produced in the tested code, use string literals, thus actually
testing that the formatting code is working as expected.
The only thing not allowed in 1.1 currently used is the track color
tag, which is moved into the "<extensions>" tag to make it conform to
the 1.1 schema.
The only thing not allowed in 1.1 currently used is the track color
tag, which is moved into the "<extensions>" tag to make it conform to
the 1.1 schema.
The only thing not allowed in 1.1 currently used is the track color
tag, which is moved into the "<extensions>" tag to make it conform to
the 1.1 schema.
The only thing not allowed in 1.1 currently used is the track color
tag, which is moved into the "<extensions>" tag to make it conform to
the 1.1 schema.
The GPX schema requires waypoints to come before the track.
Waypoints are not currently used in TCX export, so there are no
changes there.
In KML files, both tracks and waypoints are "Placemark"s, so it
doesn't matter what order they come in there.
This does change the order they appear in CSV files, which could
potentially invalidate some assumptions made in downstream tools.
The GPX schema requires waypoints to come before the track.
Waypoints are not currently used in TCX export, so there are no
changes there.
In KML files, both tracks and waypoints are "Placemark"s, so it
doesn't matter what order they come in there.
This does change the order they appear in CSV files, which could
potentially invalidate some assumptions made in downstream tools.
The GPX schema requires waypoints to come before the track.
Waypoints are not currently used in TCX export, so there are no
changes there.
In KML files, both tracks and waypoints are "Placemark"s, so it
doesn't matter what order they come in there.
This does change the order they appear in CSV files, which could
potentially invalidate some assumptions made in downstream tools.
The GPX schema requires waypoints to come before the track.
Waypoints are not currently used in TCX export, so there are no
changes there.
In KML files, both tracks and waypoints are "Placemark"s, so it
doesn't matter what order they come in there.
This does change the order they appear in CSV files, which could
potentially invalidate some assumptions made in downstream tools.
Addresses issue #299 and ensures Latitude and Longitude are formatted
correctly as well.
Also orders the elements in the waypoint correctly according to the
schema: <ele> and <time> need to come before <name> and <desc>.
Addresses issue #299 and ensures Latitude and Longitude are formatted
correctly as well.
Also orders the elements in the waypoint correctly according to the
schema: <ele> and <time> need to come before <name> and <desc>.
Addresses issue #299 and ensures Latitude and Longitude are formatted
correctly as well.
Also orders the elements in the waypoint correctly according to the
schema: <ele> and <time> need to come before <name> and <desc>.
Rodrigo Damazio