Modify

Opened 8 months ago

Closed 8 months ago

#16496 closed defect (fixed)

Time bug for geolocalization with nmea file

Reported by: StephaneP Owned by: team
Priority: normal Milestone: 18.08
Component: Core Version:
Keywords: template_report nmea Cc:

Description (last modified by Klumbumbus)

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

Attachments (3)

nmea_time_bug.JPG (17.0 KB) - added by StephaneP 8 months ago.
nmea_time_bug.joz (2.3 KB) - added by StephaneP 8 months ago.
nmea_time_bug.zip (5.4 MB) - added by StephaneP 8 months ago.

Change History (14)

Changed 8 months ago by StephaneP

Attachment: nmea_time_bug.JPG added

Changed 8 months ago by StephaneP

Attachment: nmea_time_bug.joz added

comment:1 Changed 8 months ago by Klumbumbus

Description: modified (diff)

comment:2 Changed 8 months ago by 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

comment:3 Changed 8 months ago by Don-vip

Keywords: nmea added
Milestone: 18.07
Owner: changed from team to StephaneP
Status: newneedinfo

Changed 8 months ago by StephaneP

Attachment: nmea_time_bug.zip added

comment:4 Changed 8 months ago by 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.

Last edited 8 months ago by StephaneP (previous) (diff)

comment:5 Changed 8 months ago by Don-vip

Owner: changed from StephaneP to team
Status: needinfonew

Thanks :)

comment:6 Changed 8 months ago by Don-vip

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

comment:7 Changed 8 months ago by StephaneP

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

comment:8 Changed 8 months ago by Don-vip

Milestone: 18.0718.08

ok thanks

comment:9 Changed 8 months ago by 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.

comment:10 Changed 8 months ago by 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.

comment:11 Changed 8 months ago by Don-vip

Resolution: fixed
Status: newclosed

In 14067/josm:

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.