On 2020-01-07 22:21, Paul Allen wrote:
> On Tue, 7 Jan 2020 at 21:00, Colin Smale <colin.sm...@xs4all.nl> wrote:
>
>> So if I am now more explicit about my intention to help this discussion
>> towards a conclusion.....
>
> Actually, you sorta hijacked a discussion about whether to put the address on
> a
> building or a nearby gatepost. This discussion is probably needed too.
I don't think it was so much hijacking the discussion, more getting it
back to fundamentals. If an address is for the benefit of delivering
letters, its location in OSM should ideally approximate to the postal
delivery point: the front door, the front gate... Locating it implicitly
at the centroid of the building outline, or the centroid of the
associated grounds, would be suboptimal. A building, being a single OSM
object, can only really have one address. As a building can
fundamentally have N (maybe hundreds for blocks of flats) addresses for
postal purposes, then there is no point in putting an address on a
building. If a company resides in a premises, it may be useful to put
their postal address adjacent to (i.e. on the same OSM object as) the
other attributes of the company as "contact information" i.e. how to
address a letter so it gets to this building, but not by definition what
to put in your satnav. Then if multiple companies share an OSM building
they all have their own node and thus their own address. HOWEVER if you
want an address for navigation purposes, a single set of address
components will suffice to get you to the right building, irrespective
of who you are visiting.
Fix the complex case, and the rest is easy.
>> What an address refers to, is different in the UK compared to other
>> countries. We will never find a single model to fit the whole world that is
>> not abstracted to the point that it becomes useless. Let's stop chasing our
>> tails, and accept that.
>
> Already have. Long ago. Not sure that what we have, even in the UK, is
> entirely
> fit for purpose because I have several examples in my own town alone that
> don't fit
> that model. These are, to some extent, country-specific editor preset
> issues: figure
> out what works in a given country and persuade the people maintaining the
> editors to
> adopt it. Yes, I'm simplifying a lot (again).
>
>> Back to the philosophical question: Is a normal "address" in OSM: a) for
>> delivering letters, or b) for navigation, or c) an identifier of a
>> building/premises, or d) something else?
>
> The philosophical question is actually should we limit/prohibit any of those
> uses? I
> think not. We can't force any mapper to add all of the info, but we ought
> not to prevent
> them from doing so.
>
>> Should/could we cater for these different definitions of "address", e.g. by
>> having tags like addr:{address_type}:{address_element}? This is a question
>> that IMHO is probably best addressed at global level; then let each country
>> have its own model within that framework.
>
> Gut feeling, without any real analysis, is we don't have address_type, we
> just have
> address_elements. Because in one country address_element X may be a critical
> component of address_type A but in another country it's a critical component
> of
> address_type B. Just have address elements and it's up to the consumer to
> make
> sense of them.
I agree with your gut feeling..... But it is bad for OSM's data quality
if we cannot state what frame of reference was used for addressing. If
one mapper uses strict postal addressing (unreliable for navigation),
and another uses physical addressing (not matching the postal
addresses), and we cannot tell the difference from the OSM tagging, then
we are presenting our data consumers with a challenge, in the same way
that having maxspeed=N without explicit or implicit units would cause
problems. Even in the UK speed limits in km/h are used on many rail/tram
systems..._______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
