<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 15. Juli 2020 um 10:03 Uhr schrieb Lionel Giard <<a href="mailto:lionel.giard@gmail.com">lionel.giard@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">In the parking example that i talk about, the multipolygon is not usable if i want to indicate the specificity of each part of the parking lot like capacity or capacity:disabled (as the tagging is global for every outer part). I like the site relation as it allows to also group the vending machine or the amenity=parking_entrance for underground parking (as a car park may have both underground + overground parkings). I find a site relation more practical in such cases and I never used it technically for malls with only overground parkings (but that was in the original proposal example i think ^^). </div></blockquote><div><br></div><div><br></div><div>yes, the site relation is useful when you have something that can be considered a "site" and you have objects like nodes and lines that are not inside the area. In theory it could also be useful if you want to have specific roles (e.g. this is the ticket office for this site, or like in your example, these are the vending machines for this parking). Or this is the parking for this supermarket (if it is not adjacent/part of the area, I have an example around here).<br></div><div><br></div><div>IMHO, a city wall around a city, fragmented or not, is not suitable as a "site", because it is not "compact" (not sure about the right term). Similarly, a university which is split across several, distant (relatively, e.g. hundreds of meters or some kilometers apart) places, is not a "site", it is rather several sites, and to draw them together, we usually employ "tags". If you do not like to rely only on tags, a different kind of relation would seem more appropriate. In the end it depends on scale what is distant and what is close.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>My use case was more about the underground parking where I grouped all the parking_entrance (both pedestrian and for vehicle) with a "site=parking" relation. One example is this one : <a href="https://www.openstreetmap.org/relation/8425228#map=18/50.66911/4.61226" target="_blank">https://www.openstreetmap.org/relation/8425228#map=18/50.66911/4.61226</a> (there are one vehicle entrance, one vehicle exit, multiple pedestrian entrance/exit and few vending machines for it). <b>Do you have a better way of tagging this ? ^^</b></div></div></blockquote><div><br></div><div><br></div><div>you could have the parking as an underground area and the entrances part of the perimeter, and you would not need a relation. I agree though that the site relation seems appropriate for this case (underground structures are generally a field of problems, e.g. because they are hard to survey and they are confusing people because the rendering is often not appropriate.<br></div><div> </div><div>Cheers</div><div>Martin<br></div></div></div>