[Tagging] Grouping buildings together using relations

Mon Jan 11 00:37:17 UTC 2021

1) I agree that the wiki is mainly descriptive, but it is also good to
mention when certain tags or concepts are not verifiable or there is
widespread disagreement in the community.

While some mappers might want to use relations to group together a large
category of things, like "all Starbucks coffeehouses in Europe", this is
not a good idea because it does not represent something local which can be
confirmed to be correct or not. Such a huge relation is very unlikely to be
correct: it is likely to miss out on some of the Starbucks restaurants in
Europe, and might also include some stray nodes or ways which were added to
the relation in the past but not deleted when the use of the building
changed.

Similarly, if someone tries to map a large library system with 50 branches,
it is likely that one will be added without the relation being updated, or
deleted, etc. - instead it is much better to use overpass-turbo or another
search tool to download all the features in a certain area with the
expected characteristics - this will catch duplicates and missing objects.

If there is a large University which has many departments / faculties /
schools which are in different buildings all around a city, how will this
relation be maintained? It is very likely to be incomplete because of the
complexity, and because it is not possible to verify if something is
accidentally added or deleted to it. Imagine a new mapper accidentally
deletes a building that was part of the relation, and then someone else
comes and re-maps the missing building. It will be unlikely to be added
back to the site relation. Or if a new mapper accidentally adds an office=*
node to the relation, how will another mapper confirm that the relation is
now incorrect?

We should discourage mappers from creating relations which are not
verifiable, hard to maintain, and confusing for new users. If other mapper
cannot easily check your work and improve it, then the relation is very
likely to quickly become incorrect or broken.

2) Re: "What about e.g. boundary relations?"

Administrative boundaries are sometimes verifiable on the ground,
especially for international borders. In Europe some of the internal
borders have disappeared, but I understand that border controls were put
back for COVID-19, and in most other places there are clear markers at all
international border crossings. Provincial borders might not be clearly
marked, but they are very widely known, so if they are incorrect in
OpenStreetMap local mappers will notice when the rendering looks wrong.

For International borders we actually had the most accurate set, at least
until the Crimea issue, since we go by the "on-the-ground" rule of where
the de-facto borders exist in reality.

I am willing to argue that local administrative boundaries and other types
of boundary relations are often not verifiable and therefore are a poor fit
for OpenStreetMap. If the only source for the boundary is importing it from
an official database, then OpenStreetMap users can never hope to improve
the data. This is often the case for minor boundaries which are not
significant, e.g. admin_level=9 or =10, and sometimes even lower numbers
like municipalities.

It would have been better for us to have developed a separate, open-source
database for just administrative boundaries (and other data that can only
hope to be imported, like protected areas), where the data would not be
mixed up with the things that mappers need to be editing. Any time you edit
an administrative boundary you are just making it worse, if it was imported
from a reliable source.

But this is all just whataboutism - administrative boundaries are already
imported, and I am not actually suggesting we get rid of them, even though
we can't hope to make them much better than the official maps (except at
the international border level).

-- Joseph Eisenberg

On Sun, Jan 10, 2021 at 1:47 AM Volker Schmidt <voschix at gmail.com> wrote:

> Joseph,
> Please do not forget that the wiki is mainly there to document actual
> usage of tagging. The wording of the "site" wiki page is wide, and the
> concept of what can and what cannot be described by this relation type is
> vague. I also is mainly stating what it cannot be used for.
> As said before looks as if many people have used it for this kind of
> object (university)
>
> In addition the English word "site" has a wide range of meanings, as I
> said before.
>
> The multipolygon solution is OK as long as you do not have to include
> node-type objects.
> "My" university example includes nodes, typically smaller University
> institutes that occupy only part of a building, hence are tagged as nodes
> within the building or on the outline of the building they are in.
>
>
> Another remark: You say " I believe this is a mis-use of the concept of
> relations in OpenStreetMap, since it is not representing a distinct feature
> that can be observed to exist locally, on the ground."
> Where does this come from? What about e.g. boundary relations?
> Also this one: " mapping widely disparate faculties in different
> neighborhoods as one database object is not something that can be verified
> practically by mappers. "
>
> Volker
>
>
> On Sat, 9 Jan 2021, 20:42 Joseph Eisenberg, <joseph.eisenberg at gmail.com>
> wrote:
>
>> If the type=site relation is being used in this way, I believe this is a
>> mis-use of the concept of relations in OpenStreetMap, since it is not
>> representing a distinct feature that can be observed to exist locally, on
>> the ground.
>>
>> If a site relation is used to group any set of related features in one
>> "city", consider that there are cities like Jakarta and Tokyo which have
>> millions of people spread over thousands of square kilometers and several
>> different admin_level=4 (province/State) features. The city of Atlanta, as
>> an urbanized "place", has almost 7000 square kilometers of suburban land
>> with 5 million people
>> https://censusreporter.org/profiles/40000US03817-atlanta-ga-urbanized-area/
>>
>> If a university has 4 campuses in 4 different suburbs of Atlanta or
>> Tokyo, how is it  reasonable to map them with one relation?
>>
>> What about all the Los Angeles County libraries, spread over a county
>> with over 10 million people and dozens of municipalities?
>> https://lacountylibrary.org/library-locator/
>>
>> While it's good to use a multipolygon to precisely map the area of a
>> university campus which is split in 2 or 3 parts by streets in between,
>> mapping widely disparate faculties in different neighborhoods as one
>> database object is not something that can be verified practically by
>> mappers.
>>
>> -- Joseph Eisenberg
>>
>> On Sat, Jan 9, 2021 at 10:22 AM Volker Schmidt <voschix at gmail.com> wrote:
>> >
>> > ... besides that the wiki's original and main job is to actually
>> document the use of tags.
>> > I was surprised how widespread its use is for universities - I had not
>> checked that before i proposed  it.
>> > As far as the use of the word "site" for extended or distributed
>> objects: Hadrians Wall in the UK is a World Heritage Site. So is the Great
>> Wall.
>> >
>> >
>> > On Sat, 9 Jan 2021 at 18:05, Stefan Tauner <stefan.tauner at gmx.at>
>> wrote:
>> >>
>> >> On Sat, 9 Jan 2021 17:35:26 +0100
>> >> Martin Koppenhoefer <dieterdreist at gmail.com> wrote:
>> >>
>> >> > A site is something at the same place, more or less. It is not
>> something
>> >> > the parts of which are located in 5 different places, that would be 5
>> >> > sites. Spatial proximity is implied in a site relation. Universities
>> with
>> >> > different locations (typical situation in Europe at least), are
>> operating
>> >> > different "sites", not the same site which is distributed. That's
>> not a
>> >> > "site".
>> >>
>> >> I love how you maintain to be completely vague in that paragraph
>> >> allowing for my example to be perfectly covered by it. "same place more
>> >> or less"=same town works for me. ;)
>> >>
>> >> NB: if the site relation would only be used for arrangements that are
>> >> packed together it would be completely unnecessary since then one could
>> >> use a polygon to mark the area for most uses that I have seen in the
>> >> past (hotels, unis, schools).
>> >>
>> >> --
>> >> Kind regards/Mit freundlichen Grüßen, Stefan Tauner
>> >>
>> >> _______________________________________________
>> >> Tagging mailing list
>> >> Tagging at openstreetmap.org
>> >> https://lists.openstreetmap.org/listinfo/tagging
>> >
>> > _______________________________________________
>> > Tagging mailing list
>> > Tagging at openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210110/308207b7/attachment-0001.htm>