Template talk:Infobox river

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Rivers (Rated Template-class, Top-importance)
WikiProject icon This template is within the scope of WikiProject Rivers, a collaborative effort to improve the coverage of Rivers on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Template  This template does not require a rating on the project's quality scale.
 Top  This template has been rated as Top-importance on the project's importance scale.

Revision suggestions[edit]

May I suggest some minor revisions to the template:

  • Change "origin" to "source" since that is the generally accepted term for the start of a river
  • Change "watershed" to "catchment area" or "drainage area", since watershed means different things to US and non-US geographers
  • Change "basin countries" to "location" since, for large countries like USA, Russia or Germany, it is too vague. "Lower Saxony and Hesse, Germany" is a good location descriptor but they are not basin countries.
  • Slightly increase the field name column, so that names with 2 words can still fit on one line and don't unduly extend the table
  • Slightly increase the data column, so that a full coord can display on one line (see problem at Gerdau (river))
  • Consider tweaking the format to include lines (as at de:Böhme (Fluss)) - looks neater IMHO.

--Bermicourt (talk) 12:06, 6 October 2009 (UTC)

Suggest that we harmonize the display order of Imperial versus SI units. I just spent more time than I'd like to admit in trying to figure out why the Niagara River apparently had less flow than the Colorado River, despite draining an almost equal area in a wetter location, until I realized the display order was reversed in the two pages so the Niagara does indeed have the greater flow. Now, the Colorado River page uses Geobox, but apparently the River template has options for changing the display order, which is confusing, in my opinion. (talk) 21:55, 2 November 2014 (UTC)

Is there a reason why river classification (ie. blackwater, etc.) is not included in the template? I think this is a good idea Valerie (talk) 20:12, 8 April 2016 (UTC)

Also, why is the template not a Geobox? Valerie (talk) 21:45, 8 April 2016 (UTC)

Template cleanup and improvements[edit]

Scan results[edit]


  • origin_long_s → source1_long_s
  • origin_lat_s → source1_lat_s
  • origin_long_m → source1_long_m
  • origin_lat_m → source1_lat_m
  • lakes → waterbodies
  • origin_long_EW → source1_long_EW
  • origin_lat_NS → source1_lat_NS
  • origin_lat_d → source1_lat_d
  • origin_long_d → source1_long_d
  • native_name_lang → name_native_lang
  • native_name → name_native
  • blank_name → custom_label
  • blank_info → custom_data
  • other_name → name_other
  • image_map → map
  • right_tribs → tributaries_right
  • left_tribs → tributaries_left
  • discharge → discharge1_avg
  • watershed → basin_size
  • elevation → source1_elevation
Rename (with template conversion)
  • discharge_cuft/s → discharge1_avg
  • elevation_ft → source1_elevation
  • discharge_m3/s → discharge1_avg
  • mouth_elevation_m → mouth_elevation
  • elevation_m → source1_elevation
  • watershed_sqmi → basin_size
  • watershed_km2 → basin_size
  • origin_coordinates → disperse this over source1 coordinates
  • mouth_coordinates → disperse this over mouth coordinates
  • length_mi → length
  • mouth_elevation_ft → mouth_elevation
  • length_km → length
Rename (only if simultaneous with any of above)
  • caption → image_caption
  • location → basin_cities
  • image_name → image
  • mouth → mouth_location
  • origin → source1_location
  • river_name → name


Hi. As some of you may already be aware, I have been working on a revamped version of this infobox here. Since it is now almost complete, I would like to bring it up here for further discussions/improvements before we roll it to the main template space. To summarize, some of the main changes are as follows:

  1. New parameters has been added to enable a more detailed infobox. You can see the full skeleton (with dummy details) in the link above.
  2. Looking at the existing doc page, you will notice that it is extremely long, mostly because conversions are hardcoded into the template. Infoboxes should not have hardcoded parameters with a specific format to use (i.e. km or mi). The user should be the one deciding on the preferred unit depending on the article/subject (or the doc page should state so). Having these separate parameters also make the whole skeleton unnecessarily large. The best option is to simply move the fields to a more generic parameter (example: length_kmlength), and use the {{Convert}} template. To fix this:
    (a) The parameters are changed to a more generic parameter (example: length_kmlength), with the use the {{Convert}} encouraged. But of course;
    (b) The old parameters will be simultaneously functioning (still working on it), while in the mean time, a bot will sweep through articles to
    (c) Scan for incorrect parameter usages (i.e errors), usages of non-existing parameters, and also to standardize parameter usage.
  3. The bot sweep will be done in one go, and hence will give us a good opportunity to tidy-up and stylize the parameters simultaneously, even if the changes are trivial. If you look closer at the new template skeleton listed on the sandbox-doc page, changes like native_namename_native and left_tribstributaries_left makes the overall skeleton look much neater thanks to the ordered prefix.
  4. The template also supports additional fields such as up to five sources and mouths, waterbodies, waterfalls, bridges, custom labels, free-form bottom section, etc. See the link above.

Please share your views if you think there is something we could do better. I will keep this thread open for about a week so we have time to discuss before rolling the new version, while looking at the bot results to determine the best way forward. Cheers, Rehman 15:49, 26 January 2016 (UTC)

Looks pretty impressive overall!
I think I spotted a typo in one of the parameters: shouldn't "basis_cities" be "basin_cities"? Also some additional river-specific parameters that would be useful are:
  • "river system" i.e. the parent river system that the river is part of
  • "index number" i.e. the official (usually national) hydrographic index number for the river. Used in the USA, Canada, Germany, Austria, France, Russia, etc.
  • "navigability" i.e. when and where the river is navigable
  • "ports" i.e. inland ports along the river
  • It might also be good if the discharge and water levels could be associated with a location e.g. one or more named river gauges along the river. If that's difficult, it could be added at a subsequent stage
Hope that helps. Bermicourt (talk) 17:26, 26 January 2016 (UTC)
Thank you. :) Yes, basis should be basin, good spotting. I agree with your points 1, 2, 4, and will add them soon. Would you be able to provide an example on the type of content that should go in navigability? While it sounds like a good addition, sentences/longer text are not allowed in infoboxes (the same reason I am thinking of starting a discussion regarding the etymology field, after this cleanup). For your last point, do you mean to add something like a location field for the depth and discharge sections (similar to the source1 section)? I'm off to work now, will look into it deeper when I reach back home (in about 12hrs), or if I can sneak in while in office. Regards, Rehman 00:00, 27 January 2016 (UTC)
@Bermicourt: I went ahead and added river system and ports. For index numbers, it can be slotted into the custom_label/custom_data fields for now, as only a limited number of articles have such information... Waiting for your reply on "navigability" and "discharge location". Rehman 14:18, 27 January 2016 (UTC)
I have moved further replies regarding discharge data to new section "Discharge data" below, as it involved adding/improving additional fields. Rehman 13:39, 29 January 2016 (UTC)
Rehman, can you provide an example of a river with more than one mouth? from what I have read, a river can have many sources, but only one mouth, but I could be wrong. if there are no articles about rivers with more than one mouth, we should probably remove the numeric suffix from the mouth parameters. Frietjes (talk) 22:55, 2 February 2016 (UTC)
Frietjes: I think you are right. I did a search and did not find any river that has two or more mouths. And even if there is, I'm quite positive that there would not be more than a dozen at max. I will remove the multiple-mouth parameters shortly. Thanks for pointing out! Rehman 14:08, 3 February 2016 (UTC)
Rehman, if we are not going to have |source1_coordinates=, we will need |source1_iso_region= (see {{infobox lake}}) and |source1_ref= or |source1_footnotes= (again, see {{infobox lake}}). Frietjes (talk) 00:59, 11 February 2016 (UTC)
Hmm... Do we have a template somewhere that could auto-convert and generate the region code from the basin_country parameter? Either way, I agree with you that we need to include the region code. But I am leaning towards not having an inline ref for the coord, as that is something that is very rarely available (most of the coords on wiki are manually derived by editors, and not stated on a source itself), and in my personal opinion, clutters the infobox. Rehman 16:01, 12 February 2016 (UTC)
There are certainly rivers with multiple mouths. The Grand Calumet River, arguably the Chicago River, the Amazon. Rmhermen (talk) 03:44, 11 February 2016 (UTC)
I see. in that case, we should probably default to |mouth_location=, but allow for |mouth2_location= as the need arises. In the case of Amazon River, it seems like it's more of a Delta region, since there are so many. Frietjes (talk)
Yes, the Amazon River case is a delta. Also, those examples doesn't seems to be valid as those are more or less due to human-modifications of the mouths. And even if an "all natural" dual-mouth river exist, I'm quite certain that there would be less than, say 5? I dont think we should include parameters that will be used just for a very few articles. For those cases mentioned above, we could simply include the main mouth, or use </br>.
If for any reason, we do add support for multiple mouths, I strongly suggest we add the mouth1 prefix. That gives the editor an easy understanding that multiple entries are supported, and makes the skeleton look neat. Rehman 16:01, 12 February 2016 (UTC)


the right/left tributaries look pretty bad in Speyerbach, with text overlapping on my browser. would be better to just use two fields, rather than a table. Frietjes (talk) 21:00, 19 February 2016 (UTC)

Coordinates display[edit]

Like other templates that accept geographic coordinates, this one needs a way to "turn off" the title display (of the mouth coordinates, in this case) to avoid overlapping coordinates in the title position when more than one infobox is used in an article. See Big Sandy Creek (Illinois), for example. I know little about template coding, but there has to be a way of overriding the "title=y" for the mouth coordinates. Deor (talk) 12:11, 21 April 2016 (UTC)

Hi Deor. The template is currently undergoing some maintenance. I'll definitely add this along with the other updates (which is pending a bot sweep). Rehman 14:57, 21 April 2016 (UTC)
Deor, fixed, thank you for noticing. Frietjes (talk) 15:11, 21 April 2016 (UTC)
Ah, Frietjes, we meet again. You might want to consider the case of River Cleddau with reference to this and the SSSI template. As we have it right now, the River Cleddau article describes two rivers, the Eastern and the Western River Cleddau which meet at a common mouth. That doesn't fit with this template well (and I acknowledge that River Cleddau could be split into two articles, one for each component river.) In addition, Eastern & Western both are SSSI; Eastern plus Western is a single Special Area of Conservation; and there's a second SAC at the head of the Eastern. So. A veritable template Clapham Junction, I think. Any thoughts on how we proceed, template-wise, much appreciated. --Tagishsimon (talk) 23:29, 23 April 2016 (UTC)

Gibberish parameter names[edit]

I've tried to change several vague and pretentious parameters on the template, but have been reverted multiple times for no reason. Specifically, "physiognomy" should be "physical characteristics" since the former appears to be some ind of pretentious term used solely to sound wordy and impressive, whereas the latter actually describes the parameter. Also, "size" is senselessly vague, so I tried to change that to "watershed area", but was again reverted for no reason. --Jakob (talk) aka Jakec 01:33, 1 June 2016 (UTC)

Both of these changes seem sensible to me. Physiognomy appears to be plain wrong; "physical characteristics" works well. And "Size" does indeed seem ambiguous. The variable is "basin size" and this does seem akin to Drainage basin - I'd support that as the label rather than watershed. I'm hoping that Rmhermen will give us the benefit of their thoughts on this, so that we can move on. --Tagishsimon (talk) 11:55, 1 June 2016 (UTC)
I prefer Jakec's suggestions. But either way, edit warring was not the way to go, and Rmhermen was not wrong in reverting as this is more of a personal preference. Rehman 13:50, 1 June 2016 (UTC)
I too prefer the suggested changes in both cases. Characterizing the current ones as "gibberish" seems unnecessarily hostile. --TimK MSI (talk) 02:13, 2 June 2016 (UTC)
Physical Characteristics is a better descriptor, but Watershed is an Americanism in this context. Basin Area would be a better term, linked to Drainage Basin...Jokulhlaup (talk) 14:14, 2 June 2016 (UTC)
Since it seems there's now "consensus", can someone please change it back. BTW I am fine with "basin size" (anything is better than "size") though perhaps "basin area" would be even more specific. --Jakob (talk) aka Jakec 23:50, 3 June 2016 (UTC)
I've went ahead and changed it to "basin size" (as the parameter is also called that). Thanks, Rehman 00:04, 4 June 2016 (UTC)

Standardising on one template[edit]

River Penk
River Penk upstream at Penkridge - geograph.org.uk - 1443825.jpg
The River Penk at Penkridge, with Penkridge Viaduct in the background.
Country England
County Staffordshire
 - left Moat Brook, Whiston Brook, Pothooks Brook, Rickerscote Drain
 - right Watershead Brook, Saredon Brook, Deepmoor Drain
Towns Anytown1, Anytown2, Anytown3
Source Perton, South Staffordshire
Mouth Confluence with the Sow
 - coordinates 52°48′12″N 2°04′55″W / 52.80333°N 2.08194°W / 52.80333; -2.08194Coordinates: 52°48′12″N 2°04′55″W / 52.80333°N 2.08194°W / 52.80333; -2.08194
Length 36 km (22 mi)
Basin 356 km2 (137 sq mi)
Discharge for Penkridge
 - average 2.27 m3/s (80 cu ft/s)
Wikimedia Commons: River Penk
Progression : Penk—SowTrentHumberNorth Sea
River Penk upstream at Penkridge - geograph.org.uk - 1443825.jpg
The Penk at Penkridge, with Penkridge Viaduct in the background.
Country England
County Staffordshire
Main source Perton, South Staffordshire
River mouth Confluence with the Sow
52°48′12″N 2°04′55″W / 52.80333°N 2.08194°W / 52.80333; -2.08194Coordinates: 52°48′12″N 2°04′55″W / 52.80333°N 2.08194°W / 52.80333; -2.08194
Progression SowTrentHumberNorth Sea
Basin size 356 km2 (137 sq mi)
Physical characteristics
Length 36 km (22 mi)
  • Average rate:
    2.27 m3/s (80 cu ft/s)
  • Left:
    Moat Brook, Whiston Brook, Pothooks Brook, Rickerscote Drain
  • Right:
    Watershead Brook, Saredon Brook, Deepmoor Drain

Wherever possible, we should replace {{Geobox}} with a more specific template, such as this one, instead of {{Geobox|River}} (examples above; geobox first). Here's a sample conversion. How might we speed up, or automate, this prcess? What are the barriers to doing so completeley? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:28, 1 June 2016 (UTC)

As discussed elsewhere some time ago, there is a bot sweep currently in progress (by SporkBot) - see section above. Once that is done, it will be fairly easy to switch articles to use this template, as all the necessary fields of Geobox are now in Infobox River. Or if you like, you may wish to manually change articles for now, or request a separate bot task to change the uses of Geobox to this template. P.s. I have collapsed the infobox examples which you have provided, hope you dont mind. Regards, Rehman 14:47, 1 June 2016 (UTC)
Until there is a way to present information in Infobox River in a way that is best-suited to the size and geographic extent of the river being described, I would strongly, strongly oppose a sweeping effort to switch from one infobox to another, especially an automated effort deployed just for the sake of switching, without regard for whether the change from one to the other constitutes an improvement to a given article. Looking at Sycamore Creek (Michigan), it appears to me that a switch from Geobox to Infobox River would wipe out the state, county, municipality, and township fields. It would also, illogically for a stream that flows through one U.S. state only, present to the reader first the location of the source (someplace in Michigan), then the location of the mouth (someplace in Michigan), and only THEN tell the reader that the stream's watershed is in the United States. Presenting "basin countries" AFTER the source and mouth information might make sense for large multi-country rivers, but most rivers aren't large. And the infobox's political jurisdiction options won't currently accommodate whichever levels of jurisdiction are most relevant to the size and geographical extent of the river being described, as the Geobox does. I think improvement of the information being communicated in an article ought to be the primary consideration when deciding, on a case-by-case basis, to switch from one infobox to another, and I don't think a switch to Infobox River in its current form would improve the Sycamore Creek (Michigan) article. In this case and many others, I think such a change would reduce the quality of the information provided to the reader. --TimK MSI (talk) 02:11, 2 June 2016 (UTC)
@TimK MSI: In his reply above, User:Rehman says "all the necessary fields of Geobox are now in Infobox River". Are you saying that that is not the case? Otherwise, what changes would you say are needed to this template, to satisfy your concern? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:12, 2 June 2016 (UTC)
Yes, I'm saying that all the necessary fields of Geobox are not in Infobox River, and I pointed to several examples above as a start. I'll also point out that in the River Penk example shown, the "Counties" field was stripped out in the change to Infobox River. --TimK MSI (talk) 12:39, 2 June 2016 (UTC)
Strongly agree with TimK, a mass change from Infobox to Geobox is not supported by WP:INFOBOXUSE. The Geobox has the advantage of inbuilt conversions, and a degree of adaptability, note how Staffordshire appears as a County in the Geobox (adapted from region), and can’t be included in the Infobox at all. In the example given, it looks better as a Geobox, maybe we should convert the Infoboxes instead...Jokulhlaup (talk) 14:05, 2 June 2016 (UTC)
I think the Geobox version looks bloody awful. But neither view is grounds for a separate template. We should standardise on one, and reach consensus as to what features, and style it should use. If your arguments are persuasive, then the end result will be more articles using your preferences! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:52, 6 June 2016 (UTC)
Completely agree. Lets have a proper discussion/vote as soon as the current tasks are complete. Rehman 23:38, 6 June 2016 (UTC)
Hi all. Together with the concern raised in the section immediately below, I went ahead and did the necessary corrections (as it doesn't impact the current ongoing bot task). The countries field at the bottom, and other key parameters not being where it should be was something that I overlooked when doing the template cleanup. Hope things are better now? Cheers, Rehman 13:45, 4 June 2016 (UTC)
@TimK MSI: Are you now satisfied that "all the necessary fields of Geobox are now in Infobox River"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:05, 22 September 2016 (UTC)
Thanks for asking, I'm away from my computer for a few days but I will investigate next week.--TimK MSI (talk) 12:11, 23 September 2016 (UTC)

Cities as "basin cities" vs "cities through which the river flows"[edit]

I'm curious why the only available "_cities" field is not simply used to list cities through which the river flows, instead of cities in its drainage basin. Pittsburgh and Denver are both in the Mississippi River basin but are far away from the Mississippi River. The "basin_cities" field would appear to encourage their inclusion in a Mississippi River infobox, but I don't think many editors/readers would find it desirable to include them. Would it be possible to "liberate" the "basin_cities" field from its connection to the river basin? Or, alternatively, to have an additional "cities" field that would be intended to accommodate only cities situated along the river? --TimK MSI (talk) 12:57, 2 June 2016 (UTC)

Hey there. I agree with what you said, including in the section immediately above. Lets wait a bit longer till the current bot maintenance is complete, before we go deeper into editing. If you're wondering, the current task is just a maintenance task to neaten out existing parameters in articles already using Infobox River. Cheers, Rehman 13:49, 2 June 2016 (UTC)
@TimK MSI, I went ahead and did the change as it doesn't really impact the current bot task. We now have a new cities field, which is for cities along the river. Cheers, Rehman 13:39, 4 June 2016 (UTC)
Thanks --TimK MSI (talk) 11:12, 7 June 2016 (UTC)
Rivers also flow through towns and other settlements, again this is where the adaptability of the Geobox is useful. I have altered the cities parameter for the Penk example to show three towns, without the need for a separate parameter...Jokulhlaup (talk) 10:46, 7 June 2016 (UTC)
Could we bring over the method used at Template:Infobox settlement? This uses fields named subdivision_type, subdivision_name, subdivision_type1, subdivision_name1, etc., up to subdivision_type6, subdivision_name6. This would allow editors to specify whichever political jurisdictions are appropriate to a given article (countries, provinces, states, counties, cities, towns, municipalities, townships, etc.) This solves the plural/singular problem as well, because the plural/singular form is set case-by-case in the subdivision_type* fields. --TimK MSI (talk) 11:12, 7 June 2016 (UTC)
Yes this is a better way to go. @Frietjes, may I trouble you for some help to add this support? I tried adding it, but I can't get it to work properly... Thanks in advance! Rehman 08:08, 6 August 2016 (UTC)
Rehman, added. the use of |subdivision_type1= sets the label and allows for use of |subdivision_name1=. if |subdivision_type1= is not specified, then |subdivision_name1= is ignored, and the value set by |country= is used instead. similar for |subdivision_type2=/|subdivision_name2=/|states= and |subdivision_type3=/|subdivision_name3=/|cities=. Frietjes (talk) 12:49, 6 August 2016 (UTC)
Many thanks, Frietjes! @TimK MSI, FYI. :-) Rehman 16:54, 6 August 2016 (UTC)

Format for specifying coordinates[edit]

See this RFC. basically, there is now a LUA module which can take a {{coord|XX|YY|ZZ|NS|AA|BB|CC|DD|EW}} as input and return the latitude and longitude from inside the template. since this is more compact than the method used by this template, the RFC proposes using this more compact method and deprecating the less compact form. Frietjes (talk) 12:12, 13 August 2016 (UTC)

What was the outcome of the RfC? Agathoclea (talk) 19:42, 22 September 2016 (UTC)


What is the new paramenter replacing location that is found in quite a number of infobox uses? Agathoclea (talk) 19:42, 22 September 2016 (UTC)

Hi. Any one of the below groups (depending on if any is used):
| subdivision_type1  = 
| subdivision_name1  = 
| subdivision_type2  = 
| subdivision_name2  = 
| subdivision_type3  = 
| subdivision_name3  = 
--Rehman 23:31, 22 September 2016 (UTC)