Render natural=rock areas in light grey #34

Closed
wants to merge 1 commit into
from

Projects

None yet

7 participants

@danstowell
Contributor

Render natural=rock areas in light grey.

Example location: http://www.openstreetmap.org/?lat=53.1577&lon=-1.66033&zoom=18

(Note that this isn't present in the old osm-mapnik style either. If you want to keep the master branch purely compatible, an option could be merging this into a branch for "post-compatible" map features.)

@stefanct

what about bare_rock and scree?

@math1985 math1985 added the landcover label Apr 14, 2014
@math1985
Collaborator

As far as I'm concerned, this PR can be merged.

I would like to continue with refactoring landuse after I am done with roads, and it would be best that open PR's are merged so I won't interfere with them.

@pnorman
Collaborator
pnorman commented Apr 15, 2014

This is a new feature addition, odds are it won't be added until 3.0

@gravitystorm gravitystorm added this to the New features milestone Apr 16, 2014
@dieterdreist

2014-04-15 21:09 GMT+02:00 math1985 notifications@github.com:

As far as I'm concerned, this PR can be merged.

I would like to continue with refactoring landuse after I am done with
roads, and it would be best that open PR's are merged so I won't interfere
with them.

I think there is some confusion between natural, landuse and landcover.
"rock" would IMHO be a value that fits into landcover, while landuse might
be something like "quarry" or even nothing (not used by humans), while for
natural the value could be (according to what it actually is) "boulder", or
"cliff", or "saddle", or maybe "stone_field" (not sure if the latter exists
in English) etc. (i.e. not a material description but a description of a
feature - if there is one, if there isn't you can also omit "natural").

@math1985
Collaborator

The tag natural=rock is very popular, so it seems to be that the consensus is that that's the correct tag. I see no strong reasons not to follow this consensus.

@dieterdreist

2014-04-20 1:46 GMT+02:00 math1985 notifications@github.com:

The tag natural=rock is very popular, so it seems to be that the consensus
is that that's the correct tag. I see no strong reasons not to follow this
consensus.

I do see quite a lot. E.g. see the wiki:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Drock
natural=rock is not on the map feature page for natural, because
natural=bare_rock is, and there seems to be some overlap. There doesn't
seem to be a clear and consistent definition what to use this for, but
there are indications that this was introduced by an import: "This tag was
also used during the French Corine Land
Coverhttp://wiki.openstreetmap.org/wiki/Corine_Land_Cover(See
details on the french
pagehttp://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature)
to import areas made of solid rocks".

Also this k/v doesn't fit well into the general system (should be a
landcover value and not a natural value).

@lest69
lest69 commented May 2, 2014

I agree with dieterdreist that there are problems with natural=rock.

  1. natural=rock was actually just the originally proposed name for what eventually became natural=bare_rock. The originally-named tag should probably have never been used at all.
  2. Even if you assume that natural=rock is an acceptable tag and should be used, if you look more closely at the Taginfo stats, it looks like it's being massively misused. The description states that it should be used for areas of rocks, but the tag has been overwhelmingly used on nodes, indicating people are likely using it to map individual rocks. Going by the intended use (ie. areas and multipolygon areas), this tag has only been used about 7000 times, while natural=bare_rock has been used well over 60000 times.
@math1985
Collaborator
math1985 commented May 2, 2014

Thank you both for this extra information. In that case, I agree we should not render natural=rock. We might consider rendering natural=bare_rock instead. I will therefore close this pull request now.

@math1985 math1985 closed this May 2, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment