Different rendering for barrier=kerb

[valhentai]

barrier=kerb has the same rendering as barrier=wall so there is no difference between a kerb and a wall on the map.

It could be rendered as a dashed line. Here is a example of the french cadastre were the dashed lines are kerbs.

[pkoby]

I very much agree. Barriers like walls and fences are physical impediments to passage for everyone (you must usually find a gate or stile), whereas kerbs hinder passage for some vehicles, but probably don't affect foot travel.

I have sometimes hesitated adding kerb lines because they look like walls on OSM Carto, but they're also important for accessibility mapping.

[jeisenbe]

I would suggest removing the rendering of barrier=kerb, since it is not a significant barrier in the same sense as a wall, fence or hedge.

[jeisenbe]

Another option would be to render it later, say only on z18 or z19 and above, and with a slightly thinner line

[jeisenbe]

I've researched the kerbs in a few places. There are none mapped in Prince Edwards Isle (Canada) and only 3 in Liechtenstein. Delaware, USA has only 1. Washington, DC has a couple dozen, but all of them are also part of another feature: a fountain, pool of water, garden, except for one traffic circle (which has landuse=grass, but mapped with a separate way).

Luxembourg was the first place I found that had some kerbs mapped as separate features. Most of these are parallel to a highway or path, as you might expect, so they don't render until z19 currently (sometimes they are barely visible at z18, but only partially). A few others are tagged on features like landuse=grass where there is a patch of grass in a square or plaza, surrounded by a curb. But there are a few that are mapped as separate features.

This suggests that kerbs should not be rendered before z19. (In many cases they will make much more sense if shown together with area:highway renderings at z20 or z21 and higher)

Examples:
z18 current - kerb not visible

z19 current - visible

z18 current

z19 current

z17 current - this is one of the better example where curbs might be useful (for wheelchair users or bicycles?) but still confusing. You can't tell that the line in the southeast is a fence rather than a kerb.

z18 current - even at z18 some of the kerbs are partially covered by the service road. Were it a wider tertiary or residential road even more would be covered.

z19 current - now they are all visible, but still can't tell that the line by the 3 trees is a fence

z18 before - curb barely visible - Washington DC

z19 current - better

z19 current - Liechtenstein (not visible at z18)

[jeisenbe]

Right now, with kerbs rendered the same as fences and walls, the rendering is unhelpful. A kerb certainly needs to be rendered differently than a wall. It's not possible to make kerbs much thinner or lighter than the current barrier rendering without confusing them with the outline of an area. But we can make kerbs slightly thinner (0.3 pixels instead of 0.4) and also make other barriers slightly wider at z19. At the equator a standard pixel is about 30 cm wide at z19, so it's reasonable to have barriers more than half a pixel width. This will mainly matter if we switch to double-resolution "retina" tiles, but i expect this to happen in a couple of years. For the meantime it makes the line slightly darker for most barriers, and slightly lighter (and marginally thinner, on curves) for kerbs.

I don't think a dashed or dotted line would work, because it would not be clear that this was a barrier type feature.

z19 current - Pierre/Konrad, Luxembourg

z19 after - 0.3 pixel wide kerbs, retaining wall is 0.6 pixels wide (southeast of image)

z19 current - Rue Carlo, Luxembourg

z19 after - 0.3 pixel wide kerbs (center, north, west), 0.6 pixel wide fence (southeast)

If we want to prepare for z20, I would make solid barriers 1.0 pixels wide at this level. This would also require adjusting hedges, city walls, etc:
z20 optional:

[pkoby]

I agree with everything you've posted here. My only thought is that even with a lighter, thinner line, the kerb isn't significantly different than another barrier. If you were to see only a kerb on a map, you wouldn't have anything to compare to, so it would still be tough to differentiate. I don't have a better solution, though.

I've seen versions of fences with a dash-dot-dash style, which made them very obvious, but that doesn't match the current barrier style of a solid line...

By the way, if you want some more areas to play around with, here's my local park: https://www.openstreetmap.org/#map=18/38.40746/-82.43625 There are kerbs around the grass/highways, fences around the tennis courts, and walls by the fountain.

[jeisenbe]

If you were to see only a kerb on a map, you wouldn't have anything to compare to, so it would still be tough to differentiate

This is true for many of our rendered features, unfortunately.

I've seen versions of fences with a dash-dot-dash style, which made them very obvious,

Dashed lines are problematic with computer-generated maps, because the dashes do not always behave well around corners or where objects meet or on curvy lines.

But for fences I could imagine a few things that would work. We could add a wider square every 10 to 16 pixels, to symbolically represent a fence post, but this would only work at high zoom levels. In Europe it will look fine at z19, but at the equator the dots could look rather wide. It would be safe to something like this at z20.

Retaining walls could have ticks on the low side of the barrier; this would also help remind mappers to draw the way in the correct direction.

However, I'm not sure what to do for barrier=wall, the second most common type after barrier=fence. Many walls are just solid, but they are not necessarily wider than 10 or 20 cm. At z20 they could be rendered slightly wider than a pixel, but it might be too wide at z19 at the equator to go wider than 1 pixel.

@imagico, how wide do you think walls could be rendered on z19? Do you know of any other standard ways of showing these features?

[matkoniecz]

I think that simply not rendering barrier=kerb is worth considering. I think that it is significantly less important barrier than other ones.

Note that we render barrier=gate and similar passages through walls and fences. We are not doing it with kerbs.

[jeisenbe]

Certainly, removing the rendering is the simple option.

I tried the complicated option: adjusting the rendering of the other barrier types. First, I added square every 8 pixels along standard barriers (eg barrier=fence, =wall, =chain, =guard_rail, =handrail), which symbolically represent posts or columns. These square are still sub-pixel in size, so they are very subtle.

z16: luxexpo (barriers upper left, center, lower center. And can you find the retaining walls?)

For barrier=retaining_wall, I offset dashes toward the lower side of the way. I also added a semi-transparent white "halo" line toward this side. This has some similarities to the rendering for man_made=embankment, but is different enough. The "ticks" become more visible at z19

z18 retaining wall vs embankment

z19

I used a similar idea with kerbs: they are still a thin line, but I added a semi-transparent white line toward the lower side of the way (this shows that some kerbs are not mapped in the correct direction):

z19: kerb vs fence

Probably "barrier=ditch" also deserves a variation; it's quite different than a wall or fence. Perhaps just the thin line but with a lighter halo on both sides, or a thin dashed line. This would be similar to intermittent waterways, but in gray instead of blue (most ditch barriers become ephemeral waterways when it rains hard enough).

[matkoniecz]

Unfortunately this is still not clear. I worry that wall is so far away from kerb that it may be not doable to make both visible and properly different.

[jeisenbe]

OK, last idea for kerbs. Use a thin lighter line. Worth considering?

[matkoniecz]

How it works on other landuses, especially on area without landuse?

[imagico]

I agree that rendering this - if at all - would only make sense at the highest zoom levels.

The following order of doing things seems appropriate:

• removing rendering of barier=kerb identically to hard barriers like fences/walls
• considering if and how to differentiate the hard barriers
• look for a possible rendering of kerbs that works together with the other barriers and with the rendering of roads at the highest zoom levels.

[jeisenbe]

I'd rather not remove the rendering and then add it back. But we might just have to stop rendering, until z20 is available.

It's very subtle on land-color

z19 On residential landuse (also visible: retaining wall rendering idea):

z19 Untagged land:

z19 Untagged land and residential (also a fence shown with new possible rendering)

[jeisenbe]

With a wider white line (1 pixel), 80% opacity. Shows up better on land-color, but more noticeable on residential and other landuse:

100% opacity 1px white line

[polarbearing]

While I have no objection to render kerb later or differently, I disagree with its removal.
A kerb is a physical feature designed not to be driven over by a vehicle.
It is as "hard" or as "soft" as a 0.5 m high fence that can be walked over by a pedestrian to cross the lawn.
I have mapped situations, where e.g. a kerb in the middle explains visually that a road joins only one roads of a dual carriageway.
Example:

[jeisenbe]

I tried a number of different renderings for barrier=kerb above (1, 2, 3 4), some of which required extensive changes to the rendering of other barriers, but none worked well.

If there is a reasonable way to render these features at z19 or even z20, I would be happy to see a PR or a rendering sample showing how it could work.

However, currently kerbs are rendered the same as retaining walls, walls and fences, which are mostly tall barriers that prevent entry by pedestrians. Since barrier=wall and barrier=fence are used millions of times, the very rare cases when barrier=kerb is rendered are going to be interpreted by most map users as a fence or wall; this is misleading.

[jeisenbe]

I have mapped situations, where e.g. a kerb in the middle explains visually that a road joins only one roads of a dual carriageway.

This can be seen at higher zoom levels by the fact that only one of the side of the dual-carriageway is connected to the other road. But rendering a kerb the same as a fence or wall suggests that pedestrians are physically prevented from crossing there, which is usually not the case.

[polarbearing]

the very rare cases when barrier=kerb is rendered

When you duplicate your arguments in different threads you force other to duplicate the answers, too.
225000 uses is not 'very rare'. As said before, a small fence does not prevent a pedestrian to walk over, so logically you would need to propose dropping them as well.

[matkoniecz]

Even small fences are often either legal or social barrier for pedestrians.

But I think that dropping rendering for extremely small fences is something worth considering.

[kocio-pl]

What do you mean by "extremely small fences"?

[Adamant36]

What do you mean by "extremely small fences"?

Probably like some of the smaller side fences here, or even the short ones in the front yards. I actually had that idea myself, because sometimes when I look at the area the fences make it seem over mapped or they are just distracting. Although, getting rid of might make the then free standing gates look weird.

[kocio-pl]

Oh, I see. They define the space and the only problem would be only if they are seen too early, but they're not and I have no problem with them currently.

[Adamant36]

Maybe you could do something where fence ways of a certain pixel number don't render or render at a different zoom level. It seems like it would lead to a massive amount of inconsistency though.

[jeisenbe]

The context is the comments above:

a small fence does not prevent a pedestrian to walk over

dropping rendering for extremely small fences is something worth considering.

So we are talking about a "fence" that is so short that you can walk over it, rather than having to jump or climb.

I agree that a barrier=fence with height= less than ~0.5m (~20 inches) should not be rendered the same way as a 2m (7 foot) fence.

(But this is just in theory: it does not appear that there are enough fences tagged with such small values of height for us to consider this in rendering)

[Adamant36]

I say keep rendering of curbs in the code as they are , but push them to z20 for now. Then revisit the issue later when z20 is implemented. They aren't ultimately that important and I think its only useful to display them really zoomed in, but z19 doesn't seem like zoomed close enough. I also think it will help justify z20 rendering later on if we are like "here's specific things that we want to render at this zoom level" and having them ready ahead of time (if I remember correctly there's already something else that only renders at z20. So its not a stretch).

[polarbearing]

push them to z20 for now ... aren't ultimately that important

I find that a very odd approach, like "I don't like your items in the living room, but you can push them to the attic". As one important purpose of this style is to give mappers feedback, "pushing" something into invisibility of a not-yet-implemented z level does not work for me.

[imagico]

I find the defense of the status quo without any arguments a bit problematic here and not suited to achieve consensus. Without any arguments means that the clearly argued point that rendering a kerb the same way as a hard barrier like a wall or fence or hedge (these are the three barrier values with more than a million uses and the cases the current barrier rendering is designed for) is clearly confusing and counterproductive for map legibility and mapper feedback has not received any rebuttal (beyond the whataboutism regarding fences you can step over).

In other words: Everyone who is in defense of the status quo in rendering of barrier=kerb should IMO provide substantial arguments why the current rendering is positive in your eyes. If the consideration is merely that maintaining the status quo is the only way to keep rendering kerbs since there is no chance of rendering kerbs in any way would achieve consensus that would essentially be a declaration of bankruptcy of productive cartographic development here.

Side note: By rendering barriers with a catch-all until #1986 we are largely responsible for the invention of barrier=kerb as a textbook tagging for the renderer. We failed to correct this in #1986 unfortunately.

[polarbearing]

Not sure who you mean - I don't defend the status quo, I said before I'd be happy with a lighter/thinner rendering of kerb at later z level, as long as it remains visible in the current installation. There were examples of such thinning in this thread previously.

[jeisenbe]

But you have not yet address the problems mentioned with that. Several comments above have given good reasons why a slightly thinner rendering of kerbs, but otherwise similar to fences/walls, will not work:

#3714 (comment)

"even with a lighter, thinner line, the kerb isn't significantly different than another barrier. If you were to see only a kerb on a map, you wouldn't have anything to compare to, so it would still be tough to differentiate."

#3714 (comment)
" I think that it is significantly less important barrier than other ones. Note that we render barrier=gate and similar passages through walls and fences. We are not doing it with kerbs."

#3714 (comment)
"Unfortunately this (rendering example) is still not clear. I worry that wall is so far away from kerb that it may be not doable to make both visible and properly different."

#3714 (comment)
"Even small fences are often either legal or social barrier for pedestrians."

#3969 (comment)
"Without rendering sidewalk and street areas these features are not intuitive."

#3969 (comment)
"rendering kerbs the same way as physical barriers is misleading mapper feedback.

"It also interferes with map Legibility and clarity when very different features are rendered [similarly].

"The map should be intuitively readable by users with some general experience using maps without a map key, preferrably with relatively little effort" - Line 34, CARTOGRAPH.md"

[Adamant36]

I find that a very odd approach, like "I don't like your items in the living room, but you can push them to the attic". As one important purpose of this style is to give mappers feedback, "pushing" something into invisibility of a not-yet-implemented z level does not work for me.

I'm not sure what's odd about that considering there's already other things that only render at Z20. At least I thought there was. I could be wrong though. Even if not, there must be other styles out there based on this that have z20 implemented and would benefit from kerbs being rendered at that point even though we might not, for now.

Really I'm just trying to find a good compromise. As @jeisenbe says thinner rendering probably isn't an option, nothing else so far has worked, and there doesn't seem to be other ideas at the moment. I don't find @imagico's whole thing about completely removing features from the code just because there isn't currently a viable way to improve them, when there could possibly be one in the future, a compelling option either. There's a lot more chance of someone with a new idea coming along if the code is still there and they are still visible in some maps, if not this one for now. Even with this style it's highly possible a solution would come along between now and z20 being implemented that would be easier to test with kerbs being rendered at z20 where Kosmtik still goes to. But as @imagico say's sticking to the stat quo isn't good either. So, it's a good middle ground in my opinion between something drastic (full removal), and doing nothing (leaving as is). Neither of which are good options IMHO.

[imagico]

Yes, the approach of @Adamant36 is the right one here - making concrete suggestions of what to do. I don't like the idea either but bringing forward and arguing about concrete ideas is what brings us forward in cases like this.

[kocio-pl]

making concrete suggestions of what to do

Your comment here suggests that this is quite new approach, if I understand your opinion right, but concrete suggestions on the changes (here or in the PR) were given already. I plan to write more about them soon.

[jeisenbe]

Suggestion from #4230:

I suggest that kerbs could be rendered as a light gray line, possibly with triangles or other markers on one side of the line, like in JOSM/iD.

I’ve already attempted test renderings with this feature as "a light gray line” but this did not work even at z19.

Adding hatching or arrows on one side would be similar to a retaining wall or embankment or cliff. This might be feasible at very high zoom levels like z21 (as shown in the example from JOSM) but not at z19, currently the highest level available in many deployements of this style (including on openstreetmap.org)