Many, if not all, streets in Geneva are partitioned into several ways, making it tricky to view them as a single street. Even so, I ended up splitting some streets myself, due to routing tags differing between parts. The situation is likely different from places where most streets are represented by a single way.
Relation: Rue des Alpes (19971047) | OpenStreetMap
it’s easier to view them as a street (and not just several or dozens of ways for segments or lanes) and add general tags. Afterall, it’s OpenStreetMap and not OpenLaneMap ;)
Ways for individual segments or lanes would hardly change. I don’t particularly care about adding Key:ref:ESID to the relations, but others are free to do that. I noticed that an interesting website about Geneva using OpenStreetMap had to re-draw each street as they can’t retrieve them from OSM.
Is there any downside to creating such relations? I’m aware of the “associatestreet” debate (about linking houses or house numbers), but that is a different issue (or proposal).
I would try to maintain the relations and include them in my maintenance of some of the addresses in the city.
street relations are essentially unsupported. With other words you still have to repeat the relevant tagging on the individual ways so you don’t really win anything (essentially making the relation a collection which is considered bad form). There was a longish discussion somewhere in the forum on just this topic a year or two back.
I noticed the support in various tools is limited, but tools evolve. You could easily switch to using them for your street name checks on house addresses (currently we need to repeat alternate spellings on every way to match GWR, which seems like really bad practice to me). Similarly, details about the street naming can just be mentioned once.
Nominatim isn’t working well with ways either. It’s somewhat random which lane or segment appears.
Integration of relations in the map interface should be improved, but this is mainly due to unmaintained “verflixte” relations making the tags harder to read: sample
Contrary to individual segments, these relations correspond to an easily verifiable reality on the ground, what can hardly be said about the dozens of ways they help identify.
Each tool has different priorities. The fix for Nominatim seems rather trivial, but maybe they prefer these random results. Obviously, nobody has to make use of all parts of OSM.
and it is a manual workaround that would waste massive amount of human mapper time to apply through the world (or region), while making editing harder and more confusing
Can’t we say that about every OSM feature? In any case, personally, I think it saves time compared to editing each way.
Are there any concerns specific to Geneva? (The feature isn’t new, but, as mentioned, it does appear less suitable to localities where each street is a single way).
also, in this case benefits are tiny compared to confusion and additional annoyance
but editing each way is still needed anyway so no time is saved at all (and if something applies to each street way then you can apply it fairly easily anyway)
They correspond to several ways grouped together based on their common name.
In that case related to ‚station‘, but you could fairly simply generate all collated streets in Geneva based on their name.
while it may be seemingly faster to add some reference, name, wikipedia tag or surface to relation there are problems:
now people editing such objects need to check both ways and relation
they need to learn this new complexity that previously not existed
data consumer, with rare exceptions will not support it, so tags need to be repeated anyway
relations are EXTREMELY annoying - from Vespucci when for any way of road affected by such tagging scheme, after every tap on road segment you will need to choose either way or relation, though iD where basic relation handling has gems like turn restriction editor but mostly is ranging from annoying to broken, ending on JOSM where relation editing is passable but still annoying and complex. In each case overall editing, viewing and updating only ways would be easier
last thing we need in OSM editing is increasing complexity, especially for new users - and while in some relatively rare scenarios it may save editing time (if we do not care that data consumers will not use this data) but at cost of increasing complexity pile
if data consumers would be supposed to be supporting it, that requires putting even more effort
oh, and all this relations would need to be created and maintained
all that effort and complexity, for negligible benefits (even if it overall makes editing faster for narrow slice of some power-users) is not worth it
if you often make this kind of edits it is better to look at and learn JOSM search and filter tools
and implementation effort would be better spend on grouping roads in search results
Allerdings wurde das schon vor einiger Zeit hier abgelehnt. Begründung: War glaubs was mit Unterhalt (wobei das gleiche Argument man auch bei anderen Wegen, z. B. Fuss oder Velo vorbringen könnte) Bin mir aber nicht mehr sicher, ob ich das richtig verstnanden habe.
As mentioned, the optimal model varies for each cities. For Bern, it might not be needed as almost the entire street of your sample is a single way. I couldn’t find much discussion around Geneva (maybe it was in French in the France forum).
The sample from Bern is one for “associateStreet” (which isn’t what is proposed here for Geneva) and was changed a while ago (to the “relation” model brought up here). In general, the “associateStreet” model might work for smaller localities where houses typically aren’t on multiple streets, but it’s still suboptimal when housenumber-housestreet addresses aren’t on buildings or house-door/address nodes.
In general, we seem to agree that streets can’t be easily found. The tool habi mentions could be a way to go. It’s unclear though how it could work for Nominatim. Also, we might have to create and maintain the streets on github instead (which is even more complicated).
Nominatim is indexing automatically, not manually. On Github we have code that does data processing, not manual index for each reply.
And yes, writing code for Nominating and osm.org to support it is complex, but far less effort than creating millions of relations, for each road - to say nothing about maintaining them.
I was referring to the tool habi mentions and the stored link he provided.
I will have a look at the Nominatim alternative. Though if it’s from 2014, it’s likely not to happen, isn’t it?
BTW, there aren’t that many streets in Geneva. The numbers sharply increase if one would want to edit every way instead (as you seem to suggest I or others should do).
While I’m also very opposed to having associatedStreet relations (or type:street relations, for that matter), I also do not see what you exactly want to achieve with this other than increasing the complexity of OSM data in Geneva for something that is essentially a specific use-case (of geneve-archi.ch in this case, which I’m guessing you’re probably a part of – an which looks like an insteresting project to me!).
In other words: You want to process OSM data for a third-party project, but instead of doing it on the project’s infrastructure, you try to change the OSM database in a way that suits your use case.
And I think that’s not something you should do, especially if it entails creating complex data structures for a large place. You also wouldn’t (shouldn’t) create relations grouping all, say, bakeries with the same name in Geneva into an associatedPastry relation or group all Swiss 2000m+ peaks into an associatedHeights relation. If you want to find all bakeries or 2000m+ plus peaks, you create a database query instead of modifying OSM data directly.
That’s not so much a characteristic of Geneva or Bern as such, and will change as soon as somebody decides to map additional features of, say Gerechtigkeitsgasse (or any other street for that matter), that can’t be represented as a feature of the street as a whole. (For a bad example: distinguishing between the two lanes of Gerechtigkeitsgasse split between the Stadtbach ditch).
Isn’t the only difference the part where you do not add the house(numbers)?
That’s not something you can reliably infer from the size of any locality in my experience. Just take any intersection with a building next to it, and you’re just as likely to end up with multiple possible addr:street values in a big city or a tiny hamlet.
This is not proposed, nor is there an agreed upon model for doing so. Please avoid such argumentation.
I’m comfortable with handling that. However, editing 1000 to 10000 ways instead seems much more complicated. Why would you want others to that instead?
Not that it matters, but I’m not affiliated with any of the websites mentioned in this thread.