User:Ben/Highways

link to map features

The Standardised Tagging Scheme

• I’ve gradually moved from following the tagging scheme tightly to gradually deciding that accurate data is the most important thing in OSM and this has started to make me tag very independently from the tagging scheme. I am therefore going to start this discussion to try to sort out some key problems that are really limiting any mapping that is more than just the quite basic things, as I am getting concerned that as the amount of people working on OSM increases, big changes/alterations mean more work, and I am worried that big problems with the tagging scheme will be therefore stick just threw such common usage. I’m gunna go off on a really long rant here, and I hope something can come of it. Please break it up and reply wherever, and maybe it’ll get somewhere.

• I think it’s important to have tags have quite accurate definitions, and variations from each country should be included in the data, rather than presumed, otherwise filtering out data would be inposible as 2 differnet things may be tagged the same. If keys and tags are unspecific and people use them anywhere then osm’s data will never mean much also. Multiple uses may go beyond just making the definition imprecise, it may be contradictory.

• What is usually debated on the wiki is what name a tag should have, which in the long term I don’t think matters so much, because interfaces may just translate tags to appear as what ever a person wants then to appear as. What’s important is the use of the tags, and how they are grouped so that things can be filtered and searched for easily. Things should be able to be tagged exactly with minimal amounts of tags, and with each tag having a purpose, so not being wasted. The main area where I think this problem exists is highways, so I’m gunna start there.

’What is a ‘highway’?: Permissiveness

• There is a key difference between ‘Can’ and ‘May’ that I think OSM seems to be blindly avoiding splitting apart. They are completely different. I can walk across someone’s lawn but I may not do so. I can nick stuff from a store, but I may not do so. etc. etc.

• Their lawn therefore may have a footpath across it, but it’s not a highway, so I cannot use it unless granted permission. A foot’way’ in my opinion isn’t where you can walk, it’s where you may walk, as it appears under the ‘highway’ key, which by definition (*1) is “A main, direct, public road.” (Road in the sense that it’s “A narrow strip of land made suitable for travel between places.”).

• Currently within OSM things are just being tagged as they visually appear, and some would say that the ‘Highway’ key just means anything that anything can go on (split apart by values), which is incredibly vague. There are 2 key problems with this.

1. What one person can go down is different to what another person can go down, and it’s not up to OSM to decide where people should go, but rather inform them of where they may, and of any obstacles that may be of concern.
2. If something visually appears like a highway, then how do we tag something that doesn’t appear like a highway but is, and tag it apart from the ones that aren’t but do? I.e. How do I tag tertiary roads since currently (where I have seen it being used) its just used to tag roads that are bigger than unclassified but not secondary. If I tag a tertiary that is a tiny road then I’m going against the way OSMers have physically defined it, and if I tag it because it’s physically like a tertiary road, then I’m ignoring where it really is tertiary or not. Either way is devaluing the other, and making the tag worthless.
   1. An example of this is the M96 near Morton-in-Marsh. It isn’t a highway, or a motorway. It looks like a highway=motorway, but isn’t. It’s something that physically has the same properties as a motorway, but is not public, and does not have motorway laws or access rights. It is called a motorway as a name, but the names not based on its status, but rather, what it’s a mock up of.

That is my reason for being against tagging by just physical characteristics, or by what one particular person can go down.

Therefore, if the ‘Highway’ tag means a public road then there are a few variations of a place you ‘may’ go.

1. Highway=Access Rights permit you to go down a route.
2. Provided=Councils/Local Government Provided a route that you may go down. i.e. a pavement
3. Permissive=A land owner has agreed to permit the public to use a route, but may choose to revoke that permission
4. Suggested=A route that is in an area that is public such as the Scottish highlands. A path has no more access rights than the land around it, but it’s an advised route to take.
5. Private=A member of the public must request explicit permission to use the route.

These 5 variations could either be keys or go under the access key and highway get changed to juts ways=. Personally I think they should be keys for the following reasons. If they are access values then:

1. Changing all highway to ways may involve some effort?
2. All highways with way= would require an access= (maybe excluding 1 access value that is default). This would double the tags required to do the same job.
3. Some people may dislike the key ‘way=’ just because ‘way’ has other uses in OSM.

1. If people just wanted highway information, filtering out other information wouldn’t be as simple as to just filter out all highway= tagged ways. It would require looking for all way= with highway also.

• Therefore I would personally be pro the first idea of having them each as a key. The problem I can see with having them as keys are:

1. Terms such as ‘provided’ are descriptive rather than being a singular with variations, like the other already existing keys. (excluding a few). This could be avoided by making the keys a singular rather than descriptive though. i.e. provided_way=footway. (*2)
2. It may appear more complicated, although complex from the start rather than getting increasing complex.

(*2) Personally I think the words used is far less important than how tags are arranged, but it’s a critism some people might see with that idea.

• It is important that these are all split apart so that a route planner doesn’t take me strolling over someone’s lawn, and also informs me of the certainty that a route is there, because a permissive route over someone’s lawn may just be closed without warning, so I should be aware of this when planning/doing the route.

• I think that if unknown something should never be added as highway, but private (which could be assumed with the lack of an access tag), because private is of little value, while highway is the highest value, so it shouldn’t be assumed. Just as unless people know, its best to add a road as unclassified not a motorway.

Features used as 'highway'

• The next problem is that some highway values assume other highway values, and are as well, not highways physically or politically, e.g. steps. Steps aren’t a highway, they're a feature that a route goes over, just like a cattle grid. [Or a bridge. --Hawke 07:21, 10 June 2007 (BST)] To add ‘highway=steps’ assumes it's highway=footway; with steps (when used on a segments/way). Steps aren’t a highway, and they aren’t necessarily on a footway. The same can be said for most of the second block of highway tags on the tags page. Tracks is another example of this same problem. Adding features such as a gate or cattle-grid are features that fall along the way, and I think justify there own tag. Features= or obstacles= or something to similar effect. (Discuss), but there not highways for sure.

Multiple-use routes

• This problem also exists where a higher status of highway is assumed to permit the same and more than lower status ways. E.g. in the UK a bridleway is above a footway as it has what a footway has and more. But for the purpose of OSM I don’t think we should assume anything. A Bridleway should only be horse=yes by default. This sounds contradictory to my earlier point as it would then need highway=bridleway foot=yes for all uk bridleways, but I think this could be taken care of with additional tags such as highway=bridleway_footway, and highway=cycleway_footway, wich would half the tags. (just an example, propose better).

• highway=path with Template:Access is a good solution for that --Cbm 15:49, 13 July 2008 (UTC)

Primary vs. Trunk

• The next problem! With some highway tags, multiple tags exists for the same highway, but are being used either as a shortcut for many tags, or are used to tag the same type of road under different management (in the UK). Highway=trunk and Highway=primary for example. A trunk road can usually be expected to be bigger that a primary, but not necessarily. So is highway=trunk just there as a shortcut for highway=primary + lanes=2 oneway=yes highway=primary etc. etc? Or does it mean that it’s a primary road that joins two important places? Does it split apart roads that just have different coloured signs, or should it be used to split apart roads that are managed separately? (HA/LA’s) For the latter I would think management= would be better for the UK as that is what is different. Although highway=trunk/primary may be legally different in other countries so have a reason for there being a tag.

Highway values: special ones just for rendering, unclear definitions

• The next problem with highways, is some tags seem to have been added just to render differently, but don’t have an exact meaning. Unclassified, residential, and service are the three. I do think there is a need for theses tags, but they should be used to tag roads that are quite different, not just to get a render, and not just as a shortcut to save adding abutters or width= tags.

• If you take a village, I would make any road that traffic uses to get to places other than the houses on that street and its side streets, an unclassified road.

• I would define a residential road as a side street that was built so that the houses could be accessed. I would define a service road as a road that is there either there just for access to none residential places, or roads used round the back of buildings, used for deliveries.

• The roads I have difficulty deciding on is the little roads that come off the sides of residential roads, and often exists on new housing estates in the UK. They are private to the people who own houses along it, and you would usually go up a lowered curb stone onto the road bit. The road isn’t public and is up to the residence to maintain. In effect they are just driveways that are large enough to map. I have tagged as service in the past, but highway=service is incorrect, just because they're not highways, they're private=drive/track/road really. Suggestions?

• Can we come up with some more clear definitions of the tags / change tags / make or remove tags etc.., so that they can be used with more certainty? This is how I have come to find myself using them in order to tag all roads, and keep noticeably different roads split apart. Apart from a few things tagging this way has removed all the problem I have had in the past, and clearly split apart what is different in relation to mapping and route finding.

That is ‘all’ I have to say for the time being. Please discuss

(*1) = Checked OED, Wikitionary and Dictionary.com

Discussion

Hawke

What /is/ the M96 near Morton-in-Marsh, if not a motorway? IMO if it's built to the standards of a motorway, it should be tagged as one. (motorway indicating: no non-motorized vehicles ("limited access"), one way, surface=concrete, etc.) It may need something like access=permissive or whatever...but I think "motorway" indicates the physical configuration rather than the legal configuration.

I propose the term "route" instead of "way" to avoid the ambiguity in reusing "way". Whoops, looks like route is already taken. Perhaps the current "route" tag could be expanded, or another synonym could be used.

Rather than adding so many keys for the access level, I suggest keeping (but deprecating) the key "highway" for any route suitable for automobiles. This would avoid the hassle of re-tagging pretty much every way in OSM.

IMO a better solution is to expand the use and definition of the access tag. The current values of the access tag: yes/private/permissive/unknown/no correspond rather closely with the highway/provided/permissive/suggested/private you describe. yes = highway, permissive = permissive, private=private. I'm not really clear on the suggested or provided values, so I'll leave those to others to deal with. I see no problem with those being used as well if they're useful.

I agree 100% that "steps" is a feature rather than a highway type.

For the multiple-use routes, I'd like to see something like "route=trail; bicycle=yes,foot=yes,horse=yes,ski=yes,snowmobile=yes" Alternatively, "route=trail; use='horse,bicycle,foot,ski,snowmobile'" might work, if it works with the renderer (I have my doubts). So a UK bridleway would be "route=trail; horse=yes; foot=yes" or "route=trail;use='horse,foot'"; a cycleway would be "route=trail; bicycle=yes;foot=yes" or "route=trail;use='bicycle,foot'". This also avoids the need for route/highway values for every possible use. (the "use=" tag would have that problem though)

The primary/trunk problem is also a problem in the US, where the TIGER data only has motorway/primary/secondary designations.

Perhaps neighborhood "through roads" would be a good use for tertiary? That's how I've been using it.

I think the "service road" is already used correctly, as we discussed on IRC. Anyone using it just to get a narrow road rendered is using it wrong. Perhaps the definition should specify that they must be unnamed?

For driveways, route=service/track, access=permissive/private? I would like to see a "drive" or "driveway" route/highway value.

Ben

Well after a long IRC converstion on the matter, it seems that there is some general agreement from those in the converstion that the following would work. It goes beyond the highway tag.

Highway=

Route=Road/track/trail/path

Access=

Instead of adding =yes tags to everything, the access could be used to add something such as US:Skislope. This would then just reference 1 meaning, wich would be how the tag is defined. The tag would then be linked to a definiton/law/description. This would then mean when this is changed, all tags would change. Instead of manually having to add or remove =yes/no tags everywhere its used. The other current problem with =yes tags is that in theory there is almost infinite amount os things that may go down a route. e.g. Rhinos can be taken down a UK bridleway, as I would suspect theres no law stating they can't. But rhino=yes shouldn't need to be added to each bridleway in the UK.

As a result of having values linked to an exact definition, predefined definitions would be needed for differnet regions/countries/places.

Access= would be presumed private unless stated.

The Route tag (wich values would need work as US/UK definitons varie) would just mark routes, rather than the highway. These would be private unless an access tag states otherwise. Or they are just a highway. Ben 04:22, 11 June 2007 (BST)