

Dear friends,
I'm trying to make sense of the scales for map images downloaded from OSM. For the download, you can choose the scale, and I had assumed that I could use this to convert to an actual map scale.
The downloaded png/jpg etc seem to be at 72dpi. I had assumed I could just convert pixels at 72dpi to actual dimensions (using the scale).
However  as far as I can tell  this doesn't work. Maybe I've made a mistake somewhere, but the dimensions calculated from  "feature in pixels" / (72/2.54 pixels/cm) * scale = "feature size" in cm
 latlon (e.g. bounding box provided)
Doesn't match. Moreover, the difference doesn't seem to be a constant offset or ratio, but possibly latitude dependent.
Maybe the scale offered during download is not meant to be a geographic scale? Maybe I've misunderstood something? There are two worked examples below, that show the issue.
Any thoughts? Bjoern
(and a Happy New Year!!)
Example 1:
 Open 'share',  set scale to 1:50000,  adjust view port so that "Image will show standard layer at 932x..."
On the map, there's a road (East/West), with two turnoff: First, a power line at the Eastern edge (running North/South). In the west, there are two turnoff, the second (straight one) being 11.9 km from the power line (according to JOSM). In the image, you've got those right at the edges. From the bounding box (hidden fields), I calculate 11.62km. Given that the roads are just showing either side of the image, that's bang on. Now download PNG, which will have with 932. I am assuming I have a PNG (72dpi = 28.35 dots per cm), at scale 1:50,000. I calculate:
932 pixels / (72/2.54 pixels/cm) * 50000 = 16.4 km.
So there's a difference between the dimensions calculated from the pixels and the distance calculated from lat/lon.
Full details for Example 1:
Z/L/L #13/24.1727/49.3090 bbox = [24.119651808471247,49.249992370605476 > 24.22567631717543,49.368095397949226] Pixel dim: 939 x 924; Natural image dim (72dpi): 331 mm x 326 mm, 1 : 50000 Real world dim (from pixels): 16.563 km x 16.298 km, 1 : 1 Real world dim (latlon): 11.981 km x 11.789 km, 1 : 1 Ratio: 1.382438861530757 ; 1.3824751887352615
Example 2:
Another example from the above list:
Z/L/L #13/48.6536/101.3485 bbox = [48.615207636211146,101.44741058349611 > 48.69198023486001,101.24965667724611] Pixel dim: 1572 x 924; Natural image dim (72dpi): 555 mm x 326 mm, 1 : 50000 Real world dim (from pixels): 27.728 km x 16.298 km, 1 : 1 Real world dim (latlon): 14.526 km x 8.537 km, 1 : 1 Ratio: 1.908853091009225 ; 1.909101557924329
The distance (along the highway) from the turnoffs to Undip / Lansford airstrips is 8.1km in JOSM. So the latlon calculation is correct. However, the dimension calculated from the pixels isn't.
_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


Images are in Spherical Mercator EPSG:3857 projection, so linear scale is off by cos(lat).
Dear friends,
I'm trying to make sense of the scales for map images downloaded from OSM. For the download, you can choose the scale, and I had assumed that I could use this to convert to an actual map scale.
The downloaded png/jpg etc seem to be at 72dpi. I had assumed I could just convert pixels at 72dpi to actual dimensions (using the scale).
However  as far as I can tell  this doesn't work. Maybe I've made a mistake somewhere, but the dimensions calculated from  "feature in pixels" / (72/2.54 pixels/cm) * scale = "feature size" in cm
 latlon (e.g. bounding box provided)
Doesn't match. Moreover, the difference doesn't seem to be a constant offset or ratio, but possibly latitude dependent.
Maybe the scale offered during download is not meant to be a geographic scale? Maybe I've misunderstood something? There are two worked examples below, that show the issue.
Any thoughts? Bjoern
(and a Happy New Year!!)
Example 1:
 Open 'share',  set scale to 1:50000,  adjust view port so that "Image will show standard layer at 932x..."
On the map, there's a road (East/West), with two turnoff: First, a power line at the Eastern edge (running North/South). In the west, there are two turnoff, the second (straight one) being 11.9 km from the power line (according to JOSM). In the image, you've got those right at the edges. From the bounding box (hidden fields), I calculate 11.62km. Given that the roads are just showing either side of the image, that's bang on. Now download PNG, which will have with 932. I am assuming I have a PNG (72dpi = 28.35 dots per cm), at scale 1:50,000. I calculate:
932 pixels / (72/2.54 pixels/cm) * 50000 = 16.4 km.
So there's a difference between the dimensions calculated from the pixels and the distance calculated from lat/lon.
Full details for Example 1:
Z/L/L #13/24.1727/49.3090 bbox = [24.119651808471247,49.249992370605476 > 24.22567631717543,49.368095397949226] Pixel dim: 939 x 924; Natural image dim (72dpi): 331 mm x 326 mm, 1 : 50000 Real world dim (from pixels): 16.563 km x 16.298 km, 1 : 1 Real world dim (latlon): 11.981 km x 11.789 km, 1 : 1 Ratio: 1.382438861530757 ; 1.3824751887352615
Example 2:
Another example from the above list:
Z/L/L #13/48.6536/101.3485 bbox = [48.615207636211146,101.44741058349611 > 48.69198023486001,101.24965667724611] Pixel dim: 1572 x 924; Natural image dim (72dpi): 555 mm x 326 mm, 1 : 50000 Real world dim (from pixels): 27.728 km x 16.298 km, 1 : 1 Real world dim (latlon): 14.526 km x 8.537 km, 1 : 1 Ratio: 1.908853091009225 ; 1.909101557924329
The distance (along the highway) from the turnoffs to Undip / Lansford airstrips is 8.1km in JOSM. So the latlon calculation is correct. However, the dimension calculated from the pixels isn't.
_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


Hi Darafei, dear all,
Thanks, but I still cannot get this to work.
I've now calculated real_scale = mapnik_scale / cos(lat), and used the real_scale, to calculate:
pixels * (72/2.54 pixels/cm) * real_scale = real_world_dim
However, there's still a latitudedependent discrepancy (see below). I could try to fit that to latitude, to see what the formula is, but I'm hoping somebody has the answer (or can let me know what I got wrong!)
Happy new year! Bjoern
Example 1: http://www.openstreetmap.org/#map=13/24.1788/49.3092bbox = [24.123255,49.250507; 24.234286,49.367924]bbox size in degrees (lon, lat) = 0.117416, 0.111031Pixels ('Image ... at'): 1945 x 2016; mapnik_scale 1 : 24000; real scale 1 : 26308Image dim (1 : 26308, 72dpi): 686 mm x 711 mmReal world dim (1:1, from pixels): 18.051 km x 18.71 kmReal world dim (1:1, latlon): 11.911 km x 12.346 kmRatio (dim pixels/ dim latlon): 1.516 ; 1.515
Example 2:
http://www.openstreetmap.org/#map=13/48.6617/101.3104bbox = [48.632228,101.369133; 48.691074,101.251717]bbox size in degrees (lon, lat) = 0.117416, 0.058846Pixels ('Image ... at'): 1945 x 1476; mapnik_scale 1 : 24000; real scale 1 : 36336Image dim (1 : 36336, 72dpi): 686 mm x 521 mmReal world dim (1:1, from pixels): 24.932 km x 18.92 kmReal world dim (1:1, latlon): 8.624 km x 6.543 kmRatio (dim pixels/ dim latlon): 2.891 ; 2.891
_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


Bjoern, maybe the geo functions used in iD might be a helpful reference:
The numbers I got from comparing the bbox sizes are pretty close to your numbers.
bbox1 = [[24.123255,49.250507], [24.234286,49.367924]]
dLat1 = bbox1[1][0]  bbox1[0][0] > 0.11103100000000055 iD.geoLatToMeters(dLat1) > 12359.91438226802 dLon1 = bbox1[1][1]  bbox1[0][1] iD.geoLonToMeters(dLon1, (bbox1[1][0] + bbox1[0][0])/2) > 11884.145336433623
(image1 is 11.884 km x 12.359 km)
bbox2 = [[48.632228,101.369133], [48.691074,101.251717]]
dLat2 = bbox2[1][0]  bbox2[0][0] > 0.05884600000000262 iD.geoLatToMeters(dLat2) > 6550.706755221268 dLon2 = bbox2[1][1]  bbox2[0][1] > 0.11741600000000574 iD.geoLonToMeters(dLon2, (bbox2[1][0] + bbox2[0][0])/2) > 8604.30156213755
(image2 is 8.604 km x 6.550 km)
Bryan
Hi Darafei, dear all,
Thanks, but I still cannot get this to work.
I've now calculated real_scale = mapnik_scale / cos(lat), and used the real_scale, to calculate:
pixels * (72/2.54 pixels/cm) * real_scale = real_world_dim
However, there's still a latitudedependent discrepancy (see below). I could try to fit that to latitude, to see what the formula is, but I'm hoping somebody has the answer (or can let me know what I got wrong!)
Happy new year! Bjoern
Example 1: http://www.openstreetmap.org/#map=13/24.1788/49.3092bbox = [24.123255,49.250507; 24.234286,49.367924]bbox size in degrees (lon, lat) = 0.117416, 0.111031Pixels ('Image ... at'): 1945 x 2016; mapnik_scale 1 : 24000; real scale 1 : 26308Image dim (1 : 26308, 72dpi): 686 mm x 711 mmReal world dim (1:1, from pixels): 18.051 km x 18.71 kmReal world dim (1:1, latlon): 11.911 km x 12.346 kmRatio (dim pixels/ dim latlon): 1.516 ; 1.515
Example 2:
http://www.openstreetmap.org/#map=13/48.6617/101.3104bbox = [48.632228,101.369133; 48.691074,101.251717]bbox size in degrees (lon, lat) = 0.117416, 0.058846Pixels ('Image ... at'): 1945 x 1476; mapnik_scale 1 : 24000; real scale 1 : 36336Image dim (1 : 36336, 72dpi): 686 mm x 521 mmReal world dim (1:1, from pixels): 24.932 km x 18.92 kmReal world dim (1:1, latlon): 8.624 km x 6.543 kmRatio (dim pixels/ dim latlon): 2.891 ; 2.891
_______________________________________________ dev mailing list [hidden email]https://lists.openstreetmap.org/listinfo/dev
_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


Hi Bryan, hi Darafei,
That's helpful, thanks. So we know that the calculation from the bbox is correct.
However, I guess we don't know about how pixels translate to realword dims? (Or, equicvalenly, how pixels relate to the latlon extent.)
Thanks! Bjoern
_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


Please don't  it has nothing to do with the web site code.
Please go and read about projections instead.
Tom
On 11/01/18 08:21, Darafei "Komяpa" Praliaskouski wrote:
> Hi,
>
> As long as there is nobody on the list can make sense of the values for
> almost two weeks, I'd say it should be considered a bug and filed
> towards https://github.com/openstreetmap/openstreetmapwebsite/issues>
> чт, 11 янв. 2018 г. в 2:05, Bjoern Hassler < [hidden email]
> <mailto:bjohas% [hidden email]>>:
>
> Dear friends,
>
> I was just wondering whether anybody else had any thoughts on this?
> Any tips on making sense of the mapnik_scale would be greatly
> appreciated!
>
> Bjoern
>
> On 3 January 2018 at 17:21, Bjoern Hassler < [hidden email]
> <mailto: [hidden email]>> wrote:
>
> Hi Bryan, hi Darafei,
>
> That's helpful, thanks. So we know that the calculation from the
> bbox is correct.
>
> However, I guess we don't know about how pixels translate to
> realword dims? (Or, equicvalenly, how pixels relate to the
> latlon extent.)
>
> Thanks!
> Bjoern
>
> On 2 January 2018 at 14:46, Bryan Housel < [hidden email]
> <mailto: [hidden email]>> wrote:
>
> Bjoern, maybe the geo functions used in iD might be a
> helpful reference:
> https://github.com/openstreetmap/iD/blob/master/modules/geo/geo.js>
> The numbers I got from comparing the bbox sizes are pretty
> close to your numbers.
>
>
> bbox1 = [[24.123255,49.250507], [24.234286,49.367924]]
>
> dLat1 = bbox1[1][0]  bbox1[0][0]
> > 0.11103100000000055
> iD.geoLatToMeters(dLat1)
> > 12359.91438226802
> dLon1 = bbox1[1][1]  bbox1[0][1]
> > 0.11741700000000321
> iD.geoLonToMeters(dLon1, (bbox1[1][0] + bbox1[0][0])/2)
> > 11884.145336433623
>
> (image1 is 11.884 km x 12.359 km)
>
>
> bbox2 = [[48.632228,101.369133], [48.691074,101.251717]]
>
> dLat2 = bbox2[1][0]  bbox2[0][0]
> > 0.05884600000000262
> iD.geoLatToMeters(dLat2)
> > 6550.706755221268
> dLon2 = bbox2[1][1]  bbox2[0][1]
> > 0.11741600000000574
> iD.geoLonToMeters(dLon2, (bbox2[1][0] + bbox2[0][0])/2)
> > 8604.30156213755
>
> (image2 is 8.604 km x 6.550 km)
>
>
> Bryan
>
>
>
>> On Jan 1, 2018, at 6:56 AM, Bjoern Hassler
>> < [hidden email] <mailto: [hidden email]>> wrote:
>>
>> Hi Darafei, dear all,
>>
>> Thanks, but I still cannot get this to work.
>>
>> I've now calculated real_scale = mapnik_scale / cos(lat),
>> and used the real_scale, to calculate:
>>
>> pixels * (72/2.54 pixels/cm) * real_scale = real_world_dim
>>
>> However, there's still a latitudedependent discrepancy
>> (see below). I could try to fit that to latitude, to see
>> what the formula is, but I'm hoping somebody has the
>> answer (or can let me know what I got wrong!)
>>
>> Happy new year!
>> Bjoern
>>
>> *Example 1:*
>> http://www.openstreetmap.org/#map=13/24.1788/49.3092>> bbox = [24.123255,49.250507; 24.234286,49.367924]
>> bbox size in degrees (lon, lat) = 0.117416, 0.111031
>> *Pixels ('Image ... at'):* 1945 x 2016;
>> *mapnik_scale* 1 : 24000; *real scale *1 : 26308
>> Image dim (1 : 26308, 72dpi): 686 mm x 711 mm
>> Real world dim (1:1, from pixels): *18.051 km x 18.71 km*
>> Real world dim (1:1, latlon): *11.911 km x 12.346 km*
>> Ratio (dim pixels/ dim latlon): 1.516 ; 1.515
>>
>> *Example 2:*
>> http://www.openstreetmap.org/#map=13/48.6617/101.3104>> bbox = [48.632228,101.369133; 48.691074,101.251717]
>> bbox size in degrees (lon, lat) = 0.117416, 0.058846
>> *Pixels ('Image ... at'):* 1945 x 1476;
>> *mapnik_scale* 1 : 24000; *real scale *1 : 36336
>> Image dim (1 : 36336, 72dpi): 686 mm x 521 mm
>> Real world dim (1:1, from pixels): *24.932 km x 18.92 km*
>> Real world dim (1:1, latlon):*8.624 km x 6.543 km*
>> Ratio (dim pixels/ dim latlon): 2.891 ; 2.891
>>
>>
>>
>> On 31 December 2017 at 18:59, Darafei "Komяpa"
>> Praliaskouski < [hidden email] <mailto: [hidden email]>> wrote:
>>
>> Images are in Spherical Mercator EPSG:3857 projection,
>> so linear scale is off by cos(lat).
>>
>>
>> On Sun, Dec 31, 2017, 20:07 Bjoern Hassler
>> < [hidden email] <mailto:bjohas% [hidden email]>>
>> wrote:
>>
>> Dear friends,
>>
>> I'm trying to make sense of the scales for map
>> images downloaded from OSM. For the download, you
>> can choose the scale, and I had assumed that I
>> could use this to convert to an actual map scale.
>>
>> The downloaded png/jpg etc seem to be at 72dpi. I
>> had assumed I could just convert pixels at 72dpi
>> to actual dimensions (using the scale).
>>
>> However  as far as I can tell  this doesn't
>> work. Maybe I've made a mistake somewhere, but the
>> dimensions calculated from
>>
>> * "feature in pixels" / (72/2.54 pixels/cm) *
>> scale = "feature size" in cm
>> * latlon (e.g. bounding box provided)
>>
>> Doesn't match. Moreover, the difference doesn't
>> seem to be a constant offset or ratio, but
>> possibly latitude dependent.
>>
>> Maybe the scale offered during download is not
>> meant to be a geographic scale? Maybe I've
>> misunderstood something?
>> There are two worked examples below, that show the
>> issue.
>>
>> Any thoughts?
>> Bjoern
>>
>> (and a Happy New Year!!)
>>
>>
>> *Example 1:*
>>
>> I had a look for long straight roads ... (Trivia:
>> http://www.dangerousroads.org/rankings23/3759the10longeststraightroadsintheworld.html>>  "Located in the heart of Saudi Arabia, the
>> Highway 10 is 120 miles (193km) stretch of
>> straightness. This asphalted road links Haradh and
>> Al Batha. It’s a straight road running right
>> through the desert for 2 h 1 min.")
>>
>>  Open 'share',
>>  set scale to 1:50000,
>>  adjust view port so that "Image will show
>> standard layer at 932x..."
>>  Go here:
>> http://www.openstreetmap.org/#map=13/24.1349/49.3083>>
>> On the map, there's a road (East/West), with two
>> turnoff: First, a power line at the Eastern edge
>> (running North/South). In the west, there are two
>> turnoff, the second (straight one) being 11.9 km
>> from the power line (according to JOSM). In the
>> image, you've got those right at the edges. From
>> the bounding box (hidden fields), I calculate
>> 11.62km. Given that the roads are just showing
>> either side of the image, that's bang on.
>>
>> Now download PNG, which will have with 932. I am
>> assuming I have a PNG (72dpi = 28.35 dots per cm),
>> at scale 1:50,000. I calculate:
>>
>> 932 pixels / (72/2.54 pixels/cm) * 50000 = 16.4 km.
>>
>> So there's a difference between the dimensions
>> calculated from the pixels and the distance
>> calculated from lat/lon.
>>
>> *Full details for Example 1:*
>>
>> Z/L/L #13/24.1727/49.3090
>> bbox = [24.119651808471247,49.249992370605476 >
>> 24.22567631717543,49.368095397949226]
>> Pixel dim: 939 x 924;
>> Natural image dim (72dpi): 331 mm x 326 mm, 1 : 50000
>> Real world dim (from pixels): 16.563 km x 16.298
>> km, 1 : 1
>> Real world dim (latlon): 11.981 km x 11.789 km, 1 : 1
>> Ratio: 1.382438861530757 ; 1.3824751887352615
>>
>> *Example 2:*
>>
>> Another example from the above list:
>>
>> Z/L/L #13/48.6536/101.3485
>> bbox = [48.615207636211146,101.44741058349611 >
>> 48.69198023486001,101.24965667724611]
>> Pixel dim: 1572 x 924;
>> Natural image dim (72dpi): 555 mm x 326 mm, 1 : 50000
>> Real world dim (from pixels): 27.728 km x 16.298
>> km, 1 : 1
>> Real world dim (latlon): 14.526 km x 8.537 km, 1 : 1
>> Ratio: 1.908853091009225 ; 1.909101557924329
>>
>> The distance (along the highway) from the turnoffs
>> to Undip / Lansford airstrips is 8.1km in JOSM. So
>> the latlon calculation is correct. However, the
>> dimension calculated from the pixels isn't.
>> _______________________________________________
>> dev mailing list
>> [hidden email] <mailto: [hidden email]>
>> https://lists.openstreetmap.org/listinfo/dev>>
>>
>> _______________________________________________
>> dev mailing list
>> [hidden email] <mailto: [hidden email]>
>> https://lists.openstreetmap.org/listinfo/dev>
>
>
>
>
> _______________________________________________
> dev mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/dev>

Tom Hughes ( [hidden email])
http://compton.nu/_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


Actually isn't the real problem here just needing to know what DPI is
being being assumed by mapnik when rendering?
IIRC it's 96dpi?
Tom
On 11/01/18 08:50, Tom Hughes wrote:
> Please don't  it has nothing to do with the web site code.
>
> Please go and read about projections instead.
>
> Tom
>
> On 11/01/18 08:21, Darafei "Komяpa" Praliaskouski wrote:
>> Hi,
>>
>> As long as there is nobody on the list can make sense of the values
>> for almost two weeks, I'd say it should be considered a bug and filed
>> towards https://github.com/openstreetmap/openstreetmapwebsite/issues>>
>> чт, 11 янв. 2018 г. в 2:05, Bjoern Hassler < [hidden email]
>> <mailto:bjohas% [hidden email]>>:
>>
>> Dear friends,
>>
>> I was just wondering whether anybody else had any thoughts on this?
>> Any tips on making sense of the mapnik_scale would be greatly
>> appreciated!
>>
>> Bjoern
>>
>> On 3 January 2018 at 17:21, Bjoern Hassler < [hidden email]
>> <mailto: [hidden email]>> wrote:
>>
>> Hi Bryan, hi Darafei,
>>
>> That's helpful, thanks. So we know that the calculation from the
>> bbox is correct.
>>
>> However, I guess we don't know about how pixels translate to
>> realword dims? (Or, equicvalenly, how pixels relate to the
>> latlon extent.)
>>
>> Thanks!
>> Bjoern
>>
>> On 2 January 2018 at 14:46, Bryan Housel < [hidden email]
>> <mailto: [hidden email]>> wrote:
>>
>> Bjoern, maybe the geo functions used in iD might be a
>> helpful reference:
>>
>> https://github.com/openstreetmap/iD/blob/master/modules/geo/geo.js>>
>> The numbers I got from comparing the bbox sizes are pretty
>> close to your numbers.
>>
>>
>> bbox1 = [[24.123255,49.250507], [24.234286,49.367924]]
>>
>> dLat1 = bbox1[1][0]  bbox1[0][0]
>> > 0.11103100000000055
>> iD.geoLatToMeters(dLat1)
>> > 12359.91438226802
>> dLon1 = bbox1[1][1]  bbox1[0][1]
>> > 0.11741700000000321
>> iD.geoLonToMeters(dLon1, (bbox1[1][0] + bbox1[0][0])/2)
>> > 11884.145336433623
>>
>> (image1 is 11.884 km x 12.359 km)
>>
>>
>> bbox2 = [[48.632228,101.369133], [48.691074,101.251717]]
>>
>> dLat2 = bbox2[1][0]  bbox2[0][0]
>> > 0.05884600000000262
>> iD.geoLatToMeters(dLat2)
>> > 6550.706755221268
>> dLon2 = bbox2[1][1]  bbox2[0][1]
>> > 0.11741600000000574
>> iD.geoLonToMeters(dLon2, (bbox2[1][0] + bbox2[0][0])/2)
>> > 8604.30156213755
>>
>> (image2 is 8.604 km x 6.550 km)
>>
>>
>> Bryan
>>
>>
>>
>>> On Jan 1, 2018, at 6:56 AM, Bjoern Hassler
>>> < [hidden email] <mailto: [hidden email]>> wrote:
>>>
>>> Hi Darafei, dear all,
>>>
>>> Thanks, but I still cannot get this to work.
>>>
>>> I've now calculated real_scale = mapnik_scale / cos(lat),
>>> and used the real_scale, to calculate:
>>>
>>> pixels * (72/2.54 pixels/cm) * real_scale = real_world_dim
>>>
>>> However, there's still a latitudedependent discrepancy
>>> (see below). I could try to fit that to latitude, to see
>>> what the formula is, but I'm hoping somebody has the
>>> answer (or can let me know what I got wrong!)
>>>
>>> Happy new year!
>>> Bjoern
>>>
>>> *Example 1:*
>>> http://www.openstreetmap.org/#map=13/24.1788/49.3092>>> bbox = [24.123255,49.250507; 24.234286,49.367924]
>>> bbox size in degrees (lon, lat) = 0.117416, 0.111031
>>> *Pixels ('Image ... at'):* 1945 x 2016;
>>> *mapnik_scale* 1 : 24000; *real scale *1 : 26308
>>> Image dim (1 : 26308, 72dpi): 686 mm x 711 mm
>>> Real world dim (1:1, from pixels): *18.051 km x 18.71 km*
>>> Real world dim (1:1, latlon): *11.911 km x 12.346 km*
>>> Ratio (dim pixels/ dim latlon): 1.516 ; 1.515
>>>
>>> *Example 2:*
>>> http://www.openstreetmap.org/#map=13/48.6617/101.3104>>> bbox = [48.632228,101.369133; 48.691074,101.251717]
>>> bbox size in degrees (lon, lat) = 0.117416, 0.058846
>>> *Pixels ('Image ... at'):* 1945 x 1476;
>>> *mapnik_scale* 1 : 24000; *real scale *1 : 36336
>>> Image dim (1 : 36336, 72dpi): 686 mm x 521 mm
>>> Real world dim (1:1, from pixels): *24.932 km x 18.92 km*
>>> Real world dim (1:1, latlon):*8.624 km x 6.543 km*
>>> Ratio (dim pixels/ dim latlon): 2.891 ; 2.891
>>>
>>>
>>>
>>> On 31 December 2017 at 18:59, Darafei "Komяpa"
>>> Praliaskouski < [hidden email] <mailto: [hidden email]>> wrote:
>>>
>>> Images are in Spherical Mercator EPSG:3857 projection,
>>> so linear scale is off by cos(lat).
>>>
>>>
>>> On Sun, Dec 31, 2017, 20:07 Bjoern Hassler
>>> < [hidden email] <mailto:bjohas% [hidden email]>>
>>> wrote:
>>>
>>> Dear friends,
>>>
>>> I'm trying to make sense of the scales for map
>>> images downloaded from OSM. For the download, you
>>> can choose the scale, and I had assumed that I
>>> could use this to convert to an actual map scale.
>>>
>>> The downloaded png/jpg etc seem to be at 72dpi. I
>>> had assumed I could just convert pixels at 72dpi
>>> to actual dimensions (using the scale).
>>>
>>> However  as far as I can tell  this doesn't
>>> work. Maybe I've made a mistake somewhere, but the
>>> dimensions calculated from
>>>
>>> * "feature in pixels" / (72/2.54 pixels/cm) *
>>> scale = "feature size" in cm
>>> * latlon (e.g. bounding box provided)
>>>
>>> Doesn't match. Moreover, the difference doesn't
>>> seem to be a constant offset or ratio, but
>>> possibly latitude dependent.
>>>
>>> Maybe the scale offered during download is not
>>> meant to be a geographic scale? Maybe I've
>>> misunderstood something?
>>> There are two worked examples below, that show the
>>> issue.
>>>
>>> Any thoughts?
>>> Bjoern
>>>
>>> (and a Happy New Year!!)
>>>
>>>
>>> *Example 1:*
>>>
>>> I had a look for long straight roads ... (Trivia:
>>>
>>> http://www.dangerousroads.org/rankings23/3759the10longeststraightroadsintheworld.html
>>>
>>>  "Located in the heart of Saudi Arabia, the
>>> Highway 10 is 120 miles (193km) stretch of
>>> straightness. This asphalted road links Haradh and
>>> Al Batha. It’s a straight road running right
>>> through the desert for 2 h 1 min.")
>>>
>>>  Open 'share',
>>>  set scale to 1:50000,
>>>  adjust view port so that "Image will show
>>> standard layer at 932x..."
>>>  Go here:
>>> http://www.openstreetmap.org/#map=13/24.1349/49.3083>>>
>>> On the map, there's a road (East/West), with two
>>> turnoff: First, a power line at the Eastern edge
>>> (running North/South). In the west, there are two
>>> turnoff, the second (straight one) being 11.9 km
>>> from the power line (according to JOSM). In the
>>> image, you've got those right at the edges. From
>>> the bounding box (hidden fields), I calculate
>>> 11.62km. Given that the roads are just showing
>>> either side of the image, that's bang on.
>>>
>>> Now download PNG, which will have with 932. I am
>>> assuming I have a PNG (72dpi = 28.35 dots per cm),
>>> at scale 1:50,000. I calculate:
>>>
>>> 932 pixels / (72/2.54 pixels/cm) * 50000 = 16.4 km.
>>>
>>> So there's a difference between the dimensions
>>> calculated from the pixels and the distance
>>> calculated from lat/lon.
>>>
>>> *Full details for Example 1:*
>>>
>>> Z/L/L #13/24.1727/49.3090
>>> bbox = [24.119651808471247,49.249992370605476 >
>>> 24.22567631717543,49.368095397949226]
>>> Pixel dim: 939 x 924;
>>> Natural image dim (72dpi): 331 mm x 326 mm, 1 :
>>> 50000
>>> Real world dim (from pixels): 16.563 km x 16.298
>>> km, 1 : 1
>>> Real world dim (latlon): 11.981 km x 11.789 km, 1
>>> : 1
>>> Ratio: 1.382438861530757 ; 1.3824751887352615
>>>
>>> *Example 2:*
>>>
>>> Another example from the above list:
>>>
>>> Z/L/L #13/48.6536/101.3485
>>> bbox = [48.615207636211146,101.44741058349611 >
>>> 48.69198023486001,101.24965667724611]
>>> Pixel dim: 1572 x 924;
>>> Natural image dim (72dpi): 555 mm x 326 mm, 1 :
>>> 50000
>>> Real world dim (from pixels): 27.728 km x 16.298
>>> km, 1 : 1
>>> Real world dim (latlon): 14.526 km x 8.537 km, 1 : 1
>>> Ratio: 1.908853091009225 ; 1.909101557924329
>>>
>>> The distance (along the highway) from the turnoffs
>>> to Undip / Lansford airstrips is 8.1km in JOSM. So
>>> the latlon calculation is correct. However, the
>>> dimension calculated from the pixels isn't.
>>> _______________________________________________
>>> dev mailing list
>>> [hidden email] <mailto: [hidden email]>
>>> https://lists.openstreetmap.org/listinfo/dev>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> [hidden email] <mailto: [hidden email]>
>>> https://lists.openstreetmap.org/listinfo/dev>>
>>
>>
>>
>>
>> _______________________________________________
>> dev mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/dev>>
>
>

Tom Hughes ( [hidden email])
http://compton.nu/_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


Looks like we are using 90dpi actually. The key code is here:
https://github.com/openstreetmap/chef/blob/master/cookbooks/tile/templates/default/export.erb#L121We project the bounding box from EPSG:4326 lat/lon to spherical mercator
which gives us coordinates on a projected sheet measuring roughly
40075016m on each edge (2 x PI x assumed earth radius).
We then divide by the scale factor and then convert metres to pixels by
dividing by 0.00028 which comes from:
1 / 39.701 / 90
Where we divide by 39.701 to convert from metres to inches and then by a
further 90 to convert to pixels at 90 dpi.
Tom
On 11/01/18 08:52, Tom Hughes wrote:
> Actually isn't the real problem here just needing to know what DPI is
> being being assumed by mapnik when rendering?
>
> IIRC it's 96dpi?
>
> Tom
>
> On 11/01/18 08:50, Tom Hughes wrote:
>> Please don't  it has nothing to do with the web site code.
>>
>> Please go and read about projections instead.
>>
>> Tom
>>
>> On 11/01/18 08:21, Darafei "Komяpa" Praliaskouski wrote:
>>> Hi,
>>>
>>> As long as there is nobody on the list can make sense of the values
>>> for almost two weeks, I'd say it should be considered a bug and filed
>>> towards https://github.com/openstreetmap/openstreetmapwebsite/issues>>>
>>> чт, 11 янв. 2018 г. в 2:05, Bjoern Hassler < [hidden email]
>>> <mailto:bjohas% [hidden email]>>:
>>>
>>> Dear friends,
>>>
>>> I was just wondering whether anybody else had any thoughts on this?
>>> Any tips on making sense of the mapnik_scale would be greatly
>>> appreciated!
>>>
>>> Bjoern
>>>
>>> On 3 January 2018 at 17:21, Bjoern Hassler < [hidden email]
>>> <mailto: [hidden email]>> wrote:
>>>
>>> Hi Bryan, hi Darafei,
>>>
>>> That's helpful, thanks. So we know that the calculation from the
>>> bbox is correct.
>>>
>>> However, I guess we don't know about how pixels translate to
>>> realword dims? (Or, equicvalenly, how pixels relate to the
>>> latlon extent.)
>>>
>>> Thanks!
>>> Bjoern
>>>
>>> On 2 January 2018 at 14:46, Bryan Housel < [hidden email]
>>> <mailto: [hidden email]>> wrote:
>>>
>>> Bjoern, maybe the geo functions used in iD might be a
>>> helpful reference:
>>> https://github.com/openstreetmap/iD/blob/master/modules/geo/geo.js>>>
>>> The numbers I got from comparing the bbox sizes are pretty
>>> close to your numbers.
>>>
>>>
>>> bbox1 = [[24.123255,49.250507], [24.234286,49.367924]]
>>>
>>> dLat1 = bbox1[1][0]  bbox1[0][0]
>>> > 0.11103100000000055
>>> iD.geoLatToMeters(dLat1)
>>> > 12359.91438226802
>>> dLon1 = bbox1[1][1]  bbox1[0][1]
>>> > 0.11741700000000321
>>> iD.geoLonToMeters(dLon1, (bbox1[1][0] + bbox1[0][0])/2)
>>> > 11884.145336433623
>>>
>>> (image1 is 11.884 km x 12.359 km)
>>>
>>>
>>> bbox2 = [[48.632228,101.369133], [48.691074,101.251717]]
>>>
>>> dLat2 = bbox2[1][0]  bbox2[0][0]
>>> > 0.05884600000000262
>>> iD.geoLatToMeters(dLat2)
>>> > 6550.706755221268
>>> dLon2 = bbox2[1][1]  bbox2[0][1]
>>> > 0.11741600000000574
>>> iD.geoLonToMeters(dLon2, (bbox2[1][0] + bbox2[0][0])/2)
>>> > 8604.30156213755
>>>
>>> (image2 is 8.604 km x 6.550 km)
>>>
>>>
>>> Bryan
>>>
>>>
>>>
>>>> On Jan 1, 2018, at 6:56 AM, Bjoern Hassler
>>>> < [hidden email] <mailto: [hidden email]>> wrote:
>>>>
>>>> Hi Darafei, dear all,
>>>>
>>>> Thanks, but I still cannot get this to work.
>>>>
>>>> I've now calculated real_scale = mapnik_scale / cos(lat),
>>>> and used the real_scale, to calculate:
>>>>
>>>> pixels * (72/2.54 pixels/cm) * real_scale = real_world_dim
>>>>
>>>> However, there's still a latitudedependent discrepancy
>>>> (see below). I could try to fit that to latitude, to see
>>>> what the formula is, but I'm hoping somebody has the
>>>> answer (or can let me know what I got wrong!)
>>>>
>>>> Happy new year!
>>>> Bjoern
>>>>
>>>> *Example 1:*
>>>> http://www.openstreetmap.org/#map=13/24.1788/49.3092>>>> bbox = [24.123255,49.250507; 24.234286,49.367924]
>>>> bbox size in degrees (lon, lat) = 0.117416, 0.111031
>>>> *Pixels ('Image ... at'):* 1945 x 2016;
>>>> *mapnik_scale* 1 : 24000; *real scale *1 : 26308
>>>> Image dim (1 : 26308, 72dpi): 686 mm x 711 mm
>>>> Real world dim (1:1, from pixels): *18.051 km x 18.71 km*
>>>> Real world dim (1:1, latlon): *11.911 km x 12.346 km*
>>>> Ratio (dim pixels/ dim latlon): 1.516 ; 1.515
>>>>
>>>> *Example 2:*
>>>> http://www.openstreetmap.org/#map=13/48.6617/101.3104>>>> bbox = [48.632228,101.369133; 48.691074,101.251717]
>>>> bbox size in degrees (lon, lat) = 0.117416, 0.058846
>>>> *Pixels ('Image ... at'):* 1945 x 1476;
>>>> *mapnik_scale* 1 : 24000; *real scale *1 : 36336
>>>> Image dim (1 : 36336, 72dpi): 686 mm x 521 mm
>>>> Real world dim (1:1, from pixels): *24.932 km x 18.92 km*
>>>> Real world dim (1:1, latlon):*8.624 km x 6.543 km*
>>>> Ratio (dim pixels/ dim latlon): 2.891 ; 2.891
>>>>
>>>>
>>>>
>>>> On 31 December 2017 at 18:59, Darafei "Komяpa"
>>>> Praliaskouski < [hidden email] <mailto: [hidden email]>> wrote:
>>>>
>>>> Images are in Spherical Mercator EPSG:3857 projection,
>>>> so linear scale is off by cos(lat).
>>>>
>>>>
>>>> On Sun, Dec 31, 2017, 20:07 Bjoern Hassler
>>>> < [hidden email] <mailto:bjohas% [hidden email]>>
>>>> wrote:
>>>>
>>>> Dear friends,
>>>>
>>>> I'm trying to make sense of the scales for map
>>>> images downloaded from OSM. For the download, you
>>>> can choose the scale, and I had assumed that I
>>>> could use this to convert to an actual map scale.
>>>>
>>>> The downloaded png/jpg etc seem to be at 72dpi. I
>>>> had assumed I could just convert pixels at 72dpi
>>>> to actual dimensions (using the scale).
>>>>
>>>> However  as far as I can tell  this doesn't
>>>> work. Maybe I've made a mistake somewhere, but the
>>>> dimensions calculated from
>>>>
>>>> * "feature in pixels" / (72/2.54 pixels/cm) *
>>>> scale = "feature size" in cm
>>>> * latlon (e.g. bounding box provided)
>>>>
>>>> Doesn't match. Moreover, the difference doesn't
>>>> seem to be a constant offset or ratio, but
>>>> possibly latitude dependent.
>>>>
>>>> Maybe the scale offered during download is not
>>>> meant to be a geographic scale? Maybe I've
>>>> misunderstood something?
>>>> There are two worked examples below, that show the
>>>> issue.
>>>>
>>>> Any thoughts?
>>>> Bjoern
>>>>
>>>> (and a Happy New Year!!)
>>>>
>>>>
>>>> *Example 1:*
>>>>
>>>> I had a look for long straight roads ... (Trivia:
>>>> http://www.dangerousroads.org/rankings23/3759the10longeststraightroadsintheworld.html
>>>>
>>>>  "Located in the heart of Saudi Arabia, the
>>>> Highway 10 is 120 miles (193km) stretch of
>>>> straightness. This asphalted road links Haradh and
>>>> Al Batha. It’s a straight road running right
>>>> through the desert for 2 h 1 min.")
>>>>
>>>>  Open 'share',
>>>>  set scale to 1:50000,
>>>>  adjust view port so that "Image will show
>>>> standard layer at 932x..."
>>>>  Go here:
>>>>
>>>> http://www.openstreetmap.org/#map=13/24.1349/49.3083>>>>
>>>> On the map, there's a road (East/West), with two
>>>> turnoff: First, a power line at the Eastern edge
>>>> (running North/South). In the west, there are two
>>>> turnoff, the second (straight one) being 11.9 km
>>>> from the power line (according to JOSM). In the
>>>> image, you've got those right at the edges. From
>>>> the bounding box (hidden fields), I calculate
>>>> 11.62km. Given that the roads are just showing
>>>> either side of the image, that's bang on.
>>>>
>>>> Now download PNG, which will have with 932. I am
>>>> assuming I have a PNG (72dpi = 28.35 dots per cm),
>>>> at scale 1:50,000. I calculate:
>>>>
>>>> 932 pixels / (72/2.54 pixels/cm) * 50000 = 16.4 km.
>>>>
>>>> So there's a difference between the dimensions
>>>> calculated from the pixels and the distance
>>>> calculated from lat/lon.
>>>>
>>>> *Full details for Example 1:*
>>>>
>>>> Z/L/L #13/24.1727/49.3090
>>>> bbox = [24.119651808471247,49.249992370605476 >
>>>> 24.22567631717543,49.368095397949226]
>>>> Pixel dim: 939 x 924;
>>>> Natural image dim (72dpi): 331 mm x 326 mm, 1 :
>>>> 50000
>>>> Real world dim (from pixels): 16.563 km x 16.298
>>>> km, 1 : 1
>>>> Real world dim (latlon): 11.981 km x 11.789 km,
>>>> 1 : 1
>>>> Ratio: 1.382438861530757 ; 1.3824751887352615
>>>>
>>>> *Example 2:*
>>>>
>>>> Another example from the above list:
>>>>
>>>> Z/L/L #13/48.6536/101.3485
>>>> bbox = [48.615207636211146,101.44741058349611 >
>>>> 48.69198023486001,101.24965667724611]
>>>> Pixel dim: 1572 x 924;
>>>> Natural image dim (72dpi): 555 mm x 326 mm, 1 :
>>>> 50000
>>>> Real world dim (from pixels): 27.728 km x 16.298
>>>> km, 1 : 1
>>>> Real world dim (latlon): 14.526 km x 8.537 km, 1
>>>> : 1
>>>> Ratio: 1.908853091009225 ; 1.909101557924329
>>>>
>>>> The distance (along the highway) from the turnoffs
>>>> to Undip / Lansford airstrips is 8.1km in JOSM. So
>>>> the latlon calculation is correct. However, the
>>>> dimension calculated from the pixels isn't.
>>>> _______________________________________________
>>>> dev mailing list
>>>> [hidden email]
>>>> <mailto: [hidden email]>
>>>> https://lists.openstreetmap.org/listinfo/dev>>>>
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> [hidden email] <mailto: [hidden email]>
>>>> https://lists.openstreetmap.org/listinfo/dev>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> [hidden email]
>>> https://lists.openstreetmap.org/listinfo/dev>>>
>>
>>
>
>

Tom Hughes ( [hidden email])
http://compton.nu/_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


On 11/01/18 10:38, Bjoern Hassler wrote:
> (1) DPI on exported images
>
> Actually isn't the real problem here just needing to know what DPI
> is being being assumed by mapnik when rendering?
> IIRC it's 96dpi?
>
>
> As you say (and also in the link Yves posted) it's about 90.7dpi,
> standard pixel size of 0.28 millimeters as defined by the OGC (Open
> Geospatial Consortium) SLD (Styled Layer Descriptor). However, the
> images downloaded are claiming 72dpi. I need to check whether they don't
> haveÂ dpi metadata (and therefore my OS assumes 72) or whether they are
> tagged incorrectly.
>
> Either way, that sounds like a discrepancy though, right?
If you're fetching PNG then does PNG even have a way of specifying the
DPI in the format?
Frankly it's not something I'm going to lose much sleep over and may
well not be anything we have any control over.
> (2) "project the bounding box from EPSG:4326 lat/lon to spherical
> mercator which gives us coordinates on a projected sheet measuring
> roughly 40075016m on each edge (2 x PI x assumed earth radius)."
>
> That's very helpful. What is the function (of latitude) that maps the
> sheet to the smaller scale map? I'd assumed cos(lat), but it seems to be
> more complicated. I can dig around, but if you happen to know it, thenÂ
> don't need to dig around. The code has this:
>
> Â Â scale = float(form.getvalue("scale"))
> Â Â width = int(bbox.width() / scale / 0.00028)
> Â Â height = int(bbox.height() / scale / 0.00028)
>
> where I assume form.getvalue fetches the "mapnik_" form. So,
> equivalently, it would be about the variation of the bbox.width() with
> lat, in theÂ Â spherical mercator projection. Any thoughts on this?
I don't think there is one simple function. We (or rather mapnik) just
uses the proj4 library like everybody else that does this stuff. You can
see the precise configuration we feed it a few lines above that in the
source.
It then does a load of funky maths that I'm not even going to try to
understand.
> (3) Filing a bug: Clearly there's nothing wrong with the rendering (bar
> issue 1 above?). However, one might say that the 'scale' label on the
> box is misleading to a casual user, as users would assume geographical
> scale, rather than mapnik_scale. Would it be helpful to users to have a
> few words underneath to the scale box, saying "Note that this is not
> geographical scale." and link to page that explained how to convert?
I'm not really sure what you mean by geographical scale?
Like any other projected map the value we show is the amount by which
the projected sheet is scaled. Basically you unwrap the globe (or part
of the globe that you are dealing with) and do the necessary funky
stretching to make it a flat sheet than you scale that sheet by the
specified amount. That is how every printed map you see works.
Because this is a digital version there is then a second step of how
many pixels you use for each physical unit.
Tom

Tom Hughes ( [hidden email])
http://compton.nu/_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


On 11/01/18 10:47, Tom Hughes wrote:
> On 11/01/18 10:38, Bjoern Hassler wrote:
>
>> (1) DPI on exported images
>>
>> Actually isn't the real problem here just needing to know what DPI
>> is being being assumed by mapnik when rendering?
>> IIRC it's 96dpi?
>>
>>
>> As you say (and also in the link Yves posted) it's about 90.7dpi,
>> standard pixel size of 0.28 millimeters as defined by the OGC (Open
>> Geospatial Consortium) SLD (Styled Layer Descriptor). However, the
>> images downloaded are claiming 72dpi. I need to check whether they
>> don't haveÂ dpi metadata (and therefore my OS assumes 72) or whether
>> they are tagged incorrectly.
>>
>> Either way, that sounds like a discrepancy though, right?
>
> If you're fetching PNG then does PNG even have a way of specifying the
> DPI in the format?
Per
https://en.wikipedia.org/wiki/Portable_Network_Graphics#Ancillary_chunks
I think that a pHYs chunk could store it but our images don't appear to
have that:
% ./pngcheck v map.png
File: map.png (205670 bytes)
chunk IHDR at offset 0x0000c, length 13
1192 x 1018 image, 32bit RGB+alpha, noninterlaced
chunk IDAT at offset 0x00025, length 32768
zlib: deflated, 32K window, default compression
chunk IDAT at offset 0x08031, length 32768
chunk IDAT at offset 0x1003d, length 32768
chunk IDAT at offset 0x18049, length 32768
chunk IDAT at offset 0x20055, length 32768
chunk IDAT at offset 0x28061, length 32768
chunk IDAT at offset 0x3006d, length 8933
chunk IEND at offset 0x3235e, length 0
No errors detected in map.png (9 chunks, 95.8% compression).
I suspect 72 is just an OS default.
Tom

Tom Hughes ( [hidden email])
http://compton.nu/_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


note that this will always only be approximate as it will vary across your sheet of paper (getting smaller towards the equator and bigger towards the poles in the mercator projection we use), so you would want to say something like "the scale in the centre of your sheet will be 1 : 25000") Cheers, Martin
_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


Hi,
On 01/11/2018 12:44 PM, Martin Koppenhoefer wrote:
> note that this will always only be approximate as it will vary across
> your sheet of paper (getting smaller towards the equator and bigger
> towards the poles in the mercator projection we use), so you would want
> to say something like "the scale in the centre of your sheet will be 1 :
> 25000")
Also, "this applies to the horizontal scale, the vertical scale is
another matter altogether" ;)
Bye
Frederik

Frederik Ramm ## eMail [hidden email] ## N49°00'09" E008°23'33"
_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


Hi,
Am 11.01.2018 um 10:54 schrieb Tom Hughes:
> Looks like we are using 90dpi actually. The key code is here:
>
> https://github.com/openstreetmap/chef/blob/master/cookbooks/tile/templates/default/export.erb#L121>
>
> We project the bounding box from EPSG:4326 lat/lon to spherical mercator
> which gives us coordinates on a projected sheet measuring roughly
> 40075016m on each edge (2 x PI x assumed earth radius).
>
> We then divide by the scale factor and then convert metres to pixels by
> dividing by 0.00028 which comes from:
>
> 1 / 39.701 / 90
>
> Where we divide by 39.701 to convert from metres to inches and then by a
> further 90 to convert to pixels at 90 dpi.
Nik4 goes one step beyond and multiplies the scale by (1 / cos(lat)).
lat is the latitude of the centre of the rendered image. That's a pretty
good approximation.
https://github.com/Zverik/Nik4/blob/master/nik4.py#L289Best regards
Michael

Per EMail kommuniziere ich bevorzugt GPGverschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev

