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). While it may be true from a city council point of view, that every address is only assigned once to a building/site, it isn't implying we cannot have the same address properties for several OSM objects. For example in Italy, where housenumbers are assigned to entrances rather than buildings or sites, it is inevitable to repeat the same address information when there are several businesses with the same entrance door (it is not practical to draw polygons for addresses because the same place will typically have several entrance doors and you may not know which addresses are leading to which space, or which address is the one the business is using (if there are several possibilities). It would also seem crazy overkill to create relations between entrances (assigned addresses) and occupying uses, just to avoid repeating address information. 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 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. 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). > And introduces problem 3: some > types of entity render if they have an area and building=yes > but do not render (not even a label) if they are nodes. Clubs and crafts > are two examples I can think of. As for healthcare=alternative, if > the building has an addr;housename then that is used as the label > rather than the name=*. > > Our tagging practices are heavily influenced by the limitations of > the tools we use... > IMHO looking at the details which tool supports which way of representation is not helpful. Map as you believe is "best", thereby also adding more incentive for the people who build rendered maps or editors, to cater for this way of mapping. You should not care whether the current OSM Carto visualizes areas, nodes or both. It may change at any time, and there will be many other applications that will support nodes (or areas). Cheers Martin
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
