I do see why a parking is different from a university. If there is 1 polygon in which everything is placed, there is no need for a site relation. The argument of 1 scheme is also strange, because you do make a difference for a university with 1 campus (you are not using a site relation there) vs. multiple , but not for parkings ? Furthermore there are plenty of parkings mapped without parking spaces, just as nodes or areas. Those are mapped without relation anyway.
I'm in favour of KISS, don't use a relation when it is not really needed. So +1 on what Martin wrote. m. On Fri, Sep 14, 2018 at 1:30 AM Lionel Giard <lionel.gi...@gmail.com> wrote: > > @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 _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
