Openstreetmap-carto: Differentiate service rendering based on surface

[tomass]

While investigating why some entrances to private houses are tagged with _highway=track_ instead of _highway=service_ it looks like at least part of the problem is that OSM-Carto symbolises service roads more prominently: bright white road with a casing as opposed to brown hashed track. Mappers are then reluctant to tag entrances to houses as service in urban areas where the road leading to the house is itself a track (as this gives an impression of a broken hierarchy).
Example here:

https://www.openstreetmap.org/#map=17/55.39386/22.23788
Note that some driveways in urban areas can really be symbolised more prominently, as they could have improved surface (gravel or even asphalt). But at least in the example above the driveway is simple ground/grass surface road and therefore current depiction distorts reality.

Expected behavior

Maybe service roads with some surfaces (like ground, grass) could be symbolised like tracks?

Actual behavior

Service roads with ground/grass surface are rendered very prominently so mappers are inclined to change highway type to track, which is incorrect as well as pushes such micro-roads to smaller scales.

[IgorEliezer]

Mappers are then reluctant to tag entrances to houses as service in urban areas where the road leading to the house is itself a track (as this gives an impression of a broken hierarchy).

I had similar issue here, but after reading and re-reading numerous times the wiki, I reached the conclusion that if a narrow, unpaved, permanent road is public access and leads to several houses and farmyards, it should tagged highway=unclassified + surface=unpaved + width=4 in order to avoid breaking road hierarchy. Width and surface aren't not decisive as criteria for road classification, methinks.

Maybe with the Unpaved rendering feature, unpaved service ways steaming from a track will be less prominent.

[tomass]

I had similar issue here, but after reading and re-reading numerous times the wiki, I reached the conclusion that if a narrow, unpaved, permanent road is public access and leads to several houses and farmyards, it should tagged highway=unclassified + surface=unpaved + width=4 in order to avoid breaking road hierarchy.

There are differences in road classification interpretation per region, but I would never classify such a ground road (with no possibility for two vehicles to pass without leaving a road) as "unclassified". That one would clearly be a track.

But your example is a good one for yet another (incorrect?) way of "solving" this visual hierarchy problem - "upgrading" connecting road (track->residential/unclassified) rather than "upgrading" driveway (service->track). Both "solutions" come from visual hierarchy presented by one specific map style - OSM-Carto. As per wiki and discussion in tagging ML, service is at lower level than track or equal (depending on interpretation), so regarding non visual hierarchy there would be no problem in leaving the road as track and driveways as service.

Maybe with the Unpaved rendering feature, unpaved service ways steaming from a track will be less prominent.

From what I understand - no, grass/ground service would not be less or equally prominent as track.

[matkoniecz]

Surface rendering is a good idea - see #110 that I just reopened. It was closed as it was implemented. Unfortunately this change turned out to have performance issues and was later reverted, but issue #110 was mistakenly kept closed.

Thanks for helping to detect this problem! #110 should be open as it is unfixed and fixing it is considered as a good idea. I will close this specific issue as it duplicates #3183

---

There are differences in road classification interpretation per region, but I would never classify such a ground road (with no possibility for two vehicles to pass without leaving a road) as "unclassified". That one would clearly be a track.

AFAIK it should be neither unclassified (connects small settlements) nor track (field/forest access - not for all unpaved roads, may be paved). It seems that it is rather highway=residential or highway=service.

But it should be discussed in place for discussing tagging - tagging mailing list, OSM Wiki or one of other places for such discussions.

[tomass]

It was already discussed in tagging list. It was confirmed there that service is either lower than track, or on the same level in road hierarchy. OSM-Carto visual hierarchy does not correspond to it thus confusing mappers who use OSM-Carto.

[jeisenbe]

Off topic:

AFAIK it should be neither unclassified (connects small settlements) nor track (field/forest access - not for all unpaved roads, may be paved). It seems that it is rather highway=residential or highway=service.

A rural road that connects isolated farmhouses, ranches or stations would be unclassified. But I agree that it should not be a highway=track if it leads to a residence.

It was already discussed in tagging list.

Looking back at the discussion, several people mentioned that houses and other residences should not be connected to the rest of the road network by a highway=track. See:
https://lists.openstreetmap.org/pipermail/tagging/2019-August/046967.html
https://lists.openstreetmap.org/pipermail/tagging/2019-August/046968.html

That was a long discussion which mainly talked about unclassified vs residential, so I didn't follow all of it, but I don't think there is consensus that all types of highway=service and highway=track are in a certain hierarchical relation.

There are several types of highway=service: driveways, parking lot access ways, private roads in shopping centres, roads inside of mines or military bases, etc - some are more significant that others. And highway=track is always for agricultural or forestry access, but can vary in length and quality.

[tomass]

That was a long discussion which mainly talked about unclassified vs residential,
so I didn't follow all of it, but I don't think there is consensus that all types
of highway=service and highway=track are in a certain hierarchical relation.

As most discussions in talk or tagging that one quickly diverted to non important things. Unfortunately this is how it goes. You have to concentrate on start of discussion where it was about the question asked, not about some other parts important to other people.

And highway=track is always for agricultural or forestry access,

That is only in Germany! There is simply no such thing as "agricultural or forestry" roads in Lithuania (and many if not all other countries).

If you tag the way mentioned by me or IgorEliezer as unclassified (or residential), then there would be no ways left to be tagged as track therefore there would be no hierarchy. Through road classification should not change depending on the presence of the house near it. Experience in mapping in urban area and creating a cartographically correct map with a hierarchy is required to understand what I mean.

Looks like discussion is pointless here or in the context of OSM-"carto" in general. Once again it goes to insignificant (off)topic of how to tag/map one particular road rather than the point I make:
visual hierarchy is one of the most important aspects in cartography and it is not maintained in "carto" style.

[Adamant36]

@tomass, I have a semi related issue in #3850. The same thing sort of happened there to.

[tomass]

@Adamant36 that is a different problem which starts with an incorrect situation currently when having no _service=_ value has a separate meaning and not "not enough data". This makes it impossible to fully complete _service=_ data in some region as it is not possible to know if missing _service=_ means it was not reviewed or not. Whatever current missing _service=_ means, it should get its own separate _service=_ value.

[kennykb]

@Adamant36 https://github.com/Adamant36 that is a different problem
which starts with an incorrect situation currently when having no service=
value has a separate meaning and not "not enough data". This makes it
impossible to fully complete service= data in some region as it is not
possible to know if missing service= means it was not reviewed or not.
Whatever current missing service= means, it should get its own separate
service= value.

That's true. The common case around me for no 'service=*' is that the way
is a private driveway or woods road serving multiple establishments (homes,
farms, forest tracts, orchards, scrap yards, quarries, whatever). The
landowners typically share the cost of maintenance, and it's typically
access=private (if 'private' is right for a shared road). It's not a
residential way, although there may be a house or two on it. 'Unclassified'
is definitely wrong, since if the way connects to the public road at both
ends, routers might try to put through traffic on it. 'Track' doesn't quite
seem to fit, either, it's a general access way for the establishment, not a
road chiefly intended for farming or forestry equipment. Many of them
around here are named and signed - the building codes around here lately
have required that a service way be named if it's shared by multiple
establishments or has a dwelling that is not visible from the public
highway. The sign typically looks like an ordinary blade sign for an
unclassified road, except that it has 'PRIVATE' under the name.

I attribute the root cause, as usual, to conflicting cultural assumptions.
My understanding is that the distributed pattern of settlement in the US
(where houses and churches often stand along on large plots of land, there
may be very few villages and hamlets, and a long, long drive to anywhere
with a market) is uncommon in Europe, so we lack a classification for a
public or private road that exists to connect a number of isolated
dwellings, businesses or places of worship to the highway network. For want
of a better answer, we tend to use 'unclassified' if it's part of the
public road network or otherwise intended to support through traffic, and
'service' otherwise.

Previous discussions on the 'tagging' mailing list have been, to say the
least, inconclusive. Nevertheless, I suppose we could have another go. That
would be a better place than here for further discussion.

I've tagged a fair number of these, and I've more or less kept track, so if
an appropriate 'service=*' tag can be found, I can tidy them pretty
quickly. I do not like the current convention. I haven't complained,
because it's mostly harmless: routers don't typically send drivers down
service ways unless their destination is on them, and the finest details of
what zoom level should have the minor roads appear don't bother me.
Moreover, the map as it stands winds up too sparse in rural areas anyway;
in my own rendering, I've done some experiments distinguishing 'urban' and
'rural' based on the 'built-up areas' polygons from NaturalEarth. It looks
promising, especially for PoI's, but needs considerably more work before it
makes it into any of the popular renderings (such as OpenCycleMap or
Humanitarian), to say nothing of the main map.