render highway=living_street exactly like highway=residential and highway=unclassified

[matkoniecz]

Current rendering of living street is problematic:

• it is not obvious that it is a road
• it is not clear what is special about it
• colours of pedestrian-related roads are illogical. =residential is white, =living_street with both pedestrians and vehicles is dark grey and =pedestrian with restricted vehicles is light grey.
• high number of separate rendering for roads types makes harder to design a new road style
• living_street is not so different from highway=residential and highway=unclassified to justify drastically different renderting
• current rendering is not pretty, it is frequently hard to see (especially on landuse=residential Living streets are hard to see #1194) and at the same time it is too dominant on areas with many roads of this type. Problem of making it too dominant on some areas will be worsened by fixing Living streets are hard to see #1194

I propose to drop special rendering for highway=living_street and render it exactly like highway=residential and highway=unclassified. I thought about switching styles for =pedestrian and =living_street but it would fix just one problem and would be highly confusing.

[kocio-pl]

I think you're 100% right about the diagnosis, but I also don't know what is the right solution for it.

I would happily drop it like you suggest right now, because it is so problematic, and then we can think what to do in the long-term. Of course if somebody comes with a better approach now, it would be even better, but even if not, we have a good enough solution.

[nebulon42]

Yes, living street is problematic as legislation varies from country to country (see e.g. http://en.wikipedia.org/wiki/Living_street). It can be quite close to low speed residential zones but also quite close to pedestrian areas (e.g. here in Austria the max speed limit for living streets is 5 km/h and access=destination is in effect).

As far as tagging is concerned maybe the tag highway=living_street should be dropped altogether, dropping the different rendering may lead to that. But this should be accompanied by a tagging related discussion?

[RAytoun]

I raised the point about problems with the Admin Boundaries and that traditional mapping actually sets aside specific symbols for specific features and it was pointed out to me that, while conventional mapping is preplanned and then rendered...OpenStreetMap has been rendered by common usage and demand. We have reached a stage where symbol types and colours throughout are overlapping and causing confusion ...becoming "problematic" in many areas.
highway=trunk with landuse=forest (#1323, #319, #102)
Admin boundaries (#1267, #907, #1258)
Cycleway / paths (#1321, #1325, #1327)
As pointed out by @Rovastar (#1258) trying to sort this out would be "....thankless and time consuming and require real decision making...."
OSM has found it's way so far and contains an immense amount of detail but the demand for more specific information is creating more confusion as symbols overlap more and more. The time has come for OSM to rethink whether it can continue on an "ad hoc" basis.

[SomeoneElseOSM]

@RAytoun Perhaps what you need to do is to come with an example rendering (not bound by what OSM has done in the past) and show it to everyone? It's all very well saying "The time has come for OSM to rethink", but OSM isn't a sentient thing - it's just a collection of people trying to create something together. It's easy to say "this is wrong, and that's wrong...." but far harder to come up with something that, across all of the issues, is on balance better.

[matkoniecz]

@nebulon42

As far as tagging is concerned maybe the tag highway=living_street should be dropped altogether, dropping the different rendering may lead to that. But this should be accompanied by a tagging related discussion?

Yes, things like this should be discussed on tagging mailing list and wiki, not here.

[RAytoun]

@SomeoneElseOSM I have made some suggestions along the way in specific
categories of render ...as you say this is just a collection of people
trying to create something together. Where a person or group are discussing
changing a symbol or symbols I will lend my support if it is heading in a
direction that is making that range of symbols more consistent, or suggest
something along those lines, thus trying to influence decisions along the
lines I have suggested.
I am not in anyway saying "this is wrong, and that's wrong...." but
following the discussions which show that the overlapping of categories of
symbols is creating "confusion", becoming "problematic" (their words not
mine).
This is a collection of people doing a great job and no individual is in a
position to dictate, only to propose... and if the proposal is acceptable
then it may begin to creep in to future discussions by groups attempting to
introduce or change tagging and rendering. This can only happen over a
protracted period of time as it would mean changing the rendered symbols in
all areas to match (an immense task in itself).
Please understand that I am only suggesting that it may be easier in the
long run if some form of symbol categories be reserved for specific types
of features. If this is adopted along the way then it may be more fruitful
than just walking away and letting everyone get on with it.
Already you have suggested I come up with an example...you are the first to
suggest this so maybe this is the start of my proposal for a rethink? Thank
you and I apologise if I have upset anyone.

On 21 February 2015 at 20:01, SomeoneElseOSM [email protected]
wrote:

@RAytoun https://github.com/RAytoun Perhaps what you need to do is to
come with an example rendering (not bound by what OSM has done in the past)
and show it to everyone? It's all very well saying "The time has come for
OSM to rethink", but OSM isn't a sentient thing - it's just a collection of
people trying to create something together. It's easy to say "this is
wrong, and that's wrong...." but far harder to come up with something that,
across all of the issues, is on balance better.

—
Reply to this email directly or view it on GitHub
#1326 (comment)
.

[polarbearing]

colours of pedestrian-related roads are illogical. =residential is white, =living_street with both pedestrians and vehicles is dark grey and =pedestrian with restricted vehicles is light grey.

In addition, =footway is red dotted.

[matthijsmelissen]

An option for me would be to render living_street as current pedestrian and pedestrian in a totally different way, for example with a red(ish) accent to make it more similar to footways.

[kocio-pl]

@math1985: Sounds promising for me if that reddish accent is not too strong.

I also think highway=footway+area=yes and highway=pedestrian+area=yes should be rendered the same (I guess now they have different shade of gray).

[RAytoun]

I am in favour of all highways, tracks, paths, cycleways, etc as a cased symbol (different categories and importance can be indicated by thicker or thinner cased lines, solid and pecked casings, varied width, solid, pecked or patterned colour fills. The casing will then also highlight a green road through a forested area if necessary)...thus freeing up single line symbols for other uses such as waterways, boundaries and areas and thus reducing the clashes.

[kocio-pl]

Is it possible to render named living streets different than not named ones? I think (at least in Poland) we have:

1. real living streets, that are mostly like residential, but without sidewalks - and that is what we show currently,

2. some wider footways with possibility of driving vehicles, which are essentially like highway=service, which are too wide now, while similar neighbourhood with just service roads looks sane.

Even if rendering not named living streets with highway=service width is not the final solution, I think this simple fix would make things better.

[pnorman]

I don't like the idea of rendering differently based on name

[dieterdreist]

looks like a tagging problem to me. living streets render the same width than residential roads and that seems fine for this kind of feature. A name has nothing to do with the kind of feature. Are you sure your living streets aren't service roads and why do you think they are living streets?

[matkoniecz]

It is one of ideas that I consider but at this moment it is not highly likely that it will be used in proposal for the new road style.

[matkoniecz]

I already found some solution that work better than this one - so I am withdrawing this idea.