A number of streets in Fremantle have been modeled as route relations, which has enabled Wikimedia Maps to plot them on a basemap. They had been tagged route=street to distinguish them from named or numbered highway routes, which are tagged route=road. Recently, @Sam_Wilsonretagged the relations as street relations. This usage is compatible with the documented purpose of street relations, but there’s less software support for street relations. For example, Wikimedia Maps only supports highlighting route relations; this limitation has caused the relevant articles’ infobox maps to lose their highlighted streets.
As described on the wiki, street relations not only consolidate the street’s geometry but can also relate the street to everything that is associated with it. In theory, everything in Fremantle could be added to one or more street relations. However, each of these relations only contains the street geometry; buildings and shops along these streets are still tagged with addr:street=* instead of getting added to the street relations.
In the ensuing discussion, @Pikse advocated for reverting the street relations back to route relations but tagging them as route=road instead of route=street. I disagree with using route=road for this purpose, because this seems to erase the distinction between routes and the roads that carry them. This is a distinction that matters a lot in the parts of the U.S. where I map. If I’m not mistaken, the Australian tagging guidelines, which were revised just a few months ago, appear to endorse the same distinction (albeit with way tagging instead of relations).
Assuming these streets are modeled as relations, should they be tagged as type=street, type=routeroute=street, or type=routeroute=road?
Can only comment from a ontologic point of view: A route is telling me, how to get from A to B. A street is the whole of carriageway, maybe spanning several driving lanes, perhaps parking lanes, cycle-lanes/tracks, pavement/sidewalks, verges even, the lane for broke down cars on motorways, forgot what ist called in English/OSM, bus lanes, etc.
Whatever this comes out, should be translatable. type=route for a street will make this hard.
I think you’re referring to a “route” as in the output of a routing engine, in other words, an itinerary. To clarify, when I refer to highway routes above, I’m referring to a single designation that is applied to multiple roads (or occasionally just one street) as an officially recommended itinerary from one destination to another. Regardless of how these relations are tagged, routers are still able to calculate routes that traverse the streets (though route=road will make guidance instructions more awkward).
For example, this way represents a small segment of Stock Road that carries National Route 1 at an intersection where National Route 1 departs from Stock Road to follow a different road. Some routes also have names that are distinct from the names of the individual streets. Kwinana Beach Road carries Rockingham Coastal Drive.
The OSM-US Slack thread also mentions type=route, route=highway an option (as in, the things it’s grouping together are all highway=*, I think is the idea).
I liked the idea of not using type=route for streets, because it seemed a better way to group all of the things that are named together but didn’t imply anything about routability. For example, Henderson Street in Fremantle has a pedestrian part which is still called Henderson Street but which isn’t really part of a route from one end to the other (unless one were to also include the footpaths… which maybe isn’t such a bad idea).
Anyway, the real clincher at the moment here for me I think is that Wikimedia maps currently only support type=route, and so my changes have meant that a bunch of Wikipedia articles have lost their little red lines on the maps! So that’s no good. It seems like the software that manages that stuff isn’t going to be updated any time soon, so for now if it’s considered pretty much correct here and also keeps things working on Wikipedia, I’ll change everything back to type=route with route=road.
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.
National Route 1
Rockingham Coastal Drive
)