Talk:Tag:waterway=stream/Archive

This is an archive of old discussion. The current discussion is at Tag:waterway=stream

Please do not reply to discussions on here. Instead quote or move the discussion to the current discussion page

---

Opinion

Why not waterway=river, width=2m, depth=0.5m? Otherwise we'll end up with a whole family of tags (streambed, stream, large stream, small river, riverbed, river, big river, tidal river, estuary) all using unique tags when they're basically all natural flows of surface water, the only difference between them being dimensions like width, depth, flow rate, etc. Ojw 13:41, 24 September 2006 (BST)

Anything bigger than waterway=river can just be an area. I am very much for having waterway=stream and waterway-drystream (for streams that are only there after heavy rain). Perminently dry streams dont have much point though. If there just a dip in the land then the topography would show that. As for specifiying depth, that sounds inposible to do for most places. If it was there just to make clear whether the river/stream is suitable for swimming/kayaking/drowning etc, then couldnt addtional tags be put in, (like on footways). Swimming=Yes/No, Kayaking -Yes/no. (this would state the abilty to do so, rather than the legality.) I'm not completly clear on the law. But don't all rivers belong to the queen in the UK anyway? I think additional features such as waterway=rapids/Waterfall/Wear/Sluice etc are nessesery also. Ben. 14:25, 24 September 2006 (BST)

The maps of Oxford are currently looking a little silly in places, as steams are tagged as rivers, and coming out far too big. I think we should have waterway=river and waterway=stream, with implicit defaults widths on them, then allow people to set explicit widths if they know/care. That way, we can make it easy for people to get things roughly right, but allow them to get it exactly right if they are interested. Gagravarr 16:08, 24 September 2006 (BST)

I agree with Ojw and suggest waterway=yes, approx_width=x m, waterway:navigable=yes/no to avoid having too many tags for the same thing (flowing water). If we have waterway=stream and river, we also need brook, runnel, beck and so on. This is just too confusing. width=x m can be used if the width is known (measured). The same applies for depth; It is usually not known, but is nice to have. waterway=riverbed, flooding=yes might be a good way to tag areas that are usually dry.

Stating the Width and Depth is near inposible. They are so variable. The only time the width is really steady is when the river is wide (very). and in that case it can be an area, rather than a segment. For the depth. On the outside of a meander the river may be many feet deep, while on the inside it will be inches deep. Therefore how would this work? If you just have stream and river, this wouldnt be debating the 'name' of the waterchannel, so brook etc wouldnt be needed. It would just allow people to know that if it is a stream, then they tend not to have bridges built over them, or act act as any boundry in themselves, but rather a hedge row would be grown over them, and they run threw pipes. Labelling it as a dry river, would also be inportant, as if a person looks at the map and goes looking for a river in mid july, and finds nothing then it wouldnt be a problem if it was clearly marked as a river that is only there after heavy rain. Ben. 19:43, 24 September 2006 (BST)

• I've thought about this for a while as OJW's first comment above is a very valid one, a whole family of tags, probably culturally-influenced like "ghyll" is not a good idea. I've come to the conclusion that waterway=stream is still very useful and can co-exist with waterway=yes, approx_width=x m, waterway:navigable=yes/no. I think a subjective small (stream), big (river), bigger (defined by tracing banks) is vital for the early stages of OSM and being able to render reasonable maps from first-pass field data. Definition: A small naturally-forming waterway with normal banks judged to be generally less than 5m apart. In countries with dry-season, the water should run at least part of a normal year. Rendering: In a thinner line than a waterway=river tag. Rationale: Once I've done enough gps work in an area to work out any landsat adjustment, I trace in the waterways from landsat - either to give some substance to very large areas (Australia) or provide detailed mapping in local areas from memories of the area (UK). It is very easy for me to assign as stream or river, but I'd be very hesitant to try and apply widths and navigability. MikeCollinson 00:09, 3 December 2006 (UTC)

I don't wish to sound like I'm against moving forward, but it needs to be done correctly. I'm a kayaker, and have therefore seen a lot of rivers that just arnt simple enough to tag as is currently being suggested. OS 10,000 maps treat waterways as areas, with each bank being plotted and the area between is the water. I asume the depth is stored the same as topography on the land, not as 1 figure, but as lines. I think we should learn from there experience. Anyway.. Could these questions please be considered.

1) By waterway:navigable=yes/no, what means of transport does this refer to? A kayak can squeze threw tighter gaps than an oil tanker for example. Or is this just refering to the legal side?

2) Goind on the idea of a tag saying waterway:navagable, would waterway:width not seem more fitting?. It is also therefore clearer that it applies to waterways (just incase something else is along the way that also has its width stated). It would make rendering it way easier also.

Waterway=stream is very useful I agree, and use it frequently, but I hope that some day it can be removed as if more exact information is stated then that tag is unesesery. To make the width tag posible to use there are a few things that need considering. After many months of walking along waterways and mapping them, I'm still conserned about defining widths and depth. The width can be estimated easily, and is relatively stable as usually the banks of the river allow a change in depth with minimal width difference. However the problem still remains as to how acuratly it would be expected that its mapped. A small rivers width changes a lot between straights and corners. (e.g. river past my village at one point is 12 foot wide. If i walk 10 down river it is 4 footwide. The banks move diagonally inwards, so its not just a step. This would then mean i need to tag all the stages between to get an adiquat render.

If it is agreed that widths are just to be the average over a few hundred meters then this would be easier. Another consern is what large rapid rivers are tagged, the river sort of has edges, but a lot of bolders line the sides wich at one point may be dry and at another time may be 2 foot under. Highforce Lowforce in Yorkshire would be an example of this, where the widths can change greatly, and many sub river sections could become 1 raging torrent.

The proposal for depth still doesnt seem posible, and some ideas need to be throught of. Canals may have a common depth and a relitevly level base, but rivers do not. If the deepest section is tagged, that may give the inpression that any boat that goes into the water less than that amount could pass. But thats incorrect. The best example to learn from I think is how low bridges are marked in the UK. The maximum hight quoted allows for anything that hieght to have x feet (width) of room to fit threw. (About 8', 2.5meters) The bridge is actually higher in points. This still would be a problem if a large river had a range of deeper areas though.

Finally If a river is only there for part of the year, I think calling it a dryriver (or a more approprate name?), would be fine. If it was just tagged as a river, and people used the map, they may be confused why it isnt there. The difference with a dryriver and just an area that would have water rush over it in heavy rain would be a cutting wich is perminetly there, and in some way effects the landscape (e.g. hedgerow/side of track/has a footbridge over it. Ben. 21:15 16th December 2006 (UTC)

• To add my 2d worth, I have rivers near me (such as the River Quaggy and Ravensbourne River). These are much, much narrower than another river near me, the River Thames. Yet these are Rivers, not streams. However, because the former have been constrained to concrete channels, they are narrow. So these three differing waterways will be waterway=river. I suspect other rivers such as the Orinoco or Amazon are even wider than the Thames. Therefore, we definitely need a method to render the Orinoco different from the Thames, from the Quaggy. Like any river, the Thames is of substantially different widths along it's entire length. I therefore see no option but to have an optional width= tag. Some rivers are constrained by man-made concrete river banks, some have a gently sloping natural river bank. Perhaps the river names should somehow reflect the type of bank, or we should have a tag to define the type of bank.NickH 19:15, 15 December 2006 (UTC)
  • For wide rivers, see Proposed_features/Large_rivers which although proposed, is currently in use for parts of the Thames, see Putney. Dmgroom 20:23, 15 December 2006 (UTC)

• A river and a stream are very different. I have enough experience of seeing and limeited experience being in them both by craft and by wader to realise this. I recently reluctantly tagged a stream as a river, but have changed it to a stream as it is far too large and it could never be called a river. Although looking at it clicnically you could just say rivers and streams have different widths and depths people rarely use river and stream interchangeably. Only on very marginal cases. Also for streams there widths and depths are very variable along there length, and period of the year. Whereas, unless tidal rivers often have relatively more accurately definable bounds. I think that waterway=stream should definetly exist. For dry rivers and streams there should be a diferent tag but I'm not sure what. Brooks etc.. would not be necessary if stream is chosen. This can be done with name=Abrook Brook. Also I'm not sure if it exists already but I also think that river=tidal should exist as well as river=rapids, river=waterfall and river=underground. Ksbrown^talk 19:31, 6 March 2007 (UTC)

• Indeed, I cannot see how having waterway=river and waterway=stream is any different to having the widely accepted highway=primary and highway=secondary etc. tags. Sure, those who have the time could go out and measure the approximate width, but why not have the basic stream/river tags to allow the base OSM data to be built up quickly. I'd be happy to tag a stream or a river as such, but would be more likely to avoid the issue if I had to work out widths and (especially) depths. roundel^talk 18:24, 7 March 2007 (GMT)

Proposal

I've mapped a few 10's of miles of rivers and streams now and have noted down the widths, but not depths. I have said a lot above, but I think this discussion is really going nowhere. I have thought about it a LOT, and looked at how OS have done it and I think the following should be how waterways are done, and considered what was said above. I've come to this conclusion.

Natural=water should be used for linear rendering as well as closed ways. The waterway tag should be used for political status; so natural=water; waterway=canal; access=public for example. Rivers can be linear and tagged river_width=x, and render using the combination of the 2 tags. The small river usually has short steep banks so when the river height rises/lowers the width is still easily estimateable, for larger rivers the widths stay stable, the problem is when the banks are not parelell.

now..I said natural, waterway and access, for the canal, becuase then it splits up the 3 facts, that a canal is a man made channel of water, its public, and its full of water. phisical/access/use. etc. Currently I think waterways is going in the same direction as highways where discriptive, access, and status are muddled up.

Natural=water areas can be added for lakes, or deformities in the way the linear way renders. After this width rivers seem to nearly always require closed ways to mapped them correctly, and I think that making this easier requires more than a tag. An editor needs to display, in real time, the extremities of a river, relative to the river=width tag that you have given it. This way altering the shape of the river width natural=water will be easy, while at the moment it would be tricky and involve a edit/render/compare/edit/render/compare method of working.

For depths, I haven’t added it, and probably won’t most of the time, but for people who wish to, and have reliable data I think it should be tagged in 2 ways.

1) like topographical lines on the land, closed ways (rendering linear) mark lines of equal depth in the water

2) Along the line of travel along the river the depth is added along the way. Its only relevant to the node that has the tag, and if a river has 3 channels down it, and 3 main navigable routes, then 3 routes would each have the data on them individually.

Going with this idea, This is how I would map the following image

A) A wide section of the river. natural=water; area=yes, and then the waterway=river down the river route line, wich may have water_depth=x on it.

B) A narrow bit of the river. Rather than tag the river width and have many small ways gradually bringing down the river width smoothly, an area should be added. The waterway=river in the center would then need an additional tag, to stop it rendering as the default river size, (render=no?) or the average width size, wich would exceed the narror area.

C) The area opens out into a lake. The center way is waterway=river, the sides are natural=water area=yes

D) An island. Landuse=none/land layer=1 (water+1)

E) A waterdepth line. Water_depth=10

F) A stream. Natural=water width=1

G) The river contiues off just as a way

H) Natural=water; area=yes

As a round up. To fully map all waterways I think we need

• Natural=water (linear)
• Waterway=river (for routes)
• Access= public/private etc)
• River_width=x (it could just be width, but river_width is clearer for this)
• River_depth=x (again, it could just be depth, “ “)
• Area=yes (proposed)
• Landuse=none/land (in osmarender rulesheet? Maybe standard)
• Render=no (to stop rendering where things usually render by default. (similar to residential/abutters debate))

In the long run I don’t think river=stream will be needed, although currently I use it a lot, but really its just a lesser river, and a tempory solution. For people thinking that it would take a lot of effert to use all the tags above they wouldn't all be needed, just as highway=unclassified is enough to get a render, but there are many many additional tags that can go with it.

So what do people recon to trying to lay out the waterway tags more methodically, and move on from the archaic, and basic way we go about mapping waterways at present? Ben. 05:54, 8 March 2007 (UTC)

From my point of view, as someone interested in adding waterways in a fairly basic way, your illustrations terrify me :-) However, if I were able to continue mapping them with single ways, and with a roughly estimated width characteristic -- i.e. judged by walking past it or even from (usually aerial) photos -- then I'm fine with your proposal. Perhaps it needs double the tags for measurements, i.e. river_width_estimated and river_width_measured? Oh, and if we mark a way as "waterway=river" can we take "natural=water" as implied? TomChance 09:12, 8 March 2007 (UTC)

• Yeah, If people are not interested in going into detail on rivers, they can continue mapping with single ways to show the basic path of a river.
• Waterway=river would make natural=water inplied, yes. I guess I see it in the same way as landuse=wood and natural=wood. Both may appear together, but they also mean differnet things, and can appear alone. I think waterway= meeds to indecate basic navagabilty of the natural=water (river) area. If there is a river with is completely overgrown, or just marsh like, then rather than it being a river or a stream, It would just be natural=water. In this case I imagin if somebody is only tagging rivers rougly, they would add this as a natural=water or marsh area anyway.
• I agree its important to be able to tag data that goes into the system by how definate it is. I don't mind how, but I agree if a width (or anydata) is guess work rather than a good guess or dead acurate measurment then it should be somehow tagged as so, so that people in the future don't get put off from changing the data to make it more acurate. Maybe this should just go under source= as guesswork or traced? Ben. 01:21, 9 March 2007 (UTC)

Vote

Voting on the following (Added after 3 votes, so Please confirm this is what you have voted on)

• Natural=water
• Waterway=river
• Access=
• width=x
• est_width=x (Added in relation to Tom Chance's point)
• depth=x
• est_depth=x (Added in relation to Tom Chance's point)
• Area=yes (proposed elsewhere..)
• Landuse=none/land
• Render=no

Some already exsist, but I've stuck them here, as the vote should conferm their exact useage

---

For the proposal as outlined by Ben, with the ability to distinguish between measurements and guessed values.

• I approve this proposal. TomChance 17:50, 25 March 2007 (BST)
• I approve this proposal, but I was expecting some more discussion first... Ben. 18:25, 25 March 2007 (BST)
• I approve this proposal, but I would like to suggest some changes.

a) I would rather be able to use width then river_width. This is shorter and easier to type (and remember). I don't say street_width or castle_heigth for other features either.

b) I would like to keep waterway=stream as a synonym for waterway=river;width=0.5m as I find that a useful distinction and shortcut --spaetz 20:59, 25 March 2007 (BST)

• I agree I think. width and depth would drop the 'river_' Unless there is disagreement to that. Ben. 21:14, 25 March 2007 (BST)

• I approve this proposal. Janko 12:08, 12 February 2012 (UTC)