<div dir="ltr"><div dir="ltr"><div dir="ltr">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. <div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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? </div><div><br></div><div>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.</div><div><br></div><div>2) Re: "What about e.g. boundary relations?"</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><br>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).<div><br></div><div>-- Joseph Eisenberg</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 10, 2021 at 1:47 AM Volker Schmidt <<a href="mailto:voschix@gmail.com">voschix@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="auto">Joseph, <br></div><div>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.<br></div><div>As said before looks as if many people have used it for this kind of object (university)</div><div><br></div><div>In addition the English word "site" has a wide range of meanings, as I said before.<br></div><div><br></div><div>The multipolygon solution is OK as long as you do not have to include node-type objects.</div><div>"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.<br></div><div><br></div><div><br></div><div>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."</div><div>Where does this come from? What about e.g. boundary relations?</div><div>Also this one: "
mapping widely disparate faculties in different neighborhoods as one database object is not something that can be verified practically by mappers. "</div><div><br></div><div>Volker<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 9 Jan 2021, 20:42 Joseph Eisenberg, <<a href="mailto:joseph.eisenberg@gmail.com" target="_blank">joseph.eisenberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<br><br>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 <a href="https://censusreporter.org/profiles/40000US03817-atlanta-ga-urbanized-area/" rel="noreferrer" target="_blank">https://censusreporter.org/profiles/40000US03817-atlanta-ga-urbanized-area/</a><br><br>If a university has 4 campuses in 4 different suburbs of Atlanta or Tokyo, how is it  reasonable to map them with one relation?<br><br>What about all the Los Angeles County libraries, spread over a county with over 10 million people and dozens of municipalities? <a href="https://lacountylibrary.org/library-locator/" rel="noreferrer" target="_blank">https://lacountylibrary.org/library-locator/</a><br><br>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. <div><br></div><div>-- Joseph Eisenberg<br><br>On Sat, Jan 9, 2021 at 10:22 AM Volker Schmidt <<a href="mailto:voschix@gmail.com" rel="noreferrer" target="_blank">voschix@gmail.com</a>> wrote:<br>><br>> ... besides that the wiki's original and main job is to actually document the use of tags.<br>> I was surprised how widespread its use is for universities - I had not checked that before i proposed  it.<br>> 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.<br>><br>><br>> On Sat, 9 Jan 2021 at 18:05, Stefan Tauner <<a href="mailto:stefan.tauner@gmx.at" rel="noreferrer" target="_blank">stefan.tauner@gmx.at</a>> wrote:<br>>><br>>> On Sat, 9 Jan 2021 17:35:26 +0100<br>>> Martin Koppenhoefer <<a href="mailto:dieterdreist@gmail.com" rel="noreferrer" target="_blank">dieterdreist@gmail.com</a>> wrote:<br>>><br>>> > A site is something at the same place, more or less. It is not something<br>>> > the parts of which are located in 5 different places, that would be 5<br>>> > sites. Spatial proximity is implied in a site relation. Universities with<br>>> > different locations (typical situation in Europe at least), are operating<br>>> > different "sites", not the same site which is distributed. That's not a<br>>> > "site".<br>>><br>>> I love how you maintain to be completely vague in that paragraph<br>>> allowing for my example to be perfectly covered by it. "same place more<br>>> or less"=same town works for me. ;)<br>>><br>>> NB: if the site relation would only be used for arrangements that are<br>>> packed together it would be completely unnecessary since then one could<br>>> use a polygon to mark the area for most uses that I have seen in the<br>>> past (hotels, unis, schools).<br>>><br>>> --<br>>> Kind regards/Mit freundlichen Grüßen, Stefan Tauner<br>>><br>>> _______________________________________________<br>>> Tagging mailing list<br>>> <a href="mailto:Tagging@openstreetmap.org" rel="noreferrer" target="_blank">Tagging@openstreetmap.org</a><br>>> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>><br>> _______________________________________________<br>> Tagging mailing list<br>> <a href="mailto:Tagging@openstreetmap.org" rel="noreferrer" target="_blank">Tagging@openstreetmap.org</a><br>> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a></div></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" rel="noreferrer" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>
</div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>