Proposal talk:Playground Equipment

From OpenStreetMap Wiki
Jump to navigation Jump to search

Don't use numbers, tag single objects

The old OSM rule is "If an object is larger than 5m diameter, it is not a node".

Who told you this nonsense? The database is full of nodes which represent objects larger than 5m in diameter. Car parks, fuel stations, shops, train stations, etc. Just to name a few. --Cartinus 18:45, 26 March 2010 (UTC) (Lulu-Ann please sign your comments.)

Usually a swing or a slide is one node, the neighbour swing or slide is further away than 5m, so it is a single object with a coordinate.

So I propose to use:

I like this, though it does require the mapper to map the location of each item which as Cartinus pointed out on the mailing list makes the process somewhat more complicated. Accuracy in position in this case isn't especially critical and in practice I suspect most mappers would do it by eye rather than getting a fix for each item. --Antonyking 23:36, 26 March 2010 (UTC)
I've remembered why I didn't propose this initially - if you are searching for playgrounds containing particular equipment or combinations of equipment, then looking for single nodes should make that simpler. If there's an API for finding nodes contained within an area, or a means of associating the nodes with the area then it might work.--Antonyking 07:51, 27 March 2010 (UTC)
Why would you want to exclude playground equipment, that is not located in a playground? The XAPI request is
http://www.informationfreeway.org/api/0.6/node[playground=*]
regardless if the tag leisure=playground is used (correctly) or not! Lulu-Ann
you are correct the search would return everything regardless if it was in an area or not, which is great.
I've re-written the proposal to incorporate the ideas here; I think we're getting close to a really useful schema here! --Antonyking 21:43, 31 March 2010 (UTC)
I also think that we should map the singular objects at their supposed position. For smaller playgrounds thats mostly trivial and bigger ones could be traced from aerial photography or gps. -- Dieterdreist 23:03, 31 March 2010 (UTC)

Add tags for surfaces to the proposal

I'd also like to see some recommendations

how to tag the various surfaces

  • landuse=grass
  • natural=scrubs
  • natural=water
  • there is missing something for sand I think (well people use natural=beach), and there is an inactive proposal for natural=sand but currently proposing this only for "large areas" which would mostly not apply for playgrounds.
I can't imagine anyone would tag all the different surfaces in playgrounds - typically (in the UK) each item has a rubbercrumb area around it, and the bits in between are filled with either grass or tarmac. Very fiddly to map as each area will be in the region of a couple of square metres - ie, at the limit of what you can resolve with GPS. By all means use them as they are standard area tags, but I don't think they should go in as especially recommended for playgrounds. --Antonyking 21:41, 3 April 2010 (UTC)
For sand, I've got playground=sandpit which should cover it.--Antonyking 22:06, 3 April 2010 (UTC)

or which useful combinations of well established tags are there

these ones should go in with the possible exception of 'surface' (see above); I'm already using barrier=fence and barrier=gate on my local playgrounds.--Antonyking 21:42, 3 April 2010 (UTC)
shelter is a curious one; there's a lot of different types of them and not much agreement between tags for them. The types of shelters you often get in playgrounds here are known by the local authorities as 'teen shelters', so I have proposed a new value for playground of playground=teenshelter', to distinguish it from bus shelters, mountain shelters, bothies etc. They frequently have a play aspect to them too, eg climbing apparatus or tactile decoration. --Antonyking 22:04, 3 April 2010 (UTC)

Don't use "inclusive"

":inclusive" does not say anything about with which disabilities an object can be used.

Better use

These categories aren't really as helpful for playground equipment as they might be for, eg directing you through a town via a step free route. Some disabled users have fatigue problems, some have serious balance problems, some have no trunk stability or no grip and therefore cannot sit on, eg, a bench swing. Very little playground equipment excludes deaf or blind children from using it (blind children might need a spotter or helper for safety depending how brave they were). Some equipment is specifically designed to be used by someone in a wheelchair (eg the park leisure roundabouts, and some swings that look a bit like luggage hoists) where as other equipment is perfectly usable but the user would need to transfer to it. Perhaps a new disabilities tag 'sitting_disability' might be appropriate here. This suggestion also implies a separate node for each item, which in turn requires the playground to be defined as an area, the implications of which may need some thought --Antonyking 23:36, 26 March 2010 (UTC)
See tactile_paving on information what makes an object usable for blind persons. Swings for example are dangerous if you don't notice that you walk into the area where the swing can hit you. As other renderers can already show icons for accessible objects for different groups of disabilities, the same tags shall be used ( [1], [2] )! I agree to 'sitting disability', that sounds reasonable. Of course playgrounds are areas. What do you want to think about? Lulu-Ann

Relations

There is a proposal for a relation of type Relations/Proposed/Site, which we could use here to make a logical relationship between individually named pieces of play equipment, and the area that bounds them. The relation could look like this:

Key Value Discussion
type site
site playground
name a name The name of the playground

This should make searching simpler while still allowing detailed placement and description of each item of equipment. ---

I think you are right, the relation is the way to go for grouping the single items. -- Dieterdreist 22:42, 31 March 2010 (UTC)
I think the site relation is great. But... shouldn't the site=playground tag really be leisure=playground, to be consistent? I don't see a need for a separate site=* key in the relation. Just a thought. I realise it's more applicable to the Site relation proposal, but thought I'd note it here before I forget. Cheers. --Waldo000000 12:51, 20 April 2010 (UTC)
'site' was intended for a variety of types of sites; the proposal for the site relation was that the relation was of general type 'site' and the specific site in this instance is a playground. Are you suggesting we have site=leisure and leisure=playground? That might have some merit as there are other types of leisure site (eg a static caravan site) that could be covered. I don't have the time or energy to start getting into proposals for relations as well but perhaps someone else could pick that up. If at some later stage the relations tags get agreed more formally we can change it but for now I'm happy with it as it is - it's unambiguous and clear as to what it is.--Antonyking 19:21, 20 April 2010 (UTC)
I just can't see the reasoning behind using site=playground, when it is actually describing a leisure=playground. Using site=* seems to confuse things without adding any information. --Waldo000000 04:32, 21 April 2010 (UTC)
'site' is describing what kind of relation it is, so I think it needs to stay; other types of relation are reasonably well documented, like turn restrictions, campuses, regions etc (see Relations). If we don't put 'site' in the relation then renderers won't understand the association between the playground=* objects and the leisure=playground object. I'm thinking in the more general case - if the number of types of relations is relatively restricted then there's more chance that renderes will be able to do something useful with them. --Antonyking 06:03, 24 April 2010 (UTC)
Reading this again, and in conjunction with the page about using multipolygons to draw lakes with islands in (!) I can see where I misread what you were saying - ie, keep 'type=site' but replace 'site=*' with 'leisure=playground'. Assuming that's what you meant, I concur and will update the main page. --Antonyking 21:24, 13 May 2010 (UTC)

Example Playgrounds

( Antonyking ) I'm using this tagging scheme to tag the playgrounds here, complete with relations:


Themes - Type of "Storyboard"

what about proposing an additional tag (for playground-nodes, -polygons and -relations) theme? This could be

  • theme=adventure for all kind of "adventure"-theme like wooden fortress,
  • theme=plastic for those fancy sites with tubes and sinks made of coloured raisin and synthetics.
my boy would love a playground made of raisin! Antonyking
  • theme=forest for playgrounds in the forest with features made of mainly of timber or stone
  • theme=sand for playgrounds with little more than a sandpit (could also be theme=basic)
  • theme=water for playgrounds with water supply to play with in the sand.

...

  • theme=userdefined for custom ideas

-- Dieterdreist 22:42, 31 March 2010 (UTC)


This could be very helpful. I'd suggest adding
* theme=accessible
as well, as there are a few playgrounds that are explicitly designed for disabled children.
--Antonyking 16:27, 1 April 2010 (UTC)
Against, because a playground can be a water playground and accessible at the same time. "Accessible" is not a theme. Just add wheelchair=yes or whatever disability fits. Lulu-Ann

Play equipment falling into multiple categories

Minophis pointed out to me that some equipment contains features from several categories of equipment, eg a climbing frame with a slide. I would suggest (and have put on the main proposal page) simply semi-colon separating a list of the name tags, starting with the one that most represents the item being described. So our climbing frame with slide would be playground=climbingframe;slide --Antonyking 20:52, 5 April 2010 (UTC)

Semicolon separated values are a pain in the ass. They are hard to query and hard to render. It would be better to have two very narrow nodes representing each object. Lulu-Ann
It's not /that/ hard to deal with, and is semantically more correct to represent one physical object with one node (or area or way). It's not exactly unprecedented either! Suppose you had a shop that was both a postoffice and a general store (lots of those in the UK since the gvnmt started shutting postoffices!) - should that be two separate nodes? Rendering would need a little thought - the easy way would be to just show (in our example case) a climbing frame icon with a slide icon next to it. Querying? I'm not familiar with the API but a quick scan through the docs suggests you can't search by tag value anyway, so any query would be a case of fetching a bounding box and searching through the XML which should be easy enough. Do you have any examples of where you've had problems with semicolon separated values before? --Antonyking 06:38, 24 April 2010 (UTC)
Talking to myself, it occurred to me that most items that fall into >1 category are things like climbing frames with a slide sticking out one side, which could be drawn up as a closed way for the climbing frame marked as playground=climbingframe, with a spur for the slide marked as playground=slide - each part is then labeled up correctly, which satisfies my wish to have the connected parts drawn as one single entity, and your (Lulu-Ann's) requirement to avoid multiple descriptions per node. --Antonyking 15:33, 12 May 2010 (UTC)

Sensory Objects

Another form of play equipment that seems to be integrated into climbing frames quite often and that is not currently covered by current tags is sensory play equipment such as panels with different colours and textures, wheels and gadgets that can be moved and fiddled with and audible parts such as drums, bells (suitable for the blind) etc.

I propose the tags: playground=sensory_visual, playground=sensory_tactile, playground=sensory_audible--Minophis 19:59, 18 April 2010 (UTC)

I have changed it to sensory=audible etc. to allow combinations without forcing semicolon separated values. Lulu-Ann
That sounds sensible; using ';' to separate lists of nouns(eg climbingframe) and adjectives (eg audible) would be bad. --Antonyking 06:41, 24 April 2010 (UTC)

Definition der Zielgruppe

Auf der deutschen Wiki für Spielplatz wird darauf verwiesen, dass man sich bei ungeklärten Punkten sich an die englische Wikiseite für Spielplätze richten soll. Zu meinem Problem: Es gibt hier in Deutschland und vermutlich anderswo auch, Spielplätze die von der öffentlichen Hand betrieben und geflegt werden. Dann gibt es auch Spielplätze die privat betrieben werden, zwar öffentlich für jedermann zugänglich sind es aber unerwünscht ist, wenn Kinder die dort nicht wohnen, da auch spielen. Eine Trennung von privaten und öffentlichen Spielplätzen fehlt derzeit in Openstreetmap. --Edwin-ldbg 12:07, 6 April 2010 (UTC)

Google says: "On the German wiki page for playground will be pointed out that one should focus on unresolved issues at the English wiki for playgrounds. To my problem: there is here in Germany and probably elsewhere, the public playgrounds of the hand operated and manicured. Then there are the playgrounds are operated privately, but publicly accessible to everyone but it is undesirable if not the children live there, play there, too. A separation of private and public playgrounds is currently lacking in Openstreetmap"
Assuming google translate has that about right, there's always the access=private/public option in that instance
I agree, access=private/public and operator=Church St. Michael fulfills your needs. --Lulu-Ann 21:05, 6 April 2010 (UTC)

Old-fashioned stuff still in use around here (NL)

  • hopscotch court

    hopscotch court

  • marble hole ???

    marble hole ???

--Cartinus 20:47, 20 April 2010 (UTC)

Cool stuff. I guess you can add it to the page right away. Lulu-Ann
I'm adding the first one, as hopscotch .

Additional Features for Playgrounds

1. State (of equipment): - rather new - fair - worn - inacceptable (dangerous)

Against. Better store the date when it was last renewed. We don't need another tag with subjective values, please. --Lulu-Ann 20:46, 1 May 2010 (UTC)
Probably best to link this data to an external database rather than clutter up OSM with data that will be fiddly to update and go out of date quickly; I'm running a separate project Accessible_Play which could conceivably hold parent reviews of playgrounds; contact me directly if you want to get involved in that. --Antonyking 15:53, 12 May 2010 (UTC)

2. Catering I like playgrounds where parents can get a cup of coffee or tea. In urban areas, you find playgrounds attached to cafés or beergardens. I suggest taging these with "catering=yes".

Against. Tag the source as what it is. A restaurant, a café or whatever. It has its own node or building area. --Lulu-Ann 20:46, 1 May 2010 (UTC)

3. Fenced In some areas, fenced playgrounds are nice, because fences stop dogs from abusing sandpits as toilets.

This is nothing new, the fenced tag already exists and is well used around playgrounds. --Lulu-Ann 20:46, 1 May 2010 (UTC)

4. Ages Some playgrounds are designed for infants (say 1-5 yrs), others rather apt for teens.

I propose to use minage and maxage tags for this. --Lulu-Ann 20:46, 1 May 2010 (UTC)
There's also baby=yes proposed to cover stuff specifically for babies (in practice between 0 and 2-4 years depending on the child) --Antonyking 15:53, 12 May 2010 (UTC)

5. Watched (?) There might be playgrounds that are watched by a nanny or sim.

This sounds to me like an "opening hours" information. Compare with kindergarten tag. --Lulu-Ann 20:46, 1 May 2010 (UTC)

6. Indoor mostly in restaurants or bars ("Kindercafé).

This is represented by the tag building=yes with access=permissive or private. Also nothing new, I think. --Lulu-Ann 20:46, 1 May 2010 (UTC)
We're in danger of 'scope creep' in this section; I suggest we consolidate the ideas already in place rather than adding too much more detail at this point. --Antonyking 15:54, 12 May 2010 (UTC)

Scope too narrow

Since this proposal covers everything to do with tagging playground equipment, it's too limited in its actual scope imho, since it really only covers "accessibility". If you were going to categorise a playground into the broadest categories, would you really think "suitable for disabled children/unsuitable for disabled children"? I think not - you'd think "suitable for children under 5/10/15" or something like that. I guess most of the tags are ok - but why not propose a broader range to cover everything you're likely to want to tag. Perhaps "playground:min_age=5" and "playground:min_unsupervised_age" or something would be useful.

I don't like "theme". Plastic is a building material - not a theme. I find it hard to see what this tag would be useful for, and it would be quite subjective. Is a vaguely castle shaped playground constructed out of wood "theme=castle" or "theme=forest"? I think objective tags like "surface=sand" or "surface=rubber" would be more useful.

Also consider proposing a relation to group all elements of the playground together. Stevage 01:48, 14 May 2010 (UTC)

There already is a whole paragraph in the proposal about such a relation. (Feel free to remove this comment and your last sentence together.) --Cartinus 12:47, 14 May 2010 (UTC)
@ Stevage - did you actually read the proposal or just the rational bit at the top? It covers accessibility, surface=*, barrier=*, minage=*, maxage=*, relations (in excruciating detail, discussed at length on the discussion page) etc etc - I'm more worried about the scope being too broad than too narrow. Read it again then state what's missing and we can discuss it. Feel free to ignore theme=* - it is marked as optional. I've only felt the need to mark up one playground with it so far. --Antonyking 16:02, 14 May 2010 (UTC)

Traffic training playground DE: Verkehrsgarten

Hi,

I think I would like to add "traffic training" as a playground equipment. I will add a photo soon. Lulu-Ann

Playground equipment - combined apparatus

I've tagged one single-piece of equipment at http://www.openstreetmap.org/browse/node/746610555 as playground=combined - playhouse, slide, climbing frame; there are actually other pieces which could be added to the combination, such as a vertical tic-tac-toe board (uses rolling tumblers to assign X and O). Thoughts on these "all-in-one" playground equipment items? --Ceyockey 16:45, 23 May 2010 (UTC)

There's a section above on it; the consensus was, where possible, draw the item as a way and tag each leg of the way with what's there; otherwise use a semi-colon separated list - eg Playground=playhouse;slide;climbingframe. If the items are sort-of-separate, treat them as individual nodes. There's masses of variation in playground equipment so we're never going to get perfect mapping of it, so I think a 'best effort' approach is sensible otherwise we'll end up with a behemoth tagging scheme which is barely better than just having a freeform 'note' tag! --Antonyking 19:30, 25 May 2010 (UTC)
I disagree. Better tag single nodes and combine them with a relation. Semicolon separated tags suck! Lulu-Ann

New play equipment types found since voting started

(ramblemode on) I've mapped a few more playgrounds and found some new types of equipment. One is a linear climbing frame made of balance beams, tight ropes and other obstacles, the other is a roundabout in the shape of a cup. The former could be described as a playground=obstaclecourse, though to avoid tag proliferation, calling it a climbing frame with type=linear would make life easier for renderers. The other is known as a cup roundabout but it is near enough to a normal roundabout that perhaps an extra tag type=cup would be appropriate.

I guess what I'm proposing here in the most roundabout way possible is an additional tag called 'type' whose value is specific to the particular playground object being mapped. --Antonyking 21:29, 31 May 2010 (UTC)

Put new objects here to find good names

Trampoline

playground=trampoline sitting_disability=yes - though lying on a trampoline with someone else doing the bouncing probably isn't approved (and is quite scary!) --Antonyking 21:27, 18 June 2010 (UTC)

Soccer

should this be covered as a subkey of Key:sport ? --Antonyking 21:27, 18 June 2010 (UTC)

I would place it in sports if it is a full size soccer field. I would place it in playground if it is smaller. Lulu-Ann
and you always know the official size of a field and you are able to measure it ? --Skyper 09:40, 24 June 2010 (UTC)
Soccer playgrounds and fullsize fields differ in size so much that it is easy to estimate. Yes, my GPS does measure meters from one flag to another if I want it to. Lulu-Ann

Basketball

see soccer --Antonyking 21:27, 18 June 2010 (UTC)

here I am able to get the size of the field, but how do I measure the height of the basket ? (has to be 3.05 m)--Skyper 09:42, 24 June 2010 (UTC)

Naturspielplatz - Skovlegeplads - Nature Playground

In Denmark, I found some very nice "Skovlegepladser" which are situated in the woods/forests. All featured devices were wooden, and spread accross a wide area. There are also amenities like toilets or fire places for barbeque.

Such nature sites are getting more in vogue, again. How to tag them?

sledding hill

i would like to suggest another playground value: "sledding_hill". normally short downhill areas near a playground for kids to go sledding in the winter. see http://en.wikipedia.org/wiki/Sledding

--Flaimo 14:39, 28 April 2011 (BST)

multiple playground values on a node

sometimes i have to map playgrounds as a node, where i cannot pinpoint the exact location of each play equipment. that is the case for example, when there are a lot of trees covering the area and you can't see the ground on the satellite images. therefore i suggest that it should also be possible to add a list of playground equipment to the playground tag. example: playground=seesaw;water;sandpit. this way i could also include the information in a single node if necessary. on the other hand this doesn't allow to map if a certain equipment is explicitly NOT available. therefore an even better notation would be playground:seesaw=yes|no // playground:water=yes|no // playground:sandpit=yes|no --Flaimo 15:11, 28 April 2011 (BST)

refactoring zipwire to aerialway=zip_line

Proposed feature/aerialway=zip line has already 80 uses and I see very little reason to have two tags for the same feature. Playground zipwires maybe "just toys" but most "real" zip lines are also just toys - only for adults:)

The differences in access, difficulty etc could be mapped with existing access style keys, maxweight and suitable mapping of adjoining connections. RicoZ (talk) 13:23, 28 December 2014 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Playground_Equipment&oldid=2516551"