Images not in proper location

[kalmanbencze]

From @n76 on August 8, 2016 4:37

For example, see track file number 11585 and observe the location of the images being shown as on the freeway when the images themselves are clearly still on a surface street running roughly at a right angle to the freeway. The same, or at least a very similar, positioning error is evident when looking at the images using JOSM with the OSV plugin.

My phone doesn't have the best of GPS receivers, but I've never see it that far off when using any nav app nor when using things like KeypadMapper or OsmTracker.

This may be related to kartaview/android#16 which was about track file number 11498.

Copied from original issue: kartaview/android#19

[kalmanbencze]

Hi n76,
You are right, the track displayed on the site is incorrect, most probably the position wasn't accurate enough and it got matched elsewhere on the map. We'll sort the problem out.
Thanks.

[RafalR]

This may be a problem during processing. Incorrectly tagged images can not be downloaded later in JOSM. In applications everything looked ok (GPS track) but after uploading to the server, some images are not available.

[RafalR]

http://openstreetview.org/details/11556/1 - first image with incorrect position. App running 5 minutes before i start recording, this is not problem with GPS fix.

[iav]

Same for track http://openstreetview.org/details/12223/21

[krl0z-cor3]

Same for track http://openstreetview.org/details/12595/1
my first test track and has error location

[n76]

I don't personally think the position was an issue: While the phone is old and it takes a while for the GPS to lock, the position reports from the GPS system are usually within 10 meters. And other apps running at the same time (e.g. OsmTracker, OsmAnd, Maps.me, SatStat, etc.) all show or record tracks and mapped data pretty closely.

I am wondering if the issue is lack of a ODB2 speed source. The one I picked up doesn't work with OSV so my test runs were using GPS alone for positioning and speed.

[kalmanbencze]

Hi, you are right, this is most probably a matching issue, even without obd, the track should be OK with good GPS.

[Lankaster]

Same for track http://openstreetview.org/details/14400/1
But I was without car.

[alxlion]

Could we manually synchronize with the correct position to fix this problem ?

[kalmanbencze]

Although not available yet, it's on the roadmap to edit these tracks, for now you don't need to worry, the matched track is only for display, the original gps+sensors track remains accurate. The visible track will be shown correctly as soon as the matching algorithm improves.

[n76]

It seems more than the matched track is at issue: I've just done another test run completed about an hour ago. I've deleted the uploaded track because by then end the images were shown miles, literally miles, off from where taken and it seemed to me that no images showing up in JOSM was better than images that far off.

This is with v1.9.5 of the Android app on a phone running Marshmallow. And while making the test run, I started another GPS using app first so when OSV started the GPS was already locked and had a reasonable accuracy (5 m). While making the test the little inset map view showed a reasonable position (lagging a little from time to time but not by much).

So I am pretty sure that there was a good GPS location available for each image but that is certainly not reflected in the position of the image shown after upload.

At this point, I consider this bug a deal killer. I'll continue to monitor this project and when I see updates that might affect this I will try again. But for the moment collecting street images with OSV on my Android phone is simply a non-productive waste of time.

[james2432]

Not sure how this is a deal breaker if images in JOSM are accurate(where it counts)

[n76]

Images don't seem to be accurate in JOSM which is the problem.

[n76]

Okay, went out for another test drive and the track is 14800

Looking at the images in JOSM, the order and placement appear to be the same as at http://www.openstreetview.org/details/14800/40

In this case I drove the length of a road and made a turn around at the end. You can see the turn around in images 75 through 85 but the website and JOSM would have you believe that it occurred in images 36 through 39.

It is interesting that it only shows three images for the turn around on the track but it actually took 10.

Also interesting that the track continues far past the last image uploaded. And the track ends prior to where I actually turned off recording. That could be the result of a bungled upload, see screen shot below.

It seems like it it trying to space the images along the track rather than place them at the GPS location when the image was taken.

Since the locations shown in JOSM seem to match that on the website edit/preview, they are worse than useless for editing. I will re-verify the JOSM locations in about 12 to 14 hours to see if your post processing somehow corrects. But it seems to me that leaving them in the system for others to make map updates off of would be harmful.

The weirdness on the upload is shown in this screen shot.

[kalmanbencze]

Originally you had 149 pictures on this track,on the website there are 98 images. there is a bug which is known to us that the pictures are shifted from their position if one ro more of the mp4 files are missing. this will be fixed aproximately on monday.

Also the shutter animation white splash is done after encoding, not in the moment of the picture's creation, so the 10 flashes what you've seen were pictures taken at an earlier position being encoded from the frame queue. this will also be modified to reflect the moment of the pictures creation not the finishing of the encoding process.

The biggest issue is the shifting of the pictures, and it is our highest priority.

[n76]

If this is a known bug and a fix is on the way then I'll delete the track to avoid confusing people. I'll wait until I see a new version of the app appear and try again.

[n76]

I've still having this issue. . . I thought that once the BT ODBII issue was resolved this might fix itself but testing today and still have the same problem.

I deleted my test track to avoid issues with mappers thinking the images were in the correct location and the map was wrong.

[kalmanbencze]

@n76 for next time please don't delete the tracks, so that we can debug the issue. You don't have to worry about it reaching Osm thus degrading it, because our processing algorithm treats problematic tracks differently and also we can make exceptions.

If you leave the source data online, we have the base data, which probably is correct, so we can correctly process it after debugging the issue.

[iav]

@kalmanbencze http://openstreetview.org/details/12223/21 same

[kalmanbencze]

@iav Yess, thanks for this track. there has been 2 bugs happening here, I have just confirmed it. one is long fixed, the second is fixed in the 1.9.10 version of the app, but the fix on the server has not been deployed yet (need to reprocess older recordings).

You can leave these tracks on your account, no need to delete it. basically it's a meta data (which contains gyro, accelerometer, gps, compass, data) format bug, that's why it can be fixed with the reprocessing of the track.

[abienvenu]

Same problem here, using 1.9.10 version of the app. This image http://openstreetview.com/details/27139/328 is taken at the moment I leave D777. But for the website and JOSM, it is located 500m further in "Rue Jean-Marie Lacire".
If this is relevant, I have poor internet connection, and the upload has been paused/resumed several times. I have a copy of the files before the upload began, in case you need it.

[kalmanbencze]

@abienvenu Yeah its really annoying, we know about this issue. This is a display-only bug on the website. The data is correct no need to upload it again, the locations and pictures are matched together correctly, but the way the website displays it is wrong. There is already a script written which fixes it but it hadn't been fully deployed yet. I'll keep pushing.
Thanks.

[n76]

@kalmanbencze I've uploaded yet another test. And despite reading that "this is a display-only but on the website", I see the photos misplaced in JOSM too and that is where it really matters. For example, the image at http://openstreetview.org/details/27186/12 is shown as being after passing under the motorway when it is clearly before.

In this case the GPX track actually seems to start and stop at the correct place (earlier tests had the track continuing on after I stopped recording photos). However the photos taken represent only about the first half of the track. There was no error indication on upload, so I don't know what happened to the other photos that must have been taken.

I did not have the OSV app clear the data on the phone, so there might still be something there that I could pull off for you.

[kalmanbencze]

@n76 Where does the data viewed in JOSM originate from?

[n76]

The OSV layer from the OSV plugin.

[kalmanbencze]

@n76 Unfortunately the JOSM plugin uses the same OSV api as the website, thus displaying the wrong data. I made sure that what I tell you is not BS. Don't worry this is just an API issue through wich you obtain the data for: display on the website, JOSM, apps, etc.

[n76]

@kalmanbencze So if a "armchair mapper" comes along, sees there are OSV images in the area and decides to "correct" the OSM data based on the images there is nothing to warn him/her of the misalignment. Sounds like this is a pretty serious issue and one ought to delete (or hide) tracks where the images are misaligned until it is fixed.

[martijnv-telenav]

I think this is a duplicate of #38 -- if so can we close one of them @kalmanbencze @bogdans-telenav @mirunac-telenav ?