No, it cannot be omitted. Most applications that use street names do not even evaluate associatedStreet, and would therefore not find the name. Please also note that associatedStreet is only used by a minority of mappers, and Relation:street is essentially just a proposal. --Tordanik10:48, 12 August 2014 (UTC)Reply
Ok you don't like these relations, but ~200.000 relations (combined) cannot be ignored. Relation:street is no longer a proposal, with its 15.000 uses it has been adopted by some people (I wish we could merge both relations).
If applications do not evaluate relations, it is the problem of applications. It must not prevent from improving tagging.
I like these relations because they avoid duplication. I often have to split a way in multiple parts. I don't like repeating the same name=* as many times, it seems very error prone to me... and just not logical.
But I understand your concern: it is more difficult to extract the name from a relation than directly from a way. --Oligo (talk) 19:29, 12 August 2014 (UTC)Reply
You are right, I don't like them, they may seem elegant in theory but harm usability. But I believe that my statements are be supported by facts regardless of my personal preferences.
The associatedStreet relation is without doubt established. Nevertheless, only 10% of all addresses use the relation, so it's clearly a minority tagging style. And there was never a documented intent to have the relation replace street names on the highway way.
Meanwhile, the claim that the street relation should be considered in active use is highly dubious. To find out whether something is established, you cannot only look at the usage counts of that tagging itself, you have to compare with related tags. Only 40 852 of the total 81 257 868 highways in the database are members in a street relation, i.e. less than 0.05%. --Tordanik14:04, 13 August 2014 (UTC)Reply
Associate sidewalks?
Latest comment: 11 years ago3 comments3 people in discussion
When Sidewalks are drawn as separate way (for whatever reason, distance, shape, etc), this relation could be used to associate them to the street. Do you think we could add a "sidewalk" role for this? Or is there another method to help routing engines to determine street names and other attributes for the sidewalk? Kempelen (talk) 13:51, 22 August 2014 (UTC)Reply
I oppose this proposal. Strongly NO. This type of relation is needed for multilingual street names. Ukrainian mappers decided to use it instead of addr:street tag. --Dimonster
I approve this proposal. Just confusing. There will always be editors that don't support it which will result in duplicate or missing information. --AndiG88 (talk) 18:28, 21 January 2015 (UTC)Reply
I oppose this proposal. I still think they are an elegant solution to make clear which addresses and street parts belong together. It's also a lot easier to determine COMPLETE addresses this way, than to have to perform spatial queries. It makes the data self contained for situations where one doesn't have access to these spatial functions. Lastly it allows to do some validation. That others don't feel like using it is one thing, but please don't try to discourage the people who do see value in it of using it. --Polyglot (talk) 06:11, 22 January 2015 (UTC)Reply
I suggest to ignore the above vote because it is clearly based on a misunderstanding; addr:street/addr:city tags provide ample opportunity to create self-contained address information not relying on spatial data, and are indeed easier to process than relations. --Frederik Ramm (talk) 10:34, 22 January 2015 (UTC)Reply
That is incredible, when I say COMPLETE address, I mean one that can receive snail mail, i.e. including postcode and village/city/municipality information. The vote stands--Polyglot (talk) 15:51, 22 January 2015 (UTC)Reply
I approve this proposal. The claimed benefits of the relation for applications don't actually work out. Meanwhile, the hit to usability is all too real. --Tordanik07:38, 22 January 2015 (UTC)Reply
deprecate it. In my opinion it is more burden to the mapper, more work for the consumer, quite fragile and usually out-of-date. --Imagic (talk) 07:44, 22 January 2015 (UTC)Reply
I would like to express a degree of incredulity at this proposal. With it's current usage (~20% of addresses) and position as the primary means of mapping addresses in some regions, it will continued to be used for new addresses and data consumers will have to support it if they want to parse addresses. Pnorman (talk) 10:15, 22 January 2015 (UTC)Reply
It's 7% of adresses (which, of course, is still a lot). And of course we will need a migration plan etc. This would just be the signal to start that process. --Tordanik08:19, 23 January 2015 (UTC)Reply
I oppose this proposal. Don't deprecate it. It is indeed the only way we have to normalize addresses and other stuff. The only one that makes sense, at least. It solves so many problems that I can hardly understand how people cannot like it, let alone even think of deprecating. --SimoneSVC (talk) 10:25, 22 January 2015 (UTC)Reply
We have 2 relations for almost same purpose. associatedStreet has flaws. It doesn't matter if it is popular right now in database, you have other means to normalize data. With Relation:street you can normalize any tag. Xxzme (talk) 10:31, 22 January 2015 (UTC)Reply
I would like to express a degree of incredulity at this proposal. I don't see a reason to deprecate it. It's still widely used and it's currently the only solution to assign multiple addresses to the same building (I'm not talking about different addresses per entrance). --Nadjita (talk)
We should try to get along without relations wherever possible, because working with endless relation lists in our editors is a horror. The associatedStreet relation is illogical in various respects: 1) There are no associatedCity, associatedCoutry etc. relations. 2) Adresses don't depend on the course of the road and vice versa. So why bind them together? 3) What if the street is split in multiple pieces, or if there are mulitple parallel carriageways, service roads etc.? Which of these bunch of ways shall be part of the relation? 4) The camelCase spelling is Java standard, not OSM standard.
The only justification I came across was to enable the use of name variations (such as name:en) without having them defined redundantly, but I think that addr:street:xx tags (e.g. xx=en) are not actually redundant. They denote that the street name in that language is actually in use for that address.
However, I am afraid that formal deprecation of that relation type will encourage developers of validation tools to incorporate a warning. This will lead to "manual" mass edits soon. I am not happy with that behaviour. Please let the relations in place unless you are editing an area for other reasons too.
I would like to express a degree of incredulity at this proposal. I'm totally opposed to this proposal.
Why deprecate a widely used relation associatedStreet to benefit the less used one street ?
Some of the votes should be ignored, unless this vote is pros vs cons relations, no on associatedStreet relations.
In some case relation allowed to desambiguous case in a clean way, it's easy the work of maintenance and validation, it's easy the change over the time. Frodrigo (talk) 12:46, 22 January 2015 (UTC)Reply
I oppose this proposal. Repeating addr:street on all address nodes is not elegant, and at the moment it seems to be the only alternative (please, tell me if I'm wrong). Relations are a much more structured approach than repeating the street name on all nodes. --PiRK (talk) 12:57, 22 January 2015 (UTC)Reply
I oppose this proposal. associatedStreet-relations are widely used in Ukraine to support multilingual address data. addr:street allows to enter data only for one language. There are 16717 associatedStreet-relations, which contain 253718 housenumber way members out of 312155 housenumber ways in Ukraine. --dudka (talk) 13:34, 22 January 2015 (UTC)Reply
I oppose this proposal. How would you tag something like http://www.openstreetmap.org/relation/3015852 ? relation street is not an option because according to wiki it "is not established and unsupported by some applications". You can't use geographical proximity because you will never find some of the numbers. By using only the addr: sheme, if the street is renamed then you would have to change it on 20 objects, this is a prone to errors and you will probably forget to change it on some of the numbers ! --Ecologeek (talk) 15:20, 22 January 2015 (UTC)Reply
Prone to errors is exactly what this is. I bet it's 100x more likely your average street relation will be damaged by some newbie mapper, before it gets renamed. Also with JOSM it takes a few seconds to filter for a street: name in a area and replace it. --AndiG88 (talk) 18:15, 22 January 2015 (UTC)Reply
Isn't it the role of the editor to show some warning when an osm object will be damaged ? I don't think we can blame new (or experimented) mappers if the editor let them do whatever they want whithout any validation of the resulting data ! --Ecologeek (talk) 13:01, 23 January 2015 (UTC)Reply
I oppose this proposal. as long as there is no a clear alternative to this relation, and a previous serious discussion. Gall (talk) 15:55, 22 January 2015 (UTC)Reply
I approve this proposal. Adding "addr:street" is much more beginner-friendly and there is much less chance that this simple approach is destroyed by someone. The relations have the big problem, that it is difficult to keep them up-to-date. Most of them, in fact, are incomplete.--M-Reimer (talk) 16:04, 22 January 2015 (UTC)Reply
I would like to express a degree of incredulity at this proposal. Where does this deprecation proposal come from ? Any explanation ? These relations are widely used in France and a lot of tools rely on them. Why deprecate a commonly used tagging scheme ? Cquest (talk) 17:55, 22 January 2015 (UTC)Reply
I approve this proposal. -- associatedStreet is totally over-engineered and for a lot of people only works on PowerPoint. This concept should have been deprecated years ago, as most (especially newbie) mappers just struggle with the complexity and don't find much use in it. I converted ALL of the associatedStreet relations in my area, because they were a huge unmaintained mess, full of inconsistencies. Couchmapper (talk) 18:39, 22 January 2015 (UTC)Reply
I would like to express a degree of incredulity at this proposal. This scheme is widely used, maybe not perfect (probably not the simplest to use), but it is way better than repeat addr:street=* on every single address. --PanierAvide (talk) 19:57, 22 January 2015 (UTC)Reply
I oppose this proposal. associatedStreet's are are widely used in multilingual countries, and all multilingual information will be lost. With that you will create a huge problem. Please don't do that. --UkrainianZombie (talk) 21:35, 22 January 2015 (UTC)Reply
Actually Nominatim doesn't use any of those addr:**:** tags as you might assume. Nominatim rely on spatial data to associate addr:** objects and streets. This is totally inappropriate for lot of data consumers - it is much easier to process associations described by street-relations than uncertain neighborhood association. --dudka (talk) 14:08, 23 January 2015 (UTC)Reply
I oppose this proposal. some entire countries are mapped this way, so unless a feasible migration scheme are developed, I would say no XAN (talk) 21:55, 22 January 2015 (UTC)Reply
I approve this proposal. From a computer expert point-of-view relations are fantastic for data integrity and to keep database size low. From an OSM point-of-view, which includes being friendly towards novice users, relations should be avoided whenever possible. And associatedStreet relations are avoidable. Naturally the existing associatedStreet relations should not be deleted because they contain valuable info. Perhaps a bot could do a conversion towards the Karlsruhe scheme. --It's so funny (talk) 23:07, 22 January 2015 (UTC)Reply
I oppose this proposal. There are 2 data models for adresses at the moment, each with its own advantages. If you don't like the associatedStreet approach, use the addr:street one, but please don't try to convince all of us. Kind of a useless fight.Vincent 95 (talk) 09:23, 23 January 2015 (UTC)Reply
I oppose this proposal. strong - This is a stupid vote given that there was absolutely no discussion for proposing another scheme. It is not even clear that it is against all relations, or about the type of this widely used relation in favor of a newer one (with minor differences) only for the purpose of unifying them. You cannot deprecate any tag without first approving a new scheme. This vote is then INVALID and will be unapplicable, whatever its result (and two dozens of votes above are clearly not enoguh compared to the many users and contributors of this relation type. — Verdy_p(talk)10:45, 23 January 2015 (UTC)Reply
I oppose this proposal. Relations (either associatedStreet or Street) are a better approach than repeating the address details on all nodes --Renecha (talk) 22:48, 23 January 2015 (UTC)Reply
I oppose this proposal. There seems to be no comprehensive explanation to why exactly should this relation be declared as "deprecated". While using relations for address information has its flaws, some more obvious than the others, as it was already said, it simplifies multilanguage support (a good point in the countries with many languages used), helps avoiding typos and maintaining address data. I feel this relation should be enhanced, its usage reformed, its support perfected, not deprecated. Otherwise we better have other instruments to handle the problems it helps us handle now. --Kilkenni (talk) 12:40, 24 January 2015 (UTC)Reply
The last sentence sounds like addresses in Kilkenni's land are mapped by bots, or even Kilkenni is a bot himself. In both cases you are wrong. It has been stated earlier that Nominatim does not support the tags from yours example. That's why no one can deprecate associatedStreet relations until the real alternative will be found. So einfach geht's. --UkrainianZombie (talk) 14:10, 24 January 2015 (UTC)Reply
Could you give me another query example where the part of interest (e.g. "Strada Riva di Sotto") is placed not in "addr:street" tag, but in "addr:street:##" only? --UkrainianZombie (talk) 22:13, 24 January 2015 (UTC)Reply
I oppose this proposal. This voting process is too unclear. Those who seek deprecation of a used tag or usage should document what they want to deprecated, to be replaced by what, and explain how to discourage future usage. Because of unclarity, I vote for statu quo : returning wiki pages to what they were before new crontroversial changes were done. sletuffe (talk) 17:32, 24 January 2015 (UTC)Reply
I approve this proposal. Deprecate it. With example addr:* vs Postal_Addresses (deprecated and removed) notations: 1. two concurent schemes is bad idea, because only one edited mostly, so this make data smell bad especially for nested data (for example relation can contain part of another street after splitting way, still contain old houses when it was demolish). 2. flat scheme more easy for editing/understanding. 3. duplication question for related object still open, because streets and houses should not contain street name and addr:street+addr:housenumber (housenumber for two and more addresses for building) to avoid duplication and smell data. 4. Multilanguage mapping can be resolved for flat scheme with language suffixes for example. tbicr (talk) 07:21, 25 January 2015 (UTC)Reply
So shortly my point: 1. it should be only one scheme. 2. is should be mostly simple scheme. 3. it should resolve or has point about known issues (multiaddress, multilanguage, duplication, breaking changes). 4. better when this scheme widely used. 5. better when this sheme widely supported by software. tbicr (talk) 09:52, 25 January 2015 (UTC)Reply
I oppose this proposal. This relation is elegant and clean. That working with relation is difficult is not a matter of the releations itself but a matter of poor tools. So I'd say keep this relation and create better tools! Ogmios (talk) 12:26, 25 January 2015 (UTC)Reply
So what? As I said, it's a matter of good tools. I such a crap happens and the tool I think of needs improvement. This doesn't prove that associatedStreet-relations are generally bad but that the mapper didn't know what he was doing and the tool wasn't very helpful. Ogmios (talk) 20:46, 25 January 2015 (UTC)Reply
I oppose this proposal. There is no point in tagging higher level information, such as multiple names for a street and postal codes, in a low level entity with multiple occurrences, i.e. buildings. Hence this relation is a valuable asset for avoiding redundancy. In fact it would be logical to instate further relations for associated cities, that these relations should be part of and associated country with the associatedCities as their members and so on. Granted, keeping a generic tagging scheme requires some effort of tool developers, but this should in no way compel us not to do it. Burnus (talk) 12:34, 25 January 2015 (UTC)Reply
I oppose this proposal. Relation serves it purposes, can't see any profits without alternatives and migration plans. Most of relations are confusing for newbies. With such attitude, we will get discussion about deprecation of multipolygons eventually. nazgul5 (talk) 16:16, 25 January 2015 (UTC)Reply
I oppose this proposal. I like this relation and often used it in the past because it is a great way to avoid redundancy! Obviously, an easier usage in the newbie editors is necessary to increase its acceptance. Tumsi (talk) 18:08, 25 January 2015 (UTC)Reply
I strongly agree. A new user using iD shouldn't even see if the street name is associated by a tag or a relation in the first place. Ogmios (talk) 21:04, 25 January 2015 (UTC)Reply
I approve this proposal. We should focus on only one address scheme. Address data is in my eyes the most important information after the road network. Adding and editing address data should be as simple as possible, especially for beginners. Therefore we should not use relations for address data. --Klumbumbus (talk) 20:25, 25 January 2015 (UTC)Reply
I would like to express a degree of incredulity at this proposal. Where are the discutions ? Into the vote ? Amazing way to debate ! Is the maintainability of such relation in question ? We just revert a tag building=yes put by ID on a boundary. Must we deprecate relation boundary, because there are difficult for newbies ? Amazing way to approach a problem ! Yes really amazing : voting without discussion, giving a solution without thinking FrViPofm (talk) 20:36, 25 January 2015 (UTC)Reply
I oppose this proposal. While I personally don't like associatedStreet relation, I think deprecating it in such way will not do any good. Also I strongly support ones who think we should map address information through relations. Yes it slightly more difficult for newbies, but I think their advantages outweigh greatly. In my opinion we should deprecate it through development of a new scheme (probably further refine street relation) with several solved problems (e.g. buildings with several addresses, corner houses, addresses for areas not buildings, etc.) and consideration to regional differences (so ideally communities should describe address systems in their respect countries with examples of difficult cases). Also I think it would be good to develop relations schemes which will form full graph of address information from country level to buildings and entrances. --Newpavlov (talk) 01:09, 26 January 2015 (UTC)Reply
I oppose this proposal. I just started mapping adresse in Italy with AssociatedStreet and I find it of simple use, having placed the housenumber nodes without other attributes and adding the relation the work is simpler and faster -- Rallysta7409:55, 28 January 2015 (UTC)Reply
I approve this proposal. This relation is not really needed and introduces additional complexity and overhead, benefits are too weak to justify it. Mapping the addresses correctly and uniformly is really important for OSM, so let's keep this part of the mapping as simple and intuitive as possible. --HybridOL (talk) 09:34, 30 January 2015 (UTC)Reply
I oppose this proposal. It's easy to create on modify relations with JOSM. When I have a short street, I don't use relation, but when I have a complexe case T use the relations. When an other user have created or not a relation, I don't change his work. -- Lenny (talk) 22:22, 30 January 2015 (UTC)Reply
I approve this proposal.The aim of OSM is to provide a streetmap. If the data-modelers agree with this aim, its their duty to attract a huge deal more mappers - especially in rural areas. But If the very vast majority of the mappers does not understand the associatedStreet or find it hard to use, then this is bad for our aim. If we want to scare them away, we should use the complicated modell aS, because they cannot maintain it. Keep in mind that they do not handle data in their job. I bet with the complicated modell OSM had less than a tenth part of adresses in hand-edited regions. I approve because I do not want this. Further I approve the proposal for the majority of mappers who cannot understand aS. Because of that they cannot take notice of the discussion and the vote. Thus please deprecate aS. -- Tirkon (talk) 20:37, 2 February 2015 (UTC)Reply
I oppose this proposal. Duplication of data always leads to the problems. This relation is a good way to eliminate it. Vort (talk) 06:26, 8 February 2015 (UTC)Reply
I would like to express a degree of incredulity at this proposal. As many said it seems that there was no discussion. I also don't understand why there is two relations (associatedStreet and street) for the same thing, and why we would depreciate this one and not the other one. --IamSylve (talk) 17:27, 27 February 2015 (UTC)Reply
I oppose this proposal. It's harder for newbies, but this should be made easier by software, relations are always more difficult, but removing them because of that you have to remove all relations. I think it handles in a clean way names, there are some street names that could be written in lots of ways, because of wrong spell, short or long form, adding or not the street type ("St.", "Av.", etc.), I give you an example: San Martín, José de San Martín, San Martin, General San Martín, Av. Gral. San Martín, General José de San Martín. Couldn't we have a dual mode? I mean, default way is addr:street, but if some user wants to make relations just let him. --Pertile (talk) 20:33, 8 September 2015 (UTC)Reply
Voting closed
Voting on this proposal has been closed.
It was rejected with 45 + 4 votes for, 40 + 10 votes against and 0 abstentions.
{{OK}} has been recorded as yes and {{vote|wat}} as no. Many thought this type of voting is too unofficial, next time a separate proposal should be used. The best tool for opinion polls is Umfrageplatform.--Jojo4u (talk) 11:46, 9 September 2015 (UTC)Reply
"Pros and Cons" section
Latest comment: 11 years ago11 comments4 people in discussion
User Vincent De Phily added a pros&cons section to the feature page. I don't agree with the contents of that section.
"It handles renames and multilingual names automatically (no contributor awareness needed) and prevents typos"
This is wrong, because the multilingual names belong to the street segements and (according to the feature page) to the relation too. So there's plenty of redundancy anyway.
There's no redundancy. The names *are* on the street segments. The relation's name tag is not address data, it is optional and only useful to help mappers pick the correct relation in the editor window. Vincent De Phily (talk) 21:39, 23 January 2015 (UTC)Reply
"It can be created before the street name is known (for example during armchair mapping before a survey)"
This is wrong, because if you don't even know the street name, you don't know the housenumbers either. Neither do you know which housenumbers will relate to which street.
Times by times, by adding street address from open data set there is difference in name (typo), relation allow a more clean way to deal with, avoiding to duplicate uncertain data. Frodrigo (talk) 23:26, 22 January 2015 (UTC)Reply
I stand by this one too, I use the technique all the time, Bing-tracing buildings in JOSM before surveying housenumbers with vespucci. House "assignment" mistakes can happen, but that's the usual armchair mapping caveheat. Often, a survey will reveal housenumbers/names but not street name. Besides, knowing which house relates to which street is useful information by itself, even if the street name and/or the housenumber isn't known. Vincent De Phily (talk) 21:39, 23 January 2015 (UTC)Reply
"It can help to route to the correct street segment"
No, it can't. The relation contains all segments of the street. (The feature page says: "more than one way possible if they are the same street, just have been split for mapping reasons")
Yes it can. Multiple ways per relation is optional, not mandatory. And the "find point on street nearest to the housenumber POI" algorythm can pick the wrong street segment is some (admitedly rare) cases. Vincent De Phily (talk) 21:39, 23 January 2015 (UTC)Reply
"It can take more time to create (depending on editor and skill), but takes less time to maintain"
Why does it take less time to maintain? This is just an unproven claim.
Once the relation is create you can manage all component of the street at once, no need to seek parts, dig into misnamed element, missing tags on some part and so on. Frodrigo (talk) 23:21, 22 January 2015 (UTC)Reply
Any maintenance that has to do with changing the street name is a no-op with relations. For other cases it's murky (that's why this point is tagged yes/no). I've updated the description, is that better ? Vincent De Phily (talk) 21:39, 23 January 2015 (UTC)Reply
"While tagging an simple object is supported by almost every editor, the usage of relations is not supported by every editor."
I'm curious as to which general-purpose editor cannot edit relations. And since relations are used everywhere, not just for addresses, editors that don't support them are either purposefully very restricted (ie not general-purpose) or very bad news for osm. Vincent De Phily (talk) 22:04, 23 January 2015 (UTC)Reply
I don't think most mobile editors can. And yes other are often purposefully restricted, but that's even more of a reason to tag addresses in a simple way, because that's exactly one type of information those editors need, use and imput into the database. --AndiG88 (talk) 12:55, 24 January 2015 (UTC)Reply
Xxzme added: " It is easier to track if house X was ever part of some street by examination relation history, but harder to track street history based on house history "
I do not agree. (1) OSM is no historic geodatabase. (2) Object IDs at OSM are no hard, static IDs. They may change by time.
Latest comment: 9 years ago6 comments5 people in discussion
It seems to me that all the voters against this proposal are against using simple address nodes without relations. On the other hand, half of the voters in favor of this proposal are advertising the use of address nodes without relations, and the other half just wants to replace type=associatedStreet with type=Street. There should be 3 choices in this vote instead of a simple yes vs. no. --PiRK (talk) 06:22, 23 January 2015 (UTC)Reply
"Should mapping addresses using associatedStreet relations be declared as 'deprecated'? If the majority says Yes, relations (type=associatedStreet and type=street) should not be used to map new addresses anymore. Existing associatedStreet relations should be replaced by addr:street=* on the nodes/buildings slowly, not mechanically." --Nakaner (talk) 12:46, 23 January 2015 (UTC)Reply
In that case there are at least 5 misguided yes votes to be ignored (the ones in favor of keeping relations type=street). --PiRK (talk) 16:17, 23 January 2015 (UTC)Reply
You are not right when you say If the majority says Yes, relations (type=associatedStreet and type=street) should not be used.
Using this wording -- "Should mapping addresses using associatedStreet relations" -- the proposal says about type=associatedStreet relation and nothing more. If the majority says Yes, we should deprecate just associatedStreet relation in favor of no-relation style mapping, or using another relation (type=street or another) or any different method. --Surly (talk) 09:32, 24 January 2015 (UTC)Reply
That informal poll has a much too low participation to be conclusive when there are thousands contributors using one or the other solution, or that suppprt both options (which have their own interest). In addition you cannot conclude globally, because how addresses are represented is highly dependant on national usage (i.e. per country). The actual decision cannot be made on this page, but on relevant pages for each country (and most of this is discussed in fact in their local mailing lists or local communities).
So please avoid reaching such global consensus. Leave each country decide themselves what is their best interest and on local practices. I think that both options are valid, and many tools can work using both models simultaneously.
However, if a street has a relation for addresses, all referenced nodes or ways should no longer tag the addr:streetname (just the addr:housenumber), to avoid conflicts and simplify the maintenance. Relations are used for excellent reasons, but also because maintenance of billions addresses is a major issue and redundance of information in massive amounts of data does not really help (and this is really a caase where absence of tagging for street names and cities causes significant errors if this info is infered by an purely geometry-based heuristic. Streets by themselves exist as distinctive objects in many open data sources, independantly of the number of houses that may be located in them, and streets frequently belong to several cities, and are also frequently split into multiple discontiguous segments (separated for example by square places or roundabouts, or by another work passing through their middle). Streets are highly evolitive objects whose geometry constantly change independantly of houses referenced in them.
So keep both approaches: the simpel tagging can solve many simple cases, street relations solve all other problems and then help maintenance and it is a quite simple and natural evolution, but that is not required everywhere. Note also that addresses are basivally only nodes, not houses: many building have several addresses, or do not participate to addresses of the neearest street, or have parts located in different cities, but all referenced at the same address in only one (it is in fact impossible in many cases to define a polygon, and the building polygons are wrong, most often too small to cover what would be needed (which also includes parts of the physioal surface covered by the public street, up to the middle materialized by central ways somewhere in their middle.
Note also that there are disagreements about using building ways for addresses and about the placement of the node (on the border of the building or on the limit of the private property, at the public access point or at postboxes or frontdoors or gates). Most official opendata use nodes located at the limit of a private parcel, but independantly of accesses (so they may be located on a closing fence, and they are generally aligned along the central way of the public street, and more regularly spaced). Then when it's not evident to whichc address node we can attach a building or other object, additional addr:* tags may be added to disambiguate them (notably for use as contact addresses), and in case of disagreement these additional tags have lower pritoryt if we just look for addresses for general use (we can discard duplicates created by building tags: the set of address nodes however should be exhaustive, independantly of building located nearby or over these nodes).
So I maintain the option of statu quo on this global page and keep both (this is also the most open solution that will satisfy more people): this is not the proper place to decide it when almost all contributors completely ignore this talk page and have discusssed it in more relevant places for each country. And taking global statistics as arguments is complete non-sense when countries have very different coverages and needs. — Verdy_p(talk)11:47, 23 February 2017 (UTC)Reply
Clarify role of associatedStreet-Relations for QA tasks
Latest comment: 11 years ago1 comment1 person in discussion
Quite a lot of no-voters (apparently from the French OSM community) mentioned the use of associatedStreet-Relations for some QA tasks and report that some tools will break / no longer function without those relations.
Please pardon my ignorance, but can you give some more detailed hints as to which tools those are, how they basically work and other assumptions (e.g. will work best with some OpenData import, etc.). I guess not everyone is accustomed with those tools. Other local communities might use completely different approaches and don't rely on those relations at all for QA tasks.
I think these geographical distribution maps also clearly show that a overwhelming majority of people don't use this relation. It is mostly appears on isolated areas where a few mappers use it. I looked closer at Bavaria and there are like 5 cities where the tag was actually correctly used (not necessarily extensively!), all the other small dots where usually just a single relation, often 3-5 years old and incomplete or relicts from the JOSM Terracer bug --AndiG88 (talk) 18:15, 25 January 2015 (UTC)Reply
Abandoned
Latest comment: 7 years ago5 comments4 people in discussion
It seems the main wiki page is abandoned and the state is not clear. It still advertises the closed vote of 2015 for participation. Can someone enlighten what the state of the associatedStreet relation is? I know its used by mappers. What support do the consumers have? Nominatim, OSMAnd, MAPS.ME? In Milano we had a discussion and it seems support for relations other than Multipolygon is basically broken everywhere. I dont like the associatedStreet relation. I have tried them but its basically a lot more work to keep track of the relations than to simply produce self contained address enabled objects. Yes - Its a little redundancy but i currently use that redundancy to check for errors. Flohoff (talk) 13:33, 29 November 2018 (UTC)Reply
For me it is clear that associatedStreet lost and has limited use. But while I am 100% sure that it is considered as unwanted in Poland I am not sure how it generalizes to other regions Mateusz Konieczny (talk) 17:02, 30 November 2018 (UTC)Reply
Latest comment: 5 years ago66 comments60 people in discussion
In Germany, mappers are discussing about whether associatedStreet-Relations should be deprecated in Germany. I want to discuss this here as well before editing the German wiki-page.
We would like to collect opinions until April, 15th 2019.
I approve this proposal. Ich denke, es ist zumindest in Deutschland überflüssig und sollte auf der Wiki-Seite (zumindest DE) so gekennzeichnet werden. --Theodin (talk) 10:42, 07 April 2019 (UTC)Reply
I approve this proposal. Ich würde es auch als überholt ansehen und es sollte auf der Wiki-Seite (zumindest DE) so gekennzeichnet werden. --Geri-oc (talk) 08:42, 13 March 2019 (UTC)Reply
I approve this proposal. Meinem Vorstoß in der Sache aus dem Jahr 2015 kann man meine Argumente gegen diese Art von Relationen entnehmen. --Nakaner (talk) 22:09, 22 March 2019 (UTC)Reply
I approve this proposal. Gerade eben, bei einer entsprechenden Aufräumaktion, war ein Haus in einer Relation, das zu einer komplett anderen Straße gehörte. Dies ist eines unter vielen Beispielen, dass es schwierig ist, diese Relationen zu pflegen. --glglgl✉14:19, 2 April 2019 (UTC)Reply
I approve this proposal. Es ist gute Lösung wenn mal Straßen umbeannt werden, aber die Fehler die dadurch passieren sind wesentlich größer. Die Verarbeitung der Daten ihne die Relation wird somit auch einfacher. --Christopher (talk) 10:01, 14 April 2019 (UTC)Reply
Feedback from other community members on this vote
I oppose this proposal. While I probably have no vote in Germany, I think removing the relations is a big mistake. Yes they are practically abandoned, but WHY? Well, I can tell you why I have stopped creating those relations, after a few experiments - because the main reason to have those relations is a possibility to show a street as a whole when searching for the street, AND NOMINATIM IGNNORES THESE RELATIONS. So why create relations if they are not used then and search for a street still returns plenty of pieces, but not a street as a whole? But that's not a reason for abandoning relations, because they are still the only way to keep the street together; it's a reason to update Nominatim so that it shows the relation first if it finds one. Then it will make sense to keep the relations and people will use them again. --Rmikke (talk) 13:56, 31 March 2019 (UTC)Reply
@Mmd: That's... impressive, for sure. Is there a way to use it in Nominatim so that when asked for a street, it returns a street? Because, you see, the problem is not that it's not possible to collect all the pieces. The problem is that our default search engine returns pieces. I was thinking of relations, because it seems easier for the search engine to prefer relation over way, but maybe your way is better. Anyway, please don't remove this demo, it's useful :) Rmikke (talk) 19:31, 25 May 2020 (UTC)Reply
I oppose this proposal. I am not German, but I don't see the need to localize this vote. Either associatedStreet does not fit the OSM model and IRL entities for most of the world, or they do. Looks like a divide and conquer move.
Well, "most of the world" doesn't use those relations (see https://taginfo.openstreetmap.org/tags/type=associatedStreet#map). I believe, in France many of those relations have been automatically added by some script. Chances are that they are never touched again, and therefore break less likely. In Germany, that's different: they have to be manually maintained, and frequently break or are outdated. That's why a large majority of mappers opted to get rid of them. Mmd (talk) 20:10, 4 April 2019 (UTC)Reply
Taginfo does not display relations on that map, so the difference isn't actually quite as dramatic as it seems. But yes, associatedStreet relations are relatively uncommon globally, with addr:street tags outnumbering 'house' members 20:1. --Tordanik19:30, 7 April 2019 (UTC)Reply
I approve this proposal. associatedStreet are overly complex method compared to alternative, without any real benefits (I expressed my opinion after creation of separate section). Data consumers may easily merge entire street in results (using name=* tags) Mateusz Konieczny (talk) 16:58, 5 April 2019 (UTC)Reply
An overwhelming majority of mappers in Germany voted to deprecate associatedStreet-Relations in Germany. Since April 15th 2019, 16:00 none of these relations exist anymore in Germany.
A house that is a relation
Latest comment: 3 years ago2 comments2 people in discussion
Question: Can I add a house that is a relation to an associatedStreet relation? Some of the buildings may contain an inner part or more than one outer contour. — Grass-snake (talk) 19:32, 24 August 2022 (UTC)Reply
I oppose this proposal. of course not Barbos
I approve this proposal. Yes, associatedStreet should be declared deprecated --Gormo (talk) 08:54, 21 January 2015 (UTC)
deprecated ... at least no NEW relations of that type are needed in theOSM data. --Stephan75 (talk) 17:54, 21 January 2015 (UTC)
I would like to express a degree of incredulity at this proposal. With it's current usage (~20% of addresses) and position as the primary means of mapping addresses in some regions, it will continued to be used for new addresses and data consumers will have to support it if they want to parse addresses. Pnorman (talk) 10:15, 22 January 2015 (UTC)
Relation: associatedStreet
Relation: associatedStreet
Relation: associatedStreet
addr:street
to an associatedStreet relation? Some of the buildings may contain an inner part or more than one outer contour. — Grass-snake (talk) 19:32, 24 August 2022 (UTC)