-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Honour key informal on paths #4365
Comments
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). |
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.] |
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. |
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 #4097 (comment)) 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 #4097 (comment). |
I skimmed the linked threads. Reading the linking as an invitation to comment further, from my personal point of view: On this issue here:
On the other issues there:
So much for the noise, please excuse if nothing of interest came out of it. |
I am extremely skeptical is it viable. I tried really hard to implement road/paths properly - and fitting even I would say that this extra info is basically impossible to fit. |
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) |
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 |
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. |
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 #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? |
I am rather unhappy about the decision that this proposal was rejected. In our local forest there are paths whose quality ranges from 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 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 |
Note that |
I agree, but as long as we don't have something like a 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. |
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
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. |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: