Honour key informal on paths

[hungerburg]

Expected behavior

Key informal can be used to tag anything, to tell something about how a feature came into existence, mostly it is used on paths though. Paths having this key=yes should be rendered differently from paths that do not have this key. Less prominently, not the same as access=no, but …

Actual behavior

This key is not honoured when rendering paths, but the very essence of it is, that those features, speaking of paths, cannot be trusted to be as welcoming or as nicely groomed, as features without it being in the mix. Mind you, unlike smoothness &c. it is not subjective.

Links and screenshots illustrating the problem

Samples abound, a prominent editor not too long ago took up the key in its inventory of suggested markup, for the very same feature of paths especially, so usage is expected to grow.

[imagico]

This is unlikely to be feasible - we have already been contemplating if rendering both access restrictions and the paved/unpaved distinction is feasible in #110/#3399/#4137. This would further add to the problem. Also note informal=yes is an inherently non-verifiable tag (intent of people is by definition non-verifiable).

[hungerburg]

So I fired up the Gimp for a mock-up, where every other dash of the stipple is omitted. Now contemplating, if that makes these paths more or less inviting; sample below.

Some elaborations of "informal"

The intent of the people, that created these paths is no secret, they just want to get from somewhere here to somewhere there. If a number of them, quite a small one is sufficient, happens to have the same desire, a path comes into existence. But how to tell, if one only sees the bare path on the ground, for the first time?

Informal=yes is a positive statement about something, that is absent. That in itself is not non-verifiable. Things to look out for might be guideposts and trail-blazes, benches and waste-baskets along the way, steps, handrails and other constructions, last not least, grooming and also paving. That is my understanding of things, that tell, that a certain path is not an informal one. Some foot-ways even may have started informally and grown into managed properties, cf. the article on desire-paths in the OSM-Wiki.

Another such indication of a path not being informal is the presence of it on a map; that is, most any map, but one based on OSM data. Showing informal desire paths distinct in OSM-Carto might help people that map what is on the ground in discussions with people that want OSM to only show what is officially designated, and safe in the sense of, there is somebody to sue, in case something went wrong. [Please excuse, I cannot help the diatribe.]

[Picture of two shortcuts between hiking paths]

[imagico]

We use different dashing patterns to indicate paved and unpaved paths, introducing a fourth dashing pattern to indicate a completely different tag that does not even describe a physical property of the path would definitely not be advisable.

Not going to have a tagging discussion here - i am sorry if my comment could be read to invite one.

[hungerburg]

I see, now I understand the link you posted. It never occurred to me, that there are differently dashed paths. Panning a bit, indeed, if they cross or are very close, I can spot those, I always considered these differences rendering/aliasing artifacts.

PS: So if stipple is already used for physical properties, colour remains, following the access distinction. Below picture of informal path painted "GoldenRod" in umap mockup at zoom 19. It is quite subtle, only double zoom shows the difference clearly so even someone not in the know cannot look and not notice.

Just a quick stab into the dark to get a bit of an impression

[imagico]

Yes, the clarity of the footway line signatures is a big issue we have had for a long time. See #1793, #1765 and #4097. There are known ways to do this better (see https://github.com/gravitystorm/openstreetmap-carto/pull/4097#issuecomment-605869908) but so far no one has gone to implement such here - partly because of the other issues with footway/cycleway rendering (which depend on moving cycleways away from blue color) that would be good to solve before or at the same time - see #1748 and https://github.com/gravitystorm/openstreetmap-carto/pull/4097#issuecomment-606032102.

[hungerburg]

I skimmed the linked threads. Reading the linking as an invitation to comment further, from my personal point of view:

On this issue here:

• Please keep no-acces showing - Consistently, people outside of the community, but also from within, complain about no-access paths being mapped at all; Rendering them visibly distinct as closed/forbidden in the standard map on openstreetmap.org is the only fair way to deal with wishes to wipe stuff, along a line "We map what is on the ground, and, look yo! if there are signs or other circumstances we are aware of, of course we map them too!"
• Please extend that to informal=yes, context more or less the same; Showing on a map might make some people believe, that something is managed; yet, OSM is not the city gardening department, and OSM-Carto is not published by that department. Still, making the difference distinguishable might help many discussions to a happier end.
• Both could be considered a way to deal with the success, that openstreetmap has become. Mappers that happen to care and mark stuff accordingly should get the support of the standard map.

On the other issues there:

• I would not mind paths over bare rock being barely visible on OSM Carto. Actually, its a nice match with reality, as these paths are usually in high mountain areas and just as barely visible on the ground too. If it were not for the trail blazes, lots of people would get lost. A dedicated hiking map will show them, as blunt as a hiking map must do, of course, and if out there, such a map is highly recommended anyways.
• If I understand the reasoning behind differentiating surface values, I guess that comes from the unfortunate dual use of path, as a multi-purpose way as intended some time in the past perhaps, and as a means to map back-country paths. Surface looks a good candidate to separate them; I'd include "compacted" as meaning "paved".
• There are some promising ideas in the other issues, I like the opposition of dashed vs. dotted, this is widely known from conventional cartography and can be grasped without a legend. I imagine that asphalt paved paths could even have no stipple at all, as those often are true roads, except for the width maybe, too little for an SUV, but the gardening department drives them with their Piaggio quite fine.

So much for the noise, please excuse if nothing of interest came out of it.

[matkoniecz]

I am extremely skeptical is it viable.

I tried really hard to implement road/paths properly - and fitting even surface is something that is either not done or basically failed.

I would say that this extra info is basically impossible to fit.

[map-per]

Another approach coud be to leave more empty space between the dots or change the with by making paths without informal=yes wider. (In CyclOSM e.g. the lines for path are a little wider)

[matkoniecz]

I looked at OSM Wiki page and had some additional doubt - see https://wiki.openstreetmap.org/wiki/Talk:Key:informal#Clarify_that_it_does_not_apply_to_features_that_evolved_into_official_ones

[pnorman]

I am extremely skeptical is it viable.

I tried really hard to implement road/paths properly - and fitting even surface is something that is either not done or basically failed.

I would say that this extra info is basically impossible to fit.

Closing for these reasons. We're already trying to display too many variables with the various path-like renderings, and I don't see how we could get anything else in. If we removed surface and tracktype rendering we could consider this.

[SomeoneElseOSM]

I don't disagree that the "everything louder than everything else" approach won't work - you have to decide what to show and what not to show, and there are only certain variables available.

However to help explaining the current situation both here and on https://github.com/gravitystorm/openstreetmap-carto/issues/1500 it'd be great if someone could explain what variables are currently in use - perhaps as an OSM diary entry. Maybe link to something like https://map.atownsend.org.uk/maps/map/map.html#zoom=16&lat=-24.99151&lon=135.11134 (which FWIW is based on https://github.com/SomeoneElseOSM/SomeoneElse-style-legend/blob/master/legend_roads.osm ) to show the current tags handled and what variables in the rendering are used to display them?

[imagico]

For linear ways tagged highway=path we have the following variants (including construction - which is not technically a variant but a separate primary tag).

Many of them can be combined obviously - leading to a larger number of permutations.

tag	rendering z18
highway=path
+access=no
+bicycle=designated
+bridge=yes
+horse=designated
+name
+oneway=-1
+oneway=yes
+surface=paved
+surface=unpaved
+tunnel=yes
highway=construction+construction=path

[cdauth]

I am rather unhappy about the decision that this proposal was rejected.

In our local forest there are paths whose quality ranges from this:

to this:

On the map these all look the same.

Personally I don't like the distinguishment between “paved” and “unpaved”, as it leaves no room for local varieties. For the same reason, the different types of roads are not tagged/rendered according to their surface, but for their significance in the context of the local road network. In my region, a path with surface ground, compacted or fine_gravel is often better to use for bicycles, wheelchairs and prams than one with surface asphalt or paving_stones. This might be the complete opposite in regions where it rains a lot or where the government properly maintains non-car infrastructure.

As opposed to roads and tracks, we don't have a way to tag the significance of paths. This is why I at least use the informal to distinguish two levels of quality/significance. Rendering that would give at least some indication to the user whether a path is one or the other of the two examples that I have shown above.

[matkoniecz]

In our local forest there are paths whose quality ranges from this:

Note that informal=no may apply to both upper and lower example. So rendering it would not really help with distinguishing them.

[cdauth]

Note that informal=no may apply to both upper and lower example. So rendering it would not really help with distinguishing them.

I agree, but as long as we don't have something like a pathtype, I am not aware of any better alternative than relying on informal.

Objectively, the quality of a path would be determined by its width, surface, smoothness and softness (for the last I believe we don't even have a tag). But the problem with those is still that they don't include any local context.

[imagico]

This is why I at least use the informal to distinguish two levels of quality/significance.

This is one of the reasons why we probably would not want to use the tag in rendering even if it was feasible design wise. Lacking a consensus about a verifiable meaning of the tag it is used widely by mappers as a subjective aggregate importance rating.

Side note on the concrete mapping problem (off-topic here) - the two examples you showed in terms of established verifiable tagging would differ in terms of surface=* (>4M uses on highway=path) and width=* (>500k uses on highway=path). The first would possibly by many mappers also be considered a different highway=* class (depending on practical use).

As opposed to roads and tracks, we don't have a way to tag the significance of paths.

To avoid misunderstandings: We interpret (in line with how most mappers also use them) the main road classes (primary to unclassified) as being a classification of functional importance - or in other words: of how the roads are practically used in terms of moving people and goods between places. The delineation between the classes differs between countries and is not always documented well - but it is at least locally applied fairly consistently and is in principle practically verifiable through observation of traffic.

That is fundamentally different from aggregate significance/importance ratings meant to indicate how someone would like a feature to be visualized in a map based on the combined consideration of many different aspects - which often includes factors derived from context in addition to inherent properties of the feature in question.

[hungerburg]

We interpret (in line with how most mappers also use them) the main road classes (primary to unclassified) as being a classification of functional importance - or in other words: of how the roads are practically used in terms of moving people and goods between places. The delineation between the classes differs between countries and is not always documented well - but it is at least locally applied fairly consistently and is in principle practically verifiable through observation of traffic.

Off-Topic: It is a pity that openstreetmap nomenclature offers such granularity only for motorized traffic.

[imagico]

Off-Topic: It is a pity that openstreetmap nomenclature offers such granularity only for motorized traffic.

That is a somewhat narrow point of view i think. You could also look at it this way: Functional importance can largely be inferred from route relation memberships. For roads OSM has - for historic reasons - developed the practice to use this information for primary classification of the road ways because large scale mapping of roads predates route relations. For paths large scale mapping happened significantly later when route relations were already established - hence there was less necessity felt to do the same.

This is still strongly simplified of course - there are other factors that play in here as well.

[hungerburg]

Even more OT: There are relations for motorized traffic too, route=road - Something that I was ignorant of for a very long time, likely there are consumers out for that, perhaps it is time for me to love them.

PS: I mapped my share of walking routes. I hate the datatype - an ordered collection - The most prominent editor messes those up consistently. A chore to keep the in shape. I map benches, guideposts, wayside shrines/crosses along the way and refs on the way. Perhaps some time in the futures some consumer can make use of that - sure indicators of a path having some kind of operator that guards usability or at least of having some notoriety.

PPS: Please excuse the rant of yesterday's. Here most of the walking network cannot be cast into routes in the OSM sense. German members of the community working on type base-network relations, that would be unordered collections. They can get quite large though. So some rather go back to lwn=yes. It so much easier.