Talk:Tag:waterway=dam/Archive 1

From OpenStreetMap Wiki
Jump to navigation Jump to search

old content

This proposal replaces an earlier proposal --Swampwallaby 01:46, 14 December 2007 (UTC)

Comments

  • Please start discussion for current proposal here.--Swampwallaby 02:17, 14 December 2007 (UTC)
  • Looks good, a yes from me. Thanks for the time spent on the drawings! I've been using man_made=dam but this is equally logical. It would be nice, but not vital, to introduce a convention for which side is "up" and "down" for linear drawing, e.g. down is to the right of the line in the direction of drawing. This convention could then be applied to weirs and cliffs - it is cliffs that I'm really wanting if for. MikeCollinson 08:32, 14 December 2007 (UTC)
  • And another thought, this could also be used for levees perhaps or should they have there own tag? A levee is one of those long embankments along rivers in low lying areas to stop them flooding. MikeCollinson 08:32, 14 December 2007 (UTC)
    • As a none native speaker, I'm a bit confused about the differences to embankment=yes. Could someone clarify this for me? -- Ulfl 09:14, 14 December 2007 (UTC)
  • embankment=yes is a tag added that can theoretically be added to a road to indicate it is raised above the surrounding country. A levee is a stand-alone embankment with no road on top. Mike, I have seen levees drawn on maps as thick black lines, I think that would work well. For the up/down, since we have water on the right for coastlines, it would make sense to have down is to the right. --Swampwallaby 11:04, 14 December 2007 (UTC)
Excellent!! MikeCollinson 15:45, 28 December 2007 (UTC)
  • wouldn't it be cool, to map very big dams as an area? --Cbm 00:13, 29 December 2007 (UTC)

Voting

  • Voting commenced 28th December 2007
  • I Approve this proposal. --Swampwallaby 11:23, 28 December 2007 (UTC)
  • I Approve this proposal. --TomChance 11:59, 28 December 2007 (UTC)
  • I approve this proposal. --Eimai 12:26, 28 December 2007 (UTC)
  • I Approve this proposal. -- Franc 13:23, 28 December 2007 (UTC)
  • I Approve this proposal. -- MichaelK 13:25, 28 December 2007 (UTC)
  • I Approve this proposal. --Onion 14:01, 28 December 2007 (UTC)
  • I approve this proposal. Robx 15:13, 28 December 2007 (UTC)
  • I Approve this proposal. -- MikeCollinson 15:46, 28 December 2007 (UTC)
  • I Approve this proposal. -- Myfanwy 03:03, 29 December 2007 (UTC)
  • I Approve this proposal. --Cohort 03:50, 29 December 2007 (UTC)
  • I approve this proposal--Walley 22:08, 29 December 2007 (UTC)
  • I Approve this proposal. -- Ulfl 12:31, 31 December 2007 (UTC)
  • I approve this proposal. --Gummibaerli 23:37, 3 January 2008 (UTC)
  • I approve this proposal. --Cartinus 12:19, 9 January 2008 (UTC)
  • Voting close 11th January 2008
  • Proposal Approved

node for waterway=dam

--acrosscanadatrails 13:47, 17 July 2009 (UTC) in the GeoBaseNHN import, a single node can be presented for those dams which are really small, and the rivers are represented by ways rather than areas. Can I import these, even though they dont yet get rendered?

Constructed dam (infrastructure) should be man_made=dam

Because of ambiguity of the meaning of the word dam, the constructed barrier should rather be in the man_made=* namespace. --Skippern (talk) 16:49, 15 April 2015 (UTC)

Sounds reasonable but with 100k objects mapped this ship has sailed unless a mass-edit is made which is not worth the hassle imho. Also weir and lock_gate have the same problem.--Jojo4u (talk) 17:33, 26 June 2015 (UTC)
Historic note for reference: They could co-exist, as in the beaver dam example above (and landslide dams, etc) for natural=* features. In theory, it is only that man_made=* is assumed for waterway=dam, like many other features/tags. waterway=* in itself means a waterway feature only. The key says nothing about the value's origin. -- Kovposch (talk) 20:53, 29 February 2020 (UTC)
Resolved: Feel free to make proposal to change tagging in this way, but I would not expected a success Mateusz Konieczny (talk) 21:29, 9 December 2020 (UTC)