Your feedback on removing associatedStreet relations

Hello German community,

In the French community, we like associatedStreet relations (around 60% of the 10M French addresses use them) , but it generates editing conflicts between contributors using relations and contributors using addr:street=*.

We’re currently having a lively discussion on our forum on the subject of should we decide to favour one scheme over the other. (We’re not talking about completely removing one scheme, but favour one).

In this context, we would be interested in your feedback 5 years later on the abandonment of associatedStreet relations in Germany, with regard to some of the arguments discussed:

  • about contributors :

New contributors don’t dare contribute to addresses because of the co-existence of the 2 schemes, it’s too complicated to understand. Showing a preference for addr:street=* will encourage new contributors.

Making relations obsolete will discourage contributors who have spent time adding them, and they will stop contributing.

Did it happen this way in Germany? Have you lost some experienced contributors and gained some new ones? Or were relations already in minority use when they were abandoned?

  • about tags

Relations can be used to manage different versions of the name: mainly regional languages, sometimes alternative spellings. It would be far too complicated to duplicate these different versions on each node.

Without a relation, how do you manage the ref:FR:FANTOIR tag used to link to the national database?

Do you have a similar situations in Germany? How do you manage them?

  • about updates and consistency

Duplicating street name information across all its buildings is a major source of inconsistency. If different nodes don’t have the same addr:street value, how do you know which is the right one?

Relations make updates very easy: you only need to change 1 value. With nodes, there’s always a risk of missing one.

There are overly complex cases, where the use of an associatedStreet relationship will be indispensable.

Is this something that happens often? How do you deal with discrepancies in addr:street in the same street? Do you ever regret totally removing associatedStreet relation because they did have their advantages for updates and consistency ?

Thanks !
Etienne, for the French community

2 Likes

You win some, you lose some.

I guess we’re not bothering with alternate spellings on address objects. “Chóśebuz” is recorded on the Cottbus city object, that ought to be enough. old_name is set on the highway only.

Hopefully, whoever added addresses used Ctrl-C,V in the editor to begin with. There are validation utilities in editors (for small Levenshtein distances) and external utilites (higher orders). I remember one webpage which just lists all street names in a city in alphabetical order, and it only took looking at it visually to see if something was repeated twice.

No. People kept adding names outside the associatedStreet relation anyway, so discrepancies between the relation and {the rest of the city} were never eliminiated, at which point eliminating associatedStreet was the sensible choice.

4 Likes

Please have a look at wiki/Relation:associatedStreet#Usage_stats .

Imho these experienced contributors will find more than enough other things to add in OSM.

Is it? I’m using a mapstyle in JOSM that shows me the building and the street in the same colour. Pretty easy to spot something wrong. On “what to do”:

  • write a note so someone walks there and checks on the ground.
  • Check mapillary
  • Check open government data
  • Ask the previous mapper where did the get it.
  • If the “wrong” one is the newest one, maybe they just misspelled it? Sometimes some assumptions could and should be made in my opinion.

If i ever want to map somewhere and i encounter some adress-relation i will not add anything. Never seen relations used for adresses before in austria. I personally think relations should be avoided if possible because it increases the starting-barrier for new contributors.

We have a official postal adress and thats the only one used as far as i’m aware (in austria at least).

Could you explain what you mean with that? In austria we are able to get the adress from open government data, but we don’t link it to anywhere. Example Way: 238895536 | OpenStreetMap A JOSM-Plugin is used to catch the address from the government database.

Hm, currently cannot think of any case where a relation is needed.

The only benefit of using a street/associatedStreet-relation is that we don’t have to copy & paste massive amounts of information and can refer to the street as a single object. This is especially good for all sort of names, especially etymology, and also wikidata.
It would also be nice to group the accompanying cycleways and sidewalks into that relation, definitely.
But apart from that … nothing is indispensable, and especially adding houses to these relations always seemed like a bad idea to me[1]. When I started OSM, these associatedStreet relations were the most scary things around, also because they were all broken where I mapped :person_shrugging:

Given proper support from editors, I think street-relations could be a good thing, but given the current state, I’m happy the German community ditched them back then.


  1. One reason is that it doesn’t elegantly solve houses with multiple addresses, because you’ll still need addr:housenumber. Also country and zip can be calculated from relations, so you really only save addr:street, which is nothing that outweighs the mapping complexity overhead ↩︎

3 Likes

The basic issue is that there has never been any native editor support for associatedStreet relations and there is unlikely to ever be, given that they are dead everywhere outside of FR.

So while there are some CSy theoretical advantages to them, in real life any such advantage is massively outweighed by the added complications in adding, maintaining and consuming them.

5 Likes

seems like the last ones where removed a few months ago, but i am not aware of any recent example where it was used not only in addition to but instead of the other scheme

Inconsistencies happen from time to time, for example when someone changes the spelling of street names without changing the corresponding addresses, but it is usually also noticed by various QA tools

1 Like

Wow, I didn’t know this existed. Nice to know.

Just my 2ct:
I personally add data to OSM by walking down the street, having the SCEE app open on my smartphone, then adding “the stupid stuff“: Material of the road, quality of the road, has lanterns, and also for houses: house type, roof type, floors, …

When it comes to the address, it’s as easy as:

  1. Type in the number
  2. Tap on the street on the map. So, there’s no “mistyping“.

SCEE creates an addr:* block then.

When I see “a wrong structure“ like a missing path etc., I fix that either in “Vespucci“ on the phone or in “JOSM“ on my computer.

Having added a lot of data this way I still consider myself not experienced enough to deal with relations. I still don’t get how the work, and after trying multiple tutorials to no success, I decided to never touch them at all. I add a note and run away.

Maybe I’m stupid, but I read it multiple times here, experienced mappers don’t dare to touch relations, or the more couraged mappers excuse for having broken a large relation.

So… if you want to support mappers like me, contributing “a lot, but only simple OTG data“, then stay away from relations.

Disclaimer: That’s my personal 2ct and I’m aware the world doesn’t rotate around me. Just saying.

2 Likes