for start, they appear to have distinct names (not sure are names tagged correctly, unfamiliar with location but in cases known to me trails very very often if not nearly always have names distinct from path/road names)
We make a distinction between roads (the local name) and routes but most people who don’t think about this stuff all the time will be just as likely to say “this road is called Route 7” as they will be to say “this road is called Shelburne Road”. A route is just a certain type of road as evidenced by the tag being route=road. I don’t see this situation as fundamentally any different from a hiking trail having two different identities where a long distance trail follows a path with a local identity.
I wouldn’t say it like that. I’d say there are some properties that apply to a road segment (surface, lanes, presence of sidewalk) and other properties that apply to the whole length of the road (mainly name or ref). So surface=asphalt applies to one section of the road, but not another where surface=compacted applies instead.
I doubt it’s USA specific to have a path with a single name. This seems like a very common and normal thing. Are you saying that every named footpath in Poland always has at least two names? One that somehow names just the “path” and one naming the “route” that follows the path? There are no small, unimportant paths that just have one name? This seems very odd to me, but perhaps I am just not understanding properly.
Regardless of all this, the point I’m trying to make is that it seems to be working out fine having many paths mapped as relations so I don’t see how roads/streets being mapped in the same way would be a horrible maintenance nightmare.
I would need to run some data analysis, but only small part of roads and paths is in hiking relations. And editing them is more annoying than paths and roads free from relations.
Public transport routes are also making things really annoying.
But for street relations big part of waste is manually building relations that can be seemingly auto-generated if someone needs them, unlike hiking routes. I worry that people start spending massive effort on something that seems pointless.
It is typical to have say Yellow Foobar Trail hiking route going on unnamed paths. So having them represented as separate object makes sense.
This does not happen with road names - given road will have a single road name so benefit of adding relations to data modeling is small.
EDIT to answer lower post:
Yes, it would be “Let’s take a walk on Yellow Foobar Trail” - but it would be used by hikers walking on trail, not used in context where road name would appear.
But would someone actually say this in real life though? Or is this just the way OSM people think about it? “Let’s take a walk on Yellow Foobar Trail hiking route following unamed paths” sounds rather awkward. I’d expect most people would simply say “Let’s take a walk on Yellow Foobar Trail”.
Let’s take a step back. I don’t think we need to decide here whether individual streets can have names. Everyone participating in this thread so far hails from a country where they generally do have names. We also don’t need to decide whether there’s a notion of a highway route separate from the notion of a road or street. That has been proven many times over by mappers and data consumers. Trails can get a bit fuzzier because they often aren’t as systematic as roads in many respects. We can try to hash out a consensus about them, but I think it probably deserves a separate thread.
Aside from any routing aspects, what is a street, and how do you delineate it? One very common way to delineate a street is to look for the (mostly) contiguous roadways that share the same name, modulo the occasional directional prefix. But a street is more than a name, as the Wikipedia articles demonstrate: it has an identity that may be bound to a long and storied history, all worth documenting outside of OSM. OSM benefits when there’s some link to those external projects in one direction or the other. We can tag individual roadways with their wikidata=* tags, but some mappers have attempted to refactor them into a single coherent relation, following the mantra of “one feature, one OSM element”.
Now take the paragraph I just wrote and replace “street” with “waterway”. There’s still a lot of uncertainty about how to delineate a waterway, but no one argues for the abolition of waterway relations. In some regions – maybe not Western Australia – there are even more waterways than streets, but we take a pragmatic approach, sometimes creating waterway relations and sometimes just tagging wikidata=* etc. on individual waterways.
Now take that paragraph and replace “street” with “railway”. Rail mappers have to keep multiple concepts in their head at the same time: the physical trackage on the ground, the railway line as a system, and any services in operation along the line. Some countries even distinguish between route=railway and route=tracks. This goes right over my head. Rail mappers probably get away with this degree of highly technical structure because the rest of us manage to ignore rails except at crossings.
Do either of these precedents inform whether there should be street relations and, if so, how they should be tagged?
This really interesting topic. I learned here, that I likely edited many route=road relations, not that I noticed. I consider them fine, naming fits too for me. There are some monsters in the E class (European roads), but the B and L classes (national/regional routes) look manageable. They are true routes, a single line from A to B, all numbered and named, mostly called after the area they make accessible. Quite useful perhaps for verbal instructions in a routing itinerary. (The E class is not signed here on the ground, but google street-view paints it on the carriageway some times.)
I kind of abhor relations. I remember to have created a route=foot after, what was a single way before, got split into umpteen particles to map mountain-bike difficulty. Later this got retagged route=hiking, no idea why, it is just a two to three hour walk. And it is not a good idea to go MTB there I was told too by somebody with experience: Far too many pedestrians. If I could have told with certainty, cycling was not allowed there, I’d just have reverted.
This comes straight from how hiking paths are handled by the Swiss administration. I cannot go into details, but I once read, that waymarked trails had to brew some special soup to get along with that.
I’d say, if the goal is just a collection of stuff that shares a single name or wikidata and goes (way) beyond a consecutive line, then route=* is the wrong key, IMO.
2 Likes
Just have take a look at any random place in Europe to see a massive numbers of hiking and walking route relations. For example. I question whether relations are truly necessary for all of them
there are (potentially at least, but for example in Italy very common) additional properties referring to the hiking route and not to the road, e.g. duration, difficulty, name, operator (of the route, which can be different than the road), ref, symbol etc. If you add these to the road it is not clean, and if tomorrow someone splits the road because of any reason, the repeated route data would even be wrong.
1 Like
In the ensuing discussion , @Pikse advocated for /…/
route=roadinstead ofroute=street/…/ this seems to erase the distinction between routes and the roads that carry them.
I’m not necessarily against route=street. I just note that so far almost always route=road has been used for streets too, and it’s still unclear to me if significant benefit comes from this additional tag. It may be also difficult to follow as the distinction between routes and roads or streets, as outlined above, is quite difficult to understand.
I understand that a road can be used for many different routes like bus routes or bicycle routes, or we might say that roads carry these routes. But when it comes to a route in sense of a major highway then I get it as @ezekielf put it above: route is just a certain type of road. In this sense routes seem much more similar to streets than to bus or bicycle routes.
Streets and routes (major highways) in essence are both the physical structure for land transport. In English “road” seems to be the broad term for this type of physical structure. (I do see that Wikipedia article “Road” currently in its lede section contrasts roads to streets but this is dubious, and it conflicts the the following more sufficiently sourced passages in the same article that also discuss roads that are streets.) Australian tagging guidelines for roads that were mentioned earlier also deal with both major highways and streets. This is also reflected in various official road classifications/hierarchies, e.g. in my country (Estonia) types of roads include national highways and local roads, and the latter in turn include streets. Also as someone already mentioned above, in German language even the term for streets and the broad term for roads (including major highways) are the same word.
In case a major highway passes a city, as in these Australia examples, I wouldn’t say that streets carry this highway. I’d consider it more clear to say that locally, on other level of road hierarchy, sections of this major highway simply carry other additional (street) names. This is normal also in my country.
route=roadwill cause problems for routers like OSRM and Valhalla, which add cardinal directions to turn instructions based onroute=roadspecifically
Is it certain that this isn’t rather a problem with these routers if this is what they really do? I don’t think that cardinal directions even make sense in most parts of world, apart from these a few countries named in linked wiki page.
I would rather not use any relation for the streets, but if the mappers insist on using relations (for grouping, which is what it is)
In regard to street as an individual named linear feature (not including adjacent buildings, lamp posts etc.) I don’t quite see why not have relation if it makes the data structure simpler the same way as it does for highways outside of cities. One way or another we could live without these relations but this would be also true for relations of major highways. In situations where relation for a street is truly less useful, e.g. it’d consist of one member way, or there is no data about the entire street in addition to name, it isn’t obligatory to create a relation anyway.
major reason against it is that it does make data structure more complex
1 Like
If a router here tells users to follow E533 it should say too, please look at google-street-view to learn the name of the route you are on, because E533 is not signed on the ground. I rather have drivers look at what is ahead.
Does that mean, those routes have to be trashed? After all, they have no OTG?
I’ve been intentionally contrasting the words “road” and “highway route”, because “highway” is more ambiguous. In regions that distinguish between roads and highway routes – apparently not including Estonia – both roads and highway routes may have “highway” in the name. This isn’t determinative: across the English-speaking world, plenty of non-expressways have “expressway” in the name, plenty of streets and routes have “trail” in the name, etc.
You’re citing Estonia and the German language as evidence that there’s no conceptual difference between a road and a route, but a more likely possibility is that Estonia and German-speaking countries simply don’t need to distinguish because they’ve conveniently ensured a strict one-to-one relationship between roads and routes. Some jurisdictions are able to accomplish this because the regional or national government owns roadways between and through cities and cares about consistency. Good for them!
I am also somewhat familiar with this situation: in Ohio, where I grew up, county-maintained routes are called county roads, because the county only designates whole roads, end to end. If you say “county route” to someone there, they’ll know what you mean, but it’s kind of pedantic to speak of them as routes. However, in OSM, some of these roads are part of route relations (in which each way happens to have the same name and ref) in order to communicate information about the route network in network. While these relations may be pedantic for the use case of pointing at something and identifying it, they are useful for rendering shields that match what motorists and cyclists see on the ground.
On the other hand, the very same Ohio designates “state routes” that mostly travel over segments of “state highways” (state-maintained roads) but continue onto city streets as soon as they enter the city limits. In Oregon, a state route such as Route 126 travels over multiple state-maintained roads with names like “Florence–Eugene Highway No. 62” and “Ochoco Highway No. 41”. Would you rather model Route 126 as a superroute – a made-up word that some mappers likely coined out of confusion – due to this more complex structure?
You’re right that a layperson might just prefer to think of these situations as simply a road with multiple names. But one of those names belongs to something beyond a road. Again, this distinction is relevant to routers. If you’re getting directions from home to a spot eight blocks away in the same town, you don’t need to hear about the state route. But if you’re traveling from Perth to Melbourne, maybe the route matters more than the local street name. Keys like loc_name and nat_ref sort of communicate this information, and Australian mappers used to tag network directly on the roadways, but the more complex needs in other parts of the world, including many of the countries on this map, called for a more systematic approach using route relations.
Overall, I’d just ask folks to be a bit more circumspect than assuming that a distinction doesn’t matter just because it doesn’t exist in your language or part of the world. The conflation between streets and routes evidently surprised a local mapper and doesn’t fit that well into the national tagging guidelines – surely this matters? Maybe the distinction doesn’t need to be a top-level tagging concern, and maybe the tags don’t need to be based on plain language if plain language offers no good solutions.
This is a feature, not a bug. However, the behavior should ideally be limited to the countries where cardinal directions are part of the normal way of giving directions – including New Zealand (which shares this forum category), but perhaps not Australia. OSRM requires the cardinal direction to be explicitly tagged, which is not the case so far in Australia.
If the route isn’t signposted in a useful manner and normally isn’t marked on maps, at least its relation should be tagged unsigned_ref, not ref, to keep it from misleading users. But the “E road” system is a real thing in some countries, so I’d be careful about jumping to conclusions based on just one locality.
What I tried to articulate is that there is a general concept that encompasses both major national roads (can be named route, highway, autobahn or whatever) and local streets, and in English language commonly term “road” seems to denote this general concept. I’m not saying that road and route are the same, contrarily in previous comment I quoted another US user saying that “route is just a certain type of road”.
Of course word “highway” in the name isn’t determinative. As far as I can see the same applies to word “route” in road names, while above you made an argument that some roads are true routes while others (streets) are not, seemingly based only on the fact that names of certain roads include word “route”. As I argued in my previous post, we might say that streets aren’t routes, in some sense at least, but then easily the same can be said also about other kinds of roads (including these that happen have “route” in the name).
I’m in no way saying that any local/regional distinction shouldn’t be mapped/modelled in a clear way (using network=*, highway=* or what they have come up in respective tagging scheme). To me it just isn’t clear what is this distinction that you try to make by using route=street in addition to route=road, or how it even could clear considering that you seem to propose that this distinction should be made globally.
I understand that renderers need to figure out which names, which road network, or which level of road hierarchy they use in certain situation, and yes, of course this is why systematic approach using route relations is useful. Appropriate keys added to these relations then also allow selection of appropriate relation among relations of roads that overlap on different levels of road hierarchy. But I doubt that things become any easier or clearer should we arbitrarily declare that some road names belong to “something beyond a road”. I also don’t understand why only a layperson would consider that a road segment can have multiple names.
I have no will to advocate for or against superroute relations here. However, kinds of roads that are mapped as superroutes illustrate my point that hierarchy of overlapping roads exists, and it exists even if we for some reason excluded local streets from this hierarchy.
As for the case of routers adding cardinal directions, I of course understand there can be such feature. I just doubt if this feature is properly implemented if these directions are truly added only based on route=road, especially if it’s done globally.
To be clear, in the examples I gave, this was based on the fact that the route traverses (parts of) multiple roads, not based on the name. The route’s name could’ve contained “highway” and the effect would have been the same.
Another way of looking at it is that a route is created by designation, not by construction. For example, in October, dozens of new national highway and cycling routes were approved in the U.S. without building or renaming anything. Each route is defined as a list of sections of roads. New destination signs and reassurance markers will eventually be posted, but not necessarily new road name signs. The component roads and trails will retain their identities for the most part.
The process is different in every country, but the point is that there should be some way to differentiate designated routes from their component roadways. Creating relations for physical streets is the much later, much rarer practice, so it should not co-opt the tagging for designated routes.
What I meant here was that in everyday speech the words route and road have a huge overlap and can be used nearly interchangeably depending on the context. This doesn’t mean there is no distinction worth making between numbered highway routes and named roads/streets. They are both roads in a very broad sense, but they are distinct in the public consciousness due to differing signage and map display styling.
Either statement accurately describes the situation. Ultimately the data structure just needs to be able to indicate the full extent of the local street, the full extent of the major highway, the fact that they share a certain segment of roadway, and that one is a local street and the other is a major highway.
1 Like
To add some more color to this: as you’d expect, state and local governments are normally responsible for building and naming roads in the U.S. However, Interstates and other national routes generally aren’t designated by a legislature or even by a government agency. Rather, the entity responsible for these routes is AASHTO, an NGO that technically has the same legal status as OSMUS, but with state highway departments as voting members. They only designate but do not have the funding to build. (Australia had a similar arrangement prior to the establishment of Austroads.)
This arrangement is an artifact of history. Until the 1950s, signposted routes in some parts of the U.S. and Mexico were the responsibility of private auto clubs. At least in California, these “sign routes” intentionally contradicted the legislatively defined routes in order to better guide motorists. A very similar situation exists today in some places with respect to long-distance cycling and hiking routes, which are designated by NGOs, often signposted by volunteers, and travel over trails that are maintained by a variety of unaffiliated entities. (This should sound familiar to Germans.)
Even if route=road didn’t turn out to be a perfectly unambiguous tag name in retrospect, we should avoid skunking it for the sake of the mappers and software developers who have put inordinate effort into developing and supporting this tag. It’s easy to say that only some countries care about the difference between roads and routes, but if route=road becomes the normal tagging for street relations in some countries, it will also become the normal tagging for street relations in other countries, where it would dilute the meaning of more important relations.
1 Like
To be clear, I never said that “only some countries care about the difference between roads and routes”. Obviously all countries mentioned above have their types of roads, and likely they all also classify local roads within cities (streets) differently from roads between or passing cities (including roads that are classified/named as routes). This is why network=*, highway=*, designation=* or other relevant tags are used to make any such distinction clear where needed.
So, above route=road is said to apply if respective road overlaps (or “traverses”) shorter roads that have different names. But then what about national roads or regional roads or let alone other types of local roads outside of cities that don’t overlap any shorter roads with different names? Are these also to be banned from using route=road then?
I still don’t think it is apt to compare routes like Oregon Route 126 with cycling routes, or bus routes or other similar routes. Word “route” has among its other senses the following two distinct senses, I quote from this dictionary entry: 1) “a course or way which is traveled or passed”, and 2) “a road or path; often specifically a highway”. Above you seem to make a case that routes like Route 126 are routes in sense 1 instead of sense 2, but at least for me, sorry, this isn’t convincing. (To be clear, I don’t have a problem with type=route being used for routes in both senses as this is just an arbitrary key value, and distinction is still made using route=* key.)
As for designation vs. construction, really both routes/highways outside of cities and local roads within cities are both built and and both can be designated. Road network can be rearranged both outside of cities and within cities, e.g. streets are also occasionally merged to form a new named street without any construction work, or entire streets too can be designated as main roads or secondary roads or alike, etc. Sure, there are also different designation authorities (national government, local government, NGO, or other), and different authorities that manage/build roads, but I don’t see what this has got to do with route/street distinction, as both roads outside of cities and within cities are normally designated/built/managed by some authority.
As for routers and software development, I haven’t tested these particular routers myself, I rely on descriptions provided above. And if it’s said that cardinal directions are added across the world based only on route=road, including in majority of countries where cardinal directions make little sense, then to me it seems quite clear that this feature needs further development. Above it was mentioned that some routers add only cardinal directions that are explicitly tagged, so these a few others could do the same. I also once more point out that overlapping road relations exist also without these that are for streets, and then somehow it still needs to be specified which level of road hierarchy or which road network is relevant for directions.
To me it doesn’t seem like route=road has to be redefined (or skunked) so that it could be used for streets. As I pointed out already in afore-mentioned changeset discussion, per wiki documentation it doesn’t seem like the use of this tag was ever limited in manner which is suggested here in this thread. Accordingly other people have also put inordinate effort to map and model road networks in their countries in national, regional and local levels using uniform data structure, and now here it’s told that due to some rather obscure reason large parts of this work should be redone. This would also mean that due to less uniform approach it’d be harder to use the road data. Also, as said earlier, it isn’t even clear which roads really should be redone (just streets, or also other local roads, or also certain national roads).
I also understand that originally route=road was used mainly for major routes, but as far as I can see it’s normal that people for a start map larger/major objects and then over time the data gets more detailed.
As I’ve mentioned, some routes happen to conveniently follow only one road. This does not necessarily mean the route is the road.
I’m not saying the designated routes are arbitrary itineraries. Wiktionary’s definition isn’t as precise as it could be. After all, in English, one cannot point to just any road or path and call it a route. (Really, it would just be weird.) An example of a more precise dictionary definition comes from The Century Dictionary, which distinguishes between:
- A way; road; path; space for passage.
- A way or course of transit; a line of travel, passage, or progression; the course passed or to be passed over in reaching a destination, or (by extension) an object or a purpose; as a legal or engineering term, the horizontal direction along and near the surface of the earth of a way or course, as a road, a railway, or a canal, occupied or to be occupied for travel.
Indeed it is a somewhat technical definition rather than a colloquial one. But even in colloquial English, one may call a route a road but would not typically call a road a route.
Specifically, OSRM only appends the cardinal direction if the route is mapped as either a bidirectional route with cardinal directions as roles or as a pair of one-way routes with direction, not unlike what the PTv2 specification uses for public transportation routes. I agree that Valhalla’s tendency to infer cardinal directions is problematic, but for a different reason: that the cardinal direction isn’t necessarily the route’s predominant direction geometrically.
I think there’s a misunderstanding. The route=road relations for streets in Fremantle were the work of one mapper. Another mapper had been using type=street for some other streets in the same city and converted them all to be type=street for consistency; that’s the changeset you commented on. It’s difficult to know how many route=road are actually used for roads that are not routes and how many of the nearly 29,000 type=street relations are used for streets rather than abstract geocoding workarounds.
Rest assured, the road=route relations in Estonia are probably fine. All but a handful of them have network, which probably means no one is using it to represent the streets that are normally represented as highway ways rather than relations. (Otherwise, a very small minority of these relations would have network.) If in Estonia you consider those relations to represent roads of a certain road type, that’s fine; that’s a close analogue to what English-speaking countries call “routes”, just more orderly.
1 Like
As I’ve mentioned, some routes happen to conveniently follow only one road. This does not necessarily mean the route is the road.
This brings us back to the question of how does one know which roads can use route=road. Also why does one of the overlapping roads have to be the road at all?
I’m not saying the designated routes are arbitrary itineraries.
Maybe not itineraries but you still seem to insist that routes like Oregon Route 126 somehow “follow” roads, similar to how cycling routes or bus routes follow roads, and this pretty much implies you consider certain type of road to be a way traveled or course of transit (sense 1) instead of it being a road (sense 2). To me any such premise makes little sense.
These glosses from The Century Dictionary in essence seem to be for the same senses that I referenced from Wiktionary (apart from legal/engineering subsense). In both sources route in first sense is described as a road not the other way round, i.e. as far as I can see there’s no need to read it backwards as if roads were described as routes. Similarly, if it’s said that dogs are animals then it doesn’t mean that (all) animals are dogs. And also, where I said that routes, such as Route 126, and streets are both roads I don’t mean that streets are routes (a notion that you for some reason persistently try to attribute to me), similar to if it’s said that dogs and cats are animals it doesn’t mean that dogs are cats.
You suggest that streets should use different route=* key value but if the most confusing part for you is the key name “route” itself then how does this really clear up anything? To me it seems this would only make things more confusing considering that key value “road” would be still used but only for a subset of roads. It also confuses me that at the same time you admit that tag names may not be perfectly unambiguous, and above you also described yourself how route=* is used for different kinds of routes anyway (railways etc.) and you don’t seem to consider it a big problem.
I made this comment both in changeset discussion and here in response to your general remark on how route=road should be used differently from what has been documented for many years.
road=routerelations in Estonia are probably fine. All but a handful of them havenetwork, which probably means no one is using it to represent the streets
Local roads (so far mostly streets) in Estonia actually use network=ee:local. And it’s not only about Estonia anyway. As already evidenced above route=road has been used in similar manner for streets in other countries as well, with our without network=*.
It’s difficult to know /…/ how many of the nearly 29,000 type=street relations are used for streets rather than abstract geocoding workarounds.
I suppose it wouldn’t be too difficult to query this. But regardless whether majority of type=street relations include buildings and other objects in addition highway ways, or not, and as said previously, I don’t think it’s reasonable to consider using type=street for our purpose as long as currently it has different purpose documented. If we agreed to use it differently from what some other folks have agreed upon then this would result in a truly skunked tag.
I’m sorry it doesn’t make sense to you. If you’re interested in learning more, I recommend reading up on the old auto trails in North America to understand how the concept of a marked route developed. This concept subsequently spread to other regions, including Australia. Even in the United Kingdom, which only numbers roads and motorways, there is a formal concept of a “primary route” that laypeople experience as green-and-gold signs bearing the component roads’ numbers.
I think you’re reading too much into the wording of a dictionary definition as if it’s an OSM tag definition. Dictionaries generally do not provide the full context as other reference works, such as the ones I’ve cited.
I wonder what you think a bicycle route is, since bicycle routes routinely travel over multiple facilities, including on- and off-road segments. Is it so unimaginable that the same concept could normally apply to vehicular travel as well, if not in your country then in others?
Even though I haven’t convinced you that routes and roads are orthogonal concepts, you have acknowledged my main point: roads and routes are not synonymous. Therefore, we should err on the side of precedent and backwards compatibility by sticking to the longstanding usage of route=road for highway routes (or “on-road routes” if that’s clearer) and finding some other tagging for relations representing a street per se. It doesn’t have to be type=street.
Some 70% of these local roads have ref. Does this mean there’s some kind of systematic designation and marking of local roads? If so, it may be similar to the county road “routes” I described earlier, in which the main reason for conflating roads with routes is to enable renderers to distinguish different road networks’ distinctive shields. It’s a pragmatic approach but technically inaccurate. There’s an ongoing debate about whether to apply this approach to forest roads in the U.S.:
Even at the city level, it can be conceptually useful to distinguish between streets and marked routes. Maybe someday we’ll get around to creating relations for the streets of Fremont, Ohio, but they should not be tagged identically to the city routes that guide motorists along those streets. With the thousand or so different values of network now being used across the U.S. to represent marked highway routes, I wouldn’t want data consumers to have to know the difference between network=US:OH:SAN:Fremont and network=US:OH:SAN:Fremont:but_not_actually_a_route.