[Tagging] Why isn't the amenity=parking object part of the relation ?

Lionel Giard lionel.giard at gmail.com
Thu Sep 13 23:28:43 UTC 2018

*@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:
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

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 <dieterdreist at gmail.com>
a écrit :

> sent from a phone
> > On 13. Sep 2018, at 22:35, OSMDoudou <
> 19b350d2-b1b3-4edb-ad96-288ea1238eee at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180914/fbb96e58/attachment-0001.html>

More information about the Tagging mailing list