Sure, we can discuss using this strict definition. However, eg MUTCD defines expressways and freeways as partial and full control of access respectively. If you want access_control=full to mean control of direct access only, =full could be defined as unspecified, and have =full_at_grade and full_grade_separated added.
To cover the case where the minor roads connected via RIRO doesn’t cross the major road, the definition can be clarified as “grade-separated when other roads are crossed”. I didn’t want to write longer and be more pedantic.
But what do you mean by a roundabout is controlled-access, when an intersection isn’t? Both are centralized at-grade junctions.
You already have a difference from the expressway definition in terms of divided roads, when expressway=yes includes single-2-lane grade-separated controlled-access roads. Why not use the highest common factor access_control= directly then?
I doubt how you can subclassify expressway= perfectly with different terms. It’s likely to cause some awkward if not counterintuitive tagging. That’s why I suggest using another categorization.
That’s why I think motorway and expressway should be terms used purely for rendering. Or expanded upon with other functionality-related values and each of the values would have default tags that a router uses in cases when those tags are missing.
This is jumping too quickly to a potential solution and making assumptions about what may or may not be possible.
National and global mappers can get onboard with sensible proposals that change tagging. @ZeLonewolf had great success with WikiProject Waterways/River modernization - OpenStreetMap Wiki by building consensus around the problem and then suggesting clear solutions that were minimally invasive to solve that clear problem.
Trying to suggest large tagging changes that will affect all mappers and data-consumers globally without buy-in and shared understanding of the problem to be solved will just result in circular arguments and a lot of noise without making any progress.
3 Likes
Yes, we agree that different places are inconsistent with their application of the main highway=* tag.
Why is that a problem? Is it causing any problems that the application of the highway tag differs from place to place?
So far what I am getting out of this discussion, is that the problem we are trying to solve is purely about bicycle routing. I am also understanding from your posts that inconsistent tagging between countries makes you very uncomfortable. But, discomfort is not really enough to say that there is a problem.
Are there any other specific uses of OSM data we can think of, that would be harmed by inconsistent tagging of the main highway=* tag between countries?
1 Like
So if we’re talking about the steps to take, I suggest everyone to add adequate importance=* values (listed on my wiki page) to highways in their country. The job will be a lot easier in countries that already use importance-based highway=* values. Though maybe an importance=* proposal should be carried out first.
Short highway=trunk segments cause transition_penalty for routers which could make the road less favourable when the goal is the opposite.
And overall I think it is a big problem if somebody mapping access-controlled roads in one country as highway=trunk, comes to another country and does the same thing when it’s not what its meant to do there. Inconsistency is always and issue. How is a data consumer supposed to know what a trunk road in a certain country is?
Even in the US it’s used for both important roads and urban arterials meaning based on parameters/functionality.
There’s also ambiguity with residential vs unclassified. In some countries these are the same, just differing by surroundings and in others they signify different levels of importance.
Another thing is having both highway=trunk/…/residential and highway=motorway/service/busway/… in one key which is something you just don’t do. Also no primary tag determines an object’s importance and it’s exclusive to highways.
Once again, you are assuming that a new key called importance=* is the solution to a problem that others are not yet in agreement about.
I’m really not trying to be difficult. I’m trying to help you formulate a problem statement that we can all agree on before we suggest solutions.
4 Likes
We are not, so please stop jumping to that. We are trying to ascertain what the problem is we’re trying to solve. For example, we certainly have cases of
…in the United States, in cases where a stretch of road motorway in parts and trunk in parts, where the build quality is below that of a motorway. This is not causing any problems.
There are also cases where there are
…between stretches of primary road. These are generally a holdover from the days when we used highway=trunk to describe what we now use expressway=yes to describe. We have mostly eliminated these cases by re-tagging the whole road as either trunk or primary and then adding expressway=yes to describe the built-up bits.
The problem with these
…is that it makes it impossible to generate a low-zoom road map using the main highway value alone. Before the change, you needed to pull in all motorway, trunk, and primary to render the interconnected road network, and that’s too many roads for low-scale (i.e. zoomed-out) applications.
Now, many folks in OSM are afraid to say that rendering has any value or consideration in how data is organized. Indeed, you will quickly get “oh, you’re tagging for the renderer” any time a renderer is brought up. Folks, maps are easily in the top 3 use cases of OSM data, if not the #1 use case. OSM data should be capable of producing good maps. The situation you are describing in central Europe makes it impossible to produce good road maps.
There is really no such thing as “correct” or “incorrect” OSM data, in the context of the main highway tag, unless you are in the UK or Ireland where it literally corresponds 1:1 with their native system. But, what you can say is “the current way that these tags are applied, makes it impossible to create usable low-scale (i.e. zoomed out) maps.”
Problem statement.
5 Likes
Good luck adding that key to the ~millions of roads already mapped on OSM and ensuring all editors will force users to add that key when mapping roads…
Yes I do think that for the reasons I have already presented. If you don’t agree then please give reasoning as to why not.
There’s definitely a difference between “tagging for the renderer” when adding tags to an object (problematic), and designing your tagging schema in a way that works for all data consumers (not problematic). The situation you’ve described is clearly the latter, and something that should be considered when proposing tags.
4 Likes
There’s a lot of replies in this thread, and it’s really hard to actually see a reasoning for using importance= as a tag. What people are asking for is the problem that led to you coming up with the idea, because what everyone appears to be seeing is discussion around a new tag that would result in massive changes in how to interpret roads, yet no clear reason why that new tag is needed compared to what we have now.
What’s the problem with the current road tagging schema, that can’t be fixed in other ways (i.e. better documentation, new tags for specific details, possible changes to renderers/routers/other data consumers)?
6 Likes
To clarify, osm.org uses routing profiles for OSRM and Valhalla that are maintained by FOSSGIS out of Germany, and OSRM indeed was largely developed by Mapbox’s Berlin-based team for several years. But by the same token, Valhalla was developed by a team based out of Lancaster, Pennsylvania, only one of whom speaks Pennsylvania German. 
Regardless of the developers’ identities, OSRM’s behavior has been pretty heavily influenced by tagging decisions in the San Francisco Bay Area a decade ago. Likewise, Valhalla was influenced by tagging decisions in the Mid-Atlantic around the same time. It’s only a lovely coincidence that mappers in these two regions of the United States happened to more or less agree with the German community on the meaning of highway=trunk while using the word “expressway” or “parkway” to describe it. But no longer.
access_control=* is a decisive key but not a particularly useful one. Renderers don’t need to depict roads differently based on access control, because they can simply depict the roads that exist and let the whitespace do the talking. Routers don’t need to route differently based on access control because they only tell people to bike or drive along paths or roads that exist. At best, this information would serve niche maps specifically about access control, of interest to roadgeeks and perhaps transportation planners but not to the general public.
By contrast, expressway=yes serves more practical needs. Many maps show a tier of highways that’s “better” than conventional surface streets but “worse” than full-fledged freeways/motorways. In North America, the public expects any transportation map to show this detail. The “Avoid Highways” option in navigation systems better approximates user expectations if it also avoids expressways as well as freeways/motorways. No extra detail is required. Expressway classification is useful because it’s a generalization.
As I’ve explained on multiple occasions, to the extent that we classify an urban principal arterial as highway=trunk, it’s because it provides an analogous level of mobility as a rural principal arterial, not because it looks similar. Otherwise, any incoherent highway=trunk you see in urban areas is simply outdated tagging.
We don’t need a new standard to solve the problem of inconsistently applied standards:
7 Likes
This rendering and routing decision doesn’t seem to be only option. You can certainly highlight access-controlled roads, and prioritize them (better flow, less conflict and interruption)? Doesn’t access_control=partial do the same at showing ““better” than conventional surface streets but “worse” than full-fledged freeways/motorways”?
Should we be separating to another expressway= vs access_control= post? Not wanting to bump this highway= proposal too much.
The Natchez Trace Parkway is a limited-access conventional road, not an expressway by any means. The Chickasaw Turnpike is a controlled-access expressway but it’s undivided (not a dual carriageway). Capitol Expressway is a divided expressway but it has scant access control.
Data consumer use of access_control=* is basically theoretical, while expressway=yes is in actual use by both renderers and routers. In addition to the use cases I’ve already mentioned, any router that handles default speed limits globally must consider expressway=yes in some jurisdictions, because that’s exactly how vague the law is.
So by all means promote tagging specifics such as access control, but they aren’t a replacement for classification.
I have been participating in the discussion on the motorway classifications proposal, and today I thought of extending the expressway=* key to allow describing both the limited-access and controlled-access versions of the word “expressway”. I have drafted a proposal for this, so I’d appreciate feedback on the discussion page.
It’s okay to want to see more rationale and reasoning but please stop saying there hasn’t been any reason given.
But to repeat, this is a big reason:
And to add to onto that, some countries interpret highway=secondary as what corresponds to the secondary road in their country by national classification.
You can see the full, broad list of interpretations on that wiki page I linked in the first post.
Another big issue is with correct interpretation but wrongly scaled: in the UK what is tagged as trunk will be tagged as primary in continental Europe, primary in the UK will be secondary in continental Europe and so on.
There’s no way to keep the current scheme and have a coherent definition across at least most of the countries.
Many have pointed out there are two different road hierarchies: importance-based and functionality/parameter based.
Some have proposed tagging such as highway=trunk + motorway=yes or highway=trunk + highway:quality=motorway which, by the way, to me it’s kind of weird to call a motorway a trunk road, and overall, because over half of highway=* values don’t depend on importance, I think it’s better to have functionality as highway=* values, similarly to what railways have.
To repeat, there is no other primary key which has its values be based on the object’s importance—only highways have that and not even consistently because only about half of the values are importance-based.
actually in Germany bicycles are allowed on trunk roads by default, to make them forbidden the tag motorroad=yes is used.
Generally as a cyclist I would prefer lower class roads if available, trunk roads are likely having lots of traffic and fast moving vehicles.
6 Likes
Looking at a fairly common situation in Ireland, both OSRM and Valhalla route cyclists straight through the village of Virginia here, on a trunk road tagged with bicycle=yes. Graphhopper routes partly on the trunk road and partly on side streets where available. It may penalise the trunk road too heavily in this specific situation (a village street with maxspeed 50). But that is presumably a parameter that could be tweaked (on Graphopper’s own website, it depends on which cycling profile you choose whether it detours off the trunk road or not).
Looking at other web routers, cycle.travel routes along this trunk road, and the BRouter web client uses it for some cycling profiles and tries to avoid it where possible for others.
For similar roads without the bicycle tag, OSRM refuses to route along the trunk road, while the other two don’t seem to be strongly affected by that tag (although it might change some relative weightings, I didn’t test enough examples to tell).
Overall the fact that some routers might not be ideally parameterised on the global OSM site doesn’t seem like a strong argument for reinventing highway tagging. But even assuming the proposal is worthwhile for other reasons, it is not clear to me how it would change anything in these situations.
9 Likes
Not quite. The ring in a roundabout is controlled access. You can’t just install a random driveway into one like a street. Access to the ring is controlled by ramps. That’s all the ingredients for controlled access right there. It’s just not grade separated.