Proposal talk:Tag:natural=rock overhang
Don't suggest mapping as both a way and an area, please
Currently the proposal suggests that it's possible to map as
- a node (this is good)
- an area (that is, a closed way or a multipolygon which represents the area of the shelter) - this is fine
- also as a linear way which is shared with part of the natural=cliff way. This last idea is bad for database users. What if there is a circular rock with an overhang all the way around, or a circular sinkhole with an overhang? In this case, you would be tempted to map the whole overhang as a single linear way - but this will be ambiguous. There will be no way for database users to clearly determine if a closed way is meant to be a linear feature or an area in that case.
Generally, it is good to avoid using the same tag for area and linear features, since OpenStreetMap does not have an area database primative. In this case, using an area or node should be adequate, so I recommend removing the suggestion to maps these as a linear way. --Jeisenbe (talk) 04:16, 27 October 2020 (UTC)
- Thanks for the feedback. It's a good point about a closed way now being ambiguous, I hadn't thought of a circular sinkhole with overhang all the way around. Perhaps instead we could request the area=* key to make it explicit. The idea behind allowing a linear way was that for wide sections you could mark out exactly which part of the cliff has the cave like opening underneath and map styles could render this. Alternatively you could place a single node and add the width tag which would have the same affect, so perhaps that's the alternative here. Generally I like to keep the options for object types flexible to allow for micromapping. I'll think about it. Keen to hear more feedback. --Aharvey (talk) 05:57, 27 October 2020 (UTC)
The draft proposal embodies the assumption that the rock overhang will be coincident with the clifftop, but that's not always the case. A cliff is mapped at its top and not at its base. The base of a tall, near-vertical cliff can be far enough away from the top of the cliff (horizontally) that the rock overhang should be mapped in its true position, and not at the position of the cliff-edge at the top of the cliff. Rock overhangs at the base of a cliff are often formed where there is some irregularity/bulge at the base of the cliff such that the opening of the overhang is not coincident with the line of the clifftop. --Roger Browne (talk) 08:16, 27 October 2020 (UTC)
- Technically yes, in practice if I'm mapping one usually the slope of the cliff isn't too great so I'd just map them together. It's not like I can measure the difference with GPS anyway. If there is significant slope and you want to map this with more detail then yes I think it's fine that the node is not on the cliff way, but where the cliff is mostly straight or as a first pass, on the cliff way is fine too. Data consumers who may want to connect the two could still just do a post processing closest point on line for the nearest cliff line if they want it snapped to the cliff. --Aharvey (talk) 10:50, 27 October 2020 (UTC)
The paragraphs starting with "When mapped as a..." could be replaced with something like the following:
- When mapped as a simple node the natural=rock_overhang tag should be placed on a node at the daylight edge of the rock overhang, at the place where the overhang has maximum depth. This may be on a node part of a natural=cliff, when the daylight edge of the rock overhang coincides with the clifftop
- I was seeking an unambiguous rule by which to place the node. "Maximum height" would probably work better than "maximum depth". Sometimes the natural place for the node would be midway along the overhang, or at the natural point of entry into the overhang. Maybe just leave it to the mapper's judgement. --Roger Browne (talk) 14:06, 27 October 2020 (UTC)
- When mapped as a linear way the natural=rock_overhang tag should be placed along the daylight edge of the rock overhang. It may share a natural=cliff way for part or all of the section of the rock overhang, when the daylight edge of the the overhang coincides with the clifftop.
- When mapped as a closed way (when the rock overhang extends all the way around a closed cliff or sinkhole), the natural=rock_overhang tag should be placed along the daylight edge of the rock overhang. It may share a natural=cliff way for part or all of the section of the rock overhang, when the daylight edge of the overhang coincides with the clifftop. It does not represent an area.
- I guess I was trying to still give people the freedom to map as an area, more important for huge rock shelters where they want to map the shape (important to show the floor space). Yes you could add height and depth but not quite as good as the full floor space mapped out. --Aharvey (talk) 10:50, 27 October 2020 (UTC)
But isn't this over-complicating things? A simple node is all that needs to be specified at this time. It solves the current problem elegantly, without closing off any options for a future time when areas under natural features are desired to be mapped in detail. --Roger Browne (talk) 08:16, 27 October 2020 (UTC)
- In that case, I think it would be a better proposal if the three lines starting with "When mapped as a..." were deleted. If we don't want to discourage people who might map in more detail, we shouldn't make the details overly prescriptive. We can sit back and see how mappers use nodes or ways to map rock overhangs. The proposal can achieve its objective of using "rock overhang" instead of "cave entrance" without the lines starting with "When mapped as a...". Either way, I'm ready to support this proposal when you open voting. --Roger Browne (talk) 17:01, 22 November 2020 (UTC)
Should we vote on this
Hi @Aharvey, what do you think, when can we start voting on this proposal? --SLMapper1 (talk) 20:32, 9 April 2021 (UTC)