On Wed, 19 Aug 2020 at 04:26, Colin Smale <[email protected]> wrote:
> There are two use cases here: one is "what is the address of this building > (or whatever)" and the other is the reverse situation: "where can I find > number XXX". As long as we have tagging that is potentially ambiguous we > won't be able to cover both. > > In the US I know of cases where an apartment number can follow the street > address, i.e. 10-321 meaning Street Address 10, apartment 321. In Europe I > know of the suffix being used to indicate apartment number, or floor number > - e.g. 379-3 meaning Street Address 379, Floor/Flat 3. Sometimes other > characters are used for the floor/flat such as A/B/C or I/II/III - in these > cases it is unambiguous because it is non-numeric. > > On the other hand using the "1-5" notation to indicate a range is pretty > well understood in the UK at least. What it is missing is the > "interpolation" value (even, odd, all). > > So let us sort this mess out by defining: > 1) that a hyphen indicates a range > 2) sub-addresses like a floor or apartment number must not use the hyphen > notation, but must be given in addr:unit > Agreed, in those cases when it's not a range but actually an apartment number or unit number addr:unit is best. > 3) an address using the range syntax should indicate the interpolation > scheme by means of addr:interpolation=* > The problem with this is addr:interpolation is currently defined as "Every nth house between the end nodes is represented by the interpolation way.", when mapping an address which uses a range, there is no start and end nodes, it's just a single address, you're not saying this range interpolates multiple addresses here, you're saying there is a single address and it's a range. In this case we don't need to record the addr:interpolation since the interpolated addresses don't actually exist (where exists means signposted).
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
