Re: [OSM-dev] Scale of downloaded images seems to vary.
Hi Tom, hi Darafei, hi Yves, dear friends,
thank you for your messages!
(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?
(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?
(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?
Many thanks,
Bjoern
On 11 January 2018 at 09:54, Tom Hughes wrote:
> 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.
>
> 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/openstreetmap-website/issues
>>>>
>>>> чт, 11 янв. 2018 г. в 2:05, Bjoern Hassler >>> <mailto:bjohas%2...@gmail.com>>:
>>>>
>>>> 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 >>> <mailto:bjohas...@gmail.com>> 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
>>>> real-word dims? (Or, equicvalenly, how pixels relate to the
>>>> lat-lon extent.)
>>>>
>>>> Thanks!
>>>> Bjoern
>>>>
>>>> On 2 January 2018 at 14:46, Bryan Housel >>> <mailto:br...@7thposition.com>> wrote:
>>>>
>>>> Bjoer
Re: [OSM-dev] Scale of downloaded images seems to vary.
Hi Tom, dear friends, I'm not really sure what you mean by geographical scale? It would be helpful to have text like this: "This image is 90.7 dpi, or 28 dots per cm. If printed at this dpi, the scale will be 1cm to 25,000 cm." Particularly if the formula is complicated, then it would be helpful to retrieve this information from the libraries. The online map has a scale bar super-imposed - how is that produced? Maybe the relevant information could also be read as part of that. Regarding the missing DPI information in the png: It would be great to add it. But with the above statement, at least the user is warned, esp. if that led to a wiki page with additional information. So not too bothered about getting it all right or make it all explicit, but it would be really helpful to provide a link so users don't have to hunt around (as I did, and I do a lot of work with OSM...). Many thanks! Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Scale of downloaded images seems to vary.
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 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 real-word
> dims? (Or, equicvalenly, how pixels relate to the lat-lon extent.)
>
> Thanks!
> Bjoern
>
> On 2 January 2018 at 14:46, Bryan Housel 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.111031055
>> iD.geoLatToMeters(dLat1)
>> > 12359.91438226802
>> dLon1 = bbox1[1][1] - bbox1[0][1]
>> > 0.117417321
>> 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.058846262
>> iD.geoLatToMeters(dLat2)
>> > 6550.706755221268
>> dLon2 = bbox2[1][1] - bbox2[0][1]
>> > 0.117416574
>> 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 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 latitude-dependent 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 <
>> m...@komzpa.net> 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 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
>>>>- lat-lon (e.g. bounding box provided)
>>>>
>>>> Doesn't match. Moreover, the dif
Re: [OSM-dev] Scale of downloaded images seems to vary.
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 real-word
dims? (Or, equicvalenly, how pixels relate to the lat-lon extent.)
Thanks!
Bjoern
On 2 January 2018 at 14:46, Bryan Housel 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.111031055
> iD.geoLatToMeters(dLat1)
> > 12359.91438226802
> dLon1 = bbox1[1][1] - bbox1[0][1]
> > 0.117417321
> 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.058846262
> iD.geoLatToMeters(dLat2)
> > 6550.706755221268
> dLon2 = bbox2[1][1] - bbox2[0][1]
> > 0.117416574
> 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 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 latitude-dependent 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 <
> m...@komzpa.net> 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 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
>>>- lat-lon (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.dangerousr
>>> oads.org/rankings23/3759-the-10-longest-straight-roads-in-the-world.html
>>>
Re: [OSM-dev] Scale of downloaded images seems to vary.
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 latitude-dependent 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
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 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
>>- lat-lon (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/3759-the-10-longest-straight-
>> roads-in-the-world.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:5,
>> - 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 turn-off: First, a power
>> line at the Eastern edge (running North/South). In the west, there are two
>> turn-off, 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) * 5 = 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 : 5
>> 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.38247518873526
[OSM-dev] Scale of downloaded images seems to vary.
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 - lat-lon (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/3759-the-10-longest-straight- roads-in-the-world.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:5, - 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 turn-off: First, a power line at the Eastern edge (running North/South). In the west, there are two turn-off, 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) * 5 = 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 : 5 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 : 5 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 dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Automatically triggering export as PDF from openstreetmap.org -> share?
Dear friends, thanks for your suggestions so far! Another possibility that I have come across is https://inkatlas.com, which offers an API (https://inkatlas.com/docs/), however only as part of the "Pro" paid-for package. As our project is non-profit, the dev's are going to give us access to the API, so we can try this out. In case people are interested in our project (an atlas of the Ghanaian Colleges of Education), I'll send a link to the final (collated) PDF when we have it. Suggestions and updates remain very welcome! Thanks again! Bjoern On 23 December 2017 at 13:36, Bjoern Hassler wrote: > Hi Hartmut, > > thank you! > >> >> https://maposmatic.osm-baustelle.de/maps/10931 > > > Thanks! > > At DIN A2 SVG has ~100KB, PDF ~200KB, 300dpi PNG 1.3MB (~650K when using >> reduced color space) > > > That's very useful to know, and as suspected. > > >> You can re-render the map at any time using the "recreate" icon in >> the result page. > > > That's also useful! > > >> Good news is that I plan to work on this on 34c3 (chaos communication >> congress) between christmas and new year, and better automation is high >> on the todo list ... > > > That's great! Do keep me informed! > > Bjoern > > >> >> >> -- >> hartmut >> >> >> >> ___ >> dev mailing list >> dev@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/dev >> > > ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Automatically triggering export as PDF from openstreetmap.org -> share?
Hi Hartmut, thank you! > > https://maposmatic.osm-baustelle.de/maps/10931 Thanks! At DIN A2 SVG has ~100KB, PDF ~200KB, 300dpi PNG 1.3MB (~650K when using > reduced color space) That's very useful to know, and as suspected. > You can re-render the map at any time using the "recreate" icon in > the result page. That's also useful! > Good news is that I plan to work on this on 34c3 (chaos communication > congress) between christmas and new year, and better automation is high > on the todo list ... That's great! Do keep me informed! Bjoern > > > -- > hartmut > > > > ___ > dev mailing list > dev@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev > ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Automatically triggering export as PDF from openstreetmap.org -> share?
Hi Joost, hi Martin, thanks for the comments - I'll have a look. I may just print the maps by hand from the OSM site for now, and look into more advanced options in the future. QGIS lets you export / print to raster (png), pdf (AFAIK both, raster and > vector, there's an option "print as raster") and svg (not working well, > e.g. I had problems with uncropped lines at the border). Depending on your > settings (resolution, scale and feature density on the map), it is not a > given that a vector representation will produce smaller files in any case > (when zoomed in you will usually get smaller files, if there is a lot of > detail in a large scale map, you will not see it in the print, but it will > inflate your file). > Yes of course - that's very true! In my case, I'm producing maps a few 100m across (the size of a college). Many thanks again! Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Automatically triggering export as PDF from openstreetmap.org -> share?
Dear Frederik, dear Paul, Thank you for your message! I suppose I made the mistake of asking for a technical fix, rather than fully explaining the problem... I have 40 small, discontinues areas in Ghana (the 40 public colleges of education), like this http://www.openstreetmap.org/way/450562441#map=16/7.4129/0.4631 and I want to produce print. The files itself will be downloaded locally (or emailed), and then printed locally. So the file needs to be small, and print resolution (say for A2 or A3). We're actively editing this at the moment (and have been over the last year), so we'd like to print from up-to-date data. Print + small files, means PDF, as its vector, and can be printed at any size. I assume PNG at 300dpi, A3, would be massive. There aren't loads of areas, and manual export would be ok. However, because the areas are discontinuous, I am looking for a solution where I can work from lat/lon, rather than having to manually select areas. Once this would be ok, but we'd like to be able to repeat the export later. Most tools don't allow you to go back to maps that you've already produced, to reprint simply with data a year on. > https://operations.osmfoundation.org/policies/tiles/ > ... so using a script to produce these PDFs would violate the policy except > in rare circumstances where running the script is triggered by a user > request. > I'd be quite happy to click manually. At the moment, I enter the values for scale manually, resize the browser window so it gives me the right nominal dimensions (for PDF), then export. However, it would be helpful to have a preconfigured link, that gives me my settings (scale, dimensions). > > * download and stitch tiles, convert to PDF; search for "OSM bigmap" for > different implementations. * use the "staticmap" script on openstreetmap.de like this: > http://staticmap.openstreetmap.de/staticmap.php?center=40,-50&zoom=2&size= > 500x350 > > Both will only give you standard resolution raster images. As above, vector would be preferable. > You could > also try > > * https://maposmatic.osm-baustelle.de/ (a working fork of the > discontinued MapOsMatic project, does PDFs) > I'll see whether it's possible to generate maps of predefined areas or re-print maps (with the same boundaries). At least from the web UI, it doesn't look like it. > * http://printmaps-osm.de:8080/ (Europe only, quarterly data updates, > does PDFs in theory but currently only PNG works) > I'm outside Europe, and need up-to-date data. > or if you're on Windows or willing to use Mono, Maperitive can also > generate PDFs for any region using data from Overpass, and it's > scriptable (even headless). > OK, I'll have a look. However, it looks like it produces only SVG, which I'd then have to process. > > Of course, the canonical solution is "install your own > postgres/mapnik/nik4.py and run it locally" ;) > > Paul, why is the recommendation to produce PNG first? Thanks both for you input - much appreciated!! Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Automatically triggering export as PDF from openstreetmap.org -> share?
Dear friends, Suppose I have a standard OSM URL, e.g. as follows: URL1 = http://www.openstreetmap.org/way/450562441#map=16/7.4129/0.4631 Is it possible to automatically produce a PDF, say via URL something like this: URL2 = URL1?format=PDF&dimensions=800x1000&scale=2500 The idea would be to produce a PDF in the same way as manually going to export, selecting format PDF, scale 1:2500 and dimensions 800x1000? I suppose there would be some kind of POST request that could be done, that simulates the form input? Would be great to have a script I could use, rather than trying to figure it out. I would be most grateful for any suggestions!! Many thanks, Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Subscribing to objects I have edited
Dear friends, To answer my own question - the API would do it: /api/0.6/[node|way|relation]/#id/history. Also on talk http://osm-hall-monitor.herokuapp.com/ and https://tyrasd.github.io/ osm-qa-feeds/ were mentioned, which is great. Follow up question: Does anybody know of a script that allows you to retrieve all your changesets (via http://api.openstreetmap.org/api/0.6/changesets), and gets the changeset content (http://api.openstreetmap.org/api/0.6/changeset/123/download)? It's easy to write such a script, but if somebody has something already, I might as well save the time! Many thanks, Bjoern On 24 June 2017 at 10:42, Bjoern Hassler wrote: > Dear friends, > > Further to my message on talk, how would you retrieve the history of an > object from OSM via an API? > > I am aware of diff/adiff in overpass, but as far as I can see overpass > can't produce the change set history of an object, or answer the question > "Has this object been edited since it was edited by user X?" > > Any thoughts? > Many thanks! > Bjoern > > -- Forwarded message - > > Dear friends, > > I'm sure this would have been discussed before, but I'd like to raise it > again, I would really like a way in which I can subscribe to objects in > OSM, e.g. objects I have edited, so that I receive some kind of > notification if the object is changed (by email, or perhaps through a web > service). I know it has its complications, and you would not want to add > everything. But we all invest hours in our special interests on OSM, and > I'd like to know if others contribute to the same objects (both to know > about improvements, as well as potential issues). > > What do others think? > Bjoern > > > > ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Subscribing to objects I have edited
Dear friends, Further to my message on talk, how would you retrieve the history of an object from OSM via an API? I am aware of diff/adiff in overpass, but as far as I can see overpass can't produce the change set history of an object, or answer the question "Has this object been edited since it was edited by user X?" Any thoughts? Many thanks! Bjoern -- Forwarded message - Dear friends, I'm sure this would have been discussed before, but I'd like to raise it again, I would really like a way in which I can subscribe to objects in OSM, e.g. objects I have edited, so that I receive some kind of notification if the object is changed (by email, or perhaps through a web service). I know it has its complications, and you would not want to add everything. But we all invest hours in our special interests on OSM, and I'd like to know if others contribute to the same objects (both to know about improvements, as well as potential issues). What do others think? Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Moving tags in JOSM
Dear all, I've got a couple of questions about moving tags in JOSM. (1) The only time you get a "merge tags" dialog seems to be when merging nodes. E.g. copy/paste tags overwrites silently and utils2 functions also overwrites silently. (Though e.g. you could use Shift+R to go from object 1 to object 2 and then back to object 1 to preserve object 1 tags.) Is there an option/plugin that can marge tags from a node into a way, with a merge dialogue (or a "do not overwrite existing tags" option)? (2) Is there a way of copying/moving tags from a node or way to a relation? Ideally something like "move tags to relation" -> "select tags to move" -> "select relation to move to (if more than one)" -> move. I am sometimes moving wikidata/wikipedia tags from nodes/ways to relations, and there doesn't seem to be a simpler way than manually copying them one by one. Many thanks! Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fwd: Printing to PDF
Hi Hartmut, thanks for that! > > Tracks and named Waypoints are rendered when using the new experimental > GPX Track upload feature. > > Level of details depends on the auto-calculated zoom level, so for > showing buildings at low zoom levels the underlying stylesheets would > need to be tweaked. > > Or you could try the "Schwarz-Plan" overlay (last in the list), that > should render buildings as filled black rectangles at all zoom levels > as far as I remember ... so you'd have the base map without buildings > but then the overlay would draw them on top. > OK, I'll try that! The page doesn't accept bbox get parameter, does it? E.g. something like: https://maposmatic.osm-baustelle.de/new/?bbox=0,0,1,1 > In the "Share" menue -- opened by the third Icon from the bottom -- you > can export the current view in PNG, PDF, SVG ... > Ah ok - thanks! :) This might work, if I had a screen that was much larger than my screen... basically I can't quite get the area that I need (at the resolution I'd like). However, the tile is exported as vector, which is great. How are these produced? And can I get them programatically? Thanks! Bjoern > > > > ___ > dev mailing list > dev@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev > ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Fwd: Printing to PDF
Dear all, thanks for comments! I basically want to preserve the detail, e.g. buildings. It's a rural area (Fiwila, Zambia), so even after extensively mapping roads and buildings (thanks for new DG Premium), there isn't that much data (e.g. about 2,000 buildings in the area). (1) maposmatic - this works well - thanks for maintaining this https://maposmatic.osm-baustelle.de/. Plus the overlaid grid would allow us to discuss issues quite easily. People could draw on the map, and take picture of the square - easy to amend OSM then. So that's great. What's the spacing algorithm for the grid? Round number of km? That would be very useful. However, when I try to capture a larger area, it doesn't show buildings. https://maposmatic.osm-baustelle.de/maps/2960/YitJcomYWseZgmbH. However, if the roads were rendered thinner, buildings could still be shown. The full area is something like 40km (N-S) and 60km (E-W), but I'd be happy to have two sets 40km by 30km. There are some additional features I'd like to show, but these could be added using GPX waypoints - haven't tried that yet, but I guess waypoints are rendered? or just tracks? (2) I didn't understand this: > 20x30km isn't that big really. Is the export option on the OSM map not sufficient? As far as I can see, the export on openstreetmap.org only gives me the OSM data? Or am I missing something? I can of course print from the browser, but for a large area, this gives me low resolution. (3) I would have been quite happy with writing my own MapCSS (though ideally not another format specification), but I guess something like "command data.osm map.css output.pdf" doesn't exist? (Where command doesn't have complicated dependencies...) I definitely don't want to spend a long time setting something up - it's a one off. I guess the best option is mapnik? It has homebrew for OS X, and might be most flexible, as it would allow me to tweak the humanitarian carto style as well. (4) Maperitive seems to be cross platform - so I'll look at that too! (5) A related question is to produce an atlas - similar to field papers. The idea is that the large map can go on the wall in the health centre, and people can use the atlas for driving around (and of course maps.me when people manage to charge their phones - there's no mains electricity, and people tend to have old / basic phones). Field papers is great and easy to use, but ideally I would like some overlap between pages (as a road atlas does), and the QR isn't needed. Most importantly, I'd like to render / highlight some features that aren't in the standard style. I guess I could use mapnik again? And just iterate over my area? I found this tutorial https://wiki.openstreetmap.org/wiki/User:Moresby/Understanding_Mapnik so mapnik is pretty flexible it seems. Many thanks! Bjoern On 27 May 2017 at 09:39, Martin Koppenhoefer wrote: > > 2017-05-27 0:21 GMT+02:00 Hartmut Holzgraefe >: > >> for standalone you may want to give https://github.com/Zverik/Nik4 a try >> > > > +1, thing is it requires at least half a day to set this up (database, > mapnik, download + import data) and get it all running, especially if you > haven't done it before. There are lots of potential problems involved and > the stack might be currently broken on your OS (at least this is what I > experienced on OSX with homebrew, where python bindings (required for nik4) > are available only for mapnik 2.2. but it doesn't compile)). > > if you're on windows you can use mapertive, on Ubuntu I guess mapnik will > install easier, but with MapOSMatic (using a working deployment on someone > else's system) you could have a print in a few minutes, or similar with the > bigmap script (in screen resolution). http://openstreetmap.gryph.de/ > bigmap.html > > Cheers, > Martin > > ___ > dev mailing list > dev@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev > > ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Printing to PDF
Dear all, what's the best way to print to PDF? I'd like to print a 30km by 20km area to a single A1 or A2 sheet. This is a "sparse" area in Zambia, so downloading OSM data and rendering is quite possible, rather than attempting to print tiles. I did have a look at https://wiki.openstreetmap.org/wiki/OSM_on_Paper, but it's tricky to see what's current, and what works well. I guess it's possible to use QGIS as well, but ideally a stand-alone version of something like his would work for me: https://wiki.openstreetmap.org/wiki/MapPDF. Also, I couldn't really get PDF out of JOSM - would be very nice to improve that. Any thoughts on options? Thanks! Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Clustering of points
Hi Darafei, Thanks for the quick response. I'm not hugely familiar with the tools, but quite possibly that is all that's needed. Do you have some code, or link to a recipe or a good page to get started? Thanks! Bjoern On 16 May 2017 18:34, "Darafei "Komяpa" Praliaskouski" wrote: Is there anything in this that's not covered by importing OSM data using osm2pgsql and then using a combination of PostGIS's ST_ClusterWithin and ST_ConvexHull? On аў, 16 мая 2017, 20.28 Bjoern Hassler wrote: > Hi all, > > I'm interested in clustering of OSM points, as sometimes seen on maps, as > well as finding convex hulls. Basically the idea is to assist mappers in > locating villages in remote areas in sub-saharan Africa. > > Would anybody be interested in discussing this, and work out what the > options are? > > We're working with health workers in Zambia, and might be able to write a > publication on this, in case it's motivation for somebody to participate. > > All the best wishes, > Bjoern > ___ > dev mailing list > dev@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev > ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Clustering of points
Hi all, I'm interested in clustering of OSM points, as sometimes seen on maps, as well as finding convex hulls. Basically the idea is to assist mappers in locating villages in remote areas in sub-saharan Africa. Would anybody be interested in discussing this, and work out what the options are? We're working with health workers in Zambia, and might be able to write a publication on this, in case it's motivation for somebody to participate. All the best wishes, Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Wikipedia/OSM integration - round trip?
Hi all, just in case anybody else is interested: I've created a short tampermonkey script here: http://bjohas.de//wiki/Maps/Linking_wikipedia_to_OSM It extracts coordinates and wikidata from a wikipedia page, and adds various direct links near the "Coordinates" bit on the wikipedia page, which link to OSM/iD/JOSM / http://osm.wikidata.link/ / etc. It's of course simple to do, but I still fiddled with it for a bit until it worked, so thought I'd share it. In putting this together and testing it, I also added some POIs for wikipedia objects that weren't on OSM (but clearly visible in bing/mapbox) - so it's been helpful to me. Final question: (Also, the OSM search doesn't return anything for the wikidata object > http://www.openstreetmap.org/search?query=Q925624 - would be great if it > did.) Should this be addressed? Thanks! Bjoern On 27 April 2017 at 13:11, Bjoern Hassler wrote: > Hi Imre, > > that's very interesting - thanks for pointing this out! I'll follow up > with the developer! > > Thanks! > Bjoern > > > On 26 April 2017 at 19:54, Imre Samu wrote: > >> >I'm interested in working across Wikipedia and OSM, e.g. fixing Wikidata >> tags in OSM, and coordinates in Wikipedia, etc. >> > I've also found this very useful in terms of ensuring that data is >> correct on both. >> >Does anybody have suggestions for faster linking from Wikipedia to OSM? >> >> I have found an interesting project: >> * "Match OSM entities with Wikidata items": http://osm.wikidata.link/ >> * source: https://github.com/EdwardBetts/osm-wikidata >> >> example: >> >> Sassari ( Italy ) : https://osm.wikidata.link/matcher/40683: view >> match candidates : 16 items found >> Link for "view match candidates" ; And you will find the matches .. >> * 7 candidates found >> * Items with no match found in OSM : 9 items >> >> Best, >> Imre >> >> >> 2017-04-26 17:03 GMT+02:00 Bjoern Hassler : >> >>> Hello all, >>> >>> I'm interested in working across Wikipedia and OSM, e.g. fixing Wikidata >>> tags in OSM, and coordinates in Wikipedia, etc. I've also found this very >>> useful in terms of ensuring that data is correct on both. >>> >>> Does anybody have suggestions for faster linking from Wikipedia to OSM? >>> >>> To explain: >>> >>> The wikipedia coordinates link (on a wikipedia page) is something like: >>> https://tools.wmflabs.org/geohack/geohack.php?pagename=Nurag >>> he_Santu_Antine¶ms=40.4865_N_8.7698_E_ >>> which then lets you go to OSM (by coordinates) - but obviously, you have >>> to click that link first, then pick OSM from the list on that page. On OSM, >>> you then have to click edit to identify the object referred to in OSM (if >>> there is one). So it's not too bad, but if you do this regularly, it's a >>> bit tedious. >>> >>> A better way would be if the wmflabs url could be rewritten (clientside, >>> e.g. greasemonkey/tampermonkey), to have a direct link from the wikipedia >>> page to OSM. >>> >>> Even better would be if the url contained the wikidata item >>> https://tools.wmflabs.org/geohack/geohack.php?pagename=Nurag >>> he_Santu_Antine¶ms=40.4865_N_8.7698_E_&wikidata=Q925624 >>> (could be done on the wmflabs side, or also with greasmonkey, as it's >>> embedded on the wikipedia page). >>> >>> Greasemonkey could add a link from the wikipedia page to a resolving >>> service, say >>> https://WikidataToOSM/?pagename=Nuraghe_Santu_Antine¶ms= >>> 40.4865_N_8.7698_E_&wikidata=Q925624 >>> which would allow redirect to the actual object on OSM: >>> http://www.openstreetmap.org/way/258094245 >>> >>> That would mean that with one click on a Wikipedia page, you'd see the >>> corresponding object in OSM. >>> >>> The other way is straight forward: Because that listing on OSM rewrites >>> wikidata/wikipedia tags to URLs, it's just one click to go back from there >>> to wikidata/wikipedia, so that's straight forward. >>> >>> (Ideally, Greasemonkey would also add a direct link to remote control.) >>> >>> (Also, the OSM search doesn't return anything for the wikidata object >>> http://www.openstreetmap.org/search?query=Q925624 - would be great if >>> it did.) >>> >>> Does anybody have any thoughts on this, know of a tool, or coded >>> something in the past? >>> >>> Many thanks, >>> Bjoern >>> >>> ___ >>> dev mailing list >>> dev@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/dev >>> >>> >> > ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Wikipedia/OSM integration - round trip?
Hi Imre, that's very interesting - thanks for pointing this out! I'll follow up with the developer! Thanks! Bjoern On 26 April 2017 at 19:54, Imre Samu wrote: > >I'm interested in working across Wikipedia and OSM, e.g. fixing Wikidata > tags in OSM, and coordinates in Wikipedia, etc. > > I've also found this very useful in terms of ensuring that data is > correct on both. > >Does anybody have suggestions for faster linking from Wikipedia to OSM? > > I have found an interesting project: > * "Match OSM entities with Wikidata items": http://osm.wikidata.link/ > * source: https://github.com/EdwardBetts/osm-wikidata > > example: > > Sassari ( Italy ) : https://osm.wikidata.link/matcher/40683: view > match candidates : 16 items found > Link for "view match candidates" ; And you will find the matches .. > * 7 candidates found > * Items with no match found in OSM : 9 items > > Best, > Imre > > > 2017-04-26 17:03 GMT+02:00 Bjoern Hassler : > >> Hello all, >> >> I'm interested in working across Wikipedia and OSM, e.g. fixing Wikidata >> tags in OSM, and coordinates in Wikipedia, etc. I've also found this very >> useful in terms of ensuring that data is correct on both. >> >> Does anybody have suggestions for faster linking from Wikipedia to OSM? >> >> To explain: >> >> The wikipedia coordinates link (on a wikipedia page) is something like: >> https://tools.wmflabs.org/geohack/geohack.php?pagename=Nurag >> he_Santu_Antine¶ms=40.4865_N_8.7698_E_ >> which then lets you go to OSM (by coordinates) - but obviously, you have >> to click that link first, then pick OSM from the list on that page. On OSM, >> you then have to click edit to identify the object referred to in OSM (if >> there is one). So it's not too bad, but if you do this regularly, it's a >> bit tedious. >> >> A better way would be if the wmflabs url could be rewritten (clientside, >> e.g. greasemonkey/tampermonkey), to have a direct link from the wikipedia >> page to OSM. >> >> Even better would be if the url contained the wikidata item >> https://tools.wmflabs.org/geohack/geohack.php?pagename=Nurag >> he_Santu_Antine¶ms=40.4865_N_8.7698_E_&wikidata=Q925624 >> (could be done on the wmflabs side, or also with greasmonkey, as it's >> embedded on the wikipedia page). >> >> Greasemonkey could add a link from the wikipedia page to a resolving >> service, say >> https://WikidataToOSM/?pagename=Nuraghe_Santu_Antine¶ms= >> 40.4865_N_8.7698_E_&wikidata=Q925624 >> which would allow redirect to the actual object on OSM: >> http://www.openstreetmap.org/way/258094245 >> >> That would mean that with one click on a Wikipedia page, you'd see the >> corresponding object in OSM. >> >> The other way is straight forward: Because that listing on OSM rewrites >> wikidata/wikipedia tags to URLs, it's just one click to go back from there >> to wikidata/wikipedia, so that's straight forward. >> >> (Ideally, Greasemonkey would also add a direct link to remote control.) >> >> (Also, the OSM search doesn't return anything for the wikidata object >> http://www.openstreetmap.org/search?query=Q925624 - would be great if it >> did.) >> >> Does anybody have any thoughts on this, know of a tool, or coded >> something in the past? >> >> Many thanks, >> Bjoern >> >> ___ >> dev mailing list >> dev@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/dev >> >> > ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Wikipedia/OSM integration - round trip?
Hello all, I'm interested in working across Wikipedia and OSM, e.g. fixing Wikidata tags in OSM, and coordinates in Wikipedia, etc. I've also found this very useful in terms of ensuring that data is correct on both. Does anybody have suggestions for faster linking from Wikipedia to OSM? To explain: The wikipedia coordinates link (on a wikipedia page) is something like: https://tools.wmflabs.org/geohack/geohack.php?pagename=Nuraghe_Santu_Antine¶ms=40.4865_N_8.7698_E_ which then lets you go to OSM (by coordinates) - but obviously, you have to click that link first, then pick OSM from the list on that page. On OSM, you then have to click edit to identify the object referred to in OSM (if there is one). So it's not too bad, but if you do this regularly, it's a bit tedious. A better way would be if the wmflabs url could be rewritten (clientside, e.g. greasemonkey/tampermonkey), to have a direct link from the wikipedia page to OSM. Even better would be if the url contained the wikidata item https://tools.wmflabs.org/geohack/geohack.php?pagename=Nuraghe_Santu_Antine¶ms=40.4865_N_8.7698_E_&wikidata=Q925624 (could be done on the wmflabs side, or also with greasmonkey, as it's embedded on the wikipedia page). Greasemonkey could add a link from the wikipedia page to a resolving service, say https://WikidataToOSM/?pagename=Nuraghe_Santu_Antine¶ms=40.4865_N_8.7698_E_&wikidata=Q925624 which would allow redirect to the actual object on OSM: http://www.openstreetmap.org/way/258094245 That would mean that with one click on a Wikipedia page, you'd see the corresponding object in OSM. The other way is straight forward: Because that listing on OSM rewrites wikidata/wikipedia tags to URLs, it's just one click to go back from there to wikidata/wikipedia, so that's straight forward. (Ideally, Greasemonkey would also add a direct link to remote control.) (Also, the OSM search doesn't return anything for the wikidata object http://www.openstreetmap.org/search?query=Q925624 - would be great if it did.) Does anybody have any thoughts on this, know of a tool, or coded something in the past? Many thanks, Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Linking OSM and Wikipedia - WIWOSM
Dear all, I just wanted to check that WIWOSM is still active. If so, should I be using wikidata tags (wikidata=Q123), or stick with article names (wikipedia=en:xyz)? Many thanks, Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Dev help on "overpass turbo / table display"
Hi all, This pull request https://github.com/tyrasd/overpass-turbo/pull/18# has been open for some time, but the original developer currently doesn't have much time to complete it at the moment. IMHO this is a super-useful feature that adds a 3rd tab to overpass turbo to view the data retrieved by the query in tabular form. This is very helpful for quickly inspecting what tags exist in an area, whether tags are consistent, etc. Because it's just a 3rd tab, it's very usable as well, and could be used to illustrate tagging of various features. I'm not aware of another tool that can easily display tabular OSM data quite in this way. Would anybody be willing to contribute to get do a bit of work on this, to move the fork forward, so the pull request can be completed? I'm happy to contribute, but most likely in testing, though could potentially do some coding as well, depending on what's needed. Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Wiki account creation, "Account creation error Incorrect or missing CAPTCHA."
Hi all, I've just tried to create an account on the wiki, but I get the following: Account creation error Incorrect or missing CAPTCHA. However, below the text "To protect the wiki against automated account creation, we kindly ask you to type the two words you see in the box below:" there's no captcha visible (Firefox and Chrome). I managed to create an account by switching to on developer tools, and inspecting the page with a mobile browser setting, which brought up a street-number-type captcha. (Sorry if this is the wrong list!) Thanks! Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Simple app for "making contributions" (not to display maps)
Hi Simon, Rory, Guillaume, Frederik, Martin, Mikael,
Thank you for your input - that's very helpful and appreciated. Let me try
a digest reply. Overall, I'm thinking of something much simpler than
displaying maps. Overall, there's (at least) two different areas:
(1) Traces
(2) Tags / resolving bugs
** On traces **
> On 29 June 2016 at 13:41, Simon Poole wrote: In general I'm not convinced
that raw GPS tracks are of a lot of use without additional information in
areas that might not have a well established road network, ...
It may not be without additional information - see next answer.
> Who is "we" in this context?
E.g. I'm working with teachers in Ghana, where mentors travel to
schools/colleges to give support. They do have tablets/smart phones with
GPS. GPS Logger probably comes closest to what we could use (
http://code.mendhak.com/gpslogger/), mainly because it offers to auto
upload a trace. So for us, that could work, because we have a set of known
users (and can receive traces via dropbox/email/etc). We tried OSMAnd
previously, but because GPX cannot be sent automatically, it was too
tricky. (Similarly for OSMTracker.) We're yet to try GPS Logger. But
suppose we were to work with users less well known to us:
*Scenario A ("friends of friends" contributions): *For other users, GPS
Logger can also upload to OSM. Suppose we'd ask friends in certain towns to
use the tool, as a "semi-anonymous" mapping campaign in that town, we'd
then have to find those traces on OSM (or at least be notified that a
relevant trace has come in). *How would you do this? It doesn't seem as if
you can search for traces in particular areas?*
*Scenario B (crowd contributions): *Something similar to OSM Logger, but
that could switch on automatically (e.g. when people are driving with GPS
enabled). "We're short of maps in this area? Do you want to help?" If the
users taps yes, then a trace is recorded and submitted (anonymously). This
could be stand alone, or (to provide an incentive to the user) be
integrated into OSMAnd/map.me etc.
Perhaps (if integrated into an app) the data would not be that useful
anyway (as Simon suggested), as you don't know what kind of track the user
is on. Stand-alone, you could ask the user some questions afterwards: Major
road yes/no, tarmac yes/no, etc.
On 29 June 2016 at 13:43, Frederik Ramm wrote:
> Your user's contributions would be immensely more
valuable if there was a way for them to at least record the information
whether they're currently on a path or travelling cross-terrain.
> (Sometimes this can be guessed from the speed of movement but not always.)
>
Agreed!
On 29 June 2016 at 13:34, Guillaume AMAT wrote:
> You're searching something I plan to implement in MapContrib (but I don't
> know when...), see https://github.com/MapContrib/MapContrib/issues/148.
> Is that issue the exact need of yours?
>
Yes, I think the issue above is similar to the way GPS Logger works. I'll
have a look at the app, and will comment if I have a suggestion. Also see
point about 'tags' below.
Rory, maps.me seems to be more aimed at using maps - certainly the site
doesn't foreground contributions. It's similar with OSMAnd - it can
display/add bugs/notes, and e.g. display the 'fixme' tag, but the main
purpose is to use maps.
** On tags * *
Apart from traces, it may also be helpful to fix tags / collect other
information. Here are some thoughts:
*(A) Location validation / resolving issues. *We've got a list of education
institutions, which we think is accurate on the whole. However, there are
also some errors. It would be great for us to have an app that could
validate locations (as a "friend sourcing" or "crowd sourcing" exercise).
You upload a set of locations into the app, and (over time, as a user
travels to a location) the app asks: "Are you now near XYZ school? Yes/no".
Over time, that would allow us to validate a large data set.
Similarly, extra information about map issues could be collected. E.g.
Vespucci also notifies you about nearby map issues, which is great.
However, on the whole the app has a different audience from what I have in
mind. So just the notification part of Vespucci, with the ability for the
user to respond.
*(B) Street names (and other POIs).* In some places there are roads, but
they don't have names (when the local roads do have street signs). Users
may be willing to contribute street names. Similarly, POIs could be added
in this way. E.g. the POI contribution in OSMAnd is useful, but ideally an
app would only have the "POI submission" feature.
Either the app shows the OSM tile or perhaps just a list of local POIs
(with geo-intent to visualise in other app). The user types name and POI
type, and data is submitted (with GPS accuracy). Optionally, the user might
answer some more questions, depending on the POI type (like opening hours,
etc). Also, perhaps the data is not added to OSM automatically, but perhaps
to a "crowd layer", where map editors then transfer the data
[OSM-dev] Simple app for "making contributions" (not to display maps)
Hi all, first post to the list - hope this is of interest. The background to my question is working is areas where map coverage is poor (e.g. parts of Africa). Sometimes only low-res satellite/bing imagery is available, sometimes obscured by clouds. In some low populated areas a GPS trace could be useful to map out roads connecting settlements (despite inaccuracies of GPS). There are many great OSM apps out there, including apps for recording traces (e.g. OSM tracker, etc). However, unless I've missed it, I would say that none of those apps is suitable for the "non-technical" user. Indeed, we've tried using various such apps, and it's been difficult in terms of usability. Is there interest in (or is anybody working on) creating an very simple-to-use app that allows "non-technical" users to contribute OSM information? E.g. a large red button for recording a trace with automatic upload (optimised for poorly internet connected environments, e.g. wait for wifi, upload in chunks etc; information submitted with GPS accuracy information). (There are of course issues with GPS traces, so perhaps automated capture of GPS traces is not that useful.) Many thanks! Bjoern ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
