Extended Expressway Tagging

General talk Tagging general discussion
,
1

As a result of the recent discussion about highway classifications, I decided to propose an extension to the existing expressway=* tagging, so as to better be able to describe the physical construction of a highway. The original goal of the proposal was to be able to describe a road as a controlled-access expressway (also referred to as freeways) independently of the highway=* value (since highway=motorway has importance/legal implications), but it comes with the added benefit of allowing roads that should be highway=motorway (in accordance with regional laws and mapper consensus) as a limited-access expressway when this is the reality. Some users have pointed out that in regions such as Japan, roads that are legally motorways can sometimes have LILO intersections or other access, so this tag would help to differentiate highways in such regions.

There is already some conversation on the proposal’s discussion page, but I would appreciate feedback here as well for those that are not comfortable using the wiki.

2

My rationale for extending the expressway=* key for this purpose is explained in this section of the proposal, but the two main points are:

  • The word “expressway” is used to describe both types of road in common language
  • The key expressway=* is already being used to talk about the overall physical construction of the road, without talking about legal classifications or importance
3

So what this proposal is doing is turning the expressway=yes tag which is growing in popularity and already has some support, into a new values expressway=limited which sounds like some sort of partial or bad expressway. Then it turns the motorway=yes tag into a different value — expressway=controlled. My question is: why? Why “destroy” two perfectly fine tags and break from the convention of motorways being the best roads and expressways being semimotorways? The reasoning seems to be just that motorway=yes describes a legal feature but I’m opposed to that usage. Tags describing official classification or signage should not be boolean tags but rather improve upon other tags, in this case zone:traffic=XX:motorway. OSM is British English-centred and both terms ‘motorway’ and ‘expeessway’ are used in the UK so I just don’t see any point whatsoever. Let’s fix actual issues like the wrong interpretation of highway=trunk in continental Europe.

4

expressway=yes will still be a valid option, though discouraged; it will mean that a road is either an expressway=limited or an expressway=controlled. Each retagging of an expressway=yes should be done on a case-by-case basis. As for motorway=*, I do not suggest altering the key at all. It will still be used as it currently is, to say whether a road has the same legal restrictions as motorways in the region. Whether or not you are opposed to this usage, the reality is that it is currently being used that way. Additionally, using motorway=yes has the potential for confusion with highway=motorway.

Much like we are able to say that a road is a limited-access expressway regardless of its highway=* value, we should be able to do the same for whether a road is a controlled-access expressway/freeway. I do not suggest replacing highway=motorway, or even altering most of those ways, since that tag will now imply expressway=controlled.

Furthermore, by having specific values for each meaning of “expressway”, we can properly express that a road properly tagged as highway=motorway for a given region’s rules (e.g. Japan) is not a full controlled-access expressway/freeway.

5

Essentially, I think that it would be best to have a single key (expressway=*) that is used to describe the overall physical construction of a road, orthogonally alongside a single key (highway=*, with the exception of highway=motorway which implies expressway=controlled) that is used to describe the importance classification. Having multiple keys used to describe what is essentially the same property complicates things and is not as descriptive.

6

I agree that it should be a singular key. I have explained my concept in the other thread already. I propose moving the importance-based values into importance=* while all of the highway=* values would depend on functionality, meaning there would be highway=expressway. I don’t want to stop here and I’d introduce more values such as arterial, collector, local, which will correspond to different sets of parameters of a road. I have explained the concept more throughly here. This of course cannot be implemented right away so another option would be highway=road + road=motorway/expressway/etc. (at first without highway=road).

7

This seems like it could be a reasonable idea. I expect it would function similarly to tunnel=* where all the values other than no can be interpreted as simply meaning yes, or they can be interpreted with more specific meanings depending on a data consumer’s needs.

I think we’d want to consider the possible values carefully and make sure we have some (at least theoretical) data consumer use cases for a level of detail beyond expressway=yes. If every data consumer would end up treating all the values the same then maybe there is no need. I’d also want to consider whether the existing tags access_control=full/partial/no and dual_carriageway=yes/no cover this same information or not.

A few years ago I made this chart attempting to delineate what counts as expressway=yes and what doesn’t. It specifies four level of access control which may be helpful in this discussion:

No access control
Intersects with most cross streets and provides direct access to adjacent properties via service roads and driveways. Intersections are standard at-grade style.

Limited access
Intersection frequency is limited to minimize interruptions to through traffic. Direct access to adjacent properties is right-in right-out (RIRO)* only, infrequent, or non-existent. Intersections are standard at-grade style.

Partial access control
Some access is via controlled interchanges with on/off ramps or RIRO* intersections. Other access is via standard at-grade intersections. Intersection frequency is limited to minimize interruptions to through traffic. Direct access to adjacent properties is RIRO* only, infrequent, or non-existent.

Full access control
All access is via controlled interchanges with on/off ramps. All crossings are grade separated. No standard at-grade intersections. No direct access to adjacent properties.

The reason I included a distinction between limited access and partial access control is to account for rural limited access roads that don’t look much different from a typical undivided highway but that do have small signs indicating limited access, a lack of direct driveways, and infrequent intersections by design. Here’s an example: https://www.mapillary.com/app/?pKey=145375070909988&focus=photo
Roads like this probably wouldn’t be thought of as expressways by the average person so I believe the general consensus has been to not tag them expressway=yes.

8

As a continuation of response to @Minh_Nguyen , I could agree if expressway= is a superset, with =motorway included as a subset, and =yes is an unspecified positive avoided as much as possible . However, the limitation of expressway= persists in naming.

  • =limited
    1. Unclear whether it means limited-access, a limited number or extent of criteria fulfilled over the entire length, or there’s a limited length where the requirements are met. The latter two is the usual meaning of =limited in OSM. =partial would have the same problem. Distinction from access_control= is lacking.
    2. Furthermore to me unlike @Adam_Franco Proposal talk:Extended expressway tagging - OpenStreetMap Wiki , single-2-lane undivided roads should be separated to a lower category.
  • =controlled
    1. It doesn’t distinguish between controlled-access grade-separated non-freeway-grade roads, and freeway standards
    • Besides geometrical design, there may be priority-controlled merges, and unseparated bus stops (depending on exact definition of access control adopted).
    • Rural ones may lack full-width shoulders, if this is expected for rural freeways
    1. Naming doesn’t highlight it having more requirements than access_control=full

So I disagree with having 2 classes only https://wiki.openstreetmap.org/wiki/Proposal_talk:Extended_expressway_tagging#2_or_3_values?

As a result, my suggestion is 4-class

  • =limited →
    • Eg =constrained : For single-2-lane undivided roads, and possibly other lesser quality roads
    • =semi (borrowing Singapore’s “semi-expressway” )
  • =controlled→
    • Eg =highspeed (Borrowing an official technical term “high-speed road”, and as a analogy to high-speed railways)
    • =motorway : Clearly shows they are =motorway standard. expressway= can be emphasized to be physical to clarify.
9

I’m concerned that this proposal stems from some misunderstandings which lead it to a poor strategic choice.

Colloquial English is a poor source for choosing highway classification keywords. I think we all realize it at this point. Every dialect makes different distinctions, using some of the same terms as other dialects but for completely different things. I grew up in Ohio, where every road is either a conventional surface street or a “highway”. We make no further distinctions. Now I live in California, where “highway” can refer to some surface streets too, and people say “freeway” and “expressway” when they need to distinguish what Ohioans call highways. Over in Britain, even footways and bridleways can apparently be highways too.

Because of this inconsistency, the name of expressway=yes comes from the field of traffic engineering in several English-speaking countries. The author of the original proposal for expressway=yes also comes from Ohio, so they don’t use “expressway” when speaking to family and friends. Nonetheless, traffic engineers and authorities there use the term expressway more or less like their counterparts in California, Canada, New Zealand, or the UK. It’s only a happy coincidence that laypeople in the western U.S. also go by the traffic engineering terms. (It’s probably an accident of history, something to do with when expressways were being built and the popularity of magazines like California Highways and Public Works back in the day.)

As far as I can tell, the premise of this proposal is that we need to consolidate physical classifications into a single key. I wouldn’t consider it a high priority, but it is a reasonable strategy if we expect to need several more physical classifications in the future, such as street and stroad. I do not think expressway=* is the right target for this consolidation effort. No one dialect or profession conflates both freeways and expressways as “expressways”, let alone considering other kinds of roads to be a subset.

Moreover, access control can be a good rule of thumb for deciding between highway=motorway distinguishing between freeways and expressways in some regions, but this rule of thumb is not a robust foundation for the proposed tagging scheme. The proposed limited and controlled values would be misnomers on freeways and expressways with atypical access control.

Another problem with the proposal is what it does to existing usage of expressway=yes/no. In general, the proposal process should not be used to broaden the meaning of an established tag that’s currently mutually exclusive of other tags. To do so would discard the hard work of countless mappers, requiring them to reevaluate or even resurvey what has already been mapped correctly. This is only a good strategic move when the existing tag has already been skunked beyond repair, such as with crossing=zebra.

Well, this is already confusing. Why are there two different tags for a legal motorway designation (a concept that doesn’t exist everywhere)? Can we settle on one, so that the other can express a build quality? The author of the expressway=yes proposal complemented it with motorway=yes, for roads that only pedantically qualify as highway=motorway due to physical characteristics. But highway=motorway could be that physical tag if consistency with the legal living_street=yes is preferred.

Instead, this proposal would commandeer a third tag to simultaneously indicate some notion of a motorway. I haven’t heard anyone articulate a problem statement that we have too few tags for motorways. On the contrary, I hear a desire for classifying highways that aren’t quite motorways. expressway=yes serves that need without intentional skunking.

If the real problem we’re trying to solve is that some of us wouldn’t personally use the same terms as traffic engineers in our own dialects, then the simple, no-build option is that an editor or data consumer can label expressway=yes as something else depending on the audience.

3 Likes
10

Okay, I have a few changes I think I would like to make to the proposal, to address some of the issues that people have had. Instead of adding new values to expressway=*, we could create a new key, expressway:type=*. That way, consumers could continue to look for expressway=yes or highway=motorway to determine if a road is of improved construction. To preserve the existing meaning of expressway=yes, it will now imply expressway:type=limited by default, but a higher tier can be specified manually by setting expressway:type=controlled.

There are already some roads that are of motorway quality but have been set to highway=primary+expressway=yes due to regional classification standards (e.g. here), so in these cases we would only be adding back the information by adding expressway:type=controlled.

Additionally, I will change the names of the values:

  • expressway=limited → expressway:type=basic
  • expressway=controlled → expressway:type=best

The exact names are still up for discussion, though I quite like expressway:type=best for the highest quality of roads in a region (this should mostly align with highway=motorway, which will imply the tag by default). If anything, this is the meaning that I would expect =highspeed to have, as is the case for railroads. I am considering whether to add intermediate values like @Kovoschiz suggested, but I would want to make sure the difference is decently clear.

11

If this is needed, *:type= is a meaningless suffix that should be replaced with a specific aspect. =basic and =best seem too subjective-looking and normative.
For =highspeed , I don’t meant it to be exactly the same as HSR. In a sense, preexisiting lines upgraded to 200km/h is considered high-speed. Roads have freeways already. It’s a characterization, not precise term.

1 Like
12

I don’t understand the problem subclassifying expressway= ? You could consider eg expressway=motorway to be a negative if you want, as in it is and is not an “expressway” at the same time. For me, what I intend is to distinguish different definitions of “expressway”. Otherwise this term isn’t favorable from the various connotations and expectations across the world.
highway=motorway serves a functionality classification at the same time. So motorway= can be the legal, and expressway= the physical.

13

That’s just not what the used terms are. Nobody thinks of a motorway as a type of expressway. Furthermore, it makes no sense to have motorway=yes as a legal tag because many countries, e.g. Hungary, have both motorways and expressways so they should have a legal tag for both. Would you recommend motorway=expressway? Come on. Can you tell me what’s wrong with zone:traffic=XX:motorway?

14

can you explain how Hungary “has” “expressways” and “motorways”? Or maybe they are “freeways”? Isn’t “expressway” a synonym for “motorway”?

15

Can you improve your reading comprehension first? We are discussing motorway= for highway=motorway , not “expressways” that are motorroad=yes legally. No one is talking about your zone:traffic= here. Please keep that to your other posts.
This is about spiting what expressway=controlled is. There are freeway standard ones, and lesser ones that are still better than the other expressway=limited proposed.

16

In some countries motorways can lie inside built-up areas

17

What do you mean by specific aspect? I like the idea of using a suffix like this because that way, we could properly preserve the meaning of expressway=yes without any other tags. The default value of expressway:type=* should correspond to the current typical meaning of expressway=yes. It also would more safely allow consumers to treat the road as some kind of expressway, since treating any non-=no value as =yes could be suboptimal in the case of undefined values (e.g. =n). Consumers wouldn’t have to change anything for this, whereas with expressway=controlled they might treat the road like not an expressway at all unless they update.

I agree that =basic is not perfect, but I think =best works fairly well. It would be applicable in the usual case for highway=motorway, with that tag defined as “the highest-performance roads within a territory”. As such, highway=motorway would now imply expressway:type=best, but this can be overridden in cases like Japan’s motorways with LILOs. As for additional values besides the two I mentioned, I am open to the idea, but the difference should be clear.

18

Nobody thinks of a motorway as a type of expressway.

It doesn’t sound that unnatural to my ears, since in my region “motorway” isn’t used at all and “expressway” is used to talk about freeways. But either way, expressway=* is already being used to talk about physical class, not legal.

19

In other words, tag the specific characteristics that make something limited vs controlled access.

20

Let’s break down this example, since it seems to be part of the motivation for your proposal. The LaSalle Expressway is a freeway in New York that happens to be named “Expressway” (as a great many indisputable freeways are). It’s less than 3 miles long, a spur of another freeway that terminates onto a local street. The freeway was planned to be at least three times as long, connecting to a second freeway on the other end, but those plans never panned out.

The LaSalle meets most of the qualifications for highway=motorway in the national guidelines, except for the last one:

Designed and maintained to support high speeds over long distances as part of an interconnected motorway network

This is a sanity clause to prevent the sort of pedantic “motorway” classification that instigated the whole classification guideline project: a certain mapper went around the whole country identifying each individual grade-separated interchange on an otherwise conventional road and painting a short highway=motorway around just that interchange. Preventing this practice was such a priority that it appears multiple times in the guidelines:

The set of roads tagged highway=motorway or highway=trunk should collectively form a coherent network of interconnected roads, without dangling spurs or “islands” of disconnected roads.

There was no consensus to use this guideline as a cudgel against real-life freeways that dangle or jingle. The guidelines explicitly allow a motorway to be inessential. The LaSalle surpasses the most conservative distance threshold for a valid “motorway island” that we could agree on:

Roads which are disconnected from the motorway network, but briefly exhibit motorway-like characteristics for short distances (also known as “motorway islands”), should not be tagged as a motorway. In general, a disconnected motorway should have multiple grade-separated, controlled access interchanges over a significant distance, generally at least 2-10 miles, in order to be tagged as a motorway island.

Mappers in New York chose to customize the national classification guidelines based on official NYSDOT classifications, assuming that it would save them the work of classifying everything by hand. NYSDOT assigns the LaSalle an ACC of 3 and an FCC of A15 (“Limited access, separated”). This falls well within the A10–A18 range for highway=motorway. In the interest of making the map look tidier, there’s a carveout that an ACC of 3 or greater becomes highway=primary expressway=yes. The idea is to deemphasize the many beach access highways that Robert Moses was notorious for. The LaSalle is collateral damage.

This downgrade doesn’t sit well with you. Surely there must be some way to indicate that it’s an actual, real-world freeway without cluttering a perfectly rational map. Fair, but why does this indication need to go in a key named expressway=*? You’ve pointed out that proliferating mutually exclusive keys is problematic, but I don’t see two as proliferation. And if there are more than two possible values for different kinds of highways, then expressway=* is definitely too specific a key.

We’re presuming that it’s too late to define motorway=yes as a physical attribute rather than a legal one. But if motorway ends up as a value of expressway=*, then it needs to coexist with a disjoint yes or some weird value like expressway=expressway. The number of dangling freeways is extremely small compared to the number of real-life expressways that would be affected by your proposal, rather the tail wagging the dog.

Are you sure expressway-something-or-other is the only possible solution? Why not take a page out of @pavvv’s many proposals and use something more generic like highway:physical=* for refinement, by analogy with maxheight:physical=* and maxwidth:physical=*? Then we can solve other problems at the same time. People frequently ask me how they can tag a road as a stroad, but I have no answer for them. expressway=stroad would be an oxymoron, but highway:physical=stroad gets the point across without extra confusion.

expressway=yes was an attempt at avoiding colloquial terminology in favor of international terminology from the traffic engineering field. I’m sorry that traffic engineers in your region are an exception. That doesn’t justify intentionally skunking a key that’s in significant use. By the same token, here in California a motorway is a winding dirt road, while in Indiana it’s a raceway, but I’m not going to suggest motorway=track and motorway=raceway on that basis.

By stuffing the fast-but-not-too-fast kind of motorway into expressway=*, we’d exchange one problem that’s been manageable so far for several more that we haven’t even begun to think through. Let’s give the alternatives a chance.

2 Likes