Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

[landcover] "mapnik" rendering: residential or private gardens: reduce visibility at low zoom #3302

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 6 comments

Comments

@openstreetmap-trac
Copy link

Reporter: a.t.chadwick[at]gmail.com
[Submitted to the original trac issue database at 11.02am, Thursday, 21st October 2010]

A user in my area has recently been adding residential housing and gardens from high-resolution OOC mapping.

These are tagged

  leisure=garden
  access=private
  garden:type=residential

e.g. http://www.openstreetmap.org/browse/way/79633228

Could these be made a little less obvious at low zoom? By "low", I mean at around z14 or z15. To be perfectly honest I don't think private gardens should render at all at anything less than z18 or higher, and it may be wise to render residential gardens with a variation on the same sort of grey used for landuse=residential.

Rationale: the general public visiting the OSM website aren't going to be interested in residential gardens. The 80:20 rule applies for most zooms. For the detail-obsessed visitor and mappers like me, there's always z18.

@openstreetmap-trac
Copy link
Author

Author: Andrew Chadwick
[Added to the original trac issue at 10.33am, Tuesday, 26th October 2010]

More examples:

And a long thread in the German OSM forums: http://forum.openstreetmap.org/viewtopic.php?id=9710&p=1

The German example uses access=private to distinguish private gardens from interesting ones that we want on the map (IMO!). The Czech one uses, oddly, barrier=fence around the area... but I suppose that has a meaning of "private", given the nature of barriers.

Could "don't render if access={no or private}, or barrier=" be used as part of a rule for rendering leisure= areas?

@openstreetmap-trac
Copy link
Author

Author: Andrew Chadwick
[Added to the original trac issue at 10.53am, Tuesday, 26th October 2010]

Maybe not the barrier criterion, since for the renderer you get into horrible logic like "does the barrier have an entrance and if so what are its access tags?" Far better to stick with plain old access=<no or private or get_orff_moi_laaarnd>.

@openstreetmap-trac
Copy link
Author

Author: Andrew Chadwick
[Added to the original trac issue at 11.20am, Tuesday, 26th October 2010]

Corner cases like large and notable but nominally private estate gardens exist.

Can Mapnik rendering or db loads make use of hints hints from enclosing areas? If so, then surrounding the garden area with a larger landuse=residential ought to provide enough clue. But I'm not sure if this can be done.

Could look for landuse=residential on the object itself of course, and just render that with a higher priority. It's true of course - a residential garden has residential landuse - but it's not one feature:one OSM object, so it might not be great tagging.

@openstreetmap-trac
Copy link
Author

Author: Andrew Chadwick
[Added to the original trac issue at 3.04pm, Tuesday, 26th October 2010]

Another possibility (for tagging) which came up during discussion here: residential=garden, which is probably best described by its proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/residential_details. It has the distinct advantage of being backwards-compatible.

@openstreetmap-trac
Copy link
Author

Author: a.t.chadwick[at]gmail.com
[Added to the original trac issue at 11.41am, Monday, 23rd May 2011]

Okay, I'll just assume there's no great will to fix this in the renderer then. Let's address the problem by gathering some consensus among taggers and fix up the new, confusing documentation on the wiki page.

http://wiki.openstreetmap.org/wiki/Talk:Tag:leisure%3Dgarden#Deprecate_this_for_private.2C_residential_gardens.3F

@openstreetmap-trac
Copy link
Author

Author: math1985
[Added to the original trac issue at 4.28pm, Monday, 28th July 2014]

This issue is now being discussed on Github: gravitystorm/openstreetmap-carto#782

Therefore, I will close the issue here.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant