The problem is not that it is duplicated. It’s that something that is supposed to be grouped is not. Someone might now just change one relation and overlook other ones. If I would change addr:street on that scale, I would just filter that area with JOSM and replace all tags in a few seconds. Also my main point is not that addr:street won’t make you overlook anything, but that associatedstreet relations are nowhere near as perfect as people claim they are.
First of all, it’s not clear what an associated street is. Is the street still associated when it crosses a municipality border, or when different parts get different postcodes? Do cycle lanes belong to it? And what about driveways? That relation is trying to bring structure to something that doesn’t have a unified structure on it.
Secondly, it makes “upgrading” addresses from points to buildings hard. When only tags are used, it’s quite simple to copy the tags from the node to the building, and erase the node. When relations are used, there are more actions needed. You still need the copy operation to bring over the house number (and perhaps other tags s.a. shops or amenities), but you also need additional work to search for the right relation in the list (which can become a long list), and add your building to it.
What’s wrong with that screenshot ? Multiple AS for the “same” street can be usefull, it’s up to the contributor to decide wether it is or not. The “easyer to change street names” quality still applies. With addr:street you’d get even more duplication, and finding all houses associated with a street require a search instead of 2 clicks.
I’m not sure what the title has to do with the image. It’s obvious that changing the name on six relations is easier than changing it on 62 nodes. That being said, it would be even easier if it were just one relation.
What the image shows is addresses mapped as nodes in the middle of buildings. In my opinion the address should be on the building. If there were no buildings then address nodes would be fine but having both is confusing.
@Vincent de Phily, so instead of looking of 1 associatedStreet relation to change the name of a street, I now have to find multiple relations ? Isn’t that a search ? The same thing you criticize for addr:street ?
And further there is no guarantee that the associatedStreet is complete, maybe there are “loose” address nodes that have to be updated as well. Without associatedStreets, a simple find will locate all addresses that have to be updated, with associatedStreets you’ll never know. Some might have the addr:street tag, some get there address through the relation
Since you are in favor of associatedStreets, you might now whether there is a QA-tool that checks whether there are “loose” addr:street nodes and marks them as errors ? If this is not checked, the completeness of an associatedStreet-relation can be broken at any time, leading to a more complicated method to update simple typos in streetnames
You don’t have to touch the relations at all to update the street name. Go ahead and remove the name tag from the relation if it bothers you, it’s only cosmetic, it’s used neither for routing nor for rendering. And hey, maybe the rename is only for one section of the road, with the original mapper having wrongly assumed that all the streets were named the same. Happened to me more than once.
Concerning “loose” addresses: mixing two tagging schemes on one street is going to be more work, so don’t do that. Consider the pros and cons of each scheme individually.
No matter how you put it, that “simple find” is always going to me more work than “two clicks” or “nothing” (depending on the modification you’re doing).
QA tools such as osmi handle missing/mismatched street addresses just as well for both schemes.
Rationale behind associatedstreet deprecation is simple: there no need for 3 different schemes
1. Karlsruhe Schema
2. relation associatedstreet <- ban this thing
3. relation street
There no definition in associatedstreet how custom tags should be applied to each member of associatedstreet.
Actually relation:street may work for some regions and definitely not for places like AndiG88 shown.
I’m not sure what the title has to do with the image. It’s obvious that changing the name on six relations is easier than changing it on 62 nodes.
Except with JOSM it isn’t. If I have to filter an area for 6, 62 or 1000 nodes doesn’t matter. It’s exactly the same amount of clicks.
And even with ID I rather check those addr:street tags than finding those 6 relations.
@Peter Mead One building can easily have more than one address, so there is a real need to map some addresses as nodes. Address nodes also have the advantage that they can indicate an entrance: eg an apartment building can have two adresses, with entrances quite far apart. So I’d just map all addresses as nodes.
@d1g I’d certainly defend keeping only one of relation:street and relation:associatedStreet, but the relation:street doesn’t have much of a technical advantage and is 10x less popular. So ‘street’ would be the one to go.
@d1g There’s no documentation of what tags to apply to the members because there’s nothin special abou them. IMHO the relation itself shouldn’t have any tag other than “type=associatedStreet”, and editors should be able to grab the name from the street member for display purposes.
@AndiG88 I really don’t understand your issue with the workflow. If you’re willing to search, you’ll find all objects (house, street, relation) in one go with both schemes, there’s no difference here (or if you want to nitpick, the addr:street schema makes searching more complicated because you need to search for either name=* or addr:street=*). And in many cases you don’t need to search : you just click on the street or house, then on the relation and voilà - all the info you need.
I think that the vague definition of associatedStreet is also causing a lot of different unfulfilled expectations. I have read that that people put all street names and translations on the AS so they only have to change it once, some people still create multiple AS for each street segment. Other people hope that Nominatim takes the street name of city of the AS in case it is mentioned there.
Vincent now turns it in to a collection relation of all objects with the same addr:street.
In order the be useful, the definition should me much clearer, the editing & QA tools should give better support, more data consumers should use it, etc.
Since addr:street provides more or less solutions for all of this, why should I bother with AS ? (rhetorical question)
It’s clear that there is some uncertainty around AS that harms its adoption. That should be fixed, but right now the debate has become so entrenched that any wiki edit feels like a political statement.
However, I am not turning it into a “collection of all objects with the same addr:street”. AS members by definition don’t have an addr:street tag.
Your rethorical question is also plain trollbait, as the pros and cons have been largely debated and each scheme has good arguments. AS handles some usecases that addr:street cannot; the workflow and newbie-friendlyness has been debated to no end with no clear winner (not because people aren’t convinced, but because they are convinced by opposed conclusions).
At this stage, please realize that neither AS nor addr:street is going to be deprecated or dissapear from the db. Keep calm and carry on mapping using your prefered scheme. Go improve the tools and the documentation.
I’ll admit that changing the wiki page right now is not a good idea. It’s even difficult to start a discussion on how a good AS should look like at this moment.
Please note that I have added many AS in the past ( maybe >100), but given the current set of tools (e.g. the terrace plugin in JOSM), other people that do not keep AS up to date, the fact that the Belgian community decided to have addr:street on the nodes anyhow, people complaining about my tagging because KeepRight (?) did not recognized AS and insisted on addr:street, validation problems with streets with multiple names, POIs that repeated housenumbers, and maybe some other causes, I stopped creating them. AS just slowed me down without giving me something back
So for me there were more disadvantages than advantages, that’s maybe a better explanation for my rethorical question above
I still like the idea behind AS, but don’t see how the benefits hold when there is an alternative way that has to be supported (see my remark on Belgian convention).
OpenStreetMap
Discussion
Comment from gileri on 24 January 2015 at 19:30
I’m not sure if this post is just for the laughs, but just in you are trying to get a point across :
The name would have been duplicated even more, so the problem would have been the same…
Comment from gileri on 24 January 2015 at 19:31
(I meant without associatedStreet, silly me not reading my post before posting)
Comment from AndiG88 on 24 January 2015 at 20:59
The problem is not that it is duplicated. It’s that something that is supposed to be grouped is not. Someone might now just change one relation and overlook other ones. If I would change addr:street on that scale, I would just filter that area with JOSM and replace all tags in a few seconds. Also my main point is not that addr:street won’t make you overlook anything, but that associatedstreet relations are nowhere near as perfect as people claim they are.
Comment from Sanderd17 on 24 January 2015 at 22:47
I don’t like AS relations, but for other reasons.
First of all, it’s not clear what an associated street is. Is the street still associated when it crosses a municipality border, or when different parts get different postcodes? Do cycle lanes belong to it? And what about driveways? That relation is trying to bring structure to something that doesn’t have a unified structure on it.
Secondly, it makes “upgrading” addresses from points to buildings hard. When only tags are used, it’s quite simple to copy the tags from the node to the building, and erase the node. When relations are used, there are more actions needed. You still need the copy operation to bring over the house number (and perhaps other tags s.a. shops or amenities), but you also need additional work to search for the right relation in the list (which can become a long list), and add your building to it.
Comment from dcp on 26 January 2015 at 06:30
Like Sanderd17 I see no advantage in using associatedstreet relation and for exactly the same reasons. Get rid of it!
Comment from Vincent de Phily on 26 January 2015 at 13:17
What’s wrong with that screenshot ? Multiple AS for the “same” street can be usefull, it’s up to the contributor to decide wether it is or not. The “easyer to change street names” quality still applies. With addr:street you’d get even more duplication, and finding all houses associated with a street require a search instead of 2 clicks.
Comment from Peter Mead on 26 January 2015 at 15:31
I’m not sure what the title has to do with the image. It’s obvious that changing the name on six relations is easier than changing it on 62 nodes. That being said, it would be even easier if it were just one relation.
What the image shows is addresses mapped as nodes in the middle of buildings. In my opinion the address should be on the building. If there were no buildings then address nodes would be fine but having both is confusing.
Comment from escada on 27 January 2015 at 07:46
@Vincent de Phily, so instead of looking of 1 associatedStreet relation to change the name of a street, I now have to find multiple relations ? Isn’t that a search ? The same thing you criticize for addr:street ?
And further there is no guarantee that the associatedStreet is complete, maybe there are “loose” address nodes that have to be updated as well. Without associatedStreets, a simple find will locate all addresses that have to be updated, with associatedStreets you’ll never know. Some might have the addr:street tag, some get there address through the relation
Since you are in favor of associatedStreets, you might now whether there is a QA-tool that checks whether there are “loose” addr:street nodes and marks them as errors ? If this is not checked, the completeness of an associatedStreet-relation can be broken at any time, leading to a more complicated method to update simple typos in streetnames
Comment from Vincent de Phily on 27 January 2015 at 11:38
You don’t have to touch the relations at all to update the street name. Go ahead and remove the name tag from the relation if it bothers you, it’s only cosmetic, it’s used neither for routing nor for rendering. And hey, maybe the rename is only for one section of the road, with the original mapper having wrongly assumed that all the streets were named the same. Happened to me more than once.
Concerning “loose” addresses: mixing two tagging schemes on one street is going to be more work, so don’t do that. Consider the pros and cons of each scheme individually.
No matter how you put it, that “simple find” is always going to me more work than “two clicks” or “nothing” (depending on the modification you’re doing).
QA tools such as osmi handle missing/mismatched street addresses just as well for both schemes.
Comment from d1g on 27 January 2015 at 13:31
Rationale behind associatedstreet deprecation is simple: there no need for 3 different schemes 1. Karlsruhe Schema 2. relation associatedstreet <- ban this thing 3. relation street
There no definition in associatedstreet how custom tags should be applied to each member of associatedstreet.
Actually relation:street may work for some regions and definitely not for places like AndiG88 shown.
Local mappers should agree about usage in their local guidelines here: http://wiki.openstreetmap.org/wiki/Category:Tagging_guidelines_by_country
It was stated already that only few countries want to use this: http://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet#Geographical_Distribution_Maps
IMO we should definitely ban associatedstreet but leave relation street for some regions vie their tagging guidelines.
Comment from AndiG88 on 27 January 2015 at 14:14
Except with JOSM it isn’t. If I have to filter an area for 6, 62 or 1000 nodes doesn’t matter. It’s exactly the same amount of clicks. And even with ID I rather check those addr:street tags than finding those 6 relations.
Comment from joost schouppe on 27 January 2015 at 16:13
@Peter Mead One building can easily have more than one address, so there is a real need to map some addresses as nodes. Address nodes also have the advantage that they can indicate an entrance: eg an apartment building can have two adresses, with entrances quite far apart. So I’d just map all addresses as nodes.
Comment from Vincent de Phily on 27 January 2015 at 17:20
@d1g I’d certainly defend keeping only one of relation:street and relation:associatedStreet, but the relation:street doesn’t have much of a technical advantage and is 10x less popular. So ‘street’ would be the one to go.
@d1g There’s no documentation of what tags to apply to the members because there’s nothin special abou them. IMHO the relation itself shouldn’t have any tag other than “type=associatedStreet”, and editors should be able to grab the name from the street member for display purposes.
@AndiG88 I really don’t understand your issue with the workflow. If you’re willing to search, you’ll find all objects (house, street, relation) in one go with both schemes, there’s no difference here (or if you want to nitpick, the addr:street schema makes searching more complicated because you need to search for either name=* or addr:street=*). And in many cases you don’t need to search : you just click on the street or house, then on the relation and voilà - all the info you need.
Comment from escada on 27 January 2015 at 17:34
I think that the vague definition of associatedStreet is also causing a lot of different unfulfilled expectations. I have read that that people put all street names and translations on the AS so they only have to change it once, some people still create multiple AS for each street segment. Other people hope that Nominatim takes the street name of city of the AS in case it is mentioned there.
Vincent now turns it in to a collection relation of all objects with the same addr:street.
In order the be useful, the definition should me much clearer, the editing & QA tools should give better support, more data consumers should use it, etc.
Since addr:street provides more or less solutions for all of this, why should I bother with AS ? (rhetorical question)
Comment from Vincent de Phily on 27 January 2015 at 19:10
It’s clear that there is some uncertainty around AS that harms its adoption. That should be fixed, but right now the debate has become so entrenched that any wiki edit feels like a political statement.
However, I am not turning it into a “collection of all objects with the same addr:street”. AS members by definition don’t have an addr:street tag.
Your rethorical question is also plain trollbait, as the pros and cons have been largely debated and each scheme has good arguments. AS handles some usecases that addr:street cannot; the workflow and newbie-friendlyness has been debated to no end with no clear winner (not because people aren’t convinced, but because they are convinced by opposed conclusions).
At this stage, please realize that neither AS nor addr:street is going to be deprecated or dissapear from the db. Keep calm and carry on mapping using your prefered scheme. Go improve the tools and the documentation.
Comment from escada on 28 January 2015 at 09:57
I’ll admit that changing the wiki page right now is not a good idea. It’s even difficult to start a discussion on how a good AS should look like at this moment.
Please note that I have added many AS in the past ( maybe >100), but given the current set of tools (e.g. the terrace plugin in JOSM), other people that do not keep AS up to date, the fact that the Belgian community decided to have addr:street on the nodes anyhow, people complaining about my tagging because KeepRight (?) did not recognized AS and insisted on addr:street, validation problems with streets with multiple names, POIs that repeated housenumbers, and maybe some other causes, I stopped creating them. AS just slowed me down without giving me something back
So for me there were more disadvantages than advantages, that’s maybe a better explanation for my rethorical question above
I still like the idea behind AS, but don’t see how the benefits hold when there is an alternative way that has to be supported (see my remark on Belgian convention).