*@OSMDoudou :* At the moment, i only used the role entrance for the underground parking site relation with some parking_entrance, because it was suggested by JOSM. Roles could be used when the situation is complicated (ex : no clear perimeter exist -> like for underground parking), it may then be useful to indicate the entrance role (even if it should be implicit from the tag amenity=parking_entrance...). For the perimeter role, it may be more useful when multiple polygons are in the site relation (like for historic castle where you could have the whole site but also the inner court, ...). In case of parking site relation, the perimeter role is maybe less useful as the perimeter should always be the polygon with amenity=parking, but i'm not really taking position on this old debate about implicit vs explicit values.
I often dupplicate the tags from the site relation to the amenity=parking polygon (or a node/polygon for other site relation like for historic=castle). And only to get "useful" data for most apps and services that don't use site relation at all (i think only http://gk.historic.place/ use site relation for historical features). For parkings, most of the tags are duplicated by using the common scheme (polygon with amenity=parking) and the "advanced scheme" (with site relation like in the proposal), all this because i maintain compatibility with both scheme (which is good and bad...).And as the site relation are mostly ignored by most tools and maps, it doesn't matter at the moment. Finally, i find the site relation very useful to quickly query the whole group of elements member of a site). *@Martin*, I tried to use multipolygon relation for this before, but it is not good in some cases. The site relation allow to group elements where a multipolygon is not correct : like for university buildings dispersed into a city (ex: https://www.openstreetmap.org/relation/8148420#map=18/50.66823/4.62058), where you can't make a multipolygon to group every elements of the university (they can be nodes too), and using multiple "amenity=university" is wrong as there is only one university. It also allow to group elements like you would with relation=stop_area in the public transport scheme (i.e. grouping every element at the same location that are part of the same "site"). It is useful to group historical elements of a castle for exemple (the moat, the walls, the towers, the bridge, ...) to distinguish the part that are historic to the ones that are not historic at all. I also use the relation to put the "heritage" tag applied to the "Site" as a group (when it fits no other polygon). And as described in the site relation proposal, we should not use the site relation, when everything fit into one area (like an area with tag "amenity=school" or "amenity=university"). The parking site is an exception in this to me, as the relation allow easier maintenance/selection of so many polygons linked to the area (when you tag individual parking_space...) and it allow to have only one scheme for every parking (the ones that are only on the surface, the one that are underground AND the ones that are both at the same time (like this one : https://www.openstreetmap.org/relation/8431818 where i tagged the underground part only with the parking_entrance nodes). Le jeu. 13 sept. 2018 à 23:32, Martin Koppenhoefer <dieterdre...@gmail.com> a écrit : > > > sent from a phone > > > On 13. Sep 2018, at 22:35, OSMDoudou < > 19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote: > > > > What do you think ? > > > I’m hardly using the site relation because you can express almost > everything spatially (a (multi-) polygon for the site, everything inside is > automatically part of the site), unless you want to employ specific roles > or want to add lines and nodes outside of enclosing polygons. The roles > you mention do not make a lot of sense: > > perimeter: this is usually implicit in the geometry > > entrance: this is also implicit in the geometry (a node with > entrance=main/yes in the perimeter) > > label: nobody (AFAIK) uses this. A good label position depends on other > factors (scale, other things labeled, etc.) which have to be determined > individually for each map and situation, nothing you should map (it is not > geodata). > > > cheers, > Martin > > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
