On Thu, 23 Apr 2020 at 15:08, Martin Koppenhoefer <dieterdre...@gmail.com> wrote:
> > Am Mi., 22. Apr. 2020 um 14:12 Uhr schrieb Paul Allen <pla16...@gmail.com > >: > >> This is all true. And in an ideal world we'd map the building and its >> occupying >> object as two separate-but-coincident objects. This isn't an ideal >> world. :( >> > > >> Problem 2: Duplication of address info. The building has an address >> irrespective of the occupying object. But it is convenient for >> consumers querying the occupying object to get the address of >> the occupying organization in a single step. "Don't repeat yourself" >> is a good maxim, but one we must flout with coincident objects. >> Unless you want the pain of not putting an address on the building >> if it is occupied, but transferring the address from the occupier to >> the building prior to deleting the occupier when the building >> becomes vacant. >> > > > I do not see why you would have to remove the address information from the > building when you add it to another object with the same address (like a > shop). > DRY. Having the same address info for the building and the business makes it more likely that if the information is found to be incorrect only one of the copies will be corrected. I've had to fix enough addresses (mainly incorrect postcodes but sometimes incorrect or missing street names and even cities) that having the same information in two places is undesirable. The more so when that same information is on coincident polygons that iD makes hard to manipulate, or even notice. On a sidenote, while it may not be desirable from a "clean" database > approach to have duplicate information (when the enclosing building has an > address, you will not have to repeat the same information on the contained > objects), > It makes it easier on consumers querying objects. Who may not know that they queried a node for a business without an address because the address is on the enclosing building. it could also be seen useful redundancy that strengthens the stability (if > you have verified the address information for the business, even if someone > "adjusts" the positions of the buildings and oversees the POIs, you will > still have the correct address on the POI. > But there are cases where using a node rather than a building (not just an area but a building=*) for a POI means the name doesn't get rendered. Clubs and crafts, for example. > I.e. explicit tagging is more reliable, and can be seen as a confirmation > that the information has been actually verified, compared to a POI without > addressing information lying inside a given address boundary (think about > someone placing a POI by memory roughly where it should be). > That's just another reason why people tag the same object as both a building and a business rather than making it two objects. It makes clear that there is a relationship between the two rather than it possibly being an accident. Each approach has benefits in certain situations. I don't think any of them deserve the "You must not do it that way" injunctions we sometimes see here. -- Paul
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
