Rewrite buildings code

[pnorman]

This is a relatively small change in terms of code, but substantial in what it impacts.

Fixes/superceeds

Railways:
#389
#327

Outlines:
#68
#490
#533

Supermarket
#520

Building=planned
#1061

Comments in this repository have shown that the light/dark distinction of buildings is not something easily understood, let alone something someone will grasp when viewing the map.

Comparisons to other providers

I reviewed a number of other map providers, and most use something very subtle at low zooms and moderately subtle at higher zooms, and in all cases, less obtrusive than the current rendering.

Lyrk

MapQuest

Here.com

Google

Bing

Mapbox

Samples

Outstanding issues

Low-zoom industrial buildings are too subtle

I may decrease the zoom at which the outlines appear and slightly strengthen the fill, but the solution here might be to fade back the landuse=industrial fill to be more in line with residential/retail/commercial.

Roads under buildings are invisible.

Not a new issue. I'm tempted to punt on this. It also holds true for tunnels

Churches (and other place_of_worship)

In keeping with more modern tagging of the amenity=place_of_worship on either the area or combined with building=* on the church building, the grey is moved to landcover. The gray has also been lightened slightly, depending on the original colour which depends on background.

amenity on area, building on buildings

amenity and building on buildings

Place of worship, no building

Railway stations

Railway stations were strange before. They've been fixed in line with #327 (comment). Unfortunately, I can't find any great examples in the areas I've loaded.

Demos

I've loaded up a portion of the northeast United States and made a comparison at http://bl.ocks.org/pnorman/raw/c61d6b11193081910866

Please keep in mind that the rendering server is less powerful, has a limited area, and is not consuming updates.

I have a small pre-rendered area from Seattle at http://a.tiles.mapbox.com/v3/pnorman.openstreetmap-carto/page.html which is faster.

[matkoniecz]

On 14, 15 buildings are invisible - see http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#14.00/38.9870/-76.9312 http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#15.00/38.9870/-76.9312

Maybe using here low zoom level style would be a good idea?

It also makes #70 a critical issue.

I am unsure how hard it would be to render another part of the map. If it is trivial to do in your situation - can you render Kraków? http://www.openstreetmap.org/#map=13/50.0749/19.9155

[pnorman]

On 14, 15 buildings are invisible - see http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#14.00/38.9870/-76.9312 http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#15.00/38.9870/-76.9312

Not really, it's more subtle, and #243 causes it to be visually swamped. Of course, it's a mess with the footways looking like this: (old style).
The solution referenced for low-zoom industrial areas is relevant here.

Maybe using here low zoom level style would be a good idea?

Not clear what you're saying there. It is using the low zoom building style

It also makes #70 a critical issue.

I don't really see that parking is related. The same number of P's are displayed either way

I am unsure how hard it would be to render another part of the map

It's a bit of a pain, it'd require a database reload and resetting up the extents of the layer. Maybe when I update the DB, since I'm already merging multiple extracts.

[matkoniecz]

I don't really see that parking is related.

See say http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#15.00/38.9870/-76.9308

With the new style parkings are far more visible than with the old style.

Fading landuses (residential, industrial) is IMHO necessary.

Not clear what you're saying there. It is using the low zoom building style

Sorry, my mistake.

[daganzdaanda]

Wow, this has a big impact. Especially since OSM standard style has always had prominent buildings compared to other maps. This would turn this distinction around. Don't know if that's good or bad.

While I think buildings in zoom 14 and 15 should still be visible, even on landuses, they can be extremy subtle.
I like the look when there is no landuse. Buildings are there, but unobtrusive.
But with a landuse, buildings need to be darker than the landuse. This would mean all landuses need to be lightened (as mkoniecz said). It's going to be a lot of fine-tuning.

I did a very quick test in Photoshop, and a residential colour of #e5e5e5 instead of #dddddd makes the buildings a bit more visible.
But maybe the buildings could be a little darker, anyway. If they are desaturated to being nearly grey, that might work with a lot of landuse hues. I tried #d0c8c8, but #ccc2c2 even works on the current residential colour.

On close zooms, I would prefer the buildings a bit stronger. We might not even need an outline then.

If the differences are too subtle it might make the map hard to read for the elderly or on a bad screen in the sun. Too strong contrasts will make the map hard to read always ;)
Before a huge impact change like this, it's necessary to check with as many people as possible in the forums and mailing lists and so on.

[daganzdaanda]

Could buildings have a transparent colour? So that they blend better with whatever landuse below?

[dieterdreist]

Am 25/mag/2014 um 12:28 schrieb daganzdaanda notifications@github.com:

On close zooms, I would prefer the buildings a bit stronger. We might not even need an outline then.

outlines are generally desirable to distinguish a big building from lots of small attached to each other buildings

[matkoniecz]

@daganzdaanda Is there any point in doing this? I expect that it will only encourage ridiculous tagging landuses as multipolygons with buildings as inner ways.

[vincentdephily]

Eh, I'm seeing this PR right after submitting my (less ambitious) PR #568. Overall I really like pnorman's less intrusive style (the current style being IMHO responsible for a large chunk of "osm is ugly" newbie comments).

But it completely does away with "light buildings", which I think is a pity. My PR and a lot of my building-related comments concern light buildings, as I think that it's a useful thing to render. It can actually make the map more readable, the typical example being residential areas where all the garden sheds make the rendering too crowded. As a bonus, it highlights some of osm's data richness.

[Rovastar]

It is a fairly major change. Not sure if I like it - sometimes I wonder if we are just going down the lets copy Google Maps route here.

A couple of points.

"Comments in this repository have shown that the light/dark distinction of buildings is not something easily understood, let alone something someone will grasp when viewing the map."

Really? I thought this was fairly simple premise - important building are (to be) rendered darker/more noticeable (e.g. school, church, hospital, etc) and less important less so (e.g. garages,etc) . + and nothing is tagged e.g. building just as =yes then that could be rendered less prominently (to get people to tag more correctly)

One thing to remember other mapping providers often do not do this because they do have that metadata hence everything is the same. It saddens me we should go down to their levels.

Rather than give up on all the potential differing shades of building classification and make everything one washed out lighter shade I would make:

Building=yes and 'lower' classifications (garages, etc) as they are with that grey shade.
Building with a 'normal' classification (house, etc) slightly darker than you have now (halfway between your shade and the current rendering)
Buildings with a "higher" classification (church, etc) much darker a bit like we currently have.

[matkoniecz]

I am not happy about churches not rendered properly with amenity=place_of_worship on building. Is there a good reason for this?

This tagging is really rare in linked area (most churches seem to be tagged as nodes) - but synagogue at http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#18.00/38.90004/-77.01866 is a good example.

amenity=place_of_worship on building is standard tagging style in Poland (no idea about other countries).

[daganzdaanda]

@dieterdreist -- you're right, good point about outlines. So we keep 'em.

@mkoniecz

Is there any point in doing this?

You mean the idea of a transparent colour? Well, it may look good, see the mapquest example in the first post, or the mapquest layer. Of course, it will look stupid if the edge of an landuse goes through a building.

I agree with @vincentdephily and @Rovastar about the usefulness of a light variant for lesser buildings. And I also would like buildings that are place_of_worship to keep having another colour. In many towns, churches really stand out and are a great help for orientation.

[Rovastar]

My thoughts are "higher" classification would be noticeable/important like Churches, school, town halls, stations, hospitals, etc.

[matthijsmelissen]

I would suggest to resolve the building versus tunnel issue by rendering tunnels on top of houses.

The layers in between are: citywalls castlewalls castlewalls-poly landuse-overlay line-barriers cliffs area-barriers ferry-routes turning-circle-casing highway-area-casing roads-casing highway-area-fill

• Rendering buildings below citywalls, castlewalls, castlewalls-poly, cliffs, and area-barriers would be a slight improvement, I think
• Rendering buildings below landuse-overlay and ferry-routes does not matter much
• Rendering buildings under roads-casing and turning-circle-casing would definitely an improvement (buildings are already under roads-fill and turning-circle-fill)
• The main issue is rendering buildings below highway-areas. We have many areas with a building in the middle that are currently not tagged as multipolygon. Changing the rendering would require retagging al of them. However, retagging would in my opinion be an improvement, as the building is not part of the area, and retagging is needed for routing (the building cannot be crossed for routing purposes).

[daganzdaanda]

rendering tunnels on top of houses.

That sounds weird! but I get it... But we need colours for the tunnel that work whether there is a building or not. Maybe transparency could help.

The main issue is rendering buildings below highway-areas.

Agree with what you said. Highway-areas are semantically not a form of landuse, so buildings should not sit on top of them. If it were landcover=asphalt, that would be different.

[hlaw]

While lighter buildings looks more pleasant (especially at lower zoom levels, where building coverage in many places is patchy), this may not fit with the present style of high details / contrast, not only for industrial / commercial landuses but also green areas, amenities etc.

e.g. buildings does not stand out from pedestrian ways / areas, esp. against a high contrast rendering of different shades of green
http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#17.00/38.92920/-77.04964

Rendering of stadium
http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#16.00/39.2806/-76.6191

Parking and construction areas more prominent than buildings
http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#16.00/39.4108/-76.7747

That said, I think a less "drastic" watering down of building tones should be ok without redesigning the overall style - which as I understand it is deliberately rich for feedback to mappers rather than primarily for pleasant looking.

[pnorman]

I started expanding my changes to use attachments and render some POIs which were also buildings specially (amenity=place_of_worship). I didn't like it for a few reasons

1. Attachments are a pain. This wasn't a major consideration, but they are annoying.
2. We're already rendering amenity=place_of_worship as a POI through the amenities layers. If we want to increase the prominence of places of worship, that is the more appropriate place
3. We've never been rendering churches specially (aside from INT-light)
4. If we really wanted to render amenity=place_of_worship buildings differently we have to do some kind of intersection. Probably something like

SELECT DISTINCT b.way, b.building, (p.way IS NOT NULL) AS is_place_of_worship
  FROM planet_osm_polygon b
    LEFT JOIN 
      (SELECT way FROM planet_osm_point WHERE amenity='place_of_worship' 
       UNION ALL SELECT way FROM planet_osm_polygon WHERE amenity='place_of_worship') p
      ON (ST_Intersects(b.way, p.way))
  WHERE b.building IS NOT NULL

[pnorman]

To clarify, actually doing SQL like that is not an option as well as probably horrible for performance.

[daganzdaanda]

@pnorman, I'm not sure I understand correctly. Are you saying that a building=yes that has amenity=place_of_worship can't be treated differently than another building=yes?
How does the current implementation work?

Apart from that, maybe it would be good if only the building value is looked at. Building=church|synagogue|mosque|cathedral|chapel|temple|... would get rendered different. This would get people to use these special values instead of generic "yes". The amenity=place_of_worship could be used for adding a name and icon only.

[matkoniecz]

@daganzdaanda What about buildings that were build as houses and are churches (happens frequently especially with less popular religions)? What about churches that are now closed/used as house/warehouse/shops etc (growing trend in Western Europe)?

@pnorman I am confused by your link, as it seems that you are worried by performance and link to section that describes possible bit unwanted data processing. Also, what I want is in the current style.

[daganzdaanda]

What about buildings that were build as houses and are churches (or) churches that are now closed (...) etc

Yes, that's the question: "what is the building" versus "what is it used for". And what's the best way to tag it.

I think in the first group it's building=yes and amenity=p_o_w if the church only uses part of it. If the church uses all of the building, it can be re-tagged building=church even if it doesn't look like one.

In the second group, IMHO the building=church is still valid, if the building definitely looks like one. One could add disused:amenity=p_o_w to make it clear that the use has changed. If you just leave out the amenity, it may look like it's been forgotten.

...But then, would I like to have that disused church render like a normal active one just without the religious icon? Hm... don't know. Also, a church building that has been converted to apartments or office space can't have both building=church and building=apartments or office. So what would you do in that case?

[matkoniecz]

http://wiki.openstreetmap.org/wiki/Key:building

[building=church] "A building that was built as a church."

[building=apartments] "A building arranged into individual dwellings, often on separate floors."

So church re-purposed into apartments should be tagged both as building=church and building=apartments. It would be a good idea to make consistent documentation before encouraging usage of this values.

[pnorman]

How does the current implementation work?

It doesn't handle places of worship within buildings or buildings within places of worship.

@pnorman I am confused by your link, as it seems that you are worried by performance and link to section that describes possible bit unwanted data processing. Also, what I want is in the current style.

What I described in 4 is not present in the current stylesheet. The rendering for building=* amenity=place_of_worship is a strange mix of POI rendering and building rendering.

[matthijsmelissen]

As far as I'm concerned, the following issues still need to be addressed:

• Tunnels under buildings. I would propose to solve this by changing the render order, see above. @pnorman let me know if you agree and how you prefer to handle this. I can make a separate PR changing the layer order and you can rebase, or you can include it in this PR, or we can postpone it until after this has been merged. Let me know what you prefer.
• Place of worship: polygons with building=yes and place_of_worship=yes are no longer rendered different from other buildings. There are a lot of such buildings, and highlighting is quite useful for navigation. Perhaps we could use two different shades for place of worship: a darker one for buildings, and a lighter one for landuse. The first one could be handled just like aeroway=terminal, and the second could be used in the landcover layer.
• Landuse: Buildings on z15 and lower are hardly visible on top of residential and industrial landuse, The landuse probably needs toning down. Again, @pnorman let me know what is your preferred workflow to handle this.

Apart from the issues above, I didn't spot any problems in Luxembourg.

Let me know if there's anything I can do to resolve these issues.

[pnorman]

Landuse: Buildings on z15 and lower are hardly visible on top of residential and industrial landuse, The landuse probably needs toning down. Again, @pnorman let me know what is your preferred workflow to handle this.

I've been playing with making it darker, but there's an issue there as well. Right now in the PR some buildings are visible because they're lighter than some landuse. I suppose one solution is to make it darker (but still not as dark as now) and then work at getting landuse more consistent in saturation and darkness, rather than being all over the place.

Tunnels under buildings. I would propose to solve this by changing the render order, see above. @pnorman let me know if you agree and how you prefer to handle this. I can make a separate PR changing the layer order and you can rebase, or you can include it in this PR, or we can postpone it until after this has been merged. Let me know what you prefer.

I think we can do this first without any merge conflicts in this branch, and it would fix what is currently an issue as the tunnel issue isn't a regression. An opacity of 0.9 hardly lets the tunnels be visible.

Place of worship: polygons with building=yes and place_of_worship=yes are no longer rendered different from other buildings. There are a lot of such buildings, and highlighting is quite useful for navigation. Perhaps we could use two different shades for place of worship: a darker one for buildings, and a lighter one for landuse. The first one could be handled just like aeroway=terminal, and the second could be used in the landcover layer.

I'd really rather handle them in the landcover and amenity layers, rather than styling a building based on amenities within it.

[pnorman]

I've darkened it up a bit, which actually makes buildings on industrial worse. I may need to take a look at landuse more extensively.

Demo layer cache dumped, so everything there is fresh, but your browser may have cached tiles.

[imagico]

I am pretty sure that it is a bad idea - displaying only part of buildings will result in a really weird map

I don't think so, it seems worth a try. Note i am not talking about a large threshold, at max a few pixels size. Look for example at a setting like

http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#14.00/5.2814/-3.9942

where only larger buildings have been mapped - it does not look particularly weird to me. On the other hand if all buildings would be mapped there it would look truly cluttered - probably a bit like http://www.openstreetmap.org/#map=14/3.8636/11.5019. Note this is z=14, buildings are shown already at z=12/13.

[dieterdreist]

2014-11-27 10:50 GMT+01:00 Mateusz Konieczny notifications@github.com:

Use a way_area threshold for showing buildings

I am pretty sure that it is a bad idea - displaying only part of buildings
will result in a really weird map,

I agree because many small adjacent buildings can create a very dense
structure which occupies the same space than one big building would do.
This is a question of urbanism, think e.g. ancient arabic city centers.

[kocio-pl]

Current demos for New York and Cracow show me that:

1. Overall impression is nice.
2. On some darker regions (like landuse=industrial, construction or residential) buildings look strange, as if the image colours are opaque.
3. Churches/PoW look better, but other important buildings (like schools, hospitals, theatres, castles, museums, fire stations, bus/train stations, shopping centers etc) should look alike.
4. Some places, especially (school) pitches, would look too prominent given their relatively low importance comparing to buildings.

[balrog-kun]

I'm missing the slight differentation that was visible between different building=* values previously (residential vs. garage). There's a comment saying:

"Comments in this repository have shown that the light/dark distinction of buildings is not something easily understood, let alone something someone will grasp when viewing the map."

I'm pretty sure you'd need to look at the map key to know what a specific colour means, and that's the same situation as with landuses, but the differentiation is both useful and nice to look at IMO.

[vincentdephily]

Use a way_area threshold for showing buildings
I am pretty sure that it is a bad idea - displaying only part of buildings will result in a really weird map.

Both OSMAnd and Maps.me on Android do this. It makes sense on mobile for performance reasons, but it does look really weird.

[matkoniecz]

Churches/PoW look better, but other important buildings (like schools, hospitals, theatres, castles, museums, fire stations, bus/train stations, shopping centers etc) should look alike.

I also thinks so (layer containing PoW on buildings is named buildings-major), but IMHO it would be better to handle this features separately, not in this PR.

[althio]

I do like the lighter shade of most buildings.
I do not like how only place_of_worship were made darker (and mall, supermarket or attraction? but not hospital, museums, town halls, schools...).
Please make it darker for all other important buildings... or none.

mkoniecz commented on Oct 17

Major buildings should not be displayed earlier, but using more noticeable style (maybe like current building style?). For start it may be just PoW, malls and supermarkets(2) (as it is now), but it would be nice to add more.

mkoniecz commented an hour ago

I also thinks so (layer containing PoW on buildings is named buildings-major), but IMHO it would be better to handle this features separately, not in this PR.

So can you really handle these features separately and not change both here: buildings lighter and place_of_worship darker?

[DaCor1]

I honestly don't see a reason for making certain buildings more prominent.
By doing that you end up with (as is the case already in this thread)
people looking for more and more buildings to be given an exception to the
norm. The end result will be a checker board in appearance

IMHO, the way that makes most sense is colour them all the same and invite
icon development instead, which would be far more beneficial (greater
variety of icons)

[matkoniecz]

The end result will be a checker board in appearance

It would happen with uncontrolled adding of important building types. Doing this carefully will result in much better map (see comparison at the bottom of #565 (comment))

Please make it darker for all other important buildings... or none.

#565 (comment) affected only PoW for three reasons: currently only PoW building are rendered specially (and intention of my change was to keep this special rendering), because for many types of buildings it requires either tricky preprocessing or tagging change[*] and because I would prefer to discuss what is an important building in a separate issue (this one already has a gigantic and unwieldy discussion).

[*] For example - there is currently no way to reliably decide whatever something is a school/university building. Checking whatever building is inside amenity=school/university polygon probably counts as overcomplicated and therefore unwanted data processing. Also, I am not sure is it doable with current database and what worse not all buildings in amenity=university polygon are university buildings (rendering sheds or substation as a special building just because it is on university area is a poor idea). Checking value of building tag would be also unreliable and would establish an undiscussed tagging scheme.

[dieterdreist]

2014-11-28 7:56 GMT+01:00 Mateusz Konieczny notifications@github.com:

Checking value of building tag would be also unreliable and would
establish an undiscussed tagging scheme.

IMHO we should indeed check the value of the building tag, aka the building
typology. A place of worship inside a residential condominium isn't usually
a landmark, while a building built as church but not in use as such anymore
IS typically still a landmark. The same goes for other types of buildings.
I am aware, as it stands now, by far the most buildings don't have a
specific building tag associated, for several reasons, one being imports,
one being explicit advertizing of "building=yes" (e.g. in a map with this
title), one being editor presets and defaults, yet another one the poor
documentation of building types in the wiki. Checking for the building type
to determine the importance of a building in rendering would pose a counter
momentum and would advocate for more detailed typology tagging.

[daganzdaanda]

As said above, I'd like the buildings to be a little bit darker and more of a neutral grey.
Also, buildings should always be darker than the background IMHO. So if we make them very light, we lose possible variations in background colours.

I too hope we can make use of the different building values some time. How about grouping the values into 3 tiers: important/outstanding - standard/average - lesser importance ?

[vholten]

I think that a more neutral gray would work better than the proposed yellowish/brownish gray, as has also been said by others here and on talk. In fact, in an earlier comment I suggested using the color d6d1c8, and @math1985 and @gravitystorm responded that they liked this color.

Here is a comparison of the currently proposed building color (left) and my suggestion (right):

[kocio-pl]

@vholten: I guess the background is landuse=residential? Looks better for me, but could you also show a big picture on some other "troublesome" backgrounds (especially dark, like landuse=industrial, commercial and construction)?

I prefer darker outline from the mentioned comment. The lighter one could be used for building=garages or something like that.

[vholten]

@kocio-pl : I've set up a demo with the Krakow (Poland) area here.

[matkoniecz]

@vholten

I think that gray buildings are too close to living_street - see
("Stare Miasto" on the right and "Akademia Górniczo-Hutnicza" on top left are areas affected on this screenshot).

[kocio-pl]

@vholten: Buildings coloured like that are better on dark backgrounds in most cases and some other are still good enough. Let's check:

1. landuse=commercial and construction is good ( https://a.tiles.mapbox.com/v4/vholten.kcmgl2g2/page.html?access_token=pk.eyJ1IjoidmhvbHRlbiIsImEiOiJFT3p2aVVRIn0.QEIwuQzGCeTdfnFmcQSOmA#17/50.08776/19.98069 )
2. landuse=military is also good ( https://a.tiles.mapbox.com/v4/vholten.kcmgl2g2/page.html?access_token=pk.eyJ1IjoidmhvbHRlbiIsImEiOiJFT3p2aVVRIn0.QEIwuQzGCeTdfnFmcQSOmA#17/50.08259/19.98254 )
3. landuse=military+military=barracks is just acceptable, but still better than what we have ( https://a.tiles.mapbox.com/v4/vholten.kcmgl2g2/page.html?access_token=pk.eyJ1IjoidmhvbHRlbiIsImEiOiJFT3p2aVVRIn0.QEIwuQzGCeTdfnFmcQSOmA#17/50.05565/19.97085 )
4. landuse=industrial is good, amenity=allotments is a bit strange, but I guess this is of less importance, since we don't map the buildings there too much ( https://a.tiles.mapbox.com/v4/vholten.kcmgl2g2/page.html?access_token=pk.eyJ1IjoidmhvbHRlbiIsImEiOiJFT3p2aVVRIn0.QEIwuQzGCeTdfnFmcQSOmA#17/50.04865/19.97463 )

mkoniecz is right when talking about too small difference between buildings and living streets, but then I always thought they are strange and differs too much from the rest of streets - I think living streets should be much lighter. We should also make pitches and probably landuse=military+military=barracks lighter.

[kocio-pl]

1. power=generator looks strange (the background is much darker than buildings), but I feel it would be hard to avoid it - maybe this background should also be lighter ( https://a.tiles.mapbox.com/v4/vholten.kcmgl2g2/page.html?access_token=pk.eyJ1IjoidmhvbHRlbiIsImEiOiJFT3p2aVVRIn0.QEIwuQzGCeTdfnFmcQSOmA#16/50.0533/20.0119 )

[pnorman]

replaced by #1153