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.
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.
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.
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.
Question from Europe to the Americans and Australians. When I’m cycling I sometimes encounter a situation where I’m on, say, Anne Street which is part of national cycle routes 7 and 32 at that point, and then I get to a junction and if I want to continue on Anne Street I have to head straight on, but if want to stay on cycle route 7 I have to turn left, and for cycle route 32 I have to turn right.
Does this sort of situation happen with road routes in the US or Australia?
Yes, this situation certainly happens here. I’m in California and map a lot of USBRs (our national cycleway routes). See OpenStreetMap for example. This is in the state of Indiana, at the junction of USBR 35 (a N-S route) and USBR 50 (an E-W route). If you are on 35 cycling north, you must choose (at the roundabout, which are frequent in Indiana) whether to go west (to continue to go north on 35 AND west on 50) or east (to go east on 50, leaving USBR 35).
Road routes do this too, I’m not as easily finding an example, but they do exist in the USA, I am certain of it. Must the originating “road” be double-routed (as in your example)?
Yes, routes that depart from roads are very common among highway routes in the U.S., moreso in some route networks than others. Route concurrencies are also very common.
Highway routes work similarly in Australia, including at this intersection in Fremantle:
This intersection in Cincinnati is an extreme example of both phenomena. Central Avenue carries eight routes belonging to four different networks, so many that it breaks OpenMapTiles. Most of these routes follow the street as it continues north past the intersection, but U.S. Route 50 Truck and the Ohio River Scenic Byway turn left to follow an expressway westbound. That expressway also carries a State Route 264 that begins at the intersection and never follows Central Avenue. It’s also worth noting that a one-way couplet begins at this intersection: even though Central Avenue remains a two-way street, it carries the remaining six routes northbound only while a parallel Plum Street carries the same routes southbound only.
Awesome example in Cincinnati, Minh. (Look at its ref=* tag, carrying seven routes!) Only several blocks north of that Central Avenue (location, which looks like a certain “center of the universe”!) is Central Expressway, recently updated both in the real world (AASHTO’s Autumn Round) to be part of USBR 25 through Ohio, which “cinched” (or clinched?) routing of a bicycle sort (at a national level), simplifying (in its own small way) bicycle routing through this incredible maze and in/on OSM. Good routing (by people, usually some sort of elected representatives in the transportation arena) + good routing (by OSM mappers) = success. Well, in this context, anyway. (Mapping chases routing chases mapping, and eventually things settle down as many heads nod).
Happy mapping. Tag well. I might even say (here, now) “especially routes.” A salute to all who carefully map routes, it’s pretty awesome what we build and how we build (and even render) them.
This piqued my interest, so I spent a few minutes briefly trying to understand the situation better. Please correct me if I’ve gotten anything wrong.
Indeed, it appears that Estonian mappers have comprehensively added thousands of city streets to route=road network=ee:local relations based on their names and official classification as kohalikud teed. The relations correspond one-to-one with streets: plenty of the relations have more than one member, but only because a street has been split due to variation in lane count, turn lanes, and so on. Virtually all of these relations’ members have uniform names; a mere 21 relations or 1.3% have discrepancies among the members, mostly typos and differences in abbreviation.
The names of 30% of these relations match the names of their members, except that the suffix tänav (“street”) only appears on the relations but not the ways. The rest only mismatch because mappers are abbreviating street names on the ways but not on the relations (Puiestee versus pst for “avenue”, maantee versus mnt for “highway”, etc.). This seems like an optimization to increase label density in renderers, presumably simulating how print maps traditionally shortened street name labels. No wonder mappers feel the need for an additional element to hang the full name off of.
Of the ee:local relations, 70% also have a seven-digit-long ref tag. As far as I can tell, this is an internal inventory number rather than anything useful for wayfinding or turn-by-turn navigation. (Then again, spot-checking around Tallinn, street name signs don’t appear to be posted as prominently as in places I’m familiar with, so maybe locals don’t expect such things to be as easily verifiable on the ground.)
In fairness, Estonia is not the only country that has a *:local network. In fact, network=ua:local is more than six times as common. This tag represents Ukraine’s raion network, the lowest classification of “roads of local importance”. But unlike in Estonia, about a quarter of these relations have some variation in naming among their members, suggesting that a raion road is typically overlaid on the street network. Moreover, there does not appear to be a significant practice of putting hromada streets into route relations.
The situation is similar in Latvia and Poland, the other two countries with a significant number of *:local relations. It has been claimed that other countries typically put streets in route relations without tagging them as such, but I do not know of a straightforward way to definitively prove or disprove that claim. What I can say is that network appears on 95% of route=road relations in Ukraine, 80% in Australia, 77% in Poland, 75% in France, 45% in Italy, 43% in Germany, and so on, and none of these countries have networks that obviously correspond to city streets. If it’s really the case that city streets are commonly modeled as network-less route relations, then one would expect these percentages to be drastically lower, as a typical city has a lot of distinct streets and these countries have a lot of cities.
So, have the Estonians successfully and permanently skunked the route=road tag? Not quite. Should the community ever decide to revisit this tagging practice, the consistent use of network=ee:local makes it easy to find all the occurrences and retag them. In the meantime, a data consumer could classify the route=road network=ee:local combination as a troll tag, ignoring it for the things it normally does with a route relation. (By coincidence, OSM Americana is rejecting all these relations’ refs as possible tagging errors because they’re longer than six characters.)
If the kohalikud teed aren’t really causing any immediate problems, why shouldn’t the Australians or other communities copy the approach in Estonia? Maybe Estonia is getting lucky because it only has road types but not marked routes per se. But this is not the case in Australia or the U.S., as I’ve hopefully demonstrated to everyone’s satisfaction. Not every city in these countries has a marked route system, but a number of them do. If it’s such a good idea to create relations for streets, it should be just as good an idea in Fremantle or Fremont as it is in Talinn.
If we do create relations for the streets in these three cities, ideally they would be of the same type so that editors and data consumers don’t have to handle them drastically differently. That distinction should not be relegated to network, a key that already conveys so much information in such a complex hierarchy.
You are talking about routes as understood in some specific region or in some specific countries. I think we have already established that various types of roads exist, there are differences. But if we discuss how route=road tag is used globally then this matter in my opinion is rather about what is common to these various types of roads. This is what I tried to outline above.
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 don’t think that I said anything about what an OSM tag definition is or should be based on dictionary definitions really. For route=road I instead explicitly referred to OSM wiki documentation which so far hasn’t limited this tag to certain types of roads, contrary to what is suggested here in this thread. For some reason you overlook this.
I referred to senses of word “route”, as provided in a dictionary, specifically in response to your general colloquial English based explanations, so that we could establish what are we talking about in the first place if we talk about routes. I don’t think it is possible to discuss this in a clear way as long as you insist on using two afore-mentioned and distinct senses of “route” interchangeably.
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?
I don’t quite understand why you ask. I understand a bicycle route as a course which is traveled or passed using a bicycle. Previously I already brought it as an example of a route in respective sense. Do you dispute this?
Very likely there are similar (named) routes for vehicular travel also. But as for roads and route=road relations, this again comes to the distinction between two senses of a word “route”. It is still unclear to me why you insist on discussing the physical infrastructure (road) as if it was a course traveled, and why you treat a different type of road (street) differently in this regard. After all, people normally don’t limit their travel route to certain named road or its section. Their vehicular travel routes normally pass multiple named roads (including highways, motorways, streets or other types of roads), regardless whether they travel within a city or across the country. I’m also fairly certain that this is the case also in US.
these local roads have
ref. Does this mean there’s some kind of systematic designation and marking of local roads? /…/ As far as I can tell, this is an internal inventory number rather than anything useful for wayfinding or turn-by-turn navigation.
In Estonia there’s a coherent numbering scheme that includes numbers for both national roads and local roads. Just ranges of shorter numbers are used for national roads. It is probably true that these road numbers are not well-known compared to US situation. On some larger intersections, mostly within cities, numbers for some national roads can be found on traffic signs, being appended to a general direction like “(to) Tallinn”. Most Estonian road numbers, including these of national roads, indeed don’t appear anywhere on the ground, nor are they normally used for navigation, but what should we make out form it really? ref key after all isn’t used only for navigation purposes or for numbers that are marked on ground.
Also, most likely designated roads that are not streets and are not used primarily for navigation exist in other countries too. You are not suggesting that relations for any such roads should be removed, are you?
Virtually all of these relations’ members have uniform names; a mere 21 relations or 1.3% have discrepancies among the members
I don’t see why this matters really. It is expected that in hierarchy of roads there are also the lowest level roads that don’t overlap any shorter named roads. I don’t think this means that relations for these shorter roads couldn’t be useful. As already pointed out above, coherent data structure for types of roads would still make it easier to use the data. Also as you pointed out above yourself, without relations it was difficult to manage the data of all overlapping roads, and as far as I can see this is equally true in relation to these roads that happen to be streets (as you can see, their data can also include network, ref and other identifiers).
networkappears on 95% of route=road relations in Ukraine, 80% in Australia, 77% in Poland, 75% in France, 45% in Italy, 43% in Germany, and so on, and none of these countries have networks that obviously correspond to city streets. If it’s really the case that city streets are commonly modeled as network-less route relations, then one would expect these percentages to be drastically lower
Even if streets aren’t mapped as relations systematically, and I repeat I don’t suggest they should be, still a lot of route=road relations can exist for streets in other countries as well. After all, you initially found them in Australia, and likely there are more in countries where these percentages are lower.
Regardless for some reason you now try to present this all as some Estonia-specific problem. I don’t think this is fair. I see now you even added a note on so-called “atypical usage” in Estonia to wiki documentation (diff) while most likely majority of route=road streets are outside of Estonia. This documentation previously just said that most streets and minor roads don’t belong to a relation if in particular they are identified only by a name tag. It didn’t say that streets can’t have relations where useful, not that streets relations are somewhat discouraged. Also Estonian route=road relations for streets actually and typically are not identified only by a name.
If it’s such a good idea to create relations for streets, it should be just as good an idea in Fremantle or Fremont as it is in Talinn.
There already is a long list regional tagging schemes and regional differences on if or how certain tags are used. As far as I can see, if Australian users at the end find that they don’t need relations for streets, because their road networks are different or for whatever reason, then they don’t have to copy some other country’s approach.
In the meantime, a data consumer could classify the
route=roadnetwork=ee:localcombination as a troll tag, ignoring it for the things it normally does with a route relation.
I still don’t think that we have really established that problem here is with some tag or tag combination, as opposed to what some consumer might “normally” do with these tags (consumer may not interpret tag correctly in the first place). Above it was mentioned that some consumer adds route=road based cardinal directions, but even without street relations, if applied globally this refers to fairly obvious problem in majority of countries where cardinal directions simply aren’t applicable.
Additionally you mention issues with route number rendering, and issues with providing directions to correct route in places where several routes (roads) overlap (you mention an example where there are 8 overlapping roads in addition to local street). But if so many routes overlap anyway, and even without the street relation some technique needs to found so that correct route(s) is/are selected, then it doesn’t seem like one additional road relation (that of a street) would be the problem really.
The route=road documentation doesn’t strictly discount streets, but it does recommend against it:
Most urban streets and minor roads which are identified only by a name=* tag do not belong to a relation.
One of the possible outcomes of this discussion might be to clarify when a route=road relation is appropriate versus whatever we decide on for streets.
Maybe an example would help. My city has a small network of marked cycling routes, of which Bike Route 11 is the first and longest. It traverses a number of streets known by names and numbers such as Oakland, 7th, 17th, and Monterey. Bike Route 11 is a route in the sense of being designated as a route, marked by wayfinding signs and reassurance markers, and suggested on a map as an intentionally maintained corridor for traveling north and south through the city. It is not strictly the kind of route that a routing engine would output, also known as an itinerary, which might follow busier or quieter streets between the same endpoints, depending on the user’s preferences.
The reassurance markers for Bike Route 11 have a distinctive design that conveys not only the route number but also the route network, which in this case is tagged cycle_network=US:CA:SJ:
Here’s that same green and white sign with an arrow letting you know that the route departs from San Salvador Street to follow 7th Street. Streets have signs too, but it’s a different kind of sign and for a different purpose. In English-speaking cities, numbered streets are referred to by ordinal numbers like 7th instead of cardinal numbers like 7, which helps to prevent confusion with numbered routes.
Every aspect of a cycling route mimics a highway route, because most people are already familiar with the latter. Here’s an intersection in the same city where State Route 130 departs from Alum Rock Avenue to follow Mount Hamilton Road up the mountain to an astronomical observatory. This winding, picturesque route is followed by both motorists and cyclists alike. A sign just up ahead indicates that another route, the Juan Bautista de Anza National Historic Trail, makes the same right turn.
What I’ve shown you so far is the norm for routes of both kinds, not the exception. The only unusual thing is that the last sign comes with flashers because motorists often miss the right turn when trying to follow SR 130. An ordinary motorist intentionally follows a route because they can count on strategically placed signs to lead them to a destination – in this case, the observatory. Some routing engines are now capable of responding to this user need by trying to stay on the route (or trying to get off of it) while satisfying other constraints like time or distance. Though no less wordy, the instructions align with the user’s high-level understanding of where they’re going, simplifying the navigation experience.
“Road” or “street” refers to the physical infrastructure, or more broadly the environment around it. “Route” is an abstract concept that can sometimes be conflated with the physical infrastructure for convenience. You are accustomed to that convenience and I wouldn’t blame you for it. But I assert once again that the situation in Western Australia is much closer to the situation in California than to the situation in Estonia, if for no other reason than that Australia’s road signs and route designations were largely modeled after those of the U.S. rather than those of Europe.
These are very good points. As far as I know, neither Australia nor the U.S. even has a comprehensive nationwide inventory of all local streets, let alone a numbering scheme for them. But in these countries, highway route numbers and route relations are an essential element of transportation maps and turn-by-turn directions. Every router, every navigation application, and most maps based on OSM satisfy this need by presenting the route number to the user in some fashion.
Like most other keys, ref is generally intended for information that is verifiable on the ground. However, some route numbers aren’t signposted in a manner that the general public can use to find their way, so we tag them with unsigned_ref to avoid confusion. If this is always the case with every route in a certain country, maybe you could justify using ref on the basis that the lack of signage is a “national default”. 
Or you could avoid making relations out of them. In the U.S., the Pennsylvania Department of Transportation systematically assigns road inventory numbers that only appear on very small signage, so we tag them on the individual ways as ref:penndot and don’t bother with relations. Some Wikipedians don’t like this very much, but that’s what the Overpass–GeoJSON–Commons approach is for.
Others in this thread have expressed an opinion that no relation should be used to represent a street. So far, I’ve avoided taking a hard stance on that, only because I think a ban on such relations would inevitably lead to Wikipedians tagging them as the next available thing, routes, to appease Wikimedia Maps without going through the trouble of exporting GeoJSON to Wikimedia Commons. Now I wonder if I should just side with them to avoid the trouble of explaining the concept of a route in increasing detail.
Yes, I have presented evidence that I believe shows Estonia to be an outlier. The 28 relations in Fremantle do not weaken this argument in the slightest. But I would be happy to generate some hard numbers to back your assertion that this is a significant global phenomenon, if you can tell me what to look for.
As the song goes, one of these things is not like the others. The bug was that eight roads routes overlapped on a single road, but I and other developers had incorrectly assumed that six was the most that would ever occur in the wild. The fix is to increase the maximum number of concurrencies to look for. This has nothing to do with whether Central Avenue is also represented by a relation. I pointed it out only to answer @osmuser63783 with a bit of good humor.
Recommends against? As far as I can see this sentence only summarizes current situation. Also, as already pointed out, it specifically speaks of roads that are identified only by name=* tag for which a relation might be less useful indeed. As shown, there are also streets that use ref=*, network=* and other identifiers just like larger roads outside of cities.
Maybe an example would help. My city has a small network of marked cycling routes, of which…
This is what I would also expect a cycling route to be. It is also expected that signage for such route can be similar to that of a road. Other than that, I think we are sort of digressing here with this exhaustive description of a cycling route. Cycling route as some suggested course of travel is still a route in different sense than a road within network or roads of some level (national, local or other), while roads of different road networks (including streets), if treated as routes, are routes in the same sense.
“Route” is an abstract concept that can sometimes be conflated with the physical infrastructure for convenience. You are accustomed to that convenience
Well, another way to look at this to accept that “route” has an abstract sense and a non-abstract sense, as evidenced by multiple dictionary references above. Then we don’t have to conflate anything.
Every router, every navigation application, and most maps based on OSM satisfy this need by presenting the route number to the user in some fashion.
So you suggest that it is problematic to present a ref number that isn’t well-known or that doesn’t appear on signs? I think this necessarily isn’t a problem, as long more useful road name is also present, and given ref number is the correct road number. Ideally of course the router could know about regional preferences.
Like most other keys,
refis generally intended for information that is verifiable on the ground. However, some route numbers aren’t signposted in a manner that the general public can use to find their way, so we tag them withunsigned_refto avoid confusion.
As far as I know, ref is also used for many kinds of identifiers that aren’t verifiable on the ground. If multiple identifiers exist, then sure, different OSM keys can be found for each.
I see you refer to “don’t map local legislation if not bound to specific objects” section in wiki guidelines but this doesn’t seem to be relevant here, as refs in question are bound to specific objects on the ground.
but that’s what the Overpass–GeoJSON–Commons approach is for
I don’t quite get why is this even considered here. If tooling support that ties map data in Wikipedia articles to a proper geodatabase already exists then this would be clearly a step backwards. As long as this geodatabase is limited to what is available in OSM then it’s also nice to additionally support individual GeoJSON files in Commons, but present-day road data is very much available in OSM.
I do realize it isn’t absolutely necessary to use route=road for streets in order to pull given road data to given geodatabase but that’s another matter. As explained above, I don’t see Wikipedia’s need as the main reason why one would use route=road for streets.
It feels to me that some more comprehensive overview of the subject matter is needed in the first place if we want to decide over some global tagging convention like this one here. If relations in question in the first place are presented as some sort of Wikipedia mess then well… the outcome of the discussion pretty much determined.
Yes, I have presented evidence that I believe shows Estonia to be an outlier. The 28 relations in Fremantle do not weaken this argument in the slightest. But I would be happy to generate some hard numbers to back your assertion that this is a significant global phenomenon, if you can tell me what to look for.
Per above comments to me it looks that Estonia is outlier only in one aspect: street relations use respective network value and this makes it easy to query the data. You pointed out you didn’t find similar local networks in other countries, but you presented an evidence that in some countries there are a lot of network-less road relations, e.g. in Germany only 43% of these relations have network tag. So you might want to look into these network-less relations to see what they are for.
To be precise, I didn’t speak of “significant global phenomenon”, I only indicated that if we already know of some examples of it in other countries too then in total there may easily be at least a few thousands of such examples (more than in Estonia). Even if this global phenomenon isn’t significant (yet) per whatever criteria then I would still like to believe that phenomenons other than global significant ones also have the right to exist in OSM, and this in itself isn’t a reason why certain tagging convention should be avoided.
The bug was that eight
roadsroutes overlapped on a single road /…/ This has nothing to do with whether Central Avenue is also represented by a relation.
I actually didn’t refer to this bug in particular, I only referred to a case that you mentioned where as many as 8 roads (or routes, if you like) overlap. I could have referred to any case where non-street roads overlap. I referred to such example in order to show that consumers have to deal with overlapping road relations anyway, no matter if streets exist or not. And therefore it’s unclear why such consumers can’t handle one additional road relation for a street (or really, what problem are we trying to solve here in the first place).
I say “road” not “route” due to the ambiguity of the latter word in this context (see dictionary references and related discussion above). At first I attempted to express clearly by saying “roads (routes, motorway, streets etc.)” or “routes like Oregon Route 126”, but now I gave up and ended up speaking of about just roads. As English Wikipedia even has general Types of road article then I would like to think that I also express myself clearly enough if I speak just about roads, as well as kinds of routes and streets as types of roads.
but I and other developers had incorrectly assumed…
Unrelated to that bug, I’m starting to feel that this thread here also has much to do with some inexplicit developer assumptions. It seems you have some assumption about a general purpose tag like route=road based on how it’s used in combination with some other tag(s) in certain region for which you develop a tool. If it then later turns out that this assumption necessarily doesn’t hold in other region(s), possibly simply because road classifications are different, then possibly you could further refine your tool or possibly you could propose a new tag for some specific purpose. But instead your first instinct seems to be to declare that other region(s) use(s) the general purpose tag in a wrong way. I’m sorry if this assessment is off the mark, but the problem statement in this thread really is vague… and so one wonders.
In the interest of time, I’m only going to respond to some of your points in full detail. Unfortunately, I don’t think I’m going to convince you about the road–route distinction, but this topic is really for everyone else too.
It’s one thing if the correct road number is verifiable on the ground, or if people refer to the road by the number anyways, just as they apparently know the names despite the lack of signage. But I don’t think ref should be a dumping ground for internal inventory numbers that one can only discover by consulting the operator’s database and that one cannot practically use in day-to-day activities. There are plenty of numbering systems that we choose not to map. I don’t think this is a controversial stance in OSM.
Every region has its own quirks, but as a project, we do generally try to avoid leaving gotchas for data consumers. If nothing else, it saves the community the trouble of having to get all the data consumers on the same page about some obscure exception, like these local route numbers in Organic Maps and OsmAnd that probably shouldn’t be rendered:
Nevertheless, if the local community in Estonia thinks this kind of mapping is useful, that’s an argument against coopting ref on route relations, which have always been primarily about rendering route shields on maps, mentioning route numbers in navigation instructions, and other practical uses.
Of the 15,255 route=road relations in Germany, only 6,562 are tagged with network. Of the remaining 8,693 relations, 6,978 (or 80%) are Landesstraßen, which is a signposted road classification. As far as I can tell, none of them has mismatching member way names. This suggests that the relations represent roads rather than routes, or to put it another way, routes that as a rule consist of only one road. Overall, route=road relations account for just 11% of the 2.1 million kilometers of navigable roads in Germany (including concurrencies).
Given the occasional angst that German mappers express in global forums regarding relations for long-distance routes, or regarding bus routes, I suspect there’s very little appetite for systematic street relation mapping there.
This discussion stemmed from the retagging of 28 relations in Fremantle, which were created for the purpose of consolidating wikidata tags so that they would automatically appear in the now-broken infoboxes of the English Wikipedia’s articles about Fremantle’s streets. Both of us were being kind of nosy by jumping into the fray, but @Sam_Wilson’s toot caught my attention and the rest is history.
It was never my intention to make this a global policy decision about whether streets elsewhere should be systematically modeled as relations; otherwise I would’ve started this topic in a global category. However, it seemed reasonable to consider the precedent that this decision might set in other places that have similar road and route networks. The subsequent back-and-forth about roads versus routes has highlighted a stark difference in perspectives across continents, but I hope I’ve demonstrated to everyone else that, here at least, “route” is not just a stylistic word for “road”.
I am a mapper first and foremost. I only referred to OSM Americana as an example of a data consumer that uses route relations. This project sprang from the U.S. mapping community and is inseparable from it. We didn’t invent route=road relations – the honors belong to the German community – nor was Americana the first renderer to make use of them. Far from dictating how the Australian community should map, we have been supporting their decisions, turning their recently overhauled road tagging guidelines into a map that they can use to track their retagging progress and share the results with friends and family.
I sort of agree there isn’t much point to continue this as we go in circles. Just for reference, and as I’ve explicitly said more than once already, there is a distinction between roads and routes. There is no need to convince me on that. Above I referenced various materials to show what the distinction appears to be, and how this distinction relates to streets. Routes and roads can be considered distinct from one another in both afore-mentioned senses of word “route”, and in one of these senses road and route indeed are orthogonal concepts.
like these local route numbers in Organic Maps and OsmAnd that probably shouldn’t be rendered
I’m not convinced either that it’s useful to display these longer ref numbers, but this also illustrates an opinion that I voiced above: if a consumer uses the data in bad way then this necessarily don’t indicate that there’s problem with the data itself. As far as I can tell, it isn’t common that renderers display all road ref numbers based on relation data.
I’m aware that OSM doesn’t include all geographic data there is, but it nonetheless also includes a lot of data that for the most part cannot be verified on the ground (perhaps most notably administrative borders). Such not-on-the-ground identifiers often use some dedicated ref tag like ref:INSEE, but circumstances around whether general ref tag or some other dedicated ref tag is used doesn’t seem to be mainly about “on the ground” aspect.
In case of these particular longer roads numbers, the reason why ref might be considered suitable is that, as already said, these numbers are part of a coherent numbering system, and at least some road numbers in this numbering system also do appear on traffic signs.
Identifiers “that one cannot practically use in day-to-day activities” can be for instance still very useful if one needs to check the data against some source dataset (in order to find errors, oudated data, changes in road network etc.)
Both of us were being kind of nosy by jumping into the fray
They reason why I commented on this particular changeset in the first place is that it was referenced in a Wikimedia bug. I thought I might be able to clarify the background circumstances a little, but oh well, as you say, the rest is history.
