OpenStreetMap logo OpenStreetMap

Mateusz Konieczny's Diary

Recent diary entries

During making documentation of OSM tools and software it is frequently useful to add screenshots. Especially tutorials are often featuring multiple ones. I always disliked that such images are frequently getting outdated. It may caused by interface changes, map style changes and edits to OSM data.

Sometimes it requires more significant update of documentation, sometimes updating images is enough. But it may be very time-consuming.

When I was making my Overpass Turbo Tutorial for newbies* I wanted to find a way to make such images easy to recreate.

I found an interesting solution. Selenium is a software usually used for testing websites. It has plenty of features but interesting here is is that one may write a simple script that will

  • open a website
  • wait for it to load
  • take a screeenshot

This way it may be possible to generate and recreate screenshots without manually taking them.

There is plenty of way how Selenium may be used, I am using Python bindings connected to Firefox using geckodriver.

Time-saving code is relatively simple.

imports:

from selenium import webdriver
import time
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

Lets say that I wanted an example of a simple website. This code will take a picture of googling results and save it to a specified file.

driver.get('https://duckduckgo.com/?q=wetland+OSM+Wiki&ia=web')
driver.save_screenshot('wetland-search-results.png')

Following code sample will modify vieport size and interact with page to hide irritating banners, then take a picture of site (note that such use is also subject of Tile Usage Policy like other automated tile downloading, but for regular tutorial updates use will be not higher than human doing the same):

See full entry

Fortunately I am typically editing area that is not a victim of landuse imports.

Unfortunately today I am trying to fix area affected by at least two landuse imports

As bonus, one is using mysterious undocumented CLC:code, CLC:shapeId tags that are not documented anywhere and it is not clear what one should do with them on modifying and merging areas with them.

Is there anywhere at least one large-scale import of landuse data that was done properly?

Using Wikidata data, fixing wrong wikipedia and wikidata tags

Posted by Mateusz Konieczny on 26 September 2017 in English. Last updated on 27 September 2017.

I invite everybody interested in

  • using data wikidata to add more data to OSM
  • fixing wikipedia tags
  • fixing wikidata tags

I would be happy to generate reports for your local area. It is possible to generate report about specific region (and I know that many people are interested primarily in fixing area they know well). Example report is at https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Bremen,%20Deutschland.html (full list of locations with currently available reports is at https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/ )

Feedback is welcomed, especially from people who looked at the site and decided to not use it - what went wrong? Also feedback from people using reports would be useful.

I already added and improved how reports work based on requests. For example, I added overpass querries usable in JOSM that skip already fixed objects.

This tool is likely to be useful - it was already used to improve thousands of objects in Poland - special thanks go to wmyrda, rmikke who fixed massive amount of objects (thanks also to everybody else who used this reports).

This is the first part of comparing openstreetmap-carto and other map styles. Note that comparison is focused on finding things that may be improved in openstreetmap-carto.

Relief data

All maps in my basic sample turned out to show relief data. It ranges from subtle, almost unnoticeable to extremely heavy and dominating over all other features. Is is open question whatever adding rendering of elevation data to openstreetmap-carto would be desirable. But it is clear that rendering elevation data is common, and in some cases effect is great.

i

But even assuming that it would improve map there are some complications:

See full entry

There is one common tagging problem - missing service tags on minor railways. It leads to a poor rendering on lower zoom levels, as renderers are rendering minor service tracks like important railways.

It is quite easy to spot places that require fixing by browsing map on lower zoom levels - see for example osm.org/#map=7/34.840/-95.902

This place at times of writing has noticeable bundle of rails near McAlester, indicating place where somebody mapped minor railway tracks without marking them as minor (note for this case is at note/630900#map=13/34.8597/-95.8650)

bundle

See service=*#Railways for documentation how service tags should be used for railways. Note that remote mapping generally is not feasible as result of subtle differences between yard and siding.

See full entry

GSoC 2016 - marking cities

Posted by Mateusz Konieczny on 19 June 2016 in English.

It is typical for maps covering large areas to display city labels. It is quite common to mark exact locations by displaying dots, circles or other symbols.

It also seems that labels for cities and towns may be displayed larger to improve the map.

I tested both ideas, without changing algorithm that selects cities and towns to be displayed. Example of before/after tested on UK are available below.

See full entry

Location: 50.000, 20.000

During GSoC 2015 I focused on improving road presentation in the Default OSM map style. This year I am again participating, but with more diverse goals. I am planning to improve performance, reduce rendering order problems and tune mid-zoom level rendering.

mid-zoom level rendering

I started with work on improvements to mid zoomlevels (z6 to z9). During search for the best and most promising ways to improve rendering, starting from trawling through reported issues. I also prepared and submitted some additional tweaks like rendering names for barriers, fixing viewpoints and forests and shops and other.

I am also like during GSoC 2015 preparing a comparison between the current map style and alternatives.

A bit of history

There are some visualisations showing how data was added to OSM. But I have neither seen nor found something similar for a map style. So, for start of next big series to the map I made a display of what was changed in the past.

See full entry

Location: 50.000, 20.000

Proposed mechanical edit: surface=woodchip to surface=woodchips

Posted by Mateusz Konieczny on 1 September 2015 in English. Last updated on 14 June 2016.

this entry is copy of osm.wiki/Mechanical_Edits/Mateusz_Konieczny/surface%3Dwoodchip_to_surface%3Dwoodchips

I plan to change surface=woodchip to surface=woodchips.

surface=woodchip is a clear duplicate of surface=woodchips. It is also less popular and undocumented on Key:surface. It would be a good idea to retag it to already documented tag before this tags are used more.

amount of surface=woodchip in OSM as of 2015-09-1 is 135.

amount of surface=woodchips in OSM as of 2015-09-1 is 228.

I’d download all surface=woodchip using Overpass API and change the tagging by search and replace using Level0 editor. The upload of the changed data I’d do in chunks to check the data once more before upload and not to create a worldwide changeset.

This would be a one time edit.

Edits will be made from account “Mateusz Konieczny: bot account”

Example: way/25453184

state before mechanical edit:

https://wiki.openstreetmap.org/wiki/Tag:highway=footway
https://wiki.openstreetmap.org/wiki/Tag:surface=woodchip

state after mechanical edit:

https://wiki.openstreetmap.org/wiki/Tag:highway=footway
https://wiki.openstreetmap.org/wiki/Tag:surface=woodchips

Changeset comment would be “ changing surface=woodchip to surface=woodchips as surface=woodchip is less popular duplicate. This mechanical edit is documented at osm.wiki/Mechanical_Edits/Mateusz_Konieczny/surface%3Dwoodchip_to_surface%3Dwoodchips

Trolltags

Posted by Mateusz Konieczny on 31 August 2015 in English. Last updated on 24 July 2023.

It is not OK to use one tag (for example amenity=hotel) and add second tag that negates or massively change its meaning (for example adding involuntary=yes to amenity=hotel instead of using amenity=prison). Additional tags should clarify meaning of main tags rather than negate it.

In general, any tag tag must be processed to avoid producing false or invalid data is a trolltag.

For example somebody wants to produce map of cycleways. Simply processing highway=cycleway, highway=path with and standard access tags should be enough to avoid listing nonexisting ones. Data consumer in that situation should not be expected to check for “proposed=yes”, “demolished=yes”, “construction=yes”, “completely_fictional=yes” or “end_date=1990”.

Obviously, one may want to look for more detail - for example to show proper map of cycleways one would want to check also access, surface, oneway and other tags. But again - segment of cycleway destroyed in landslide should be removed from map rather than tagged as [highway=cycleway, surface=giant_gaping_hole, smoothness=impassable].

Adding tags like proposed=yes is a really poor idea. In case of data consumers not supporting them it will lead to invalid and highly misleading data. And data consumers supporting completely broken tagging schemes (like [highway=tertiary; construction=yes] instead of supporting just [highway=construction, construction=tertiary]) encourages usage of this tagging method. The danger is that with more and more data tagged using trolltags other data consumers will either be forced to add support for trolltags or stop using OSM data.

And possibilities for trolltag are endless. Lets say that somebody wants to display existing shops and support all tagging schemes. Good luck with filtering out proposed=yes, abandoned=yes, vacant=yes, demolished=yes, construction=yes, empty=yes, ruins=yes, parsing start_date and end_date etc etc.

Some real examples:

See full entry

OpenStreetMap Carto 2.34.0

Posted by Mateusz Konieczny on 29 August 2015 in English.

Most obrotowy w Giżycku

OpenStreetMap Carto 2.34.0 has been released and rolled out to the openstreetmap.org servers. It might take up to 48 hours before all tiles show the new rendering.

Changes include

See full entry

Location: Osiedle Kajki, Giżycko, Giżycko County, Warmian-Masurian Voivodeship, 11-500, Poland

PR

Next pull request for changing road style was opened. This time it is a final stage of proposing a rendering change including new colours for roads, new widths and rework of a railway styling. Feedback is welcomed.

PR link: https://github.com/gravitystorm/openstreetmap-carto/pull/1736

All changes before PR were squashed into two commits - as result changes done based on feedback since creating PR are listed on https://github.com/gravitystorm/openstreetmap-carto/pull/1736/commits

Casings on z11

One of repeated comments was that casings on z11 are not working well. Therefore I prepared also another casingless variant for z11. Below are test renderings for some places (current rendering, rendering from PR, potential rendering using low zoom styling for z11)

Auckland

See full entry

highway=trunk infestation in San Paulo

Posted by Mateusz Konieczny on 8 August 2015 in English. Last updated on 10 August 2015.

To anybody editing in region of San Paulo - it seems that road classification in this region is thoroughly broken (many highway=trunk that probably should highway=tertiary/secondary given how road ends etc etc). It seems that somebody tagged all dual carriageway roads in this region as highway=trunk.

I opened also some notes - is there any better method of contact with local community?

osm.org/#map=11/-23.6260/-46.6878 osm.org/#map=19/-23.47256/-46.62624

Location: Vila Aurora, Mandaqui, São Paulo, Região Imediata de São Paulo, Região Metropolitana de São Paulo, Região Geográfica Intermediária de São Paulo, São Paulo, Southeast Region, 02416-060, Brazil

New road style for the Default map style - the full version

Posted by Mateusz Konieczny on 8 August 2015 in English. Last updated on 13 February 2019.

Next stages of developing new road style are finished.

First changes all already present on OSM website as result clutter on mid zoom levels is now reduced (#1682, #1690 and #1676).

This version is the first one tested also for low zoom levels.

At the start of this preview of the new style I want to thanks everybody who offered feedback. Obviously, not every suggestion was implemented - but many were highly useful and some are used. Thanks to everybody! Special thanks to Paul Norman for simplified osm2pgsql database dump that allowed to test low zoom levels.

For start - rendering for osm.org/#map=10/50.8302/4.4769 both in current and the new style (note - missing data that is causing poor rendering of railways in Antwerp is now fixed).

See full entry

New road style for the Default map style - the second version

Posted by Mateusz Konieczny on 23 July 2015 in English. Last updated on 29 October 2018.

“map styles: Default OSM vs Google Maps” included a comparison of OSM Default map and Google maps. Now I present a similar comparison at the same location. But now with a third version - current version of new potential road style.

From left: (1) with changes developed as part of road redesign (2) currently used rendering on the OSM website (3) Google maps

Maybe it would be a good idea to make landuse=residential darker on low zoom levels to better mark built-up areas, but overall I consider this change as a significant improvement.

Changes based on feedback:

Thanks to daganzdaanda for the idea of displaying highway=tertiary as a white line, wider than highway=residential/unclassified. As tertiary roads are no longer using yellow it made possible to display secondaries using this colour, what in turn allowed to move hue of primary toward yellow.

See full entry

New road style for the Default map style - highway=path is evil

Posted by Mateusz Konieczny on 14 July 2015 in English. Last updated on 29 October 2018.

changes based on feedback (comments on diary and GitHub):

Reverted highway=footway, highway=path changes and restored currently used version. highway=motorway, highway=trunk rendering will be distinguishable. For oneway arrows old blue version also will be considered.

In addition feedback confirmed that it would be a good idea to: render motorway junction labels in red and rework widths of roads.

Example of the current rendering of pedestrian area (left - current rendering, right - proposed new rendering). highway=footway styling was rolled back, but highway=pedestrian/living_street is changed.

pedestrian_living street in bratislava master-_new-road-style 18 18 350px master - new-road-style

Request for a testing place

I am looking for a well mapped place where displaying highway=residential on z10/z11/z12 makes sense and is desirable. I am also looking for a place where rendering highway=unclassified at z10 is a good idea. According to my tests rendering these roads later improves situation, except places with badly mapped road types (highway=residential linking towns etc).

See full entry

New road style for the Default map style - the first version

Posted by Mateusz Konieczny on 8 July 2015 in English. Last updated on 17 July 2018.

The first version of the road style is prepared. It is a work in progress and feedback is welcomed. I started work from designing z16 zoom level, currently I am expanding style to cover higher and lower zoom levels.

Current rendering (preview location from openstreetmap-carto readme) preview master -87 6515 41 8693 -87 615 41 8788

See full entry

map styles: Default OSM vs Humanitarian

Posted by Mateusz Konieczny on 10 May 2015 in English. Last updated on 17 July 2018.

Humanitarian map style is in some ways between current Default OSM style and Google maps style. It is not using so many colours for roads as openstreetmap-carto but still more than Google maps. The same may be said about how quickly minor roads are disappearing and some other choices unrelated to displaying roads.

As result Humanitarian style is also better at lower zoom levels than openstreetmap-carto - again mostly thanks to a subtler display of minor roads and not using all possible colours to display roads.

Not so wide roads also work better especially in areas with high road density.

It seems that main reason for really wide roads in a Default OSM style is to keep street labels within road area. But both Humanitarian and Google maps have labels sticking outside road areas and narrower roads what seems to work much better. Also in areas that are not so extreme.

Kraków, Poland

See full entry

map styles: Default OSM vs Google Maps

Posted by Mateusz Konieczny on 9 May 2015 in English. Last updated on 17 July 2018.

Currently I am working on a GSoC project - improvement of styling of roads and paths in openstreetmap-carto, the default OSM map style.

I started from researching how other map styles are designed. I would welcome comments and feedback as it would allow to notice my biases. Feedback on general ideas will hopefully reduce amount of time needed to rework and tweak style that I will produce.

The first compared map style is probably the most popular one, used by Google maps.

At high zoom levels any OSM map is typically better than Google Maps as a result of more detailed and rich data. Quality of Google Maps is also decreased because one of its primary roles is to be used as a place to advertise businesses - what results in businesses appearing earlier than reasonable and leaving no place for more useful information.

But as one zooms out the situation is typically changing, with OSM rapidly losing - and the worst situation is in the cities, with roads as a major source of a problem.

For example, lets try with London.

First problems are noticeable at z16 - openstreetmap-carto has more information but is also less readable. The first road-related issue is that some oneway roads are without arrows (names are displayed instead making it one of many tradeoffs - not everything may be displayed).

z15 has much bigger problems for OSM - hierarchy of road importance is clearly more readable in Google maps. It is an effect of lower amount of displayed data and no using as many colours as possible in gmaps. openstreetmap-carto is using for displaying roads blue, green, orange, red, yellow and white. Google restricted palette to white, yellow and orange - what gives much better results.

See full entry