Proposal talk:Pathtype(alternative)

Marked as 'abandoned'

I marked this as abandoned today as the proposal did not ever gain any interest or support. Rostranimin (talk) 13:55, 19 May 2019 (UTC)

Initial discussion

Space for initial comments - please remember to sign your contribution

Discussion taking place elsewhere

[https://www.openstreetmap.org/user/Rostranimin/diary/34533 Diary entry about making this proposal, with a full set of comments and replies (ongoing April 2015) --Rostranimin (talk) 21:20, 19 March 2015 (UTC)

Alternatives preferred?

sac_scale=*

This proposal seems to duplicate to some extent the already used sac_scale=*, maybe better study the sac_scale tag and rather propose additional values to that? --Skippern (talk) 22:20, 9 March 2015 (UTC)

Skippern - I agree that sac_scale is a good tag, but I think it's designed for quite a different purpose, and in particular that it doesn't cover very many of the situations I think the proposal would cover (e.g. the huge differences in paths in many urban parkland areas). I've considered using it often but always rejected it for the types of path I'm most often surveying (rarely in 'hiking' country as such).--Rostranimin (talk) 13:07, 11 March 2015 (UTC)

wheelchair=*

pathtype=a1 and pathtype=a2 would be better tagged as wheelchair=yes and wheelchair=limited. --Peter Mead (talk) 13:54, 12 March 2015 (UTC)

Hi Peter - I chose wheelchair use as an easily remembered concept, but have tried to make as clear as possible in the proposal that it's to be used as a measure of path quality not accessiblity. There are many places which I'd tag as pathtype a1 or a2 because at that immediate point a wheelchair could be used, but as wheelchair=no (or at least not wheelchair=yes) because the section of path is inaccessible. This IS confusing and I wrestled with the idea for a long time, but I can't think of any other simple concept that captures the combined elements of width, surface quality, incline and tilt (and probably several other factors)... at least nothing as clear as the idea that a wheelchair could or couldn't be used. I even wondered about whether the idea of pushchair (pram, child buggy, stroller) use would be clearer, but I was looking for something which makes sense internationally (e.g. in developing countries where carrying a baby might be more common). Also, pushchairs vary hugely in design (even more so than wheelchairs). I'm not sure if you missed this in the proposal or if you disagree - if it's that you missed it I'd like to know how to make it clearer. If it's that you disagree it would be good to hear ideas about some other simple measure to replace the idea. I wish I could come up with something to work around the problem of this being confusing, but I can't. --Rostranimin (talk) 14:57, 12 March 2015 (UTC)

Avoid values that require a key

While I see and appreciate your rationale, perhaps consider encoding the tags such that the data consumer doesn't need a key. OSM data can travel a long way from ‘The Map’, and it should be obvious to anyone seeing the data what the keys/values mean. With a two-character alphanumeric code, however, the user will always need to refer back OSM docs to be able to use the data. Consider using multiple tags with understandable values, rather then a terse, non-intuitive encoding.

I do have a little difficulty parsing the distinct elements/axes you are trying to encode/represent here. It looks like there are at least three, possibly four:

1. Visibility
2. Obviousness
3. Walkability
4. Wheelchair Usability

Maybe you could consider breaking the tagging down to elements? This would allow you to tag “unobvious, but easy to walk” paths --Scruss (talk) 01:18, 21 March 2015 (UTC)

Scruss - I've been wondering myself if we could do what I want but with two or, at most, three tags. I can't make this work though. It should be said that I'm NOT trying to encode the things you mention - that shows a misunderstanding (quite possibly the fault of my writing of course). What I'm trying to encode is the path hierarchy which we'd all recognise on the ground, but which is really really difficult to capture in data terms. When maps were drawn rather than being created from encoded data this would be captured simply with different symbols (strength of line or length of dash for example). The problem is that we're not creating our maps this way. If we're going to work from data to create a map (or something similar in data terms, such as a routing weighting) there are many features which come into play, which people are already trying to tag... we have Key:width, Proposed_features/Surface_Quality, Key:surface, Key:incline, Proposed_features/smoothness, Key:trail_visibility. To capture the character of a path properly so that we could draw the line differently (etc) we need to record AT LEAST these features.

Walkability is an interesting idea, but I suspect a difficult thing to work with. Obviousness and visibility I would like to find a better way to encode, as one tag not two... perhaps the problem is that 'Key:trail_visibility' is intended for remote situations (so doesn't work in an urban park or as an informal path becomes generally more faint). I do see an argument for something better about visibility to cover such situations perhaps - not trail_visibility, but path_visibility=good / moderate / poor / invisible?. Anyway, the point is that as a regular path surveyor I find that I cannot, in reality, record these features in sufficient detail to tell us what an old-fashioned map would have no problems conveying (and that's ignoring the issues arising with the severe lack of agreement on some of the tags I've listed).

Could we create a set of words to replace a1, a2, b1, b2, c1, c2? Perhaps... but I tend to think that this actually would make things more not less complicated. I did wonder about somehow having a flexible tag... composed of a set of approved words in any order. I don't know if this would work technically, but anyway when I tried to come up with words the whole thing quickly became far too complex to work.

So how else to do what an old fashioned map would do easily... to summarise for us what's the 'main' path... what's something solid and generally easy to navigate (physically and in terms of visibility), and what's the faint half-worn indistinct desire line which disappears entirely under leaves in Autumn or under new growth in spring?

--Rostranimin (talk) 20:51, 21 March 2015 (UTC)

Is this more about path quality?

Have been thinking about this for a while now, and it's not easy. But I wonder if what you are trying to capture is more about the path quality. I don't find the definitions of unobvious/obvious/wheelchair to be particularly clear in defining the types, although they could perhaps help when classifying.

As I see your proposal, there is basically three levels (although then subdivided into upper and lower tiers)

• good quality paths, that most people can walk/wheelchair/cycle along without problems and don't have to think about where the path goes
• intermediate quality, that may be muddy (requiring something other than normal everyday footwear) or may not be so well marked on the ground
• poor quality paths, that are either difficult to walk along because they require technical skill (steep/rocky/etc.) or that are just difficult to see where the path goes

--10:04, 5 April 2015 (UTC)Drnoble (talk)

Alternative(alternative) classification with descriptive words

To expand on the quality section above, and take into account the concerns about using values that require a key, how about the following 5 point scale (which maps to tracktype in someways). I also find it more logical to go from best to worst when defining. This loosely mirrors the Key:tracktype and Key:trail_visibility tagging schemes. I have also tried to add in how I see your classification maps, but feel free to adjust my interpretations

new value	description	your class
excellent	well built path with either tarmac or well compacted surface, can use wheelchair/mobility aids or scooters without issue (noting as you have that steps elsewhere may actually prevent this)	a1
good	surface quality not as good (perhaps too rough for small wheels of scooter, or too steep for a wheelchair) but still an obvious path that doesn't take too much effort for an able bodied person to walk along, and can easily be seen (well marked)	a2
intermediate	paths that may be a bit muddy (requiring something other than normal everyday footwear) or may not be so well marked on the ground (requires some concentration to follow) but still the sort of path most active people would walk along. Could tag surface=mud, or trail_visibility=horrible as appropriate, but this is not required for it to be useful	b1, b2
poor	paths that are either difficult to walk along because they require technical skill (steep/rocky/etc.) or that are just difficult to see where the path goes. The former would also be tagged with SAC scale.	c1, c2
horrible	completely overgrown or muddy sections, possibly where there used to be a path, but now only the most intrepid walkers would venture. Shouldn't normally be rendered on the map, but there for completeness - e.g. to show that path apparent on aerial imagery is not passable, or that an old route is now so overgrown it is almost impassable.	?

I think that part of my problem with the proposal is that conflict between wanting a hierarchy of types (symbology on the map), having a two dimensional tagging a/b/c & 1/2, and the fact that the second dimension is not consistent between levels (relative ease of use for a/b, but visibility for c) --Drnoble (talk) 10:10, 5 April 2015 (UTC)

What we need to capture/map

I was considering this issue again recently, trying to come up with a list of simple words to capture a path's character - or a list of ='yes'/='no' style keys which would work. It seems useful to write the list of things I was thinking we need to capture to convey a clear idea of path character - see below:

• maintained / unmaintained
• bound / unbound / created by wear
• worn by people passing / worn by animals / worn by people slipping
• single-track / double-track / multi-track
• narrow / wide / very-wide
• distinct / indistinct / invisible
• level / steep / very-steep
• level / sloping / very-sloping

This looks unmanageable - but there might be defaults - so the default could be maintained, bound, single-track , wide, distinct, level.

--Rostranimin (talk) 17:31, 6 April 2016 (UTC)