area:highway should probably count here as highway

[BartekChom]

I have seen in Verdaccio some complains that probably are unnecessary. Famlam on Osmose GitHub identified relevant lines in your file and asked me to report it to you ​https://github.com/osm-fr/osmose-backend/issues/1986, so I am doing it, although I am a bit confused.

area:highway=* + smoothness=* (from josm/trunk/resources/data/validator/combinations.mapcss#L276​, e.g. ​way/1162993735)

area:highway=steps + step_count=* (from josm/trunk/resources/data/validator/combinations.mapcss#L24​, e.g. ​way/950057163)

When I look at your file, I suspect that at least area:highway=service + living_street=yes should be accepted too despite josm/trunk/resources/data/validator/combinations.mapcss#L17​.

I am not sure, but probably [!area:highway] should be added to all three lines (unless I should not duplicate such tags on area:highway - however I could argue that at least with smoothness users could want to know to what area it applies).

[BartekChom]

I am sorry, [! area:highway] with exclamation mark should probably be added, but I have trouble with formatting.

[skyper]

I think it does not make sense to duplicate the tags from the highway=*. It rather leads to inconsistency as mapper might forget to adjust the duplicates when changing the values. If you are interested in the tags you can get them from the highways.

[BartekChom]

I can argue that at least smoothness=* for area:highway=emergency adds unique and arguably important information: There is no corresponding highway=*, (even if some claim that "emergency" is not the right value) in an emergency vehicles may break traffic rules driving through excluded areas and the smoothness may be different then for neighbouring lanes.

For very micro mapping I can also imagine marking pieces with different smoothness.

Besides, taking values directly from an area is much simpler although I have to agree that when an algorithm wants to use such details (even just to display them - directly available data would show too little), looking for data in contained highways is a small complication. On the other hand, making smoothness consistent for all highways crossing given area:highway requires effort too. Maybe tagging the smoothness of area:highway=footway is better than recognising which highway=footway (The one with the longer length in the area? It is enough to recognise EW below.) is relevant when a EW foot way with good smoothness crosses a SN foot way with excellent smoothness.

      |
      |
      |
      |
 c----+----c
-+----+----+-
 c----+----c
      |
      |
      |
      |

(c is a corner, the rectangle is area:highway=footway, two lines are highway=footway)
(Before our data becomes perfect, we should cut the SN and tag the part at the crossing with smoothness=good, right? Do you have a better idea?)

---

As for area:highway=steps + step_count=*, my new ​https://www.openstreetmap.org/way/1204231251 is an example of an interesting case that was too unclear for me to tag. The whole area:highway=steps arguably has a given number of steps, but some paths have less. Actually, what is the area for step_count=1? For step_count=2, is there one step with two edges?

---

area:highway=service without living_street=yes for highway=service with living_street=yes seems simply confusing. A living street is 100% connected with a specific sign with very different traffic rules, but arguably sometimes it is equivalent to a residential (highway=living_street) and sometimes to service. I can imagine that sometimes in practice one has to transit along a whole living street as part of an ordinal travel (something like highway=tertiary). Anyway I assume that, because the classification of roads on OSM is based on their practical use, not on their official status, but the official status of being a living street is always important in practice, some roads are e.g. both service roads and living streets, so tagging area:highway=service with living_street=yes is necessary to show what an area is. (Unless we assume that a living street must always be tagged highway=living_street. Then living_street=yes is wrong both with area:highway=* and with highway=*.)

P.S. I am sorry. This is long and probably unclear just because of this fact and additionally I am afraid that the grammar is wrong somewhere.

[skyper]

You got a point for areas without an appropriate crossing way. Though how many are these beside area:highway=emergency and maybe bays (bus_bay)? or node features (passing_place, turning_loop/circle, mini_roundabout)?
I'd prefer to only exclude those.

Regarding junctions they should be correctly micro-mapped on highway=*-level by splitting the ways. You example (​osmwww:way/1162993735) already has problems as ​osmwww:way/952741041 should not cross with surface=ground plus missing smoothness=* and I am pretty sure that some other tags like shoulder=* need to be adjusted for the junction part, too.
For me, this sounds more like a validator warning for linear ways with different tags inside the same area:highway=*.

Regarding steps your example is way to simple. Think about steps with different values for step_count inside the area like ​osmwww:relation/11333751 (e.g. ​osmwww:relation/957489) (pictures from different angles: ​1, ​2, ​3)
We already need the tags from the linear ways to properly render steps.

Regarding living_street=yes, cyclestreet=yes, bicycle_road, motorroad=yes and similar once again the linear ways inside the area should be used, in my opinion.

[BartekChom]

OK, if you allow smoothness=* at least for area:highway=emergency, I cannot say that adding information is discouraged. As for bus_bay, passing_place, turning_loop/circle, mini_roundabout, to be honest, I am not sure, what tagging you suggest exactly. I have at most a tiny bit of experience with such cases.

[P.P.S. Oh, what about "For very micro mapping I can also imagine marking pieces with different smoothness."? OK, very micro mapping... I am sorry (I am repeating myself), I am about to stop, my writing is becoming more and more chaotic.]

Cut ways in Pobierowo - OK, I suggested such approach myself, so I should apply it. I tried to make it a bit more correct. Description in Polish means ​the junction has special tags, suggested on (here), but I am not sure that everything is correct, I am sorry. [P.S. Now I see that StreetComplete wants to add width, but actually I am not sure that it is meaningful at all for a purely junction fragment. I am sorry, if you have an idea you can apply, please do it, probably I will not do anything for a few weeks.]

There are even more complicated stairs - OK, I see.

"For me, this sounds more like a validator warning for linear ways with different tags inside the same area:highway=*." - OK, this sounds ambitious, but I have little reasons to argue.

Even key additional tags only on linear ways - OK, if you insist.

Summary:

Thank you. It will be nice if you allow this smoothness=* for area:highway=emergency and even nicer if you manage to check consistency on linear ways inside one highway:area=*.

Besides I probably should not be stubborn. I am sorry, actually I am going to stop my activity on OSM for a few weeks from tomorrow. I can think more afterwards.

[skyper]

Ticket #23073 has been marked as a duplicate of this ticket.

[skyper]

I have thought about this again and changed my mind. The more detailed you map area:highway the more tags you need to add. Think about a road with different surfaces and likely different values for smoothness per lane. It would still be possible to use surface:lanes and smoothness:lanes but a little duplication might not harm.

Writing Validator rules in case of conflicting values of optional tags between highway=* and its corresponding area:highway=* seems to be a complex task beyond my skills and I think this could only be done with java code (if it is possible at all).

Edit: This is about smoothness. I am still opposed to step_count as the information on the highway=steps should be sufficient and for complex steps you need to use a different system, anyway. Similar is true for the other mentioned tags *=yes/no which are duplicates and a look at the linear object should tell you all you need.

[gaben]

use macros

[BartekChom]

I am sorry, I have practically no new thoughts to add. Maybe I should explain that I have finally added grave accent symbols in the ticket description. To be honest, I am writing because I want to show that I am still watching this ticket and I am happy that it is active again.

[BartekChom]

I am sorry, apparently I destroyed gaben's corrections!

[BartekChom]

I am sorry again, I am breaking everything.