[Talk-GB] Non-intuitive addresses

[Tom Crocker]

On Sun, 13 Feb 2022 at 14:40, Mark Goodge <mark at good-stuff.co.uk> wrote:

>
>
> On 13/02/2022 08:31, Tom Crocker wrote:
> > On Sat, 12 Feb 2022, 20:38 Colin Smale, <colin.smale at xs4all.nl
> >
> >     And addr:place in particular was rather frowned upon in the
> >     discussion in December 2020...
> >
> >
> > Was it? I read the whole thread (I think) and could only find you saying
> > your humble opinion was that a building was not a place. Meanwhile
> > others suggested its use.
>
> My understanding of the previous discussion is that addr:place is for
> where small settlements (eg, rural villages) use the settlement name
> rather than street names in the postal address. That's what the wiki says:
>
> https://wiki.openstreetmap.org/wiki/Key:addr:place
>
> and there's also an open issue for iD (referenced in the address cleanup
> discussion) which makes the same point:
>
> https://github.com/openstreetmap/iD/issues/2898
>
>
The wiki and that issue do give villages as an example of current usage but
do not preclude other use.  Indeed the wiki describes it as an "other
entity, usually a settlement". In my mind a terrace is certainly an entity
and a kind of micro-settlement being a group of dwellings.

In particular, the wiki says, inter alia, that
>
> "When using addr:place=*, make sure to keep the name consistent with the
> place=* object which the house number refers to."
>
> If those instructions are adhered to, then it follows that addr:place
> isn't suitable for addresses where the street level line of the address
> isn't a recognised place name.
>

My understanding is that until 2018 the wiki said you did not need a
matching place=* but text to that effect was introduced by Dieterdreist
when he discovered that nominatim required there to be a matching object,
which he misunderstood as place=* and that wasn't corrected.[1] I don't
think it's documented what nominatim will allow to match for addr:place but
I think it also allows landuse, some but not all place (not locality, ?
others), and not building. Perhaps Sarah Hoffmann can enlighten us. So the
addition was made so addr:place worked with nominatim but was inaccurate.
This was recently strengthened by Mateusz Konieczny with regards to it
being about keeping data consistent. Sarah (Lonvia) reintroduced the point
that it need not match a place=* and now we have a somewhat mangled
sentence that leaves us in no-mans land. However, it is also why I add the
relevant area of named landuse and mentioned the idea of introducing a
place=building_complex (or something) tag.


> > Place has a very broad range of meanings in the English language such as
> > "...a short row of houses which originally stood by themselves or on a
> > suburban road; any group of houses not properly classifiable as a
> street."
> > "...a physical locality, a locale; a spot, a location."
> > "A dwelling, a house; a person's home; (formerly) spec. a mansion, a
> > country house with its surroundings, the principal residence on an
> > estate. Also: a farm or farmstead."
> > https://www.oed.com/view/Entry/144864
> > <https://www.oed.com/view/Entry/144864>
> > As in the phrase "Do you want to come over to our place?".
> > It's only when we get to usage 10 that we find "a city, a town, a
> village."
> >
> > Meanwhile the wiki for addr:place for a long time said
> > "... building, which have number, which belongs to all village or some
> > another polygonal object."
> > and makes it clear the European villages are an example.
> >
> > So using it for a group of houses doesn't seem obviously incorrect.
>
> I don't necessarily disagree with that. But I think that, intuitively,
> it doesn't seem right to use addr:place for both placenames (eg, small
> rural villages) and non-placenames (eg, named buildings or groups of
> buildings in an urban area).
>
> The wiki does actually mention a tag that seems, to me, to be more
> suitable for the latter, which is addr:block. That's mentioned mostly in
> the context of Japanese addresses where the block is named rather than
> the street. But it seems to me that it would also be useful for any
> situation where the addresses are associated with the building rather
> than the highway. Another UK example of those would be the colony houses
> in Edinburgh, where the buildings have names and the postal addresses
> are assigned to the building rather than the adjacent street, like these:
>
> https://www.openstreetmap.org/#map=18/55.95813/-3.16949
>
> Those are currently tagged with the building name in addr:street, so I
> presume that nominatim barfs on those, too.
>
> > PS. I completely agree with Mark that the wiki has not made any of this
> > easy, so if any resolution is found it would be great for us to make
> > things much easier to follow for future mappers.
>
> My preference would be that we use:
>
>   - addr:street when the name is that of an associated highway
>   - addr:place where it's that of a settlement
>   - addr:block where it's a building or campus
>
> I think that's consistent both with the wiki and with normal English
> usage. But my fallback option would be to use addr:street for all of
> them, and for software which uses the data (such as nominatim) to accept
> that the addr:street value won't always match a named highway. That has
> the advantage of simplicity, even if at the expense of precision. And,
> given that iD, currently, only supports addr:street as part of the
> standard address tagging section (see the issue linked to above), this
> is what inexperienced mappers are going to do anyway as they will think
> that's what they're supposed to do.
>

I guess we all have our different intuitions about the meanings of keys. I
think what we're generally discussing are places albeit without a current
tag. I don't really see them fitting city blocks and that's why I wouldn't
use place=city_block with them. However, to be honest, if that scheme was
widely supported by editors, renderers and geocoders I would support it and
the same goes for addr:street on its own. My version of pragmatism has me
at addr:street and addr:place because they seem workable and not incorrect,
given this is an address schema. I completely agree that iD not supporting
addr:place is a major problem for its correct usage but expect that's more
likely to get fixed than the alternatives.

Regards

Tom

[1] https://github.com/osm-search/Nominatim/issues/912
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20220213/c6fbe541/attachment.htm>