On Mon, Jan 7, 2013 at 5:20 PM, Sander Deryckere <sander...@gmail.com> wrote: > If it's administrative, it's not necessarily the closest. I have given an > example of it, but there are multiple examples, like for this house: > http://www.openstreetmap.org/browse/way/174076563, it's in gemeente Staden, > but all streets around it are in gemeente Roeselare. So you can't add those > streets to the associatedstreet relation if it's administrative. Unless all > driveways should also be part of the relation.
So, this house has the official address "Groenestraat 42, Staden", but the driveway opens on "Groenestraat, Roeselare"? And the problem is that if you add it to the associatedStreet, the house will look like it's in Roeselare, right? That is tricky, but the problem is not the relation linking the street and the house, but that the relation is tagged as being in Roeselare. Or have I misunderstood your explanation? >> Or are you all really only interested in associatedStreet as a >> gathering point for the common information such as postcode and >> country? > > I thought so, as it's a general recommendation to not use relations where > spatial queries can be 100% accurate. Administrative stuff can't be 100% > accurate queried, closest street can. 'Closest street' is 100% accurate, but the street a house belongs to is not necessarily the closest one, especially if you were to consider a street that crosses a town boundary to be two separate streets. To take a similar problem, if you have a house that is divided in half by a postcode boundary, how do you determine in which postcode the house belongs? This is the kind of problem I had in mind when I said, in my first mail, that such a search was "not necessarily accurate". I do see your point that you shouldn't tag what you can find in a 100% accurate search. Of course, that leads me to the question of "Why do we add addr:city at all, assuming that every house is fully within a city's boundaries?" _______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
