Proposal:Water

Status

proposal

Proposed-by

User:Myfanwy

Proposal-date

2008-01-31

Proposal

To rename the 'waterway' top-level tag as 'water'

Rationale

A number of keys (lake, reservoir, etc.) are not ways, but should ideally be grouped under the same top=level tag as river, canal, stream, etc. for consistency. However, as they are not ways, the top-level tag needs to be re-named accordingly, to remain logical.

Tagging

The proposed tag is:

<tag k="water" v="<various values>"/>

Proposed Rendering

depends on the sub-type. this should not be altered by the change

Opinion

I would support water=* as an addition to waterway=*, with the intention of the group representing water areas. This would deprecate natural=water, landuse=reservoir and landuse=basin.

Proposed values for the water tag include, lake, reservoir, basin, etc etc. --Thomas Wood 21:05, 25 May 2008 (UTC)

The fundamental problem with the current water tags is that the schema is unbounded and changing. In other words, if you do not capture the entire set of current "water tags" you may incorrectly classify an area as land/water. For clients that want to use OSM as a source of land/water data, this is a problem. (Example: someone adds a new tag: landuse=runoff that is also water. Clients that don't know the tag cannot tell if this indicates a wet or dry tag.

Since every value of the proposed water= key, the very presence of water= would indicate a wet area, even if the particular type of water was unknown due to inventive tagging.

The problems with the proposed solution are:

• Tag growth/duplication during a transition period (or forever if old tags are never removed, e.g. if it is desirable to have landuse= also filled out).
• Enforcement: if this is not driven by the major maps, clients or some kind of automatic checker, the data will be inconsistent and clients will have to inspect old tags anyway, completely defeating the purpose.
• Duplication: if we have the technology to recognize water by pattern (this is what we have now), e.g. an auto-checker, bot, editing client or map has the set of other tags that add up to water, then this tag is simply adding what can be gathered by a SQL query. We don't necessarily want to tag what can be derived.

So IMO the validity of this depends on what is a higher priority: keeping the raw data in the map "thinner" or providing separate "planes" of tags that can be independently understood without a complete (and current) schema.

For what it's worth, I support this tag since my client code tries to extract all water for a simple wet-dry area mapping...this requires scraping the latest recognized tags from major map clients periodically in an attempt to capture "what is blue". --Bsupnik 15:26, 24 July 2009 (UTC)

Voting

Is not open, proposed for 2008-02-28