Time bug for geolocalization with nmea file

[StephaneP]

What steps will reproduce the problem?

1. Use a nmea file to geolocalize some images
2. Apply a time offset with a subsecond value, like 0.5

What happens instead?

The geolocalization is wrong. The subsecond value gives strange coordinates, it is not distributed correctly between 2 seconds (see the screenshot)

Please provide any additional information below. Attach a screenshot if possible.

I use nmea files to geolocalize images since a long time and I encountered this problem only with my new Gnss receiver (Ublox M8T) sets to track GPS, Galileo and Beidou satellites, with a 5hz frequency.
If I convert my nmea file to gpx with another software, I can use it in Josm and everything is Ok

The geolocalization is still Ok with my old nmea files (GPS + Glonass).

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-07-12 23:02:02 +0200 (Thu, 12 Jul 2018)
Revision:14027
Build-Date:2018-07-13 02:02:02
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (14027 en) Windows 10 64-Bit
OS Build number: Windows 10 Pro 1803 (17134)
Memory Usage: 384 MB / 6144 MB (64 MB allocated, but free)
Java version: 9.0.4+11, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1200
Maximum Screen Size: 1920x1200
Dataset consistency test: No problems found

Plugins:
+ DirectUpload (34389)
+ ImportImagePlugin (34389)
+ Mapillary (v1.5.14+post13733)
+ OpeningHoursEditor (34389)
+ PicLayer (34389)
+ SimplifyArea (34109)
+ apache-commons (34389)
+ apache-http (34389)
+ areaselector (1529684353)
+ austriaaddresshelper (1525848529)
+ buildings_tools (34212)
+ cadastre-fr (34389)
+ changeset-viewer (15)
+ continuosDownload (1530471163)
+ contourmerge (1033)
+ download_along (34389)
+ editgpx (34206)
+ ejml (34389)
+ geojson (84)
+ geotools (34125)
+ jts (34206)
+ livegps (34206)
+ log4j (34038)
+ merge-overlap (34389)
+ opendata (34389)
+ photo_geotagging (34206)
+ photoadjust (34389)
+ reverter (34271)
+ tag2link (34109)
+ tageditor (34109)
+ turnlanes-tagging (263)
+ turnrestrictions (34129)
+ undelete (34274)
+ utilsplugin2 (34389)

Tagging presets:
+ E:\OsmIndoor\Dossiers Persos\Antoine\Train_Station-preset.xml
+ E:\OsmIndoor\200 gares\200gares-preset.xml

Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/MaxspeedIcons&zip=1
- https://raw.githubusercontent.com/species/josm-preset-traffic_sign_direction/master/direction.mapcss

Last errors/warnings:
- E: Failed to locate image 'presets/toilet.png'
- W: [NODE, CLOSEDWAY] Toilets: Could not get presets icon presets/toilet.png
- W: Cannot lock cache directory. Will not use disk cache
- W: No configuration settings found.  Using hardcoded default values for all pools.
- W: Warning: Failed to scan file 'site-svn.openstreetmap.org-_applications_editors_josm_plugins_opendata_modules.txt' for module information. Skipping.
- W: Warning: Failed to scan file 'fr.datagouvfr.jar' for module information. Skipping.
- W: Cannot start IPv4 remotecontrol server on port 8111: Address already in use: NET_Bind
- W: Cannot start IPv6 remotecontrol server on port 8111: Address already in use: NET_Bind
- W: Cannot start IPv4 remotecontrol https server on port 8112: Address already in use: NET_Bind
- W: Cannot start IPv6 remotecontrol https server on port 8112: Address already in use: NET_Bind

[Don-vip]

Can you please attach these three files? They're not included in the session file:

E:/sotm_journey/voiture/2018-05-30_15H54mn35s/btnmeatrack_2018-05-30_15-58-00_split.gpx
E:\sotm_journey\voiture\2018-05-30_15H54mn35s\2018-05-30_18H39mn33s-Cam_avant-Y0033981.JPG
E:/sotm_journey/voiture/2018-05-30_15H54mn35s/btnmeatrack_2018-05-30_15-58-00_split.nmea

[StephaneP]

Wooooopsss! Here they are!

I thought that it could be related with the nmea logger android app i've been tinkering, but as I could convert the nmea to gpx without any warning, I think the data are correct.
​https://github.com/Stefal/bluegnss4droid

BTW: This is a case where #14103 could have helped me to find where the bug is.

[Don-vip]

Thanks :)

[Don-vip]

#14103 is fixed. Can you please make additional tests tomorrow to see if you understand where the problem comes from?

[StephaneP]

Sure, I'll make some tests in the next days.

[Don-vip]

ok thanks

[StephaneP]

Ok, I think I know where the problem is.

In my old nmea files, the time string is something like:
143847.800 for 14h 38mn 47.8s

In my new nmea the same timestamp would be stored as
143847.80

When I convert these nmea files to a data layer, the first one give correct values, but for the second one I get this:
143847.80 -> 14:38:47.08Z

Josm use SimpleDateFormat to convert the value, which use SSS as a millisecond value.

The bug seems to be a wrong subsecond to millisecond value.

I could write the python code to bugfix this, but I can't do it in Java.

[Don-vip]

Thanks! NMEA 0183 defines times as follows:

Field Type: Time
Symbol: hhmmss.ss
Definition: Fixed/Variable length field:
hoursminutesseconds.decimal - 2 fixed digits of hours, 2 fixed digits of minutes, 2 fixed digits of seconds and a variable number of digits for decimal-fraction of seconds. Leading zeros always included for hours, minutes and seconds to maintain fixed length. The decimal point and associated decimal-fraction are optional if full resolution is not required.

[Don-vip]

In 14067/josm:

fix #16496 - fix invalid parsing of NMEA time (decimal-fraction of seconds)