Talk:Tag:leisure=garden

From OpenStreetMap Wiki
Jump to navigation Jump to search

Garden beds?

I had thought that leisure=garden meant the garden bed: the flowers etc, where one does not walk, within a park. And that's how I've used it: [1]. If that's not correct (ie, the entire "gardens" should be tagged leisure=garden), then what tag should be used for the actual garden beds themselves? Stevage 04:41, 24 May 2010 (UTC)

Tag the entire garden, including the bits you can walk in. You can always add sub-gardens if it's a large or complex garden: see Proposed features/Garden specification for a proposal which specifies garden types. Grassy areas: landuse=grass. Footpaths can be mapped as footways or paths. Flower beds can change from year to year, and might not be notable or long-lasting enough to map individually. --achadwick 12:43, 26 October 2010 (BST)

Flower beds usually are on the same spot from year to year, the flowers could change though. man_made=flower_bed? garden=flower_bed, garden:detail=flower_bed. Is there a general name in english for areas of planted things, not just flowers?/Johan Jönsson 10:59, 4 September 2012 (BST)
I would go for man_made=flower_bed.

Deprecate this for private, residential gardens?

I move to deprecate the use of leisure=garden for private, residential gardens. Such gardens are of vanishingly small interest to the general public's - or the general map user's - leisure activities. Instead I suggest that we change the main page to recommend the combination:

landuse=residential
residential=garden

for residential gardens of little interest for the general map data consumer's leisure activities, retaining leisure=garden for gardens which are of general leisure interest. This pattern is in use, as described on the talk page for landuse=residential. It's meaningful since it follows the iterative refinement pattern. Additionally it's backwards-compatible, and I note that no interest has been shown in closing ticket 3302. --achadwick 10:45, 23 May 2011 (BST)

From the mailing list discussion, three possible alternative schemes have emerged:

Tagging Pros Cons
Option 1.
landuse=residential
residential=garden
  • Meaningful within a single object.
  • Drill-down refinement of existing meaning.
  • residential=garden is in reasonably widespread use.
  • Landuse implies larger, multi-plot areas.
  • Multiple tags for something really quite simple.
  • Repetition of landuse=* for the most likely use.
Option 2.
residential=garden

Within a separate landuse=residential area. The additional meaning comes from overlap(!)

  • No repetition.
  • Terse and easy to use.
  • Tag is in reasonably widespread use.
  • Drill-down refinement of existing meaning.
  • Is this even a general rule for OSM data?
  • Full meaning is not expressed on a single object.
  • Requires special processing to determine the full meaning.
Option 3.
garden=residential

Within a separate landuse=residential area. The analogy is with building=*.

  • Defines an object's garden-ness, not its residential qualities.
  • Handles occasions where a house's "private residential garden" is inside some other sort of landuse.
  • Can be combined with leisure=garden for objects where leisure=* is appropriate.
  • Full meaning is expressed on a single object.
  • Can be expanded to cover other garden types for leisure=*. Suggest we steal the values from the stale Proposed features/Garden specification
  • Might have to explain harder that leisure=* is inapplicable most of the time, but that's about it.

I find myself tending towards Option 3. at the moment. --achadwick 10:19, 24 May 2011 (BST)


For documentation: there are now the tags: garden:type=* and garden:style=*
--Dieterdreist (talk) 10:47, 18 June 2018 (UTC)

Garden overlaying other areas

Hello people,

I just tagged a few gardens over some highway=pedestrian. The problem is that, even when I modificate the layers and set pedestrian to -5 and garden to +5, it is still not rendered. How can I fix that? --Schumi4ever 14:51, 24 October 2012 (BST)

layer=* should not be used for this stuff. It is just irrelevant. You can use layer=* on stuff like highways.--Cracklinrain (talk) 16:44, 4 December 2013 (UTC)
You cannot fix the rendering in the mapping (and you should not). It is a decision of the people making the osm-carto style not to respect layers universally for the rendering, and to display highway areas always on top. In this specific case I would say you cannot have a garden and a pedestrian area on the same spot, you should likely remove the gardens from the pedestrian area by using a multipolygon relation, or split the area somehow to avoid the superposition. --Dieterdreist (talk) 10:45, 18 June 2018 (UTC)

umaintained/abandoned areas tagged as leisure=garden

According to https://wiki.openstreetmap.org/w/index.php?title=Tag:leisure%3Dgarden&diff=1619285&oldid=1613053 such areas also are tagged as leisure=garden. Maybe it would be a good idea to document this (if that is true)? Mateusz Konieczny (talk) 07:19, 18 June 2018 (UTC)

I am supposing you are writing about gardens, not any unmaintained area, and am replying to this. If you really intended the generic case you name in the title, please clarify. It is a difficult field, as gardens are always in transition, and the process of changing from being a garden to being natural wilderness is smooth. Nonetheless, in the context of a building, where there is a small fenced off area associated with this building where plants grow, I believe it is not too far stretched to speak about a garden. I do not think we should be judging the correct form and intensity of "maintenance" that people need dedicate to their gardens in order we can call it a leisure=garden. A garden that is completely left on its own will soon look similar as any "wilderness", but I would still call it a garden (through context).
The Other case you had added with the disclaimer not to use leisure=garden for these were lawns of detached houses in residential areas. Most leisure=garden objects in OSM are residential gardens, and most residential gardens are consisting of lawn, it is one typical usecase for leisure=garden.
For reference, this is the example image for something that is not supposed to be a garden according to the text Mateusz had added:
  • Rusinovo dacha 02j.JPG
  • --Dieterdreist (talk) 11:19, 18 June 2018 (UTC)

    Flower pot

    How to mark a flower pot, made of concrete, standing next to the pavement?

    --Władysław Komorek (talk) 14:18, 24 November 2018 (UTC)

    this is a recurring question, you might find related discussion in the history (forum, mailing lists, etc.). Surely it is not a "garden". There is a landuse=flowerbed tag with some usage, although I would not expect it to be suitable for flower pots like in your picture, and although I would question "landuse" is a good key for these (landuse would typically be "highway" in the space of the street). I would probably go with man_made=planter https://wiki.openstreetmap.org/wiki/Tag%3Aman_made%3Dplanter which is the IMHO best tag I found. You might be interested in adding a barrier tag as well. --Dieterdreist (talk) 13:44, 20 December 2018 (UTC)

    Landscaped Areas on University Grounds

    Don't know if this would fall under leisure=garden as sometimes all the space is really used for are a couple of trees surrounded by regularly maintained pineneedles. Frequently, however, there are bushes and vines and smaller plants that are kind of like features for a garden, but also I think of using leisure=garden for areas somewhere more intentional or specific. Not entirely a clear point here, but do other people think it makes sense to tag areas on a university campus with leisure=garden?--IanVG (talk) 21:34, 2 October 2020 (UTC)

    I believe they do fall under leisure=garden. Also have a look at the common subtagging possibilities: garden:type=* and garden:style=*, maybe you could invent a new garden:type for university context, or more generically, for "semi public" institutional gardens (I have not checked if currently there are already suitable values out there)? --Dieterdreist (talk) 15:50, 3 October 2020 (UTC)
    Good idea Dieter, I will take a look at the currently used/proposed value and see what fits best. If I don't think they encompass what I'm talking about, I'll respond back to you. Thank you! --IanVG (talk) 23:02, 3 October 2020 (UTC)
    Dieterdreist nothing from either the garden:type=* or garden:style=* keys seems quite satisfactory for the landscaping I am talking about. The garden types I mention are also pretty common for businesses and even certain front and back yards in residential situations, so I am not sure that a key for only the university or semi-public gardens is entirely the right thing here. Don't know how much pushback this will receive, but I do think maybe a key|garden:type=landscaping might somehow work here. In my area (south of U.S.) we call these "gardens" (as we don't consider them true gardens) landscaped areas, or simply, landscaping. A lot of the time it's just bushes, shrubs, and combinations of lower to higher maintenance plants for usually aesthetic or some measure of erosion and stormwater management reasons.--IanVG (talk) 13:44, 23 October 2020 (UTC)

    Pollinator Gardens/Bee Campus USA

    I'm in contact with some students involved in making our campus Bee friendly through meeting the requirements of the Bee Campus USA. Besides adding a self-made tag, are there any keys or values that could be useful here? Thanks! --IanVG (talk) 12:55, 7 October 2020 (UTC)

    Loosen Requirement to not Include Non-garden Features

    Hi,

    I have experienced mapped gardens being deleted for the reason that they overlap with buildings. The deleting person referenced the wiki part that says "Areas should not include features (for example residential houses) which are not part of the garden itself." Does anyone mind me loosening up this formulation?

    For example by:

    • A modifying sentence to "Areas should **ideally** not ..."
    • B removing sentence altogether

    I'm inclined to do B, but hesitate since I don't really understand why this sentence is here in the first place... It seems obvious that one should ideally not include non-garden things in a garden, but I think it makes sense to do it for practical reasons. For example, when a garden surrounds one or more buildings I see no practical harm in mapping this as an area encompassing the buildings. For higher accuracy one might of course map the garden as a multipolygon with the buildings as holes, but I don't think this should exclude the simple method altogether (as the deleting person apparently was lead to think based on the current formulation). --Antonr (talk) 18:56, 28 May 2022 (UTC)

    IMHO we should keep something like this, where the house is is not the garden. —Dieterdreist (talk) 21:00, 28 May 2022 (UTC)
    Dieterdreist Could you elaborate a bit? What do you mean by keep? Do you mean that you don't like deleting the sentence (B above)? What do you think about the proposal to loosen up the sentence a bit (A above)? And maybe more importantly, do you have any thoughts on how to represent the house-in-garden-but-not-part-of-garden case? --Antonr (talk) 21:21, 28 May 2022 (UTC)
    keep means: do not remove. I would not loosen the requirement either, but could live with it if a majority wants to put it less strong. I do not know about house in garden cases, rather I see houses with a garden around them. No special rules required, just map what is there. The garden object should have all the garden but nothing else contained. —Dieterdreist (talk) 07:23, 29 May 2022 (UTC)
    My confusion was whether you meant keep the sentence or keep the deleted gardens. I now think you mean keep the sentence? I'm struggling to explain this since it is not entirely clear to me why the other contributor wanted to delete the gardens in the first place, other than pointing to this sentence. I agree with sentence "No special rules required, just map what is there". Here are some concrete examples of what I think illustrates the difference between house-in-garden-but-not-part-of versus house-in-garden-and-integral-part:
    --Antonr (talk) 13:14, 29 May 2022 (UTC)
    I agree that deletions are not the appropriate answer to the problem, but the discussion about it shall be held elsewhere, it is not a question about the meaning of the tag, it is a specific edit, that IMHO best would be discussed in the changeset, and potentially escalated to an appropriate mailing list (regional/national or in the absence of these talk or tagging), or ultimately to the DWG. —-Dieterdreist (talk) 13:30, 29 May 2022 (UTC)
    Indeed discussion about particular deletes should be had somewhere else (and that is ongoing). My intention was to clarify the wiki, so as to prevent these kinds of deletions from happening in the future due to contributors interpreting the sentence to mean that garden polygons with buildings inside are strictly prohibited (which seems to have happened in this case). Do you think that is worthwhile persuing? Or do you think that the wiki should actually discourage mapping garden like the examples i posted above (of which one more has now been deleted...)? --Antonr (talk) 13:47, 29 May 2022 (UTC)
    In this cases I would expect garden to be multipolygon excluding house. And proper fix would be to create multipolygon, which is easy in both JOSM and iD. Though if there is no harden the proper fix is deleting it. Mateusz Konieczny (talk) 13:51, 29 May 2022 (UTC)
    Thanks for your input, Mateusz Konieczny. I think I agree with all you say. In the concrete examples there have been no (expressed) dispute over the actual existence of a garden (in the plain English interpretation of the word). But the sentence "Areas should not include ..." has been interpreted in a very strict sense, leading to deletion of garden areas (and most recently conversion to less informative single nodes). Thus, I feel that making the sentence less imperative would avoid other from arriving at this strict interpretation in the future. --Antonr (talk) 14:24, 29 May 2022 (UTC)
    Have you already tried contacting this mappers? In general when some not really correct data is present AND repairing is easy then it is better to repair it than delete. In some cases deleting bad data is OK, but only in cases where fixing it takes noticeably more time than deletion. And adding such notes to all wiki pages seems a poor idea. Should we add to highway=bus_stop "if misplaced and you know correct location then drag it to correct mistake rather than deleting it"? Mateusz Konieczny (talk) 15:17, 29 May 2022 (UTC)
    Yes, I continuously try to have a conversation with the contributor. Main thing I got out of that conversation was that in that contributors opinion the gardens violated this particular sentence of the wiki... I think I agree with you about avoiding adding notes stating general principles to each wiki page. That is why I proposed deleting the sentence fully (suggestion B above); I feel the sentence itself is such a general note (i.e. "don't add things to X that are not part of X" seems like a self-evident rule that is always valid). --Antonr (talk) 15:38, 29 May 2022 (UTC)