|
I tend to use associatedstreet relations instead of addr:street tags because I see a few advantages. One of the advantages is when a street is made of many different ways, nearby and often parallel (this is typical of housing estates). In this case, I use a different relation for each section of the street, which makes it unambiguous for a satnav that needs to route to a particular housenumber and might otherwise pick the wrong street segment. In those cases, I also tend to give each relation a distinct name : "streetname west", "streetname north 1", "streetname north 2" instead of a common "streetname" for all of them. As an aside, if a relation's name is equal to the street name, and is only useful to help mapper identify the correct relation in a list, then it seems silly to tag it : it would be better for the editor to display the member street's name directly. I decided to ask this question after a discussion with Pieren and realising that osmose flags multiple relations per street as error 2060. Obviously, some people frown upon multiple relations per street and/or relation names that do not match the street name. What do people here think about multiple relations per street and distinct relation names ? |
|
I can see a use of a single relation to simplify downloading all sections of a street, but cannot see a benefit of multiple associatedStreet relations. For any style of address tagging - with or without relations, a router will find the closest geometrically matched street segment as a destination. Routing problems begin when the street which is geometrically closest to the house is not the correct one to drive to. It's not that frequent but it happens. Often near a corner, a barrier, or a oneway segment, but can be anywhere. One of the original purpose of AS relations is to replace the geometry heuristic with something less ambiguous. So I guess it boils down to wether using multiple relations fixes some ambiuity.
(26 Nov '13, 14:56)
Vincent de P... ♦
|
|
Sad that you ask a question in English based on a discussion in French... and this help site is not the right place to talk about disputed stuff (better on the forum or one mailing list). Sorry, switched to English to reach wider audience. You're right, maybe ML would have been a better medium, it's just not one I'm as comfortable with. I never said that the relation name had anything to do with routing, not sure how you reached that conclusion.
(26 Nov '13, 18:03)
Vincent de P... ♦
You never state your view on the relation's name's purpose (only what its value should be). If the purpose is just "help editing", then using distinct names when there are multiple relations for one street makes logical sense to me. If (for whatever reason) the only accepted values are "absent" and "identical to the street's name", then I'd rather leave it out and let the editor figure out the display name automatically. Looking at a relation's members really shouldn't be hard ? Using a fallback if the member hasn't been downloaded is ok.
(26 Nov '13, 18:11)
Vincent de P... ♦
|
|
I like the idea of using associatedStreet to indicate routing, although I wonder if it couldn't better be done by adding in a driveway or similar structure. One assumes there is some kind of an access road or path, tagged correctly to indicate who can use it. Can you give an example of where the geometrically closest segment isn't the correct one? Creating a name for them, however, is, in my opinion, completely wrong. If the street isn't actually called that name, it shouldn't be tagged with that name. At most, you could put a more descriptive name for use by mappers in the note tag. here is a example where the geometry heuristic would get it wrong and would be fixed by using multiple relations (addresses not surveyed yet, I'm working on it :p). When I suggest using distinct name tags, it is of course for the relation and not for the actual street. AFAICT, the relation name's sole purpose is to help editing. It isn't processable "map data" per se.
(26 Nov '13, 17:52)
Vincent de P... ♦
|
|
In Belgium we use the associatedStreet in the same way as Pieren describes: containing all street segments and houses/address points. We also add postal code and city to the relation tags in the hope that we do not have to repeat them on every single building. (we do not have areas for the post code (yet)). The idea of the OP is completely different and will make it impossible for tool developers to know how they have to represent/use the relation. I hope that there will be only 1 unambiguous definition for the associatedStreet-relation. That sounds like the kind of counter-example I was wondering about, but I don't understand how multiple relations would "make it impossible for tool developers to know how they have to represent/use the relation" ? Can you give an example of how it makes things harder for tools ?
(27 Nov '13, 09:10)
Vincent de P... ♦
Because in our case the name of the street is the name of the associatedStreet relation and you "invent" a name. We want the tools to use the name of the associatedStreet relation, not the one on the road. This is needed in cases where a street has a different names on the left and right side of the street. This happens a lot when the street is the border between 2 villages.
(27 Nov '13, 11:03)
escada
How is the relation's name any better than the street's dual names in this case ? AFAIK nominatim uses the street name, not the relation name. Which tool uses the relation name ?
(27 Nov '13, 15:46)
Vincent de P... ♦
It seems that no tool uses the name of the relation. However, this is the way we interpreted the associatedStreet relation in Belgium. It would be nice that one does not have to repeat the name on the roads and the buildings, only once on the relation should be sufficient. Otherwise the relation is pretty useless IMHO. As I wrote, the street has two names, but the houses on either side of the street only have 1 street name. When you could put those houses together with the street segments in a relation and give that relation a name, postcode, city etc; one could form the complete address.
(28 Nov '13, 04:50)
escada
So you are not putting the name on the street but instead on the associatedStreet relation? Doesn't this break pretty much any tool out there?
(28 Nov '13, 06:24)
scai ♦
We still put the name on the street too, but if OSM was designed from the beginning with associatedStreets, we should not have to do that. Anyway, I described what we currently do with associatedStreets in Belgium, but since there is no support for it (read tools), I doubt whether I will continue to create them. Several people in Belgium will continue to use it the way I described: put name, postcode, city as tags on the relation and hope a tool (e.g. Nominatim) will use those instead of using other rules
(28 Nov '13, 07:14)
escada
showing 5 of 6
show 1 more comments
|
I wonder whether the routing aspect will actually get any better with relation(s). Most of the time you don't want to drive to a specific POI but instead to a nearby parking place, unless you travel by foot.
In many areas you can park right in front of the POI/house, and a nearby car park is not needed.