Template talk:Infobox river

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Rivers (Rated Template-class)
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.

Mouth and Source Coordinates[edit]

Could a field be added to give the coordinates of the mouth, perhaps using the {coord} template? A field could also be added for the source coordinates using coord, useful if the source were not some other geographic feature already tagged with coordinates (EG not a lake). papageno 01:28, 3 November 2007 (UTC)

Good idea! Markussep Talk 09:08, 3 November 2007 (UTC)
The other river infobox {{Geobox River}} has fields for source and mouth coordinates. You might consider converting the infobox for rivers you want to add coordinates to, to this other template. Markussep Talk 15:24, 30 November 2007 (UTC)

Please see discussion of coordinates at WikiProject Rivers. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:06, 9 September 2008 (UTC)

The above linked discussion is now archived here. related discussions are at Wikipedia talk:WikiProject Rivers/Archive 2#Geographical coordinates and Wikipedia talk:WikiProject Rivers/Archive 2#Use of Co-ordinates on river pages. --AussieLegend (talk) 11:38, 22 September 2012 (UTC)


I went and upgraded the template so that it would convert to and from imperial/US and SI. I hadn't realised that it was being replaced with a new version. I'll document the upgrade but put a depreciated tag on the page. JЇѦρ 05:37, 15 April 2008 (UTC)

Image size[edit]

The discussion page notes the default image size of 288px. This is great for horizontal images, but too big (in my opinion) for tall ones. Any way to override the default? See my problem at: St. Croix River (Nova Scotia) Verne Equinox (talk) 00:30, 11 September 2008 (UTC)

  • I concur. This box is usefull but size is distracting. It dominates some articles I'm working on. My contributions
    Can one of you infobox gurus please add the operator: width= to control box size.

Also same request for Template:Infobox Waterfall. Thanks Marcus (talk) 18:38, 5 October 2008 (UTC)

Possibility of expanding to cope with German Wikipedia articles[edit]

German Wikipedia has its own equivalent of this infobox (but with a few more parameters). It would considerably aid the transfer of articles from de.wiki if there was an infobox on en.wiki which recognised the German field names and automatically translated them into English and I could quite easily create this. However that would mean a second infobox (called Infobox Fluss) with a similar purpose. However it should be possible to expand this one to cope with the German fields by using a redirect and adding the extra coding required. Obviously the German coding would not be noticed by articles created in English from scratch. Is there merit in doing this (I might need some help) or should I create a separate template? --Bermicourt (talk) 15:52, 22 March 2009 (UTC)

It is possible to modify the Infobox River in order to use German infobox information. The same has been done for town infoboxes ({{Infobox German location}}). Once that has been done, {{Infobox Fluss}} can be a redirect to Infobox River. I see the German infobox has more fields than the English one, I'm not sure we need all that information. Markussep Talk 15:08, 23 March 2009 (UTC)
Sounds cool! Although the German infobox does have more fields, in some cases they display two fields as one e.g. source name and coords are separated in the infobox but display together, whereas the English infobox sticks all the data in one field. The end effect is similar. --Bermicourt (talk) 20:55, 23 March 2009 (UTC)

Let me see which fields could be merged:

  • NAME = river_name
  • BILD = image_name
  • EINZUGSGEBIET = watershed
  • LÄNGE = length
  • QUELLE = origin
  • QUELLHÖHE = elevation_m
  • MÜNDUNG = mouth
  • MÜNDUNGSHÖHE = mouth_elevation_m
  • ABFLUSSMENGE = discharge

The other fields can't be used directly, but have to be translated or converted. Markussep Talk 18:11, 24 March 2009 (UTC)


I've added a "progression" parameter; which can be seen in use on River Penk to describe the path taken by the waters of a river which is a tributary of one or more other rivers, and does not empty directly into a sea or lake. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:26, 21 September 2009 (UTC)

River system[edit]

I've added a "river system" parameter, corresponding to the de.wiki "Flusssystem" one. So now German rivers at least can be easily updated. --Bermicourt (talk) 12:06, 6 October 2009 (UTC)

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)


I have proposed that we delete {{geobox}}. That may effect this templates. You are invited to particiapte in the Geobox deletion dicussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:56, 3 January 2012 (UTC)

Geobox, again[edit]

It seems, from comparing the before and after version of this edit, that {{Geobox}} has more features for rivers than this template. I propose that we improve this template to match, then deprecate the river-specific instances of Geobox. Thoughts? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 30 June 2013 (UTC)

Strongly oppose - what is the basis for deleting this functionality of Geobox (and I presume eventually the whole template)? What policy or even guideline says Wikipedia cannot have two similar but not identical templates? Why spend all the time and effort to change this template and then to replace Geoboxes in river articles, when we have a Geobox that already works well and (as you admit) does more than Infobox:River? By the way, glad to see that you are feeling better and back on WP Andy. Ruhrfisch ><>°° 15:03, 30 June 2013 (UTC)
I seem to recall answering this question more than once previously. Perhaps you weren't one of those participating at the time. The rationale is to reduce the long-term maintenance overhead; unify the appearance and location of information in related articles for the convenience of our readers and data re-users, and to minimise confusion for editors. Conversely, what is the rationale for having two, different, templates for the same function? As for the work involved, feel free not to do any of it. Thank you for your kind words about my health. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:45, 30 June 2013 (UTC)
Oh wait, you were involved. Here's what you said: "if you want to get rid of Geobox, then 1) fix the infoboxes so they can do everything Geobox can, and 2) make sure it is as easy as possible to convert from one to the other, then ask again". That's exactly what I'm doing. It's already been done for mountains and mountain ranges, without fuss. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 30 June 2013 (UTC)
Thanks for your reply. I have changed my mind (especially as I would have to do the work of updating the river articles I am the chief contributor to if this comes to pass). Wikipedia allows editors fairly wide leeway on how they do many different things here (please see WP:IAR). One example is that there are at least three different ways to cite references (with many similar but not identical templates). Are you going to "unify" those too?
Also, could you please answer my question "What policy or even guideline says Wikipedia cannot have two similar but not identical templates?" While you're at it, what policy or guideline says that we need to make life easier for our data re-users? This is a persistent theme in your posts Andy - do you have a conflict of interest? Are you being paid by any of these data re-users? Are you being paid to make things on WP more convenient? I am going to post about your proposal on the Geobox and Wikiproject Rivers talk pages (which I think you should have done already). Ruhrfisch ><>°° 17:38, 30 June 2013 (UTC)
Your assertion that you would have to do any work in this regard is false; I even said as much above. My declaration of interests is available from my user page. I shan't be wasting time, attempting to answer rhetorical questions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:45, 30 June 2013 (UTC)
Andy, when it says here (about you) that "His advice has been sought recently by organisations including Google and FourSquare (on their use of Wikipedia data); and The BBC, Facebook and the London Assembly (on microformats)." was that paid advice? Do you have a COI? Are you being paid to edit and/or get rid of templates that Google, Facebook, the BBC and other re-users do not like? These are serious questions, not rhetorical.
I ask again (and not rhetorically), could you please answer my question "What policy or even guideline says Wikipedia cannot have two similar but not identical templates?" While you're at it, what policy or guideline says that we need to make life easier for our data re-users? I will add a question - where are there examples (on talk pages or elsewhere on WP) of users or editors confused by this template? Ruhrfisch ><>°° 18:04, 30 June 2013 (UTC)
I refer you to my earlier answer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:15, 30 June 2013 (UTC)
RE "what policy or guideline says that we need to make life easier for our data re-users", uhm, let's see, we what to make things harders for editors and readers so the site is used less and we have fewer editors helping, yeah right. I don't think so! PumpkinSky talk 18:30, 30 June 2013 (UTC)
PumpkinSky - do we write Wikipedia for general readers or to make it easier for Google, etc. to mine the data? The latter is what I am asking about re data re-users (as far as I know, we have very few corporations who are editors). I am also not aware of any complaints about information presented in any Geobox by general readers. Ruhrfisch ><>°° 20:35, 30 June 2013 (UTC)
My impression is that this represents a huge amount of labor work that won't really add or subtract anything of value to existing river articles. I'm neutral about this change, but as an editor I'd rather spend my time on actually writing articles. Shannon 20:46, 30 June 2013 (UTC)
I often disagree with Andy's position on deleting templates but sometimes he does have good ideas and I do believe that this template could do with some changes to enhance its functionality. I've tried using it in a number of Australian river articles and always found it to be lacking, so I've had to use Geobox. Geobox has its place, so I wouldn't support deletion. --AussieLegend () 23:42, 30 June 2013 (UTC)
As an example, I've created a testcase here. --AussieLegend () 01:38, 1 July 2013 (UTC)
Useful, thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 1 July 2013 (UTC)
"I'd rather spend my time on actually writing articles" No-one is stopping you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 1 July 2013 (UTC)

Strongly oppose. I donate my time and skills to the general public, not to for-profit data re-users who might wish me to edit as they see fit rather than as I see fit. I doubt that many Wikipedia editors want to work for free for Google or any other outside entity. Finetooth (talk) 00:04, 1 July 2013 (UTC)

If you don't want data re-users - many of whom are members of the general public, or not-for-profit organisations - to reuse your work on Wikipedia - which is perfectly acceptable under the licence you grant - then why are you editing? In any case, ease of data reuse is just one, small, part of the rationale for this change. Do feel free to address the suggestions I've made, to improve this template, though. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 1 July 2013 (UTC)

Unfortunately, I have to have emergency eye surgery tomorrow, and after that won't be able to edit Wikipedia for a week or two. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 1 July 2013 (UTC)

Andy, the issue that concerns me here is editorial control, which should never be ceded to a subset of the whole collective. By consensus, the collective has already rejected your proposal to eliminate geoboxes entirely. Your proposal to deprecate geoboxes is essentially the same proposal. The English Wikipedia and the Commons are parts of a commons managed collectively; anyone, including Google, may reuse the product (encyclopedia articles, data, images) under the terms of the GFDL and other licenses and may participate in seeking changes to existing policies and guidelines. However, participating in policy discussions is not the same as setting policy. That power should remain in the hands of the collective, which has already spoken on this matter.
I wish you a speedy recovery from the eye surgery. Finetooth (talk) 15:53, 1 July 2013 (UTC)

Strongly support improving this template. Why wouldn't we want it to be as comprehensive as possible? The issue seems to be whether we then remove functionality from geobox. Personally I find that template confusing, unwieldy, and, often, less comprehensive. Frequently my question has been "which parameters do I need to extract for an article on rivers/mountains/islands/lakes?". But there seems to be divergence on that, so why don't we improve this template and then discuss the nature of geobox separately at that talkpage? Bermicourt (talk) 15:39, 1 July 2013 (UTC)

I don't think anyone opposes improving the infoboxes or, for that matter, the geoboxes. Andy's suggestion, however, is to replace geoboxes with infoboxes. That's the idea that has already been rejected. As it stands, editors who prefer infoboxes to geoboxes are free to use infoboxes. Finetooth (talk) 16:06, 1 July 2013 (UTC)
Andy's suggestion is "that we improve this template to match, then deprecate the river-specific instances of Geobox". There's no reason why we can't say yes to the first part and no to the second. It doesn't have to be an all-out oppose or support. I agree that editors should be free to use either infobox or geobox. --AussieLegend () 17:55, 1 July 2013 (UTC)

Strongly oppose - I made that edit to the Tame, and did it to improve the article, both in terms of information and as the Geobox has a better format and looks more professional. There are two other reasons I oppose this, one is that nearly 4 years have passed since someone asked for the Infobox ‘origin’ to be changed to ‘source’, yet nothing has happened. I can use the Geobox, with its extra functions and neater format today, and do not have to wait for some Infobox 2 to come around. The other reason is found at Category:Geobox usage tracking for river type which lists over 13,000 uses of the Geobox: river template, it would take forever to alter (and check) those articles for a new box. Jokulhlaup (talk) 17:04, 1 July 2013 (UTC)

Comment just to be clear, I do not oppose improving any template. What I strongly oppose is removing River (or any more) functionality from Geobox, in what I suspect is a very clever and patient and stealthy way of deleting the Geobox template (remove almost all the functionalities one by one, then say - "look at this poor thing, hardly used and doesn't do much, let's delete it"). I wish Andy a speedy recovery and all the best. Ruhrfisch ><>°° 03:16, 2 July 2013 (UTC)

Alternate proposal[edit]

Since the above doesn't seem to have gained any support, I'd like to propose an alternative, based on comments above. As User:Pigsonthewing has noted, {{Geobox}} has more features for rivers than this template. I propose that we improve this template to match the functionality of {{Geobox}}, or as much of the functionality as determined by consensus, to provide a simpler alternative to the more complex Geobox. Obviously, there are situations where Geobox may be more suitable, so it should remain unaltered for those occasions. --AussieLegend () 03:11, 10 July 2013 (UTC)

Fully support and would be grateful if my request above were taken into consideration as part of the improvement drive. --Bermicourt (talk) 07:38, 10 July 2013 (UTC)
Can I suggest a simpler alternative, would it not be easier to create blank templates for {{Geobox}} rivers at different levels of complexity. You could have a Starter version for simple streams, a Mid level for larger/complex rivers, and a Full version for complex situations such as dual sources etc. It is similar to the idea used in Infobox Mountains, where they have created blank templates for different parts of the world. The unneeded commands could be removed for the simpler versions, which would remove the size and complexity issues. There would need to be some explanantion/links from the WP:Rivers page so that they could be found easily. Jokulhlaup (talk) 16:52, 13 July 2013 (UTC)
{{Infobox Mountain}} was split out from Geobox; we can make various blank versions of Infobox river, once it's improved. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:22, 13 July 2013 (UTC)

what's the status on coordinates?[edit]

Not trying to reignite any old arguments, but what's the current best practice on adding geographical coordinates (source and/or mouth) to a river article using this template? (I'm contemplating trying to add some new fields to this template for that if necessary, but if someone else already has a plan for that I don't want to step on toes / duplicate effort.) —Steve Summit (talk) 23:29, 8 February 2014 (UTC)

sounds like a good idea, since {{geobox}} supports this. what parameters would you like to add? just |mouth_coordinates= and |source_coordinates=? Frietjes (talk) 14:50, 9 February 2014 (UTC)
I was thinking of source_lat_d, source_lat_NS, mouth_long_d, mouth_long_EW, etc. —Steve Summit (talk) 11:51, 10 February 2014 (UTC)
I've taken a stab at this. See below. —Steve Summit (talk) 05:45, 21 February 2014 (UTC)

new coordinate parameters[edit]

Okay, I'm adding several new parameters to make coordinate display and entry possible. For the moment I've made the changes to a sandbox copy of the template, but if there are no objections, and if no one finds any serious problems, I'll propagate the changes to the real template in a few days.

I'll describe the new coordinate syntax and template usage, but then I have a couple of questions I'd appreciate people's opinions on.

coordinate syntax[edit]

There are basically four ways to enter origin and mouth coordinates: as degrees, minutes, and seconds, as decimal degrees N/S/E/W, as signed decimal degrees, and with the {{Coord}} template. I'll illustrate each of these with an example:

degrees, minutes, and seconds:
| origin_lat_d = 42
| origin_lat_m = 30
| origin_lat_s = 40
| origin_lat_NS = N
| origin_long_d = 73
| origin_long_m = 12
| origin_long_s = 00
| origin_long_EW = W
| mouth_lat_d = 42
| mouth_lat_m = 55
| mouth_lat_s = 39
| mouth_lat_NS = N
| mouth_long_d = 73
| mouth_long_m = 39
| mouth_long_s = 35
| mouth_long_EW = W
decimal degrees:
| origin_lat_d = 42.5539
| origin_lat_NS = N
| origin_long_d = 71.1441
| origin_long_EW = W
| mouth_lat_d = 42.693
| mouth_lat_NS = N
| mouth_long_d = 70.790
| mouth_long_EW = W
signed decimal degrees:
| origin_lat_d = 42.1807
| origin_long_d = -72.3654
| mouth_lat_d = 42.1482
| mouth_long_d = -72.6217
{{Coord}} template:
| origin_coordinates = {{Coord|42.4654|N|71.3580|W|type:river|display=inline}}
| mouth_coordinates = {{Coord|42.6465|N|71.3025|W|type:river|display=inline,title}}

These examples are from the Hoosic, Ipswich, Chicopee, and Concord River articles, respectively, so you can see these new template invocations in action there.


For the moment, to get these coordinate parameters to work, you have to use my sandbox copy of the template, which is User:Scs/Sandbox/Template Infobox river. So to try it out, the first line of the template invocation would look like

{{User:Scs/Sandbox/Template Infobox river
| name = ...

(It's probably wrong to have a mainspace article page invoke a userspace template like this, but I'm only doing it for a few relatively minor rivers, and only for a few days.)

Feel free to play with the template and let me know what you think. (Or, if you don't want to invoke a userspace template, just wait a few days until I make the changes official. Or you could try it but only hit Show Preview, not Submit. Or you could try it from your own sandbox page(s).)

If you do temporarily invoke the sandbox template, be aware that we'll have to switch it to use the real template once it's official.

The template puts the mouth (as opposed to the origin) coordinates at the top of the article, because that seems to be the consensus.


Personally, I think it's silly to have Geobox/type/river distinct from Infobox river, and ideally I'd hope one day we could settle on one and migrate to it. You may disagree, and I'm not trying to raise that issue today anyway, but your opinion on that question will probably influence your answer(s) to the two questions I do have:

  1. What should the origin coordinate parameters be called? Originally I was planning on calling them source_lat_d, source_long_d, etc., for compatibility with Geobox/type/river. But in the end I decided to name them origin_lat_d, origin_long_d, etc., since "origin" is what Infobox river uses for the source, and having parameters with two different naming conventions would be confusing. (Using parameter names identical to Geobox/type/river would seem to make converting from one to the other easier, but actually, any conversion from one to the other is going to involve renaming a bunch of other parameters anyway, so what's a few more?)
  2. Do we really need or want the third option, using the origin_coordinates and mouth_coordinates parameters? Some people seem to like this style, and it's supported by e.g. Infobox school. But Geobox/type/river does not support this style of coordinate entry, so any invocations of the new Infobox river that use that style would be that much harder to convert to Geobox/type/river later, if that should ever be necessary.

Anyway, please comment below and let me know what you think. As I said, I expect to make the changes to the official template soon. —Steve Summit (talk) 05:45, 21 February 2014 (UTC)


Having used both Geobox and the individual infoboxes such as this one I prefer the latter. I found Geobox very unwieldy and difficult to use. Turning to your actual questions:

  • We need the ability to display either "source" or "origin" to take account of the fact that some rivers are viewed as beginning at a source and some at e.g. the confluence of two headstreams each of which has its own name.
  • It is useful to be able to input the coordinates using the {{coord}} format, especially e.g. when translating articles as this is often how it will come across. So both are useful.

--Bermicourt (talk) 09:07, 21 February 2014 (UTC)

Making the label changeable would be straightforward with an origin_label parameter. You want me to add that while I'm at it? (I wonder what the default should be -- "source" or "origin"?) —Steve Summit (talk) 14:10, 22 February 2014 (UTC)
We should definitely deprecate the use of geobox for rivers; add any necessary features from it to this infobox, have a bot make replacements, then permanently remove river features from geobox. This is (has?) been done for mountains in Geobox. We most certainly do not need to worry about making conversions in the reverse direction. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:51, 21 February 2014 (UTC)
GNIS entries (such as this one: 649969) express decimal coordinates as positive/negative numbers, instead of specifying NSEW. Would there be a way to accommodate that method? It would make it speedier to copy-paste from GNIS entries.
(Separately, I do have opinions regarding geoboxes vs infoboxes, and I won't share them here.) --Malepheasant (talk) 16:16, 22 February 2014 (UTC)
Yup, ±decimal works, too. (The {{Coord}} template, which all of this is built on, is pretty amazing.) —Steve Summit (talk) 17:17, 22 February 2014 (UTC)
Hmm, if I just use ±decimals in the | origin_lat_d and | origin_long_d fields (without specifying NSEW in the corresponding NS and EW fields), it breaks the template. (And it breaks doubly if I try combining ±decimals with NSEW designations.) Do I have to paste in the {{Coord}} template to be able to use the ±decimal method? --Malepheasant (talk) 18:02, 22 February 2014 (UTC)
Well, I thought it worked, and I thought I'd tested it. Let me play with it and see. —Steve Summit (talk) 20:04, 22 February 2014 (UTC)
Okay. Sorry for the false start. I thought I'd tested it, but obviously I didn't, because you're right, it didn't work. (I guess the {{Coord}} tempate isn't quite as amazing as I thought it was.) I've got a tentative fix in place, although I might have to move to {{Geobox coor}} instead, although it's got some issues of its own (like, evidently >code>display= is different). Anyway, please give it another try. See Chicopee River for an example. —Steve Summit (talk) 21:45, 22 February 2014 (UTC)
It's working for me now, too, thanks! -- Malepheasant (talk) 23:08, 22 February 2014 (UTC)


Okay, I've deployed the changes.[1]. The new coordinates parameters are already in use on five pages: Chicopee River, Concord River, Ipswich River, Little Bighorn River, and River Manifold. I'll update the template documentation next. There's now the task of migrating coordinates out of the random places they're in now into the template; I'll start a thread on that over on Wikipedia talk:WikiProject Rivers. Thanks for everybody's input here. —Steve Summit (talk) 13:29, 23 February 2014 (UTC)

Improving this template[edit]

As discussed above, we should improve this template by importing any beneficial (if not all) river features from {{Geobox}}. I intend to start doing so shortly; does anyone have any views as to what should or should not, be imported, and how? Parameters in geobox, with with no equivalent here, include:

  • |category=
  • |country=
  • |state=
  • |region=
  • |district=
  • |municipality=
  • |parent=
  • |city=
  • |landmark=
  • |source_location=
  • |source_region=
  • |source_country=
  • |source_lat_d=
  • |source_lat_m=
  • |source_lat_s=
  • |source_lat_NS=
  • |source_long_d=
  • |source_long_m=
  • |source_long_s=
  • |source_long_EW=
  • |source1=
  • |source1_location=
  • |source1_region=
  • |source1_country=
  • |source1_elevation=
  • |source1_lat_d=
  • |source1_lat_m=
  • |source1_lat_s=
  • |source1_lat_NS=
  • |source1_long_d=
  • |source1_long_m=
  • |source1_long_s=
  • |source1_long_EW=
  • |source_confluence=
  • |source_confluence_location=
  • |source_confluence_region=
  • |source_confluence_country=
  • |source_confluence_elevation=
  • |source_confluence_lat_d=
  • |source_confluence_lat_m=
  • |source_confluence_lat_s=
  • |source_confluence_lat_NS=
  • |source_confluence_long_d=
  • |source_confluence_long_m=
  • |source_confluence_long_s=
  • |source_confluence_long_EW=
  • |mouth_location=
  • |mouth_region=
  • |mouth_country=
  • |mouth_elevation=
  • |mouth_lat_d=
  • |mouth_lat_m=
  • |mouth_lat_s=
  • |mouth_lat_NS=
  • |mouth_long_d=
  • |mouth_long_m=
  • |mouth_long_s=
  • |mouth_long_EW=
  • |width=
  • |depth=
  • |volume=
  • |discharge_location=
  • |discharge_max=
  • |discharge_min=
  • |map_background=
  • |map_locator=
  • |map_locator_x=
  • |map_locator_y=
  • |website=
  • |commons=
  • |footnotes=

plus imperial equivalents. It might be worth testing to see whether some of those (e.g. |category=, |landmark=, |width=, |website=, |commons=) are used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 26 March 2014 (UTC)

seems like the list should be revised, given the recent edit history. Frietjes (talk) 16:54, 26 March 2014 (UTC)
Oop, after posting at the Rivers Wikiproject talk page I found this. Give me a day or two and I'll respond with some detailed comments about what I'd like to see in a river infobox. Pfly (talk) 03:14, 5 April 2014 (UTC)
Okay, I said I'd post something, but looking at Infobox River and comparing it to Geobox River I find so much troublesome I can't address all of it. But here's some (for Geobox examples, see pages like Rogue River (Oregon) and Columbia River). I like how the Geobox groups similar things together and uses fine lines to organize information. So you get, for example, the parameter name Source in bold, then whatever other parameters relate to it below, like "location", "elevation", "coordinates", etc. In the Infobox information about similar things do not always appear together, like "Mouth" and "Mouth elevation". The organization of information in Geobox seems much more readable.
Also in the Infobox you get longer parameter names, which frequently wrap, making things harder to read, like "Mouth" and "Mouth elevation". Or "Left tributaries" and "Right tributaries" instead of a simple "Tributaries" field with "left" and "right" subfields. Same thing with "Basin countries" and "Basin area". At least the mouth coordinates are kept with the Mouth parameter in the Infobox. On the other hand there's "Origin", which can have coordinates just like "Mouth", but the related elevation parameter is not origin_elevation but source_elevation. More confusing is that both "Origin" and "Source elevation" are linked to the page River source.
Also confusing is the way footnoting works. I like how in Geobox if you want a footnote you add a parameter with _note appended for it. So "length" and "length_note". Or a slightly less obvious one, after specifying coords with "mouth_lat_d", "mouth_lat_m", etc, you can add a footnote with "mouth_coordinates_note". I don't see how to add a footnote to coords specified in this way in Infobox. Adding footnotes to things like "length" seems weird. Maybe I'm not understanding but it seems Infobox gives you a "length" parameter in which you use a "Full-text length of the river, using {{convert}} template if necessary". And you can append a footnote reference. But if you use length_mi or length_km and want a footnote, you put it under the length parameter? That's....counter-intuitive. "length_note" makes more sense.
I'm not completely happy with the way discharge data is handled by either template, but find Geobox better. The Infobox seems to assume you want to specify "average discharge" for an unspecified location—presumably the mouth. Usually discharge data is calculated at stream gauges that are often not at the mouth. It is important to be able to say where the discharge data is being calculated. Geobox has a "discharge_location" location parameter where you can say things like "for river mile 13", or "for Gage 04j, above Foo Creek", etc. Geobox also gives you fields for average, max, and min discharge stats. Max and min values are commonly cited and important. The Infobox example somehow gives us subfields with "annual average", "June", and "December". That might be useful in addition to max and min. Ideally one could cite various discharge stats easily. Neither template has an easy way to do that. The subfields in the Infobox are not explained—apparently you have to edit the page and examine the code? As with other parameters I found that footnotes for discharge data go under the "discharge" parameter, which is weird.
Also confusing about the Infobox is the parameter names regarding pictures and maps. If you want a picture you use image_name for the file, but when you want a map you don't give the file with map_name but rather image_map?? This is particularly confusing since it clearly doesn't mean an imagemap. Also, you use caption for your image (picture) but map_caption for your map. It all seems rather inconsistent.
Another apparently inconsistent thing is "elevation". It appeared Infobox provided mouth_elevation fields but not source_elevation. It does provide elevation fields. I didn't see how a river could have a single elevation. I guessed the idea was to use the convert template with a range of values. However when I tried it out the elevation fields are displayed as "Source elevation".
Finally, reading the list of Infobox parameters I saw native_name and native_name_lang. But the native_name_lang wants an ISO code? It took me a bit to figure this out. I tried it with the ISO code for the Quinault language, which according to Ethnologue is "qun". But nothing displays in the Infobox. I also could not get "other_name" to display anyway. (edit: Oops, it did work, displaying "Other name" like any other parameter; I guess I expected something in the box's header, near where the main name is shown) I put my pretend Infobox at User:Pfly/tests.
There are other things I could point to, but this seems plenty for now! Sorry for being so critical. One Infobox thing I did like is the "progression" parameter. Pfly (talk) 05:50, 13 April 2014 (UTC)
The ISO code of the native language is used in the lang attribute of the underlying HTML. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:02, 14 April 2014 (UTC)