It is one year since I was elected to OSMF board.

I am recording time spend on some things, including time spend on things resulting from being on OSMF board.

So I can report that since 2022-12-09 it was 355 hours.

It records time spend on what I do as result of being on OSMF board. So it excludes for example time spend on mapping and StreetComplete development. And it includes time on some things that I could complete without being on OSMF board like some attribution-related activities - that I do as result of being on OSMF board.

I have seen on tagging mailing list and some other places claims that deprecated tagging schemes continuing to be used are a critical issue.

I also have seen claims that having two tags with the same meaning is a critical issue that cause very big problems.

---

In my experience as mapper, someone working on OSM editors, someone working with OSM data:

Deprecated tagging schemes continuing to be used are not a big problem or a serious issue.

There are some tags that should be never used ( https://wiki.openstreetmap.org/wiki/Key:class:bicycle is a good example of something that is pure waste of time, see for example https://github.com/streetcomplete/StreetComplete/issues/2210#issuecomment-726974964 ).

But pointless tags can be completely ignored if they are truly bad ideas.

Note that popular tag which is not fundamentally bad idea and someone wishes to get rid of them is just regular duplicated tag for basically all purposes.

---

Duplicated tags with the same meaning.

For data consumer it is not a big issue. It is a bit annoying, but as long as new tags do not keep appearing then simple alias solves approximately all the problems.

It can be described as a problem but is definitely not in top 10 issues for data consumer. Maybe not even in top 50.

And is basically eliminated by decent documentation, if one exists at OSM Wiki.

For implementing it in editor - it depends on an exact case and definitely can be annoying.

But the worst part is case when group A demands to deprecate one tag, and group B demands to deprecate tag B. Or when one group accuses someone of being destructive because they followed documentation/consensus that documented some tag as deprecated/not deprecated and situation suddenly changed and another group appeared.

Overall this is quite ironic: people wishing to deprecate, rename, change tags often argue to be doing it to help data consumers.

While existing data consumers overall prefer stability of tagging schemes and this changes rarely make job easier for data consumers. And nothing is as irritating as discovering that you are blamed for using bad tags that month ago were perfectly fine and you need to again research situation and whether there is actual change in consensus or is it a single person (or small group) with strongly hold opinions presented as a consensus.

---

For mappers: removal of duplicate tagging schemes makes the biggest improvement to mappers starting to use given topic. For example I remember my confusion about which way merged but segregated footway + cycleway should be tagged.

But deprecated or duplicate tagging schemes existing are not critical issues, if OSM will disappear it will not be caused by fact we have both contact:phone and phone tags in use.

---

This post was triggered by “This attitude reminds me of those who oppose measures against climate change.” on mailing list (threads: 1 2). I would say that this attitude is closer to people that seen topic described as “This will decide future of the world” and discovered that debate concerns color of a bikeshed.

I participated in many tagging discussion and will continue to do this, but lets not overstate importance of tagging schemes. Existence of substandard tagging schemes is NOT a critical issue, it is NOT ever going to be the most important thing, phone vs contact:phone it is NOT worth reraising again given clear lack of consensus and no indicator that anything changed. And distinct lack of an actual importance.

Though I would be happy to deprecate contact:phone and several other tags.

---

To repeat: “something that you are using just got deprecated” is a guaranteed way to annoy any programmer. Works well also for manager in a large company.

If anyone claims that we need to deprecate heavily used fundamental tags to make large companies treat OSM more favourable, then I am going to doubt about their familiarity how they actually operate. To leave aide question why we should care about such opinions, even if actually existing.

https://wiki.openstreetmap.org/wiki/Editor_usage_stats has some interesting parts for 2021

• iD use continues to increase by percent (both edited objects and distinct users)
• iD by number of distinct users dropped from all-time-height in 2021
  • end of lockdowns? OSM slowing down? 2018 to 2019 also dropped, this year JOSM edit volume went from 996 million to 905 million edits
• JOSM still used for over 50% of all contributed edits by objects
• StreetComplete is the second most popular editor (by number of distinct users), usage almost doubled
• StreetComplete is still almost not noticeable by edited object volume - 0.8%
  • but last year it was 0.3%, it tripled to 12 million edits
• failed import and its revert is the second most popular editor, by count of edited objects
  • 1.5% of all edits in 2021
  • https://forum.openstreetmap.org/viewtopic.php?pid=760818#p760818 is an example of what was imported
• new editors: Organic Maps
  • ok, “new” as it is MAPS.ME fork
  • and that failed Finland forest import
• MAPS.ME continues to die, also as an OSM editor

StreetComplete is an application allowing to contribute to OSM by answering simple question. It makes possible to contribute without learning about tagging schemes and without learning how to handle interface of more general editor like JOSM, iD or Vespucci.

I contributed to StreetComplete in past. Recently I received a grant that will allow me to spend more time on improving it.

Grant is funded by a NLnet as part of NGI Zero grants. StretComplete grant is mentioned by NLnet at https://nlnet.nl/thema/NGIZeroDiscovery.html and https://nlnet.nl/project/StreetComplete/ pages. It will allow me to spend far more time on improving StreetComplete.

I will participate in project as usual, sending pull requests that will be reviewed and accepted (or rejected) by StreetComplete author, Tobias Zwick and minor changes commited directly (and still subject as review).

Note that I selected topics of work to be done (based mostly on open issues on the bug tracker) on my own, and it was accepted without any requested changes. I am sole beneficiary of the grant.

Total grant will depend on how much I will manage to do before deadline.

See https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849 for earlier, very similar entry.

I created https://wiki.openstreetmap.org/wiki/NLnet and submitted it OSM weekly as it seems to me that other OSM projects also may be funded.

I made https://mapsaregreat.com/osm_to_svg_in_browser/ that can be used to generate vector maps in SVG format.

Generated maps can be downloaded. This allows much easier reuse of OSM data in some cases. For example where someone needs OSM geometries of relatively small area, but existing tools are too complex for them[0]

It will likely work well for tiny and small areas, it will definitely fail for very large areas.

It is very experimental, feedback is welcomed!

https://github.com/matkoniecz/lunar_assembler/issues has list of known issues and is best place to report existing issues, but feel free to simply leave comments also here.

I am also working on making easier to make own map styles. It is already relatively easy, but documentation is missing.

[0] For many people Overpass Turbo, databases, filtering OSM data will be far too complex.

---

PS It was created as part of one of parts of https://wiki.openstreetmap.org/w/index.php?title=Microgrants/Microgrants_2020/Proposal/Tactile_maps_for_blind_or_visually_impaired_children

I was working on making generator of SVG file accepted by laser cutters, and noticed that what I am creating can be a bit more generic and accessible than initially planned tool.

Current tool is an experimental proof-of-concept with some of features that I need.

I know that tools consuming OSM data and producing SVG images exist already, but according to my research none were at once

• working in browser
• not requiring install of any extra software
• allowing easy export of a generated image
• relatively easy to implement own map styles

or easily modifiable to fit all this requirements at once

I somehow suspect that such tool may be existing already - in such case please let me know!

PPS Thanks for Overpass API! Without Overpass it would be unable to work and would require me to install, setup and maintain database replicating OSM data what is beyond my abilities.

StreetComplete is an application allowing to contribute to OSM by answering simple question. It makes possible to contribute without learning about tagging schemes and without learning how to handle interface of more general editor like JOSM, iD or Vespucci.

I contributed to StreetComplete in past. Recently I received a grant that will allow me to spend more time on improving it.

Grant is funded by a NLnet as part of NGI Zero grants. StretComplete grant is mentioned by NLnet at https://nlnet.nl/thema/NGIZeroDiscovery.html and https://nlnet.nl/project/StreetComplete/ pages. It will allow me to spend far more time on improving StreetComplete.

I will participate in project as usual, sending pull requests that will be reviewed and accepted (or rejected) by StreetComplete author, Tobias Zwick.

Note that I selected topics of work to be done (based mostly on open issues on the bug tracker) and that Tobias who will review pull requests remains completely independent - I am sole beneficiary of the grant.

Total grant was 5000 euro.

I have written a short text about what people are doing in OSM. I am curious whatever others would use the same taxonomy.

OpenStreetMap is a large decentralised project. There are thousands of people who participate for various reasons.

Mappers, people mapping the world are the most important group. They collect various information and enter it into the OpenStreetMap database - for example location of playgrounds, shapes of forests, routes of hiking trails, street names and many more.

But to make it possible it is necessary to maintain various software and hardware. It includes creating and improving editor programs used by mappers, maintaining OpenStreetMap servers and website.

Collected data is used by many people for various purposes in their projects - displaying maps on websites, using it as one of the sources in flood preparation plans, making private offline maps for various devices - GPS units, smartphones etc. There are also many, many other uses - for example, I am making a 3D map for the blind using OSM data.

And there is the largest group - people that benefit directly or indirectly from projects powered by OpenStreetMap data - they may be using maps more accurate and cheaper than alternatives, they may be rescued by firefighters using OpenStreetMap data to get to the site of an accident or watch a movie with a cool map in a background made using OSM data.

But reality is always more complicated than expected, and decision how to describe some features is not straighforward. There are people inventing, discussing and documenting ways how the world can be described and mapped.

There are also many projects that are helping mappers, developers and data consumers. One of the most prominent ones is taginfo that provides very useful statistics about tags used in OpenStreetMap. There are also QA tools detecting common problems in data like Osmose and tools making access to OSM data easier (Overpass Turbo is a great example).

Groups mentioned so far may be split into subgroups in various ways. Mappers may be split by what, how, why and where they map.

People creating software may be additionally split by their role - they may be programmers, translators, reporters of bugs, graphic designers.

There are also many other roles not mentioned in this brief overview - people who fund hardware for OpenStreetMap servers or development of various helpful software, people promoting OpenStreetMap, vandals attempting to damage data, people countering vandals and reverting their damage.

Mentioned groups are fluid. One person may be a mapper of local hiking routes, participate in discussion how colour assigned to hiking routes should be mapped, encourage friends to use detailed maps made using OpenStreetMap data and from time to time donate to fund for maintaining hardware running core OSM services and other necessary expenses.

(please, comment if there are some typos, anything unclear or something important missing)

It was originally published at my website.

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):

driver.set_window_size(1024, 768)
driver.get('https://www.openstreetmap.org/#map=10/54.2066/-4.5782')
#hide banners about SOtM and other spam
for popup in driver.find_elements_by_class_name("close-wrap"):
    popup.click()
driver.save_screenshot('Isle-of-Man.png')

overpass turbo screenshots are a bit trickier when we want to display query results

def smart_overpass_capture(url, image_file, driver):
    driver.get(url)
    element = WebDriverWait(driver, 10).until_not(
        EC.presence_of_element_located((By.CLASS_NAME, "loading"))
     )
    driver.save_screenshot(image_file)

smart_overpass_capture('http://overpass-turbo.eu/s/zNL', "Nepal-glaciers.png", driver)

Overall it turned out to be much easier than expected, and now to update all images I need to run just a python script rather than fiddle with pixel alignment and crop images to an exact size.

One nice part is to add proper image comparison to git - I used method described at http://www.akikoskinen.info/image-diffs-with-git/. It is not ideal, but it is good enough for me.

I still have to figure out how to automate generation of animated images showing usage of interface. This would allow to easily tweak and improve such animations without manually recreating everything.

*if you have time or are interested in how on may extract data from Overpass Turbo - feel free to write to me how it may be improved (by OSM message or by comments of this 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?

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.

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

• more non OSM data - what would run contrary to attempts reducing usage of external sources. It may be even considered as misleading given that OSM has no terrain data.
• Default map already renders many things. Adding something completely new to render would need really good justification and would be very complicated to do well
• To render elevation data source of worldwide elevation data on suitable license is necessary. Some data is available but either it requires major work to fix voids/peaks/pits (see http://www.imagico.de/map/aster_gdem.php http://www.imagico.de/pov/earth_srtm.php http://www.imagico.de/map/srtm1_en.php for some examples of complication). There are some sources with this problems partially fixed - http://srtm.csi.cgiar.org/ and http://www.viewfinderpanoramas.org/dem3.html seem to be the most popular, but both have a problematic copyright status. First has “Users are prohibited from any commercial, non-free resale, or redistribution without explicit written permission from CIAT”, second claims that “Elevations and contour lines are facts that should be ineligible for copyright”. While I agree that this should be ineligible for copyright I am not sure whatever these data is eligible for copyright (or fall under equivalent laws). AFAIK it is likely to be covered under database rights (collection of data may be protected even if individual entries are not copyrighted and there is no creative work involved).

See comparison of maps in a basic sample.

Landmarks

The previous comparison is revealing also another weakness in openstreetmap-carto - it is not capable of diplaying landmarks earlier. Google maps is fairly good at this - though with results badly affected by fact that “business paid for advertising” is one of criteria for landmark. Sputnik is trying, sometimes with fairly good results, sometimes with rather poor. But this problem is mostly affecting higher zoom levels.

On lower zoom levels mostly two types of landmarks are visible - “the highest mountain in region” visible above gives quite good results.

Sputnik seems to be also quite good at deciding which airports should be rendered. There are some mistakes, but overall their algorithm works fine. See Atlanta or Bogota with cluster of airpots to the west and cluster of airports in the eastern direction.

It is interesting whatever solely OSM data is used here.

See “Too many tiny private airports on the map at small scales”.

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 https://www.openstreetmap.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 https://www.openstreetmap.org/note/630900#map=13/34.8597/-95.8650)

See http://wiki.openstreetmap.org/wiki/Key: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.

Image by Basil D Soufi, CC-BY-SA license.

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.

z11

z10

z9

z8

z7

z6

z5

I ma not entirely sure about dots and I will certainly experiment with tweaking them, but I am happy with new sizes for city labels.

Additional before/after are available at https://github.com/matkoniecz/before_after_for_placenames

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.

Visualisation are available for z18

z14

z8 .

I selected Weybridge as location as map of this place was the first OpenStreetMap-based map to go on Wikipedia.

Feedback

As usually testing and review is welcomed for open pull requests, especially one considering rendering names for barriers and an associated popular tagging mistake.

I am considering to look more for inspiration/comparison in printed maps. I looked for online sources and for now I found surprisingly small number of contemporary maps that would display sort-of-similar set of symbols as Default OSM style, with scale within z5 - z10 range.

From promising findings I caught David Rumsey Map Collection and Wikimedia Commons (enabling CCI allowed to find something).

But I found nothing highly useful. For now

https://commons.wikimedia.org/wiki/File:Florida_topographic_map-en.svg https://commons.wikimedia.org/wiki/File:Scotland_map-fr.jpg https://commons.wikimedia.org/wiki/File:Scotland_topographic_map-fr.jpg https://commons.wikimedia.org/wiki/File:Deutschland_%C3%9Cbersichtskarte.png

are the best. Is anybody aware about maps or database of maps allowing to find maps similar in content to Default OSM Style, with scale within z5 - z10 range?

Thanks

Thanks to Paul Norman for simplified osm2pgsql database dump. Without that resource obtaining database for lower zoom levels would be far more complicated.

this entry is copy of http://wiki.openstreetmap.org/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: http://www.openstreetmap.org/way/25453184

state before mechanical edit:

highway=footway
surface=woodchip

state after mechanical edit:

highway=footway
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 http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny/surface%3Dwoodchip_to_surface%3Dwoodchips “

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:

https://www.openstreetmap.org/note/3796521 - there was a building. Then it was demolished. But somebody, instead of deleting it from OSM (or maybe temporarily converting it into note=”there was building here now it is demolished”) decided to add demolished=yes. Or existing building carries demolished=yes

http://www.openstreetmap.org/relation/1918067 - railway=route tagged on highways and footways. To detect that this is not a railway route but original research about line that was closed over 80 years ago one would need to process “note=abandoned railway” or “railway:end_date=1931”

In many cases (like this two cases above) correct mapping is no mapping whatsoever. What existed in past and is not existing now should not be mapped in OSM (see http://www.openstreetmap.org/welcome - “What it doesn’t include is opinionated data like ratings, historical or hypothetical features, and data from copyrighted sources.”).

In other cases objects should not be deleted but retagged. For example in really rare cases mapping proposed roads makes sense. Maybe some proposal for constructing footways are also verifiable. But in that case use [highway=proposed, proposed=footway] rather than [highway=footway; proposed=yes]. At least normal data users will not be mislead into displaying proposals as reality. (and yes, somebody did it - see http://www.openstreetmap.org/way/53821342 ).

It is OK to map objects under construction. But [highway=footway; construction=yes] is the best method to irritate data consumers (real - see http://www.openstreetmap.org/way/281018186#map=19/51.50653/-0.01904). Use [highway=construction; construction=footway] instead.

And good luck with interpreting [construction=yes; railway=tram_stop; start_date=2012]. Is it construction that was supposed to end in 2012? Is it construction that was supposed to start in 2012? And almost everybody will process it as an existing tram stop. It would be better to avoid mapping http://www.openstreetmap.org/node/1049342953#map=19/53.47988/-2.15500 until it was really constructed (or use something like [construction=tram_stop, end_date=2012])

Note that some tags may be OK or trolltag depending on how it is used. For example abandoned=yes. It is perfectly OK to add it to building - after all, abandoned building is still building. But using it on shop=supermarket to indicate that shop is no longer operating and it is impossible to buy anything there (in other words - it is no longer a shop) is not OK and should be tagged in proper way (typically - by deleting shop=supermarket).

Disclaimer - trolltags are frequently not processed and ignored. As result it is typical that [highway=motorway, construction=yes] is no longer under construction and may be used. This type of issues as usually requires survey on the ground to be properly fixed.

And you may use this overpass query to detect more in your region - http://overpass-turbo.eu/s/bcS (it includes tags that nearly always are trolltags - but certainly some false positives will appear. For example vacant=yes is fine for building).

EDIT: https://wiki.openstreetmap.org/wiki/Trolltag was created (see https://wiki.openstreetmap.org/w/index.php?title=Trolltag&action=history )

EDIT2: 2023-07-24: some examples were updated as links become confusing

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

• better rendering for highway=path/footway/cycleway - this is the next iteration of improving how footways and cycleways are displayed. Unpaved footways are now visible on natural=bare_rock and there are now three classes: paved, unpaved and unknown surface #1788
• man_made=bridge is now rendered #1633, #1791
• new rendering for landuse=quarry #1696
• amenity=veterinary is now rendered #1656
• amenity=community_centre is now rendered #1744
• amenity=prison and landuse=military rendering takes in account area size #1739
• consistent color for boundaries #1773
• tweaked zoom level for amenity=car_sharing #1762 and amenity=car_rental #1761
• Mapnik 3 preperations are now finished. The style now supports Mapnik 3. Most of the work was done on the Mapnik side. #1792

A full list of changes can be found on Github.

Style for footways and cycleways is not ideal and there are some known problems (see #1793 and #1748). Pull requests that would solve this issues are welcomed.

It is a good idea to check whatever bridges in your region are tagged for renderer - mistagging bridges as buildings is quite popular (only rare constructions fit definition of building=bridge - building=bridge is brown and man_made=bridge is gray).

For people interested in adding surface tags in their area - here is a helpful overpass query (zoom in before using “Run” button): http://overpass-turbo.eu/s/b88 This query return ways without surface tags and ones tagged with tags not documented as valid surface values. Only ways with highway=footway/path/cycleway are displayed. In nearly fully mapped regions one may modify query to search for missing surface also for other highway types.

As always, we welcome bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues where they will be tracked.

Previous release announcement: http://www.openstreetmap.org/user/pnorman/diary/35589

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

Brussels

Iceland, Reykjavik

India

Japan

Malmo

New Jersey

Rural UK

Russia

z11 will be now using casingless style, especially as attempt to improve casings on low zoom by reducing it failed to solve problems with pixelated casings and managed to create new.

highway=pedestrian/living_street is this comparison was set to pale gray/gray version. Reported problems were fixed, resulting in new shield colors, tweaked road color and subtler casings. Thanks for the feedback!

This comparison is using latest version of style, newer than one used on the OSM website. The most important change is the new forest style.

For start: place that had problem with too strong casing resulting in problems with bridge that was not sufficiently different from other sections of roads. It is now improved - and now it should be OK.

What is preferable? Large images or smaller ones next to each other (like in the previous entry)? Or maybe big pictures next to each other - but available as links and not inlined (like many in this older entry)?

Problems

Default OSM style is displaying huge amount of information. Here is image of displayed road types on some of landcovers. Note that due to size limitation effects of service tags (that would tripple different road styles) are not displayed.

Full image

New road style fixes problems with certain road types invisible on common landcovers, but there are still some situations where road is too close to landcover. Unfortunately, as result of huge amount of landcovers it is not easily fixable - but new problems are a bit less severe than old “trunk is invisible in forests, secondary is invisible on farmland”.

highway=motorway through landuse=military is poor

highway=secondary shield is almost the same as the heath color

highway=secondary is close to natural=beach

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?

http://www.openstreetmap.org/#map=11/-23.6260/-46.6878 http://www.openstreetmap.org/#map=19/-23.47256/-46.62624