Leaving custom notes location have random location error

[mnalis]

IOW, "Notes are left on quite different locations then indicated by Note marker on the screen"

When one does long-press on screen, there is a possibility to leave an OSM note (and adjust its exact location on the map). However, OSM Note does not happen at that indicated location, but with some random drift of dozens up to hundred of meters. That makes it pretty problematic to be useful.

I have a feeling that this positional error might have been happening less before (I might have said not at all, but now when I think about it I recall some situations where I assumed I have just made an error, but never went to investigate), but I could be wrong (maybe I just didn't try to use it that much, or phone model / language / Android version makes a difference).

How to Reproduce
Long press on the screen, adjust note if needed (or not), and leave note. Firstly I assumed I just made an error when leaving note, but it become obvious the positioning error is happening way to regularly for that. Although sometimes there is no noticable error at all (eg. https://www.openstreetmap.org/note/2850474, https://www.openstreetmap.org/note/2850551, https://www.openstreetmap.org/note/2850527 all point to the pretty much the same point). I could not determine why is there sometimes no error, when there is smaller error, and when there is a bigger positional error.

Here are for example 3 notes made with same phone, all 3 left at the same location (path 3-way split)

• https://www.openstreetmap.org/note/2850480 - left in OsmAnd, with perfect precision.
• https://www.openstreetmap.org/note/2850556 - left with SC 33.0, drifts some 20m into the sea, even if screen shows it exactly at crossing
• https://www.openstreetmap.org/note/2850533 - left with SC 34.1, drifts some 42m into the sea, even if screen shows it exactly at crossing

So I've taken a screenshot just before leaving the Notes to be sure it's not me:

Even if there was GPS reception error, it should not matter, as notes are user-draggable and positioned at exact map location at maximum zoom in. Notes should be left at position indicated by the marker, right?

(there are more examples, I can provide them with screenshots for most of them if needed)

Versions affected
Android 6.0.1 (MIUI 10.2)

[smichel17]

I think I've got it, give me a moment to test.

[smichel17]

Confirmed, I think. It happens when you are following your gps position before the note. Here:

StreetComplete/app/src/main/java/de/westnordost/streetcomplete/map/MainFragment.kt

Lines 467 to 476 in fe895b7

	override fun onCreatedNote(note: String, imagePaths: List<String>, screenPosition: Point) {
	closeBottomSheet()
	val mapFragment = mapFragment ?: return
	val mapView = mapFragment.view ?: return
	val mapPosition = mapView.getLocationInWindow().toPointF()
	val notePosition = PointF(screenPosition)
	notePosition.offset(-mapPosition.x, -mapPosition.y)
	val position = mapFragment.getPositionAt(notePosition) ?: throw NullPointerException()

• Earlier, when you long-press on the map and click "create note", we stop the map from following your position.
• The function above gets called when you press OK to submit the note.
• screenPosition in the arguments is the X and Y coordinates of the note pointer on your device's screen.
• On the last line quoted, we ask Tangram (though a couple layers of wrappers) for the Lat/Lon of those coordinates on the screen.
• ❗ On the first line of the function, closeBottomSheet() resumes following your location! This scrolls the map back to where you are, and so the screen coordinates are pointing at the wrong place on the map.
  • I imagine some of the wackier offsets would happen if you're using compass mode.

[timothywashere]

I thought I was going crazy with my notes all over the place.
Is the workaround for this issue to stand exactly still whilst making a note?

[smichel17]

The workaround is to disable "follow mode" (e.g. by scrolling the map) before creating a note. Or to create a note only directly at your location, but that's less practical :)

[westnordost]

Thank you, @smichel17 ! I moved the line below that.

[mnalis]

Hope it will work! Although now closeBottomSheet() will never be called if mapFragment or mapView is null (if I correctly parse what the code does).

I don't know if that situation ever happens, but since it was handled in code before, I'd thought I'd mention it (if nothing else, a chance for me to learn a little)

[westnordost]

mapView or mapFragment may be null if the fragment has already been detached (has been destroyed). Then, there is no bottom sheet to close anyway anymore.