GPX note (with GPX track and pictures) ended up at unreleated location some 200m off

[mnalis]

this is the note 4218472 which experienced the bug. Note location ended up at incorrect location, some 200-300m to the North (where I was passing previously; maybe a minute ago before starting recording the gpx track)

How to Reproduce
Not sure how reproducible it is. To the best of my recollection, I:

• long pressed on the current position on the map (about the start of gpx track, i.e. northern point of way 1277944050 which I created later) and selected new track recording
• then I continued to move some 70m to the south (to the end of that way 1277944050)
• while moving, I was using long-press and Add POI to add several benches along the way (and answer their quests that popped up)
• at the end of track, i chose to stop recording GPX track, and added two pictures (one looking forward and one looking backward).

Expected Behavior

I expected that the note would be created at the location at the end of GPX track (i.e. my current location at the time of stopping GPX recording, i.e. southernmost point of the way 1277944050) , like it did in the past.

However, It ended up some 200m north of start of the gpx recording (so about 275m from the end of the gpx recording), at the position I don't think I was panning the map to. I might have been switching between OsmAnd and SCEE though (I do that all the time).

Does it happen in normal StreetComplete?

No idea. This is the first and only time I've noticed it happening in recent years, before 57.x series.

(well, I actually did have wrong notes locations several years back in old 34.x series in streetcomplete#3312 which were happening on daily basis, but the cause of that was found and solved back then and never did appear again until now)

However, I note that there was recent vanilla StreetComplete report about wrong Note location in streetcomplete#5581 - at the time it was suspected it might've been due to new user error, but now sound too suspicious.

Versions affected

SCEE 57.2 on Android 14 (OneUI 6.1), Samsung Galaxy S23+

[mnalis]

While checking dozen or so other notes I opened in that session, they all look positioned correctly (some with pictures, some without; but none with track recording) until I found this note 4218471, made just prior to problematic one note 4218472 !

You'll see that both notes have exactly the same (incorrect by 200m+!) coordinates 45.8292443, 15.9048815 to the last decimal point; which should be hard to accomplish by just long-pressing on the map!

So my updated recollection:

• I was at the northern part of (then yet non-existent) way 1277944050
• I long pressed on the screen on my location (which is NOT the location where note ended up!) to start GPX recording
• after I few seconds I remembered that I actually wanted to take picture of start of the way too
• so I stopped GPX recording and cancelled it (maybe had to undo it? I don't recall)
• then (without having moved or moved just a few meters) I long-pressed again, and made a regular note with picture of the start (northernmost part of the way 1277944050)
• that was recorded as https://www.openstreetmap.org/note/4218471, with correct picture and description, but at the wrong location already (but I didn't notice that at the time)
• then I proceeded to record regular GPX track as outlined in original report above

[westnordost]

I expected that the note would be created at the location at the end of GPX track

No, the note is created at the crosshair position.

[mnalis]

No, the note is created at the crosshair position.

Correct, but I was scrolling the map (and adding amenity=bench POIs) as I went from North to the South position of way 1277944050, there is no reason why that red note marker would not be at the end (southernmost) position, or at least somewhere between starting (northernmost) position and ending (southernmost) position.

Most definitely it should not have ended up 200m+ north of northernmost position.

So (as also suspected in linked issue) perhaps it might be possible that StreetComplete/SCEE actually somehow automagically moved the marker position when the user did not ask it to do so. (it would be hard to notice, as the user usually would not expect that the Note marker would move after they placed it and before they finished typing text).

There is of course the possibility the I somehow moved it by myself willingly and then promptly forgot about it; but I do open notes quite often, and it did not seem to happen even once in several years (or I didn't notice), and now it happened about the same version as other person reported similar issue. Might be coincidence, but might be something more.

I will try to do more experiments to try to reproduce, but wanted to record my recollection while it was still fresh in my memory. Also, maybe something in my description might help @sjvudp remember "oh, I was doing somewhat similar when my issue happened".

[mnalis]

Another way the note gets created at wrong location if one has tilt enabled (i.e. not in "2D birdseye" mode). Note in the video at 00:00:01 I pressed to create exactly at position of the GPS (blue dot), but the map moved automatically to display form and marked ended noticeably below the selected position:

small_Screen_Recording_20240512_133930_SCEE.mp4

[sjvudp]

I don't know what's causing occasional severe mis-positioning of notes, but reading the remarks about rotation rings a bell for me:
Usually I have the map rotation turned on so that top is direction of movement. Occasionally I rotate the map manually with the touch gesture.
Quire recently I had the effect that StreetComplete claimed the GPS position would be elsewhere (not where I was standing).
As I had OsmAnd running in the background and recording the route, I switched to OsmAnd, and there the position was correct. Switching back to StreetComplete eventually showed the correct position again.
Before presenting the details, I think the issue is either calculation of map transformations relative to the (GPS) position, or the reading of the position (like misreading or dirty-reading it).

The first screenshot shows the wrong position (note the GPS indicator and "circle of confusion size"); I think I wrote a note regarding that small bridge across the river that did not exist any more (meaning: the hint position was at some distance from the current position):

The second screenshot shows the correct position (where I had been standing actually). As the Time shown is "UTC+200", the corresponding trackpoints from OsmAnd are (no positions recorded in between):

      <trkpt lat="49.184025" lon="12.3430983">
        <ele>349.4</ele>
        <time>2024-05-12T15:03:31Z</time>
        <hdop>2.3</hdop>
        <extensions>
          <osmand:speed>2.4</osmand:speed>
        </extensions>
      </trkpt>
      <trkpt lat="49.184115" lon="12.34336">
        <ele>354.8</ele>
        <time>2024-05-12T15:07:41Z</time>
        <hdop>2.1</hdop>
        <extensions>
          <osmand:speed>1.8</osmand:speed>
        </extensions>
      </trkpt>

The distance between both positions is about 100 meters (see https://www.openstreetmap.org/search?query=49.184115%2012.34336#map=17/49.18477/12.34513); the actual walking distance is more like 1km. Quite unlikely to make it in less than 2 minutes.

[Helium314]

The first screenshot shows the wrong position (note the GPS indicator and "circle of confusion size")

The large accuracy of the left screenshot hints that the location is coming from some GSM or LTE radio cell. SC uses inaccurate locations if no better recent location is available, see the related code if you're interested.
And I would argue it might not be wrong, considering the large accuracy circle.

And btw if we need to duplicate the issue on SCEE tracker already, then it should really be about SCEE. The star counter on the screenshots indicates you're using StreetCompete.

[sjvudp]

The star counter on the screenshots indicates you're using StreetCompete.

Yes, sorry if I posted to the wrong repository.