Tomasz_W's diary

Recent diary entries

Make OSM-Carto brighter

Posted by Tomasz_W on 28 September 2018 in English (English)

Few days ago I started playing with OSM-Carto leisure=park colour in Photoshop, because I find it too “crappy” for modern design standards and too blueish. Then I changed @leirure-fill colour to lighter, matching future amenity-fill colour (see: I think those are 3 (@amenity-fill, leisure=park, @leisure-fill) areas that should be made more prominent as they are almost always smaller and more interesting city part than eg. landuse=residential or landuse=industrial. I also added possible new colours for landuse=allotments (see: and natural=scrub (see:

There are many voices that current version of OSM-Carto is generally too pale, so making some elements brighter seems awaited. After changing colours of areas mentioned above, roads became less prominent. There was also some voices on Github, that we should make them brighter, so I tried also with it.

Colours used:

  • amenity-fill: ffffe5

  • park: 9df29d

  • leisure-fill: f2fff2
  • secondary road: f2e76d
  • primary road: f2c66d
  • trunk: f2996d
  • motorway: f2786d

Some before/ after screens (please notice that they are just Photoshop mock-ups to show the idea, so there are small errors like a little bit invalid outlines around footways in parks) Click to see full size!

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

What do you think about this direction for OSM-Carto style? :)

Coders needed for adding prepared icons to OSM-Carto

Posted by Tomasz_W on 17 July 2018 in English (English)

There is a lot of prepared and approved SVG icons for OSM-Carto just wainting to be added, but there is unfortunately also lack of people ready to add these new features. We would like to invite you to improving default OSM style.

Here is a task list:

Coding instruction links:

You can also ask for any help in certain tickets and PRs :)

Areas rendering order

Posted by Tomasz_W on 2 September 2017 in English (English)

Current rendering order makes some bugs or problems with displaying data.

Examples: (piece of landuse=forest missing on landuse=grass) (piece of landuse=residential area protrudes over landuse=meadow)

I took and concider all tags from landuse=* , leisure=* , natural=* and tourism=* keys, which are allowed to map as areas, and analyze them, trying to order logically as layers.

Main assumptions:

*Waters and rock/ stones above green landcovers

*Higher plants above lower plants

*Physical coverage areas above areas describing terrain usage

*Treating parks and village greens as groups of unspecified plants

Problem to solve:

An unavoidable direction which is OSM moving towards is more, and more precision. This means eg. covering an amenity=* areas by physical elements like buildings, grass or pitches. Then this cultural amenity=* or tourism=* areas becomes unvisible, and the only thing left is a label text. The same thing happens with parks overdrawn by certain types of plants, what causes loss of area park-status information, and loss of park borders information.

Examples: (barely visible amenity=hospital) (amenity=kindergarden with grass pieces missing) (barely visible amenity=school) (barely visible leisure=park) (barely visible leisure=park)

In my opinion, way_area key works good only between physical man-made landcover areas (group 5 on my list) and physical natural landcover areas (group 6). For example: small amenity=parking is rendered above large landuse=forest in the suburbs, but on the other hand, small landuse=grass pieces are rendered above larger amenity=parking area in the cities.

I very like the way, how landuse=military is rendered. That half-transparent color overlay (even without skew stripes) allows to show both things - physical landcover and area usage information - at once (example: ). I think we should discuss using this method for all areas from groups 3 and 4, or, at least, discuss darker outlines like there are now around amenity=zoo areas (example: )

List description:

I divided all of tags (treated only as areas, not points or labels) to 8 main groups. If something is listed in one string, it means that this elements are equal, and shouldn’t be mapped one on another. Proposed layers list begins from the highest to lowest level.

1) Waters:

1.1) Natural=wetland

1.2.) Landuse=basin, Landuse=salt_pond, Leisure=swimming_pool, Natural=hot_spring, Natural=water

2) Rocks, stones etc.:

2.1) Natural=rock, Natural=stone

2.2) Natural=sinkhole

2.3) Natural=scree, Natural=shingle

2.4) Natural=bare_rock

2.5) Landuse=quarry

2.6) Natural=glacier

3) Partly-physical, man-made areas:

3.1) Amenity=* (all amenity areas excluding 5.2. group), Landuse=cemetery, Landuse=military, Leisure=dog_park, Leisure=golf_course, Leisure=miniature_golf, Leisure=sports_centre, Tourism=*

4) Partly-physical, natural areas (unspecified type of landcover/ plants):

4.1) Landuse=village_green, Leisure=park

5) Physical, man-made landcovers:

5.1) Landuse=landfill, Leisure=fitness_station, Leisure=pitch, Leisure=playground, Leisure=stadium, Leisure=track

5.2) Amenity=bicycle_parking, Amenity=motorcycle_parking, Amenity=parking, Amenity=shelter, Amenity=taxi

In case of collision between groups 5 and 6: way_area key, taking the highest one tag from each group (if there are more than 2 areas overlapping)

6) Physical, natural landcovers (certain types of landcover/ plants):

6.1) Landuse=forest, Natural=wood

6.2) Landuse=orchard, Landuse=vineyard

6.3) Landuse=farmland

6.4) Natural=heath, Natural=scrub

6.5) Landuse=meadow, Natural=grassland

6.6) Landuse=plant_nursery, Leisure=garden

6.7) Landuse=grass

6.8) Natural=mud

6.9) Natural=beach, Natural=sand

7) Non-physical landuses:

7.1) Landuse=allotments, Landuse=brownfield, Landuse=commercial, Landuse=construction, Landuse=depot, Landuse=farmyland, Landuse=garages, Landuse=greenfield, Landuse=greenhouse_horticulture, Landuse=industrial, Landuse=port, Landuse=railway, Landuse=recreation_ground, Landuse=religious, Landuse=residential, Landuse=retail

8) Geographical regions:

8.1) Natural=bay, Natural=cape, Natural=fell

Some of these tags are not rendered now, but I included them on a list, because they could be rendered in a future (eg. Leisure=fitness_station). I’m not sure is it everything, so if I missed some rendered tag - let me know in a comment.

5 dreams/ proposals for OSM headquarters (please comment)

Posted by Tomasz_W on 7 September 2014 in English (English)

1. Change default Mapnik style

Terrible Mapnik style has to be heavily refreshed or changed. It looks like from ‘00 years and it deterring people from OSM. We have 2014 and design trends has changed since then. In my opinion MapSurfer style is the best alternative. It’s beautiful and renders more tags than Mapnik.

check MapSurfer style here:

2. Unflattening the map

Imagine interactive OSM - you click on a restaurant building or icon and balloon with opening hours, website etc. shows up, you click on a church and balloon with religion, denomination etc. shows up. Today most of the tags are “hidden”. There are some services based on OSM which are showing details but they are barely unknown outside OSM community. OSM is a huge database which contains a lot of informations but they are wasted now.

3. Extend thematical maps

On we have 3 thematical layers and:

  • bike map could be “tourist map” with bike and hiking trails, emphasized tourist attractions like museums, viewpoints, castles etc.
  • public transport map could be “public utility map” with public hospitals, schools, offices etc. emphasized
  • humanitarian map could be “danger map” with shelters, ruins, military buildings etc.

4. Promote offline OSM for mobiles

I’ve got Locus with offline OSM on my phone, but I find (unofficial) website with offline OSM maps for download very late. OSM should standardize one extension of offline map filetype for different apps like Locus or OsmAnd and make official website for downloading this maps, linked on Offline OSM is great because you can save money instead pay for internet on your phone, unfortunately I think very few people know about offline OSM possibility.

5. More boldness :)

I’m using OSM since 2012, and changes or updates which I can see are barely visible. More boldness with making OSM better :)

Location: Garbary, Chwaliszewo, Stare Miasto, Poznań, Greater Poland Voivodeship, 61-869, Poland