[Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging) - Cancelled

Sören Reinecke tilmanreinecke at yahoo.de
Mon Apr 13 13:06:36 UTC 2020


Due to your feedback I will cancel the proposal. AGAIN: What you say is
100% correct. This proposal's purpose was just to simplify what seems
unclear to many (not all) mappers.

But keep you eyes on the following unsolved scenario:
---
How should the following scenario be tagged:
Playground https://www.openstreetmap.org/way/320398422 just has one
equipment (sandpit) and this equipment (sandpit) fills up the whole
area of the playground. The tagging used here is as follow:
(access=yes)  reluctant for our purpose
leisure=playground
playground=sandpit

Helpful resources:
https://wiki.osm.org/Key:playground:
https://wiki.osm.org/Key:playground
---

Summary about what you said about this case:
> Re: > This would allow to map playgrounds and their equipment in
situations where a playground just has one equipment and this
equipment fills up the whole area of the playground.

> Mappers can tag "leisure=playground" + "playground=structure"  on the
same node or area in this case, right?


My answer: > The Wikipage for "Key:playground" says the following: "It
should be
tagged to separate objects within the area of a playground". An
exception is given with "Only when the position of the individual
objects cannot be mapped yet" at the really end of the page. But for
such cases where we cannot map playground equipment as an extra object
we have the Key:playground:* .

> Well the equipment in this case is playground=sandpit.
As the outline of the sandpit is identical with the outline of the
leisure=playground, why would
this be wrong?


My answer: Theoretically you need to create an object for the
playground itself
and another object for the playground equipment. Both then will share
the same geometries (outline). In practical meaning you normally won't
map it this way because it is idiotic. My proposal also reflects that
and provides a way to map such cases without having to do it the
theoretical way.


We should clarify how to handle such cases in the wiki

Cheers

Sören Reinecke alias Valor Naram
-----Original Message-----
From: Sören Reinecke via Tagging <tagging at openstreetmap.org>
Reply-To: "Tag discussion, strategy and related tools" <
tagging at openstreetmap.org>
To: tagging at openstreetmap.org
Cc: Sören Reinecke <tilmanreinecke at yahoo.de>
Subject: [Tagging] Feature Proposal - RFC - (Unifying playground
equipment tagging)
Date: Mon, 30 Mar 2020 16:43:59 +0200

Hey,
a new RFC for 
https://wiki.openstreetmap.org/wiki/Proposed_features/Unifying-playground-equipment-tagging

Purpose:Simplified tagging of playground equipment on the playground
itself oras separate object. Both schemes already exist and I want to
combinethem to help to decrease tagging errors.
Proposal:I propose the key playground to be deprecated and the use of
keyplayground:* instead. That would mean that on both playground
andplayground equipment objects in OSM the key playground:* applies.
Thisthen would also allow to map playgrounds and their equipment
insituations where a playground just has one equipment and this
equipmentfills up the whole area of the playground.



What I feel:I know many of you do not want developers to speak about
how you shoulddo things. But I think a dialogue is necessary and also
good for us alland we can learn from each other: Mappers know the
philosophy of OSM,the mapping, tagging and the QA, they know what to
achieve how.Developers know the philosophy of orthogonality and
nornmalisation ofthings and can help mappers to make OSM more useful.
I am the developer of Babykarte. Babykarte follows what I want
topropose for a quite long time already with some extra
specificationswhich enables it to be quite flexible in interpreting the
tagging. Thismakes Babykarte a really good interpreter of the tagging
of playgroundequipment. This is necessary to do for us developers (we
would be happyif all mappers would stick to the specs) because some
mappers decidednot to read the wiki carefully or not at all but instead
to actuallymap without knowing how. So developers always need to do
someinterpreting and thinking of all the possibilities people do not
map inaccordance with the spec. This makes us to create our own spec
thatbuilds on the official one because people aren't following
thecommunity's specs.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200413/6a6df81d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200413/6a6df81d/attachment-0001.sig>


More information about the Tagging mailing list