> just tag the amenity with playground=yes. That doesn't work. We have a 20 km^2 airport. Will you really tag it with a 20 km^2 playground (child_area)?
> that I feel it's hopeless to try to tag it. For the same reason you prefer hotels over motels or hostels. There many differences but you cannot tag them precisely or decide which properties you will need and which are available in OSM. In the end you will simply search for hotels first and then motels, etc. 2014-12-19 20:40 GMT+04:00 moltonel 3x Combo <molto...@gmail.com>: > > On 19/12/2014, Martin Koppenhoefer <dieterdre...@gmail.com> wrote: > > 2014-12-19 12:12 GMT+01:00 Никита <acr...@gmail.com>: > >> > >> IMO, kids_area=* is prefered when you have bigger feature: > >> > >> name=Joe pub > >> amenity=pub > >> kids_area=yes > >> kids_area:fee=no > >> > >> or explicitly using: > >> amenity=kids_area > >> fee=no > >> operator=Joe pub > >> opening_hours=10-20 > >> > > > > > > I think this tagging is generally OK, but I am not sure when a standalone > > feature is a playground and when it is a kids' area. > > We should put the focus on defining criteria for distinguishing these > two. > > IMHO the current definition of leisure=playground is flawed [1][2] > because > > it says they were "commonly small outdoor areas", therefor implicitly > > stating that they might also be indoor areas and maybe "big". "small" and > > "big" are quite useless attributes because you don't know about the scale > > or what to compare it to. > > > > IMHO we should either require leisure=playground to be outdoor only (and > > kids' areas as an independent feature to be always at least partly > indoor) > > or make kids' area a feature that is always provided by another feature > and > > cannot stand alone, otherwise there would be useless overlap. We should > > also explicitly state in playground that it is only about stand-alone > > features and not for playing areas provided by shops or similar. > > I don't like to fuel this already long thread, but I just want to note > that I don't see a need for kid_area, as playgound (with associated > tags) can already describe all the usecases. Note that I'm a father of > two yound kids, and playgrounds are very important in my day to day > life. > > I agree that an outdoor park playground, a kid-friendly area in a > shop, and a purpose-built playground business are very different > beasts, but they still all fit within the "playground" domain by > adding playgound:FOO=yes, fee=*, surveillance=*, being located in a > building or not, etc. If it's just a minor service in a bigger > amenity, just tag the amenity with playground=yes. > > As a father, I know pretty much all I need by seeing where the > playground is located and wether it requires a fee or not. The only > other things I need are opening times and website. Mapping individual > playground components is fun for the mapper, but fairly useless for > the parent (unless the thing is huge or your kid really *can't* enjoy > a playground without, say, a climing frame). > > Whether you can leave your kids there for a while depends on so many > things (kid's age, surveillance type, parenting style...) that I feel > it's hopeless to try to tag it. > > > The current playground definition already includes places with > surveillance > > and which require to pay a fee (suggested keys surveillance and fee). > > I plead guilty to recently adding these two suggested tags to the wiki. > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
