2018-05-11 10:53 GMT+01:00 Martin Koppenhoefer <dieterdre...@gmail.com>:
> May be it would be good to have a relation to keep in only one place an >> address and link there the affected elements: entrances, buildings, POI's >> and area for this address. This would be necessary only for some cases like >> a building with many addresses/POI's. The simplest use cases would be done >> as usual. Looking the history of the associated_street and street relation >> may be this idea is too controversial so opinions are appreciated. >> > > We could add relations to model which addresses belong to which POI (and > this would also work for multiple addresses for one POI), but it really > isn't the same as stating the address the POI is _using_, because it might > "have" several entrances (and windows) with addresses but use only part of > them (i.e. we would need roles to say which addresses lead to the POI, and > which is the "official" address of it, the one on it's website, business > register, receipt, advertising etc.). This would be a lot of relations for > something that can be easily modelled by adding the address property as > used by the POI to the object and be done. From the relation you will not > be able to construct actual address strings like "Foo Street 33-35" because > this could mean things like "33A, 33B, 33C, 35" or "33, 34, 35", or "33, > 35", etc. > > Even for simple cases, I would like to tag whether they are representing > an entrance (entrance=yes/main or barrier=gate) or not (entrance=no, these > are either windows or former entrances now closed or potential future > entrances, and on top of this, situations that shouldn't get a housenumber > according to current legislation, but already have one). I am also > interested in adding details like level=1 (I see the absence of level as > level=0 and the default, but add level=1 for first floor entrances. This is > useful to understand situations where the sequence of numbers seem "odd" on > the map, but actually are accurate). > > Cheers, > Martin > The kind of relation I have in mind is a type=address relation with the usual tags for an address (addr:*). A quick sketch of the members could be * role=plaque, cardinality=0-1 for a node near where the house number plaque is located. This member will be present only if exists a plaque with the number. This node could have the entrance=*, barrier=*, door=*, wheelchair=*, etc. tags if the plaque is associated to an entrance or not, like in [1] * role=to define, cardinality=0-many for the features related to this address. This could be buildings, features like shops, a landuse area, etc. Generally the current schema will still be used. The address relation will be necessary only for this: * If you have many features associated to an address and you can't draw the actual limits of a enclosing area to put the address or you want to use a node for the reasons mentioned. Then we will have one relation. * If you have many addresses for a feature. Then you will have as many relations as plaques found. The case of the official address you mention could be stated in the role. Lets see a real world example, like the Empire State Building [2]. We have one address in the building footprint and many others in nodes you can see inside the footprint (and even two of them outside, making it hard to associate them). The 350 of 5th Avenue it's repeated in many POI's. This give to inconsistency: **there are three different addr:postcode values**. It would be solved moving the addr:* tags to one relation with the POI's as members. The building have the number 2 in the West 34th Street, with the next building having the 22 housenumber. Similar for the West 33rd Street, and in the 5th Avenue the building is between 326 and 362 housenumbers, so I think that the building have many housenumbers associated in each street. Only to clarify the example, we can confirm this at [3], this entrance give access to housenumbers 1 to 25. With the actual scheme, to improve this I would move the address node [4] to this point with the entrance=main tag and using addr:housenumber=1-25 and similar for the other two streets. With the proposed relation, I would create a relation with this tags type=address addr:housenumber=1-25 addr:postcode=10018 addr:street=West 33rd Street With the entrance, building and POI's (when present) as members. Each POI could have tagged their individual addr:housenumber=n. The consumer will get the full address for a POI from: * The addr:housenumber of it (only present the addr:* tags that differs from the parent address relation * The addr:* tags of the parent address relations * Can complete it with the name or addr:housename of the building if it's only one. The final number of relations needed will be one for entrance with plaque. I think it could be possible three, one for each street. [1] https://goo.gl/maps/yTDHWbVuRWF2 [2] https://www.openstreetmap.org/way/34633854 [3] https://goo.gl/maps/gen2q28NvfB2 [4] https://www.openstreetmap.org/node/2709306512
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
