Modify

Opened 8 years ago

Closed 8 years ago

#12485 closed defect (fixed)

Wrong GPX Correlation

Reported by: StephaneP Owned by: team
Priority: normal Milestone: 16.02
Component: Core Version:
Keywords: gpx; correlation; picture; template_report; regression Cc:

Description

What steps will reproduce the problem?

  1. Load the attached gpx
  2. Load the attached picture
  3. Ignore the integrated location and try to correlate the picture's position with the gpx

What is the expected result?

You can move the picture on the gpx with the offset.

What happens instead?

The picture's location moves back and forth.

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

Josm seems to read the gpx incorrectly, as the speed indicated on the picture (top left) is wrong.
Warning : The original gnns record is a 5hz nmea.

Other Josm release
tested 8491 OK
tested 9329 NOK

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-02-03 00:53:09 +0100 (Wed, 03 Feb 2016)
Build-Date:2016-02-03 02:32:49
Revision:9720
Relative:URL: ^/trunk

Identification: JOSM/1.5 (9720 fr) Windows 8.1 64-Bit
Memory Usage: 1145 MB / 5461 MB (170 MB allocated, but free)
Java version: 1.8.0_71-b15, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Dataset consistency test: No problems found

Plugins:
- DirectUpload (31912)
- ImportImagePlugin (31772)
- Mapillary (32040)
- OpeningHoursEditor (31772)
- PicLayer (31895)
- SimplifyArea (31895)
- apache-commons (31895)
- apache-http (31895)
- cadastre-fr (31772)
- continuosDownload (1446070193)
- download_along (31772)
- editgpx (31772)
- ejml (31895)
- geotools (31895)
- jts (31772)
- livegps (31772)
- log4j (31895)
- opendata (31937)
- photo_geotagging (31895)
- photoadjust (32016)
- reverter (32005)
- tag2link (31910)
- todo (29154)
- turnrestrictions (31895)
- utilsplugin2 (32018)

Attachments (5)

gpx_test.gpx (1.8 MB ) - added by StephaneP 8 years ago.
gpx
2016-01-25_08-20-54_Xiaomi_YI-YDXJ0546.jpg (1.3 MB ) - added by StephaneP 8 years ago.
gpx_view.png (17.8 KB ) - added by StephaneP 8 years ago.
btnmeatrack_2016-01-25_06-04-59.zip (1.6 MB ) - added by StephaneP 8 years ago.
full_nmea_file
2016-02-04-222156_2400x1920_scrot.png (182.0 KB ) - added by simon04 8 years ago.

Change History (20)

by StephaneP, 8 years ago

Attachment: gpx_test.gpx added

gpx

comment:1 by simon04, 8 years ago

In 9726/josm:

see #12485 - Wrong GPX Correlation, add unit test

Regression from r9383, confusion between s and ms.

comment:2 by Don-vip, 8 years ago

Keywords: regression added
Milestone: 16.02

something remains to do?

comment:3 by simon04, 8 years ago

StephaneP, would you please confirm that r9726 fixed the issue/s.

comment:4 by anonymous, 8 years ago

Tested with r9733, and no, it doesn't work correctly.

by StephaneP, 8 years ago

Attachment: gpx_view.png added

comment:5 by StephaneP, 8 years ago

I don't know if it has something related to this bug, but the older release didn't draw the gpx like r9733. Now, there are some strange low speed then high speed segments :


btw : I wrote it was NOK with r9329. I was wrong.

comment:6 by simon04, 8 years ago

What happened to attachment:gpx_test.gpx – the waypoints are in a non-chronological order?

        <time>2016-01-25T06:47:50.600Z</time>
        <time>2016-01-25T06:47:50.200Z</time>
        <time>2016-01-25T06:47:50Z</time>
        <time>2016-01-25T06:47:50.600Z</time>
        <time>2016-01-25T06:47:52.200Z</time>
        <time>2016-01-25T06:47:51.200Z</time>
        <time>2016-01-25T06:47:50.800Z</time>
        <time>2016-01-25T06:47:51.600Z</time>
        <time>2016-01-25T06:47:52.200Z</time>
        <time>2016-01-25T06:47:52.400Z</time>
        <time>2016-01-25T06:47:51.800Z</time>
        <time>2016-01-25T06:47:52.600Z</time>
        <time>2016-01-25T06:47:53.600Z</time>
        <time>2016-01-25T06:47:53.200Z</time>
        <time>2016-01-25T06:47:53.600Z</time>
        <time>2016-01-25T06:47:53.200Z</time>
        <time>2016-01-25T06:47:52.400Z</time>
        <time>2016-01-25T06:47:53.600Z</time>
        <time>2016-01-25T06:47:53.200Z</time>
        <time>2016-01-25T06:47:53.800Z</time>
        <time>2016-01-25T06:47:53.600Z</time>
        <time>2016-01-25T06:47:54.200Z</time>
        <time>2016-01-25T06:47:55.600Z</time>
        <time>2016-01-25T06:47:55.200Z</time>
        <time>2016-01-25T06:47:55Z</time>
        <time>2016-01-25T06:47:54Z</time>

in reply to:  6 ; comment:7 by StephaneP, 8 years ago

Replying to simon04:

What happened to attachment:gpx_test.gpx – the waypoints are in a non-chronological order?

I don't know. I opened the nmea file in Josm, converted it to a layer, cut it, then converted it to gpx.

I use directly the nmea file to try to correlate the pictures. I can upload it if you want.

in reply to:  7 ; comment:8 by simon04, 8 years ago

Replying to StephaneP:

I can upload it if you want.

Yes, please!

by StephaneP, 8 years ago

full_nmea_file

in reply to:  8 comment:9 by StephaneP, 8 years ago

Replying to simon04:

Yes, please!

Done
btnmeatrack_2016-01-25_06-04-59.zip​

comment:10 by simon04, 8 years ago

In 9739/josm:

see #12485 - Fix parsing of sub-seconds

Sometimes there are really strange bugs …

comment:11 by simon04, 8 years ago

In 9740/josm:

see #12485 - Add unit test for nmea reading

comment:12 by simon04, 8 years ago

r9739 should fix the non-chronological order issue. A new build is available in ≈20 minutes from https://josm.openstreetmap.de/jenkins/job/JOSM/889/jdk=JDK7/

Good that you're tracking with 5Hz, otherwise we this bug would not have been found in ages :)

attachment:2016-02-04-222156_2400x1920_scrot.png​ shows that the speed colouring should be fixed.

comment:13 by StephaneP, 8 years ago

Thank you ! I will test r9739 tomorrow.

Yes, with #12486 #12485 #10235 I'm in the millisecond world :)

comment:14 by StephaneP, 8 years ago

tested with r9742, and the bug isn't here anymore. Thank you Simon !

comment:15 by StephaneP, 8 years ago

Resolution: fixed
Status: newclosed

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. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.