Share position moves the map to a different position than the position shared.

[lokejul]

Vespucci Version

11.1.0

Download source

Google Play Store

Device (Manufacturer and Model)

ASUS ZC600KL Version C

Android Version

Stock Android 7.1.1

Behaviour/Symptoms

When using "Share Position", Vespucci does not display the correct position for the map. The map is shown with an offset, varying at times up to several hundred metres, to the correct position. The offset seems to depend on the latitude and longitude of the original position that is being shared.

This behaviour occurs whether the originator of the "Share position" action is Vespucci app or some other app, such as OSMand.

Expected Behaviour

Open OSMand. Move the slippy map to any desired location. Use OSMand to "Share" "geo:", then select "Open with Vespucci". The map shown in Vespucci should be centered around the same location as OSMand.

Open Vespucci. Move the slippy map to any desired location. Use Vespucci to "Share position", then select "Open with Vespucci". The map displayed by Vespucci AFTER the "Share position" action should be the SAME as displayed by Vespucci BEFORE the "Share position" action.

How to recreate

Open Vespucci. Move the slippy map to any desired location (position 1) Use Vespucci to "Share position", then select "Open with Vespucci". The map displayed AFTER the "Share position" action (position 2) is often different from BEFORE the "Share position" action.

There is an exception. If you do NOT move the slippy map from position 2, activating "Share position" for a second time results in the same map position (i.e. position 3 is the same as position 2, but both position 2 and 3 are different from position 1).

Crash dump submitted (no or yes + date)

no

Any other potentially relevant information

Q. Could this issue be due to a rounding error caused by casting from one numeric type to another? e.g. in line 1429, there is a divide by 2 instead of 2.0 at: https://github.com/MarcusWolschon/osmeditor4android/commit/6bb505549b1684c63c459673c8ea489e34585408

[simonpoole]

There are likely two different issues here.

To start with the one that is clearly a simply mistaken expectation: the share position function generates a standard geo url see https://tools.ietf.org/html/rfc5870 these do not include a zoom level or anything similar that would indicate what area around the supplied coordinates should be displayed. Vespucci simply creates a "standard" size (aka derived from what is set as data download radius) bounding box around the coordinates and then zooms to that. In general that will be different from whatever you were viewing beforehand if you do your Vespucci to Vespucci test.

OsmAnd iirc uses a private extension to work around this general issue, potentially we could potentially support that.

The other issue is the positional accuracy, if you are seeing this is solely in the vertical direction / North-South / latitude then that is likely a combination of being zoomed out fairly far and the center of the viewbox not being calculated in web Mercartor projection (which I admit is just laziness). It definitely isn't a rounding issue (the coordinates are internally represented by scaled WGS84 values and rounding effects would at most be less than 0.5 meters).

[lokejul]

Hi simonpoole,

Thank you for your response.

The Share position offset appeared in Vespucci version 11.1.0

Previous versions of Vespucci (0.9.5.1.965 up to 11.0.5.0) did not exhibit an offset.

My use case is to find tag POI

[lokejul]

on OSMand, then use Share geo: from OSMand to invoke Vespucci. After zooming in with Vespucci, I was able to quickly find the relevant area and edit the openstreetmap.

My use case is now considerably more difficult with version 11.1.0 of Vespucci.

[simonpoole]

I currently can't re-create the issue with OSMand (with other words Vespucci always centers itself in the correct position), that doesn't mean that there is no problem, just that we need to investigate more (the other problem is that there were no relevant changes to the code between 11.0 and 11.1).

Could you indicate which OSMand version you are using? And perhaps a video or a sequence of screen shots illustrating the issue if it is not too much work (try the suggestion from below first though).

[simonpoole]

A further way to narrow the cause of the problem down: go to openstreetmap.org zoom in to an area, then go to the share panel and click on the geo url.

[lokejul]

I am using OSMand 3.2.0. I shall work on generating a video, and also investigating the geo: url. Please see if you can also demonstrate the issue at your end.

I chose the following example POIs near to where I am currently doing map edits.

The data is formatted as: keywords for search box in openstreetmap.org geo:url coordinates of centre of map shown by Vespucci 11.1.0.0

Some of the time, Vespucci plays nice, and centres the map at the correct location, viz:

Skaros peak geo:36.43250,25.41840?z=19 36.4325 ,25.4184

Unfortunately, most other times, Vespucci shows an offset map:

fira bus terminal geo:36.41655,25.43343?z=19 36.41975,25.43097

fira cathedral geo:3641684,25.43185?z=19 36.41989,25.43097

fira idol geo:36.41899,25.43129?z=19 36.41999,25.43097

fira donkey geo:36.41872,25.43068?z=19 36.41999,25.43097

Santorini cable car geo:36.41966,25.42898?z=19 36.4199,25.43097

P.S. Note that Vespucci 0.9.5.1.965 shows the map without any offset. I had not used Vespucci 11.0.5.0 very much, but 11.0.5.0 shows offsets that I had not previously appreciated.

I kept using Vespucci 0.9.5.1.965 for until the Mapbox tiles recently stopped working because more recent versions of Vespucci removed the "Large node drag area" behaviour when adding new nodes to a way. The new behaviour works well for a mouse or style interface, but not for touchscreen. But this personal preference is an unrelated to the Share Position issue.

[simonpoole]

Please test with openstreetmap.org as suggested above before doing the video.

As to your 2nd issue: it is not that the large node drag area has been removed, in the new way the "improve way geometry" works is that the node is not actually selected. To get the large drag area you simply need to let go of the node and then select it.

A possible (implementable) variant would be to select the node after creating it, however that would require re-selecting the way to add the next node.

[lokejul]

I did use openstreetmap.org as you had suggested. The results are reported in my previous post.

Entering the keywords into the search function of openstreetmap.org produces the the geo: urls in my previous post. e.g. search for fira donkey

I then opened the geo: url with Vespucci 11.1.0.0 e.g. click on geo:36.41872,25.43068?z=19

Then I used "Share position" from Vespucci to send the coordinates of the centre of the map to the clipboard. e.g. 36.41999,25.43097

I collected a one example (Skaros peak) that showed zero offset 36.4325 ,25.4184

All my other examples show an offset, but not in any recognizable pattern.

[lokejul]

I did some more work to investigate this behaviour.

I decided to craft the geo: url to feed in some lat,long data pairs to Vespucci, and I logged the resultant map position using the clipboard.

Below is my javascript code to generate a 10x10 list of geo: urls. I will paste the results in the subsequent post.

javascript:
document.write("<html><head></head><body>");
for(var r=i=0;i<10;++i) {
  var m,n="";
  for(var j=0;j<10;++j)
    { 
    m=
     "geo:0."+
     ("0000"+i.toString()).slice(-5)+
     ",0."+
     ("0000"+j.toString()).slice(-5)+
      "?z=19";
    document.write(n+
      ++r+
      "<input type='checkbox'><a href="+
      m+
      ">"+
      m+
      "</a><br>");
    n+="&nbsp;&nbsp;";
  }
}
document.write("</body></html>");

[lokejul]

Here are the results.

row number	url input to Vespucci	result
1	geo:0.00000,0.00000?z=19	0,0
2	geo:0.00000,0.00001?z=19	0,5
3	geo:0.00000,0.00002?z=19	0,0
4	geo:0.00000,0.00003?z=19	0,1.5
5	geo:0.00000,0.00004?z=19	0,2
6	geo:0.00000,0.00005?z=19	0,2.5
7	geo:0.00000,0.00006?z=19	0,3
8	geo:0.00000,0.00007?z=19	0,3
9	geo:0.00000,0.00008?z=19	0,4
10	geo:0.00000,0.00009?z=19	0,4.5
11	geo:0.00001,0.00000?z=19	-5,0
12	geo:0.00001,0.00001?z=19	-6,2.5
13	geo:0.00001,0.00002?z=19	-6,1
14	geo:0.00001,0.00003?z=19	-6,1.5
15	geo:0.00001,0.00004?z=19	-6,2
16	geo:0.00001,0.00005?z=19	-6,2.5
17	geo:0.00001,0.00006?z=19	-6,3
18	geo:0.00001,0.00007?z=19	-6,3.5
19	geo:0.00001,0.00008?z=19	-6,4
20	geo:0.00001,0.00009?z=19	-6,4.5
21	geo:0.00002,0.00000?z=19	-5,0
22	geo:0.00002,0.00001?z=19	-5,1
23	geo:0.00002,0.00002?z=19	-5,1
24	geo:0.00002,0.00003?z=19	-5,1.5
25	geo:0.00002,0.00004?z=19	-5,2
26	geo:0.00002,0.00005?z=19	-5,2.5
27	geo:0.00002,0.00006?z=19	-5,3
28	geo:0.00002,0.00007?z=19	-5,3.5
29	geo:0.00002,0.00008?z=19	-5,4
30	geo:0.00002,0.00009?z=19	-5,4.5
31	geo:0.00003,0.00000?z=19	-5,0
32	geo:0.00003,0.00001?z=19	-5,5
33	geo:0.00003,0.00002?z=19	-5,1
34	geo:0.00003,0.00003?z=19	-5,1.5
35	geo:0.00003,0.00004?z=19	-5,2
36	geo:0.00003,0.00005?z=19	-5,2.5
37	geo:0.00003,0.00006?z=19	-5,3
38	geo:0.00003,0.00007?z=19	-5,3.5
39	geo:0.00003,0.00008?z=19	-5,4
40	geo:0.00003,0.00009?z=19	-6,2.25
41	geo:0.00004,0.00000?z=19	-5,0
42	geo:0.00004,0.00001?z=19	-5,5
43	geo:0.00004,0.00002?z=19	-5,1
44	geo:0.00004,0.00003?z=19	-5,1.5
45	geo:0.00004,0.00004?z=19	-5,2
46	geo:0.00004,0.00005?z=19	-5,2.5
47	geo:0.00004,0.00006?z=19	-5,3
48	geo:0.00004,0.00007?z=19	-5,3.5
49	geo:0.00004,0.00008?z=19	-5,4
50	geo:0.00004,0.00009?z=19	-5,4.5
51	geo:0.00005,0.00000?z=19	-5,0
52	geo:0.00005,0.00001?z=19	-5,5
53	geo:0.00005,0.00002?z=19	-5,1
54	geo:0.00005,0.00003?z=19	-5,1.5
55	geo:0.00005,0.00004?z=19	-5,2
56	geo:0.00005,0.00005?z=19	-5,2.5
57	geo:0.00005,0.00006?z=19	-5,3
58	geo:0.00005,0.00007?z=19	-5,3.5
59	geo:0.00005,0.00008?z=19	-5,4
60	geo:0.00005,0.00009?z=19	-5,4.5
61	geo:0.00006,0.00000?z=19	-5,0
62	geo:0.00006,0.00001?z=19	-5,5
63	geo:0.00006,0.00002?z=19	-5,1
64	geo:0.00006,0.00003?z=19	-5,1.5
65	geo:0.00006,0.00004?z=19	-5,2
66	geo:0.00006,0.00005?z=19	-5,2.5
67	geo:0.00006,0.00006?z=19	-5,3
68	geo:0.00006,0.00007?z=19	-5,3.5
69	geo:0.00006,0.00008?z=19	-5,4
70	geo:0.00006,0.00009?z=19	-5,4.5
71	geo:0.00007,0.00000?z=19	-5,0
72	geo:0.00007,0.00001?z=19	-5,5
73	geo:0.00007,0.00002?z=19	-5,1
74	geo:0.00007,0.00003?z=19	-5,1.5
75	geo:0.00007,0.00004?z=19	-5,2
76	geo:0.00007,0.00005?z=19	-5,2.5
77	geo:0.00007,0.00006?z=19	-5,3
78	geo:0.00007,0.00007?z=19	-5,3.5
79	geo:0.00007,0.00008?z=19	-5,4
80	geo:0.00007,0.00009?z=19	-5,4.5
81	geo:0.00008,0.00000?z=19	-5,0
82	geo:0.00008,0.00001?z=19	-5,5
83	geo:0.00008,0.00002?z=19	-5,1
84	geo:0.00008,0.00003?z=19	-5,1.5
85	geo:0.00008,0.00004?z=19	-5,2
86	geo:0.00008,0.00005?z=19	-5,2.5
87	geo:0.00008,0.00006?z=19	-5,3
88	geo:0.00008,0.00007?z=19	-5,3.5
89	geo:0.00008,0.00008?z=19	-5,4
90	geo:0.00008,0.00009?z=19	-5,4.5
91	geo:0.00009,0.00000?z=19	-5,0
92	geo:0.00009,0.00001?z=19	-5,5
93	geo:0.00009,0.00002?z=19	-5,1
94	geo:0.00009,0.00003?z=19	-5,1.5
95	geo:0.00009,0.00004?z=19	-5,2
96	geo:0.00009,0.00005?z=19	-5,2.5
97	geo:0.00009,0.00006?z=19	-5,3
98	geo:0.00009,0.00007?z=19	-5,3.5
99	geo:0.00009,0.00008?z=19	-5,4
100	geo:0.00009,0.00009?z=19	-5,4.5

[simonpoole]

@lokejul what are the numbers in the "result" column?

[lokejul]

I treated Vespucci as a software black box.the geo: urls are the input. The output result is the centre coordinates (lat,lon) of the centre of the map reported by Vespucci via its "share position" function.

Here is the method.

I opened http://osm.org in chrome on Android. This primes chrome to allow javascript. Then I pasted the javascript: code into Chrome multibox, which then generated a page with the geo:urls. I clicked on each geo: url in turn and choose Vespucci as the handler.

For each geo url, Vespucci would display a map. I used "share position" in Vespucci. I chose a handler that would allow me to copy to the clipboard. I used the clipboard to paste the output reported by Vespucci for pasting into a spreadsheet table for display and analysis.

For row 1, after clicking on: geo:0.00000,0.00000?z=19 Vespucci reports the map is centered at 0,0 (which is an expected collect result)

However, for row 2, after clicking on geo:0.00000,0.00001?z=19 Vespucci reports that the map is centered at 0,5 instead of the expected 0,0.00001

For completeness, I collected the results of one hundred (lat,long) pairs.

I do not recognise a consistent pattern. A first guess would be perhaps 0.00001 is 1E-5 in exponential notation. This guess could explain row 11, but not any of the other rows.

[simonpoole]

@lokejul the results from your URL test likely have nothing to do with your original issue, except if you edit Null Island a lot, I've fixed the specific problem in https://github.com/MarcusWolschon/osmeditor4android/commit/eaaf4b3bb5796cdea4ccce5514e773105374aa59 (which will be in the October update).

[lokejul]

I look forward to the October update. Perhaps eaaf4b3 would also fix my URL test.

I agree that I don't (intentionally) edit Null Island. My previous post had some real-world examples in Santorini where I had manually added a few hundred nodes in sixty changesets. And I have a few hundred more edits yet to complete around Fira.

Your work on Vespucci is much appreciated. Thank you.

P.S. I noticed in line 63 at: https://github.com/MarcusWolschon/osmeditor4android/blob/master/src/main/java/de/blau/android/GeoUrlActivity.java that coords[0] + "/" + coords[0] is logged twice. Should line 63 read coords[0] + "/" + coords[1] instead?

[simonpoole]

Fixed the logging issue, thanks.

Santorini is just too far away (both latitude and longitude wise) from 0,0 for the scientific notation issue to be the cause. But on the other hand I haven't seen any other potential cause, outside of that we calculate a bounding box from the centre coordinates and then zoom to that, which is naturally unlikely to result in the centre of the screen being "exactly" at the originally supplied coordinates.

[simonpoole]

I went through your examples, and the max deviation I could find was 0.0000001° which is 1cm at the equator. I've simplified the code a bit now so that it will work properly at higher zoom levels (that is calculate the centre latitude in mercator projection and then project back), but the results remained the same (as expected).

[simonpoole]

Just to be sure (because the code is a bit different): you do have a download radius > 0 specified in the preferences?

[lokejul]

My download radius is currently set to 500m in preferences. I will change the download radius to see if that makes any difference to the offsets that I am seeing with Vespucci version 11.1.0 from Google Play Store.

[simonpoole]

IMHO it seems that at 500m you may be running in to issues with the logic that limits the bounding box size likely simply a bug that it isn't symmetric, so there's no need for you to test right now. I'll see if I can address that asap.

[simonpoole]

I'm fairly sure that I found the issue, essentially the behaviour was different if the area in question had already been downloaded or not. Fixed in https://github.com/MarcusWolschon/osmeditor4android/commit/a1ec6478c4f6f7f04d28c6cd9c9e477736e5c855