That was an idea I floated at one point, but it just adds to the confusion since the plain-English term “highway route” definitely doesn’t include that pedestrian mall!
I’m pretty sure Wikimedia Maps was working before when the relations were tagged type=routeroute=street. In other words, it doesn’t care what route=* value we use. On the other hand, route=road will cause problems for routers like OSRM and Valhalla, which add cardinal directions to turn instructions based on route=road specifically. (This test case verifies that the feature works in OSRM globally, not just for the particular hypothetical case written there.)
In other words, it doesn’t care what route=* value we use.
Yep, that’s right, it just looks for any route. The docs say that “only relations with type=multipolygon, type=route, type=boundary, type=waterway will display on maps.”
On the other hand, route=road will cause problems for routers like OSRM and Valhalla, which add cardinal directions to turn instructions based on route=road specifically.
It’s not a =route to me, as it’s not strictly something to follow for traveling on, only for looking up addresses along. Even route=power (replaced by type=power + power=circuit ) forms a valid routing. Wikimaps should try to fix itself.
But this makes a critical question as to how they should be organized. Currently type=street mix all the highway= street sections and addresses or buildings, as extreme as someone suggesting the possibility of relating all street furnitures on it before. This mirrors other =route where related features (eg =stop , =platform ) are included directly. However, considering the possible length of streets, and the amount of addresses or buildings, it could be worth considering to separate them by nesting (eg as generic as in a =multilinestring ) highway= roads inside to relate them indirectly. This keeps the size down, and the data structure tidy. Then route=street might be used for this purpose.
You’re correct from a practical perspective, but I think the reason these relations were created was to power the infobox maps on Wikipedia articles like “Stock Road”, which describe the road in the same manner as an article might describe a route. A layperson would have no particular attachment to a street or route from end to end, but roadgeeks are different. It’s a whole subculture that prizes “clinching” routes by driving from end to end and puts a lot of effort into compiling histories and technical information. These Wikipedia articles (some of which have migrated to the AARoads Wiki) originate from this subculture but are written for a broader audience.
I see no fundamental conflict between this use case and OSM. It very much reminds me of the route=railway relations curated by railfans. That tag has created endless confusion with route=train etc. I guess that would be one argument in favor of a separate relation type rather than trying to educate mappers about the difference between route=road (an on-road route) and route=street (a routable street).
Honestly, if I had my druthers, we’d whittle down street relations to contain only the carriageways and not the other roles envisioned as an alternative to addr:street and post:street. But that would be a larger discussion beyond this subforum.
That brings us back to the question of what is a “street”, and what’s a “name” on roadways. Streets are mainly named for addressing. Roads are sorta named for planning, engineering, and construction purposes first. Eg a “street” can be named from a series of differently planned roads, and a road can be broken down into different street name sections (usually for addressing purposes). They can be disconnected/discontinuous. I wonder how many enthusiasts drivers actually follow “streets”, rather planned roads and assigned routes.
In Melbourne, there are many route=road that are not really numbered or coded road routes, but planned roads, or =street .
The Princes Highway across the country includes Lonsdale St, Dandenong Rd, Queens Rd, etc, different named “streets” (if I understand their system correctly). https://www.openstreetmap.org/relation/215662
At first, Burke Rd might seem to be one named “street”. But it actually contains Burke Rd N, which would be considered a different “street” in addressing. Relation: Burke Road (8301125) | OpenStreetMap
I had the thought that a planned road should be further distinguished aside from streets vs assigned routes. Rail has =tracks too besides =railway, although they are used for different purposes. Yes, this is a greater topic, but it would be a reason to keep route=street despite the “departure from proposal” / “non-proposal compliant”, for a more fundamental reason in the long run.
Btw I have OHM in mind as well. For handling change in named street sections, and evolving road developments.
I would note that “they should be not modelled as relations” should be also considered as solution in this situation. Maybe in separate thread, but if that thread takes as axiom that relation can and should be used then it should not be treated as indicator that it should be.
And for me it sounds like doing manual preprocessing - is there some reason why it cannot be done automatically by data consumers? Making relation for every single street sounds horrific, even if it is currently working workaround for Wikipedia (another alternative is adding map as an image).
“Wikimedia Foundation spends money on other things than implementing such feature” and “noone volunteered to implement such feature” should not be a good reason to map and maintain millions of not needed relations (would they be created also for all streets with wikidata entry? Or “only” for all streets with wikipedia articles?).
– signed, someone who is happy that nearly all Relation:associatedStreet - OpenStreetMap Wiki in their local area are nowadays gone (and deleted several of them) - and would not want to get them back as workaround for missing Wikimedia feature.
Assuming these streets are modeled as relations, should they be tagged as type=street, type=routeroute=street, or type=routeroute=road?
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), then route should not be used because routes should be linear while streets are not necessarily linear, they can have parts that split off, can have several carriageways, etc.
We should also discourage adding things along the street into the street relations (like houses or pois), because it would add expensive redundancy, and essentially mean going back to is_in tagging which was abandoned for a reason
I know of a bunch of Wikipedians who would look warily at this discussion, afraid they’d have to endure a spate of new road articles that in their eyes are non-notable, just because OSM decided to create relations for them.
Wikipedia doesn’t really need these relations anyhow. When North American roadgeeks left the English Wikipedia in protest to establish the AARoads Wiki, they lost access to Wikimedia Maps and the geoline service that conveniently highlights relations on the map. So they fell back to exporting Overpass queries as GeoJSON and uploading the data to Wikimedia Commons. They’ve done this for 20 states and counting. Both the AARoads Wiki and Wikipedia are now using these GeoJSON files instead of pulling relations directly from OSM (and the same mechanism is supported on the OSM Wiki). Eventually someone will probably write a bot to update the file any time the relation changes.
Personally, I’m open to this no-build solution and have never created one of these relations myself, but the desire for a relation type for streets keeps coming up. Mappers have sometimes createdstreet relations without being aware of the more-than-a-street street relation proposal, purely out of a distaste for tagging the same wikidata=* and wikipedia=* tags on many individual roadways. I admit that there’s a certain elegance to them. It’s the same reason why mappers prefer to put these tags on higher-order waterway relations instead of individual waterway=river ways.
Yes, encoding changes to a street over time is one of the pain points in OpenHistoricalMap. I’ve just been taking the simple approach of mapping redundant, overlapping roadways, but it’s tedious and JOSM users don’t like overlapping ways. As an alternative, the developers implemented renderer support for collecting the roadways into an associatedStreet relation, disregarding the addressing aspect of that tag. But only one street has ever been mapped like that, probably because editors lack support for associatedStreet relations (for good reason).
Here’s a street relation for you, every bit, wall, pole or corner signed, often the street name printed underneath the house number tag and as this grew over time, house number chaos. If there were a wiki to include name:etymology, that’d be on the street relation and not on the street parts… nothing so maintenance loading as doing that, here 64 street sections!
That seems to be quite in line with route=hiking|foot. We do not have such here (Austria) for vehicular traffic. At least not officially sanctioned; Perhaps some tourist leaflets have that, e.g. Weinstraße – but then not for A to B but for where you get by?
When I chimed in, my concern was to create something that is portable. Obviously, neither route=road nor route=street will ever be of a concern here. The German language does not allow to differentiate roads from streets, it is all Straßen. The reasons to build them may have to do something with connecting places or regions (routes), but that does not reflect in anything formal.
UPDATE: Obviously, I am proven wrong by the Data – busily watching the spinning cursor in the standard view just to get told it hit a timeout – there are lots of route=road here, mostly created 10+ or so years ago, with 1.700 members and 500 revisions. I even changed some of them myself however unbeknown. There are no route=street here.
“Road” and “street” are basically synonyms; “street” just implies a more urban character. The distinction that matters more is between “road” and “route”, but route=road is already taken for (on-road) highway routes, so the next best option for a route that is really a road is… street.
I’m fairly ambivalent about whether streets/roads should or should not be mapped as relations. For roads that have been split into lots of little pieces for lane tagging and other attribute changes, it seems somewhat reasonable to collect these bits into one object if mappers want to. On the other hand for a short street mapped as a single way, I can’t see any reason for a relation to be added.
It is interesting to note that although relations for streets/roads are not common, for hiking trails they are extremely common. Mappers frequently add a route=hiking for any signed hiking trail, even if a single way would have done the job just fine.
route=bus is for designated routes for buses, and route=bicycle is for designated routes for bicycles. For better or worse, route=road is the established tag for the analogous concept for motor vehicles (highway routes). If we had chosen route=vehicle for this concept, then route=road would be a more obvious choice for collecting roadways with a common identity, but it’s a bit too late for that.
I think it’s for a similar reason as the streets in Fremantle: Waymarked Trails only highlights route relations. In some places, systematically numbered cycling routes aren’t as useful or well-known as named trails, so mappers have created “routes” out of the named trails, replete with an initialism as the ref. (I may be speaking from experience. )
When I originally floated route=highway on Slack, the idea was that a “street” or “trail” with a coherent identity is sometimes really a mix of streets, pedestrian malls, and paths, all of which are tagged highway=*. The same tagging could apply regardless. But the problem again is terminology: route=highway sounds like “highway route”, which is not the same thing.
hiking trail often has name distinct from road/path
hiking trail often has attributes not applying to road/path (colour/symbol)
single path/road may belong to two or more trails
(maybe these happens less in USA/Oceania than in Europe? But in my area putting name of trail on road would be clearly wrong, while putting name of road on road is fine)
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, but mappers seem to be handling the management of all these relations just fine. I see no reason this single way, 150m long bit of trail really needs to also be also mapped as a relation but WaymarkedTrails requires it to be so and it doesn’t seem to be causing any problems.
Ideally it would be nice if data consumers would handle a street/road or a trail mapped either as a way or a relation so mappers could choose the appropriate object type for the situation. This is how all area mapping works in OSM. We can simply use a closed way for simple areas or we can create a multipolygon relation for larger or more complex areas. We are not forced to use a way for certain feature types and a multipolygon relation for others. It would be strange if landuse=* areas only rendered when mapped as a closed way and natural=* areas only rendered when mapped as a multipolygon relation.
I am familiar with many places where all of these points are true, in which case a route relation is appropriate and necessary. I’m familiar with many other places where a trail/path has just one single identity so there is no need for the extra complexity (it is also not a problem though). The thing is that all these same points can equally apply (or not) to roads/streets just as they do to paths/trails.
I guess that may be USA specific thing, as it is something not happening in for example Poland.
How can you have single road belong to two or more roads at once?
How can you have road name being distinct from road name?
How can you have road property not applying to road?
(note, I am aware of named/coded routes, concurrent interstates etc, but that is covered by distinct relation type - other than one being topic of this thread)
)