Bugs in version 3.2.1 - UTM & track in GPX format
5 posters
Bugs in version 3.2.1 - UTM & track in GPX format
UTM
If I set the coordinate unit to be UTM, the format of the coordinates is not clear. For example, the UTM coordinates of Sydney Opera House should be "56H 334878 6252232" (zone number - preferably with grid zone, easting, northing), but the coordinates shown on the map are "56<>334878/6252232" - there is no indication of northern or southern hemisphere. If possible, I hope that in the next version I can also choose MGRS format (e.g. 56H LH 34878 52232).
Track log in GPX format
I use the GPX format of the track log. I noticed that the time recorded in the track log just come from the phone and so the time zone is not taken into account in the track log. When I export the GPX format of the track log to other software, the time recorded is several hours behind the actual time. I suggest that the track log should record the time come from the satellites so that the time recorded is surely correct.
Despite the above bugs, OruxMaps is very excellent. Keep it on!
If I set the coordinate unit to be UTM, the format of the coordinates is not clear. For example, the UTM coordinates of Sydney Opera House should be "56H 334878 6252232" (zone number - preferably with grid zone, easting, northing), but the coordinates shown on the map are "56<>334878/6252232" - there is no indication of northern or southern hemisphere. If possible, I hope that in the next version I can also choose MGRS format (e.g. 56H LH 34878 52232).
Track log in GPX format
I use the GPX format of the track log. I noticed that the time recorded in the track log just come from the phone and so the time zone is not taken into account in the track log. When I export the GPX format of the track log to other software, the time recorded is several hours behind the actual time. I suggest that the track log should record the time come from the satellites so that the time recorded is surely correct.
Despite the above bugs, OruxMaps is very excellent. Keep it on!
mkleung- Cantidad de envíos : 6
Fecha de inscripción : 2010-11-03
Re: Bugs in version 3.2.1 - UTM & track in GPX format
mkleung wrote:UTM
If I set the coordinate unit to be UTM, the format of the coordinates is not clear. For example, the UTM coordinates of Sydney Opera House should be "56H 334878 6252232" (zone number - preferably with grid zone, easting, northing), but the coordinates shown on the map are "56<>334878/6252232" - there is no indication of northern or southern hemisphere. If possible, I hope that in the next version I can also choose MGRS format (e.g. 56H LH 34878 52232).
Track log in GPX format
I use the GPX format of the track log. I noticed that the time recorded in the track log just come from the phone and so the time zone is not taken into account in the track log. When I export the GPX format of the track log to other software, the time recorded is several hours behind the actual time. I suggest that the track log should record the time come from the satellites so that the time recorded is surely correct.
Despite the above bugs, OruxMaps is very excellent. Keep it on!
Hi;
you are right;
Perhaps you can test the last beta-->https://oruxmaps.forumotion.com/general-f8/beta-for-test-325beta-t583.htm
orux
orux- Cantidad de envíos : 3946
Fecha de inscripción : 2009-07-06
Re: Bugs in version 3.2.1 - UTM & track in GPX format
mkleung wrote:
Track log in GPX format
I use the GPX format of the track log. I noticed that the time recorded in the track log just come from the phone and so the time zone is not taken into account in the track log. When I export the GPX format of the track log to other software, the time recorded is several hours behind the actual time. I suggest that the track log should record the time come from the satellites so that the time recorded is surely correct.
Ah! The missing timezone in the tracklogs is the reason why I had to switch off my timezone and manually set UTC+00 in my geotagging program when I tried to geotag my photos correctly with the GPX files from OruxMaps. I hope this will be fixed in the next release.
cygnus- Cantidad de envíos : 13
Fecha de inscripción : 2010-09-08
Re: Bugs in version 3.2.1 - UTM & track in GPX format
In view of solving the two problems, the Beta version 3.2.5 seems OK. But the coordinates shown on Waypoint Information (displayed when I tap a waypoint on the map) is still in the wrong format.orux wrote:
Hi;
you are right;
Perhaps you can test the last beta-->https://oruxmaps.forumotion.com/general-f8/beta-for-test-325beta-t583.htm
orux
mkleung- Cantidad de envíos : 6
Fecha de inscripción : 2010-11-03
Re: Bugs in version 3.2.1 - UTM & track in GPX format
May i know what unit for measurement did you set for your coordinates to show proper time? I'm also getting the timezone issue and still getting them on v3.2.7. Kindly let me know of any solutions to this. Thank you!
airzoink- Cantidad de envíos : 3
Fecha de inscripción : 2010-12-21
Re: Bugs in version 3.2.1 - UTM & track in GPX format
I don't think the coordinate setting affects the time. I don't have your problem with my phone. I'm using Android 2.1.airzoink wrote:May i know what unit for measurement did you set for your coordinates to show proper time? I'm also getting the timezone issue and still getting them on v3.2.7. Kindly let me know of any solutions to this. Thank you!
mkleung- Cantidad de envíos : 6
Fecha de inscripción : 2010-11-03
Date handling in GPX
I agree that a datetime value in GPX time in the 2011-01-01T23:45:35Z format while containing the local time was erroneous. However, for most uses I believe the local time value is more useful (whether you use the GPX to geotag your photos or for uploading the track to EveryTrail etc.). Therefore I think it would be better to export the datetime with the local time plus the timezone offset, e.g. 2011-01-01T23:45:35+02:00.
caroig- Cantidad de envíos : 4
Fecha de inscripción : 2010-06-06
Localización : Prague, Czech Republic
RE: Date handling in GPX
caroig wrote:I agree that a datetime value in GPX time in the 2011-01-01T23:45:35Z format while containing the local time was erroneous. However, for most uses I believe the local time value is more useful (whether you use the GPX to geotag your photos or for uploading the track to EveryTrail etc.). Therefore I think it would be better to export the datetime with the local time plus the timezone offset, e.g. 2011-01-01T23:45:35+02:00.
After some investigation I take this back. No piece of software seems to use the longer datetime format with timezone. After all, you can always calculate the local time from the coordinates.
caroig- Cantidad de envíos : 4
Fecha de inscripción : 2010-06-06
Localización : Prague, Czech Republic
Similar topics
» best track format kml or gpx
» bugs in v5.5.0
» version 3.5.7 fuerza cierre al grabar track
» Track Type of recorded tracks can not be changed anymore in the Track Database
» 2 small bugs (or not)
» bugs in v5.5.0
» version 3.5.7 fuerza cierre al grabar track
» Track Type of recorded tracks can not be changed anymore in the Track Database
» 2 small bugs (or not)
Permissions in this forum:
You cannot reply to topics in this forum
|
|