Feature Proposal - RFC - (Unifying playground equipment tagging)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature Proposal - RFC - (Unifying playground equipment tagging)

Tagging mailing list
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 or
as separate object. Both schemes already exist and I want to combine
them to help to decrease tagging errors.

Proposal:
I propose the key playground to be deprecated and the use of key
playground:* instead. That would mean that on both playground and
playground equipment objects in OSM the key playground:* applies. This
then would also 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.




What I feel:
I know many of you do not want developers to speak about how you should
do things. But I think a dialogue is necessary and also good for us all
and 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 of
things and can help mappers to make OSM more useful.

I am the developer of Babykarte. Babykarte follows what I want to
propose for a quite long time already with some extra specifications
which enables it to be quite flexible in interpreting the tagging. This
makes Babykarte a really good interpreter of the tagging of playground
equipment. This is necessary to do for us developers (we would be happy
if all mappers would stick to the specs) because some mappers decided
not to read the wiki carefully or not at all but instead to actually
map without knowing how. So developers always need to do some
interpreting and thinking of all the possibilities people do not map in
accordance with the spec. This makes us to create our own spec that
builds on the official one because people aren't following the
community's specs.


--
~ Sören Reinecke alias Valor Naram


Developer (not Founder) of the Babykarte: https://babykarte.github.io
Participating in "MapDiscover" project: https://mapdiscover.org
"Community Support" for Trufi Association:
https://trufi-association.org
Documentation for Trufi Communities on mapping bus routes:
https://github.com/trufi-association/mapping-documentation


Ein Gag zu Hamsterkäufen: https://klopapier.mapdiscover.de


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging)

Joseph Eisenberg
The current system seems to make sense.

If you have a leisure=playground feature, probably mapped as an area,
you can tag it with a list of tags like "playground:slide=yes",
"playground:swing=yes", to show what equipment is available.

If you want to map a slide or a swing as a separate feature, you tag
it "playground=slide", or "playground=swing"

What is the problem with this?

Re: > " I want to combine them to help to decrease tagging errors."

How will that help? What errors are you commonly finding?

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?

-- Joseph Eisenberg

On 3/30/20, Sören Reinecke via Tagging <[hidden email]> wrote:

> 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 or
> as separate object. Both schemes already exist and I want to combine
> them to help to decrease tagging errors.
>
> Proposal:
> I propose the key playground to be deprecated and the use of key
> playground:* instead. That would mean that on both playground and
> playground equipment objects in OSM the key playground:* applies. This
> then would also 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.
>
>
>
>
> What I feel:
> I know many of you do not want developers to speak about how you should
> do things. But I think a dialogue is necessary and also good for us all
> and 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 of
> things and can help mappers to make OSM more useful.
>
> I am the developer of Babykarte. Babykarte follows what I want to
> propose for a quite long time already with some extra specifications
> which enables it to be quite flexible in interpreting the tagging. This
> makes Babykarte a really good interpreter of the tagging of playground
> equipment. This is necessary to do for us developers (we would be happy
> if all mappers would stick to the specs) because some mappers decided
> not to read the wiki carefully or not at all but instead to actually
> map without knowing how. So developers always need to do some
> interpreting and thinking of all the possibilities people do not map in
> accordance with the spec. This makes us to create our own spec that
> builds on the official one because people aren't following the
> community's specs.
>
>
> --
> ~ Sören Reinecke alias Valor Naram
>
>
> Developer (not Founder) of the Babykarte: https://babykarte.github.io
> Participating in "MapDiscover" project: https://mapdiscover.org
> "Community Support" for Trufi Association:
> https://trufi-association.org
> Documentation for Trufi Communities on mapping bus routes:
> https://github.com/trufi-association/mapping-documentation
>
>
> Ein Gag zu Hamsterkäufen: https://klopapier.mapdiscover.de
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging)

dieterdreist
In reply to this post by Tagging mailing list


Am Mo., 30. März 2020 um 16:45 Uhr schrieb Sören Reinecke via Tagging <[hidden email]>:
https://wiki.openstreetmap.org/wiki/Proposed_features/Unifying-playground-equipment-tagging


Proposal:
I propose the key playground to be deprecated and the use of key
playground:* instead. That would mean that on both playground and
playground equipment objects in OSM the key playground:* applies. This
then would also 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.


You are proposing to abandon the distinction between playgrounds and implicit features on them (properties) and things on a playground (explicitly mapped playground equipment as a feature).
Wouldn't this move make it actually harder, rather than simpler, to understand what is represented?

Usually we are advocating for the contrary: using different keys for features provided by other features (properties) and features mapped explicitly. In this case, it is already like this, and you do not provide (IMHO) sufficient arguments to change it.

Redefining tags that are in use (properties for playgrounds then could also represent explicit features) is generally problematic, why aren't you proposing different tags as an attempt to avoid confusion?

I do not understand why this would make mapping easier or less error prone. You will find tags that are not used as documented for any feature.

Cheers
Martin


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging)

Tagging mailing list
In reply to this post by Joseph Eisenberg
> The current system seems to make sense.

It makes sense but it seems that it is also much error-prone because it
is easy to oversee one sentence in the wiki of Key:playground:* and
Key:playground that makes the difference (pointing the case where the
key should be applied)


> If you have a leisure=playground feature, probably mapped as an area,
you can tag it with a list of tags like "playground:slide=yes",
"playground:swing=yes", to show what equipment is available.

> If you want to map a slide or a swing as a separate feature, you tag
it "playground=slide", or "playground=swing"

> What is the problem with this?

No problem with it. This is alright. But Key:playground shouldn't
combined with Tag:leisure=playground .

> Re: > " I want to combine them to help to decrease tagging errors."

> How will that help? What errors are you commonly finding?

For example: https://www.openstreetmap.org/way/137931618 . In this case
Key:playground was used to tag playground equipment on the playground
object itself. But for such cases we use Key:playground:* . This is one
example of many.


> 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?

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

Cheers

Sören Reinecke alias Valor Naram


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging)

Tom Pfeifer
On 30.03.2020 20:02, Sören Reinecke via Tagging wrote:
>> How will that help? What errors are you commonly finding?
>
> For example: https://www.openstreetmap.org/way/137931618 . In this case
> Key:playground was used to tag playground equipment on the playground
> object itself. But for such cases we use Key:playground:* . This is one
> example of many.

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?

tom

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging)

Tom Pfeifer
In reply to this post by Tagging mailing list
On 30.03.2020 20:02, Sören Reinecke via Tagging wrote:
>> How will that help? What errors are you commonly finding?
>
> For example: https://www.openstreetmap.org/way/137931618 . In this case
> Key:playground was used to tag playground equipment on the playground
> object itself. But for such cases we use Key:playground:* . This is one
> example of many.

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?

tom

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging)

dieterdreist
In reply to this post by Tagging mailing list


sent from a phone

> On 30. Mar 2020, at 20:03, Sören Reinecke via Tagging <[hidden email]> wrote:
>
> For example: https://www.openstreetmap.org/way/137931618 . In this case
> Key:playground was used to tag playground equipment on the playground
> object itself. But for such cases we use Key:playground:* . This is one
> example of many.


it is not clear without knowing the place whether it is as you say.
The tags are
leisure=playground
playground=sandpit

this could also be intended as a sandpit kind of playground.

Usually in OpenStreetMap tagging, if people tag
A=B
B=C
when B is a feature, C is a subclass (more specific kind) of the B class.

There are some exceptions to this, where B=* would be things from the B domain, examples are the playground key and golf key.


Cheers Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging)

Tagging mailing list
In reply to this post by Tom Pfeifer
> 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?

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.


--
Sören Reinecke alias Valor Naram <[hidden email]>



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging)

Tagging mailing list
In reply to this post by dieterdreist
> You are proposing to abandon the distinction between playgrounds and
implicit features on them (properties) and things on a playground
(explicitly mapped playground equipment as a feature).

Not really, playground equipment (tagged with 'playground:') on a
feature tagged with its main tag 'leisure=playground' indicates that
the feature is a playground. The key 'playground:' on that feature
describes just its properties. The distinction is being done by
'leisure=playground'.

> Wouldn't this move make it actually harder, rather than simpler, to
understand what is represented?

No because the keys 'playground' and 'playground:' are not describing
the feature itself but are describing what the feature has:

leisure=playground
playground:*= yes

as I suggest describes a playground with its properties (playground
equipment) on it. Playground equipment tagged as feature (separate
object) would then be tagged like this:

playground:*=yes
...
(not containing 'leisure=playground')

> Usually we are advocating for the contrary: using different keys for
features provided by other features (properties) and features mapped
explicitly. In this case, it is already like this, and you do not
provide (IMHO) sufficient arguments to change it.

I know and I love this way of handling. I can just give one example of
how people are using the 'playground' key wrongly on a feature tagged
as 'leisure=playground':

http://www.openstreetmap.org/node/6323927215
  leisure=playground
  playground=structure

correct would be

http://www.openstreetmap.org/node/6323927215
  leisure=playground
  playground:structure=yes

That's why I think the actual way is to confusing. I am personally
total fine with the situation as it is now because it makes *sense*.

> Redefining tags that are in use (properties for playgrounds then could
also represent explicit features) is generally problematic, why aren't
you proposing different tags as an attempt to avoid confusion?

Because the key 'playground' mapped on a playground equipment (explicit
feature) is also being used on playground features with
'leisure=playground'. This is wrong and leads also to confusion. That's
why I want to propose the other way around to hopefully solve the
problem of using semicolons on the 'playground' key to indicate
multiple equipment as it is here
http://www.openstreetmap.org/way/166629582 . Normally I would run a
world wide Overpass Query for such cases and would convert it to the
'playground:*' scheme as a QA attempt.

> I do not understand why this would make mapping easier or less error
prone. You will find tags that are not used as documented for any
feature.

See my examples.

--
Sören Reinecke alias Valor Naram <[hidden email]>



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging)

Sven Geggus
In reply to this post by Tagging mailing list
Sören Reinecke via Tagging <[hidden email]> wrote:

> Proposal:
> I propose the key playground to be deprecated and the use of key
> playground:* instead. That would mean that on both playground and
> playground equipment objects in OSM the key playground:* applies. This
> then would also 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.

I do not like the idea of pseudo namespacing signle keys at all. I would even go
further to say that I generally prefer generic keys over special ones.

We already had this discussion in tourism=camp_pitch vs.
camp_site=camp_pitch.

Using the former instead of the latter will make live easier for database
imports.

Thus your proposal will make imports even more complicated as it will need
wildcard processing for keys like this:

"import all objects tagged playgroud:<something>"
instead of just
"import all objects tagged playground".

Regards

Sven

--
"Thinking of using NT for your critical apps?
                                  Isn't there enough suffering in the world?"
                   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging) - Cancelled

Tagging mailing list
In reply to this post by Tagging mailing list
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:
---

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 <[hidden email]>
Reply-To: "Tag discussion, strategy and related tools" <[hidden email]>
Cc: Sören Reinecke <[hidden email]>
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 or
as separate object. Both schemes already exist and I want to combine
them to help to decrease tagging errors.

Proposal:
I propose the key playground to be deprecated and the use of key
playground:* instead. That would mean that on both playground and
playground equipment objects in OSM the key playground:* applies. This
then would also 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.




What I feel:
I know many of you do not want developers to speak about how you should
do things. But I think a dialogue is necessary and also good for us all
and 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 of
things and can help mappers to make OSM more useful.

I am the developer of Babykarte. Babykarte follows what I want to
propose for a quite long time already with some extra specifications
which enables it to be quite flexible in interpreting the tagging. This
makes Babykarte a really good interpreter of the tagging of playground
equipment. This is necessary to do for us developers (we would be happy
if all mappers would stick to the specs) because some mappers decided
not to read the wiki carefully or not at all but instead to actually
map without knowing how. So developers always need to do some
interpreting and thinking of all the possibilities people do not map in
accordance with the spec. This makes us to create our own spec that
builds on the official one because people aren't following the
community's specs.




_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (Unifying playground equipment tagging) - Cancelled

Joseph Eisenberg
> 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

This looks fine. The whole playgorund is just the sandpit, so using
the same area for both is not too bad. And the area is about 10 x 10
meters, so it isn't tiny.

I also think it would be fine to just use playground=sandpit alone, in
this case, and especially for a smaller sandpit.

-- Joseph Eisenberg

On 4/13/20, Sören Reinecke via Tagging <[hidden email]> wrote:

> 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 <[hidden email]>
> Reply-To: "Tag discussion, strategy and related tools" <
> [hidden email]>
> To: [hidden email]
> Cc: Sören Reinecke <[hidden email]>
> 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.
>
>
>
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging