How about the other tags I mentioned?
1 Like
often differs across road parts (at least in Poland), sometimes putting it on relation would be extra-confusing
not viable to change data model for names
How would you deal with North/South or East/West, especially if those are changing force and back along the street or having gaps? Like that 14 Mile Road, which is changing from East to West a couple of times and if you scroll a bit to the West, there is a gap of one block.
Thatās a question of how the mapper getās the data displayed for editing and not necessarily related to how the data is stored in the database.
The most simple way would be to dissolve the relation in jOSM and show the relation-tags along the way-tags. If I change the name, jOSM knows that it has to change the property in the street-relation.
3 Likes
Iām not familiar with that area, but Iām guessing the name changes when the road crosses municipal boundaries? If so, it would seem reasonable to have a separate relation for the section of road in each township. Iād say a gap in a relation would be fine if it is fairly short and the street has the same name on both sides.
Itās a fair reaction and one I have myself sometimes when an idea of using a lot more relations is proposed. I started this topic to gather feedback on the negatives as well as the positives of potential street relations. Please do feel free to elaborate.
I got thinking about this because of recent threads advocating for putting street names on separately mapped sidewalk ways: Should sidewalks and crossings be unnamed? - What problem is this named "sidewalk" creating?. The idea is that the sidewalk is just as integral a part of the street as the motor vehicle carriageway and just as deserving of the name tag. Should this mapping style catch on, it would logically apply to bicycle tracks and side paths as well. I also donāt see any reason it would be limited just to name. It would seem just as reasonable to replicate these tag across separate sidewalks and cycle tracks:
This has the potential to be a lot of redundant tagging to maintain. Itās already a lot just with streets split up for lane tagging.
So the benefit Iām seeing is a container object where we could put tags that would be the same across all the ways making up a street while also relating parallel highway=* ways of different types to each other. So a street mapped as six parallel ways (two carriageways, two cycle tracks, and two sidewalks) would be unambiguously modelled as parts of the same street. This thread is just meant to be a conversation starter and Iām not about to start some ārelations for all the streetsā campaign. Iām open to non-relation based data modelling ideas for tackling this redundancy as well. Obviously any attempt to not have the name on the central highway=* would be a non-starter. Thatās far too ingrained. But some of these other tags may not be as crucial to have existing on every single way.
Maybe it could be? Or maybe not. I donāt know. If you know of any projects doing postprocessing that associates separate sidewalks and cycle tracks to streets and/or provides a model for how we could reduce redundancy of tags, please do share.
What about addresses, bus stops, electrical substations, maybe parking lots, some schools, and some POIs? And even some subway tunnels, or waymarks on boat channels that a street in question crosses? All these also make use of the name, although it might be noted in different tags. There can and will be wide discussion whether those objects shall or shall not participate in such a relation. And there will be absurd corner cases for whatever is proposed.
For the relations itself: what do different roles mean? what does the order of elements mean? Of course, this can be decreed to be ignored now. But do we really what to read two years later or so the turf war thread about whether it is car centric when the carriageway is before the footway?
The tag is a much simpler model that eliminates all this trouble by design.
For the etymology tags: does a Karl-Liebknecht-Str elsewhere really have different etymology? A Karl-Liebknecht school? Or is it just a redundant function of the name tag, which is not really geographic?
Frankly, I am astonished we are discussing this concept again. There are not so many official_name or alt_name tags on highways in general, even less on cycleways and footways. For cycleways, old_name would typically not even apply around here (because the renaming is predating the cycleway), would we have to keep different relations if an old_name tag (or any other tag) is present but should not apply to all members?
If we indiscriminately group all parts of the street which have the same name, why would we need a relation at all? It would make sense if there was some criterion that is not implicit in the data, but if it is just the same name, we can group this in postprocessing if desired. Relations are not categories.
Above, I mentioned street:name, used for streetside parking, but easily extendable to sidewalks and cycleways (currently no evidence in taginfo with cycleways and 0,04% combinations of footways, already defined for these ways in the wiki). This tag together with name could completely replace the street relation.
What are the expected benefits from these relations, is it just to avoid adding names to sidewalks? This type of relation is already around since 2008 and has gained about 32k uses (compared to 68 million highway=residential), some years after its introduction, most mappers decided it was a failed approach, for one because many mappers didnāt update the relation, so for good results you could not rely on the relation alone so it led to a combination of both: we had to maintain these relations but then also use an alternative approach to select street parts by name matching because the former was āneverā complete.
manholes, drainage inlets, post boxes, traffic islands, kerbs, crossings, traffic signs, street lamps, benches, parking ticket machines, road markings, street side restaurants, kiosks, trees, guard rails, memorials and sculptures, ā¦
In the past we have had some findings in Italy, where a street had been named after someone only locally āfamousā but with the same last name as someone famous on a national level (and as there are often only last names on the signs, someone had expanded the name to the wrong person).
The benefits Iām expecting are:
- We can model things belonging to multiple streets properly
- We remove a lot of redundant tagging of etymology, wikidata, wikipedia, operator, maybe even ref.
- We can properly distinguish between something that has its own name, and something that belongs to a street with that name
- We can add all sorts of things to the relation that wouldnāt necessarily get a name in the real world, but still ābelongā to the street (crosswalks, separately-mapped traffic signs, traffic lights, tree(row)s, and so on
- If we search for the street, instead of showing āhereās 800+ parts that make up street Xā, we can just show the relation, which, in my opinion, is a huge plus
The only downside seems that editors still donāt seem to properly support all relation types, but thatās something that can be fixed. A broken data model is harder to fix.
3 Likes
Sure, Karl-Liebknecht-StraĆe is not really ambiguous, but Peter Street or Bathurst Street are.
-
Which jurisdiction are you referring to? AFAIK there is typically no such thing that belongs to multiple streets. Things are either on one or the other street, just look at the parcel to see which it is. (not so interesting anyway IMHO, I would not split most things just because they happen to be on different parcels).
-
why is it āmaybe refā, could be also ānameā, although I would expect this to become brittle, small beginner mistakes could lead to having a whole street without name. From the 284 million highway=* objects, 20% have a name. 4.6% have a ref, 0.54% have a name:etymology:wikidata, 0.04 name:etymology:wikipedia and 0.03% name:etymology, 0.17% have wikidata, 0.09% wikipedia and 0.71% operator. I guess these are mostly overlapping, i.e. less than 1% of streets are involved, and assuming that many are unique values, while it maybe are not so few in absolute numbers, getting rid of this redundancy will not make a big difference overall.
-
we can already do this (name vs. street:name), but we cannot agree whether the cycleways and sidewalks have a name or not.
-
this is not a benefit on its own. I do not see any advantage, and generally, to be more useful than just doing spatial analysis, it would have to be better, while practice has shown that these relations were useless because they were typically incomplete.
-
This depends on the actual situation (see above, several physical āstreetsā with all the same name) and also on the search engine. It could already today make such a grouping of streets which are connected and have the same name. We do not have to painstakingly create and maintain millions of relations manually for this.
All explicitly out of scope. The idea under discussion here is only about relating highway=* ways that represent different navigable parts of the same street. No other object types. The idea would be to have a very focused and narrowly scoped relation type.
Relations of type=associatedStreet and type=street are already in use to join all the addresses, buildings, and whatever else a mapper deems related to the street. I view this as bad data modeling and a practice that should at least be discouraged if not deprecated.
This would be up for discussion but I was thinking of roles specifying whether a particular way represents a carriageway for vehicles, a sidewalk for pedestrians, or a sidepath for bicycles. It might be that roles wouldnāt even be necessary though because this information would already be communicated via the highway=* tag of the way.
Keeping ways in order where they are connected end to end in a line makes sense (like route relations), but streets having multiple parallel ways and branches means there could probably never be a perfect order. If the pedestrian advocates want to put all the footways first, we could just ignore the turf war thread and also ignore the order when consuming the data 
.
In the absence of a relation, I support using street:name on sidewalks and bicycle sidepaths:
Others have argued adamantly that this is discrimination against sidewalks, though, and they deserve the unprefixed name tag just as much as the central street ways. This argument would probably not be solved by adopting street relations, but at least we might be able to head off the same argument about other tags that apply to the whole street like alternate name tags, wikidata, etc.
1 Like
If you scroll up to
youāll see an example of where parts of a street donāt necessarily belong to a single street. We also have countries where sidewalk can sit between a dual-carriageway streets where each direction has a separate name ā even if itās just a northbound/southbound-suffix.
No one here wants to move the name of the street away from the carriageway as this will break too many things to even be aware off. Itās āmaybe refā, because depending on what ref is referring to, this might be something that inherently belongs to the street as a whole, to a route, or to a series of streets.
Good news: with relations, you donāt need to agree, because itās up to the data consumer to decide how to actually present this data. Also, street:name is dismissed by several people as car-centric tagging. And I donāt see how slapping street:name on hundreds of sidewalks is more elegant than just a single relation. But YMMV, which is why weāre trying to compare the 2 approaches 
It is a benefit, because especially with traffic signs, they can apply to one or to multiple streets, or itās unclear by their position, to which street they actually belong. But itās probably the least important of all the benefits, agreed.
a) itās a nice side effect
b) it also works for streets with gaps
c) if the relation is created correctly, the search can also show sidewalks
d) if it was easy to do, then someone would have done it already for something like Nominatim. But the implicit grouping by name would require a lot of post-processing
It would be nice if the whole āthis can easily be done with post-processingā mindset was dismissed for a little while, because we cannot expect everyone to post-process our data the same way, or to even want to post-process our data. There are things that can reliably derived by post-processing, because the rules are simple (if a POI is inside a building with an address, the the POI will very likely inherit that address[1]), but grouping the parts of a street into a street (without at least additional tags on these parts) is not that straightforward.
Exceptions apply, of course ā©ļø
I would consider crosswalks appropriate to include where they are mapped as highway=* ways. Everything else youāve listed here (especially the āand so onā) I would consider out of scope. See:
Iām not saying that we should do this, but we could. You might even consider just setting a specific role to all highway=*-elements. Again: not saying we should, but we definitely could 
I would think so. 14 Mile Road is a divider for several cities. In some blocks the left city āwonā in some the right city. But thatās rather an extreme case. It was more general, whether you would consider East and West as separate streets. Similar topic would be interstates and other dual carriage ways. On the route=road relation we are indicating east-bound and west-bound. How would this look like with the street relation?
Donāt get me wrong, not want to say itās not working. Iām just curious about your (and others) thoughts.