[Tagging] one feature one element

[Jmapb]

On 7/4/2019 11:17 PM, Joseph Eisenberg wrote:
> We've also had problems with features tagged "tourism=camp_site" or
> "landuse=meadow" plus "barrier=hedge" or "barrier=wall". Is the
> barrier supposed to be an area or a linear feature in this case?
I can see the confusion here, but I think this rule still holds:
Normally linear features like barrier and highway will only be
interpreted as areas if tagged with area=yes. The presence of other tags
which imply area is not the same as area=yes.

But it's true that this usage verges on breaking the
one-feature-one-element rule -- unless you think of "fenced camp site"
as a single feature, which is a bit of a stretch.

Regardless, it's quite common to indicate a barrier around a 2D way by
tagging it with barrier=. I don't think it's genuinely ambiguous so I
doubt that it's going away any time soon, barring editor and bot
intervention. (I used to see fenced=yes... but only on pretty old
changesets.)

> So I'd like to add a line that recommends to avoid mapping two
> different "feature" tags on the same database object.

Which exactly are the "feature" tags? Everything on
https://wiki.openstreetmap.org/wiki/Map_Features ? Obviously building=
shouldn't be included, as it's often combined with other features. I see
cycleway= combined with highway= all the time. Same with sport= and
leisure=, tourism= and historic=. There are many other examples of
commonly used tag combinations, I'm sure.

If you want to try writing a narrower list of "top-level" keys that
should be mutually exclusive, give it a shot -- but I think that's going
to be a short list once we run through it and find all the useful
exceptions.

More likely to work would be: For certain keys, a list of other keys
that should not be used in combination. This list could appear as part
of each section on https://wiki.openstreetmap.org/wiki/Map_Features, or
as its own section on the https://wiki.openstreetmap.org/wiki/Key:*
pages. It might still be difficult to get consensus on these in many cases.

Jason