Vorlage Diskussion:Infobox Fluss/Archiv/2

Dieses Diskussionsarchiv hat die empfohlene Seitengröße erreicht und gilt damit als abgeschlossen. Sein Inhalt sollte nicht mehr verändert werden (ausgenommen Kleinbearbeitungen wie Link- und Vorlagenfixe). Verwende für die Archivierung von Diskussionsbeiträgen bitte das aktuelle Archiv und benutze bitte für aktuelle Diskussionen die aktuelle Diskussionsseite. Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise [[Vorlage Diskussion:Infobox Fluss/Archiv/2#Abschnittsüberschrift]] oder als Weblink zur Verlinkung außerhalb der Wikipedia https://de.wikipedia.org/wiki/Vorlage_Diskussion:Infobox_Fluss/Archiv/2#Abschnittsüberschrift

ABFLUSSWEG bei Mündungsflüssen

Bei Flüssen, die ins Meer fließen, beinhaltet der Parameter ABFLUSSWEG nur noch den Namen des Meers. In der erzeugten Infobox steht dann „Abfluss über Meer“. Wäre es hier nicht verständlicher, wenn da „Abfluss in Meer“ oder „Mündung in Meer“ stehen würde? Zumindest hier hat es jemand irritiert und den Namen des Flusses mit eingefügt. Mit einer Fallunterscheidung über die Anzahl der ParmParts in ABFLUSSWEG müsste sich der Text bedingt ändern lassen. --Fomafix 11:03, 24. Jan. 2011 (CET)

Man könnte das auch einfach weglassen, denn die Mündung steht im Parameter MÜNDUNG schon drin. Wie wäre es, den Abflussweg auszublenden wenn nur eine Angabe erfolgt?-- SteveK ?! 14:37, 24. Jan. 2011 (CET)

Weglassen hätte die Gefahr, dass das Feld nicht mehr ausgefüllt werden würde, weil es zu keiner sichtbaren Anzeige kommt. Gerade bei diesem Feld wünsche ich mir eine vollständige Befüllung, die irgendwann mal auf automatisch auf Vollständigkeit und Korrektheit geprüft wird. --Fomafix 15:49, 24. Jan. 2011 (CET)

Da hast du Recht. Bin eh gerade am basteln und werde versuchen es zu realisieren. Einfachste und flexibelste Lösung wäre wohl ein Parameter ABFLUSSWEG-TITEL, der dann defaultmäßig auf "Abfluss über" gesetzt wird. -- SteveK ?! 19:24, 25. Jan. 2011 (CET)

Bei Mündungsflüssen ist es einfach widersinnig, ABFLUSSWEG auszufüllen, weil sie direkt ins Abflussziel münden. -- Olaf Studt 21:29, 7. Apr. 2011 (CEST)

Ein Weg der Länge 0 ist auch ein Weg. Vielleicht kann die Ausgabe unterdrückt werden, wenn Abflussweg gleich der Mündung ist. --Fomafix 21:58, 7. Apr. 2011 (CEST)

In MÜNDUNG steht ja meistens etwas wie „bei [[Xtown]] in die [[Y Bay]] ([[Zmeer]])“, da ist Gleichheit höchst selten. Außerden fördern weitere Pflichtfelder nicht gerade die Akzeptanz der Vorlage, siehe diese Klage über die Kompliziertheit. -- Olaf Studt 11:51, 9. Apr. 2011 (CEST)

Stimmt, ein Textvergleich mit MÜNDUNG funktioniert nicht. Ja, die Vorlage ist kompliziert, weil sie viele Parameter hat. Anderseits gibt es hier auch viele Experten, die die Vorlagenparameter auswerten und sich um die Vollständigkeit der Parameter kümmern. Einen neuen zusätzlichen Parameter ABFLUSSWEG-TITEL würde ich trotzdem ungern haben. Vielleicht wäre es doch am sinnvollsten, wenn die Anzeige von ABFLUSSWEG ausgeblendet wird, wenn nur ein bzw. mit Linktext zwei Parameter übergeben werden. Die Mündung steht ja weiterhin unter MÜNDUNG. --Fomafix 17:02, 9. Apr. 2011 (CEST)

Ich habe gerade eine Lösung in Arbeit, bei der die Zeile erst mal weggelassen wird wenn nur eine Angabe gemacht wird. Das war die einfachste Lösung, da nicht alle Flüsse in einem Meer enden.

Ferner habe ich dort eine automatische Kategorisierung für die oberste Flusssystemkategorie implementiert. Dazu müssten allerdings die Kategorien entsprechend den Flusslemma genannt werden, also Lenne (Ruhr) -> Kategorie:Flusssystem Lenne (Ruhr) und nicht Kategorie:Flusssystem Lenne.

Wie ist eure Meinung dazu? --SteveK ?! 22:32, 1. Jun. 2011 (CEST)

Ja, genau so habe ich mir das vorgestellt. Auch die automatische Kategorisierung habe ich mir so gedacht. Überall wird es nicht funktionieren. Die Kategorie:Flusssystem Linth/Limmat kann so nicht kategorisiert werden. Die Umbenennung der Kategorie:Flusssystem Lenne auf Kategorie:Flusssystem Lenne (Ruhr) ist sowieso sinnvoll, denn es könnte auch noch irgendwann die Kategorie:Flusssystem Lenne (Weser) geben. Problematischer sind die Flüsse, die den Klammerzusatz (Fluss) haben. Eine Umbenennung der Kategorie:Flusssystem Kocher nach Kategorie:Flusssystem Kocher (Fluss) aufgrund des Klammerzusatzes am Lemma Kocher (Fluss) hingegen ist nicht so sinnvoll. --Fomafix 23:08, 1. Jun. 2011 (CEST)

So wie ich es jetzt implementiert habe, wird immer die Kategorie gesetzt, die am ehesten passt. Im Fall der Lenne würde derzeit Kategorie:Flusssystem Ruhr gesetzt. Und beim Kategorie:Flusssystem Linth/Limmat wird Kategorie:Flusssystem Aare gesetzt. Beim Kocher könnte man den Artikel ja auch nach Kocher (Neckar) verschieben. Ich schlafe jetzt erstmal drüber. --SteveK ?! 23:33, 1. Jun. 2011 (CEST)

Jetzt habe ich das mal aktiviert und gleich gemerkt, dass der Fluss eines Flusssystems ja nicht in der übergeordneten Kategorie einzuordnen ist. Also schaut mal nach ob es funktioniert --SteveK ?! 13:17, 5. Jun. 2011 (CEST)

Aufgrund der Vorlagenautomatik nun den Klammerzusatz von (Fluss) auf (Vorfluter) zu ändern ist problematisch, denn das entspricht nicht der üblichen Erzeugung der Klammerzusätze bei eindeutigen Flussnamen, aber mehrdeutigen Begriffen. --Fomafix 15:50, 5. Jun. 2011 (CEST)

Ich habe das jetzt nur mal bei dem Aal gemacht und wollte damit nicht bei den dann problematischen Fällen weitermachen. Ich weiß welchen Ärger man sich in der WP damit zuziehen kann.--SteveK ?! 16:05, 5. Jun. 2011 (CEST)

Ok. Die Aal. Vielleicht bekommen wir hier auch noch eine technische Lösung hin.

Ich habe für die Kategorie:Flusssystem Lenne ein Umbenennungsantrag gestellt: Wikipedia:WikiProjekt Kategorien/Diskussionen/2011/Juni/5#Kategorie:Flusssystem Lenne nach Kategorie:Flusssystem Lenne (Ruhr) --Fomafix 16:13, 5. Jun. 2011 (CEST)

Es wundert mich schon etwas, dass noch keine Kollegen wegen der Kategorisierung hier aufgeschlagen sind. Beim Neckar sind wegen des Kochers etliche Flüsse in zwei Flusssystemkategorien drin.

Die Lösung kann sein, dass zuerst die Kategorie des Flusslemmas, dann die Kategorie des Alternativnamens versucht wird. Damit könnten aber falsche Einordnungen entstehen.

Ferner habe ich noch ein Problem mit der Kat.-Sortierung, das Artikellemmma ist da nicht immer richtig. --SteveK ?! 16:28, 5. Jun. 2011 (CEST)

Nur eine Zwischenfrage, ich will mich nicht einlesen, auch nicht in den IB-Quelltext. Benutzt du ifexist bei der Kategorisierung? Falls, dann erzeugst du unter Umständen Links auf rote Kategorien; das Problem besteht etwa bei der IB Ort in den Vereinigten Staaten, siehe bspw. was linkt auf Kategorie:Rensselaer County (New York) – vergleiche das mit was linkt auf Kategorie:Rensselaer County. Manchmal führt dieses Verhalten zu Irritationen auf WP:FzW. Grüße. --Matthiasb ^{(Wiederwahl? Ich bin dabei!)} 16:33, 5. Jun. 2011 (CEST)

Gibt es eine andere Lösung als ifexist zu benutzen? Ich habe das auf einer Unterseite gemacht, der Quelltext der IB ist mir jetzt schon zu unübersichtlich.--SteveK ?! 16:46, 5. Jun. 2011 (CEST)

Meines Wissens nicht, weswegen ich bei der US-IB eine ifexist-Verschachtelung brauchte, weil etwa zwei Dritteln der Countys einen Klammerzusatz haben und der Rest nicht. Ist dort auch in eine Untervorlage ausgelagert, anders wirds zu unübersichtlich. Die Alternative ist ein extra Parameter, aber wer soll verstehen, daß in den Parameter Flussystem bspw. der Rhein kommt, aber der Fluß selber ins Flussystem Neckar einsortiert wird. Frag doch mal Benutzer:Umherirrender, ob dem was einfällt. --Matthiasb ^{(Wiederwahl? Ich bin dabei!)} 16:53, 5. Jun. 2011 (CEST)

Ich habe ja auch verschachtelte ifexist-Anweisungen. Ich glaube die Links auf nicht existierende Kategorien lassen sich damit nicht verhindern. Die Ursache dürfte ja im ifexist selbst liegen, wer sonst sollte den Link erzeugen? --SteveK ?! 18:16, 5. Jun. 2011 (CEST)

Das ist schon klar, deswegen muß man, wenn's verschachtelt ist, möglichst geschickt schachteln ;-) es gibt auch keine Möglichkeit, das abzustellen. Ich will mich wirklich nicht reindenken, aber könnte man nicht ABFLUSSWEG und FLUSSSYSTEM miteinander vergleichen (ifequal) und dadurch etwa den Speyerbach beim Rhein direkt in die Flusssystem-Kategorie reinsortieren? Eine Abfrage des Abflussweges ist ja eigentlich nur notwendig, wenn ABFLUSSWEG mehr als zwei "echte" Einträge hat, also mehr als Rhein/Nordsee. --Matthiasb ^{(Wiederwahl? Ich bin dabei!)} 19:53, 5. Jun. 2011 (CEST)

Na ja, das Flusssystem ist "Rhein", ohne die Nordsee, der Abflussweg ist "Rhein//Nordsee", das ist dann schon wieder verschieden. Der Abflussweg wird derzeit nicht dargestellt, wenn nur eine Angabe, also im Regelfall das Meer, angeben wurde. Will jetzt aber erstmal sehen, ob dass mit der Kategorisierung gehen kann. Erste Beschwerde liegt vor. --SteveK ?! 20:25, 5. Jun. 2011 (CEST)

Das wäre ein problematischer, aber vernünftiger Regelbruch; ich denke dabei ans Vermeiden unnützer Arbeit. Wenn man einen Fluss – oder sagen wir einen Bach, denn hier gibt's diesen Fall bestimmt häufig – mit noch freiem Namen anlegt als Häufiger_Name (Fluss) oder als Häufiger_Name – falls denn noch gar kein Artikel anderer Kategorie unter dem Lemma dazu bestünde –, dann kann man sich fast sicher sein, dass irgendwann jemand einmal verschieben muss und alle Links ändern. Was leicht zu vermeiden gewesen wäre, indem man ihn gleich als Häufiger_Name (Aufnehmender_Fluss) angelegt hätte. Ähnliches gilt, en passant gesagt, auch in anderen Bereichen. Etwa bei gängigen Straßennamen, die sinnvollerweise von Anbeginn an mit Klammerzusatz für den Ort angelegt würden, statt dass man durch religiöses Befolgen der Lemmaregeln Kramarbeit in der Zukunft sichert. Und vielleicht auch noch den Bruch eingehender Links vorbereitet. -- Silvicola Diskussion Silvicola 22:53, 5. Jun. 2011 (CEST)

Dem ist so, doch verweise ich mal auf Benutzer Diskussion:Matthiasb#Huy (Sachsen-Anhalt), um aufzuzeigen, mit welchen Problemen/Argumenten man es zu tun hat (dort geht es um Gemeinden, nicht um Flüsse). Theorie ist schön, die Praxis erfordert jedoch viel Geduld. --Matthiasb ^{(CallMyCenter)} 22:58, 5. Jun. 2011 (CEST)

auch nach Lesen dieser Disk. und Laie in Sachen Flüsse habe ich noch Fragen:

1. Fliesst ein Fluss direkt ins Meer lasse ich logischerweise ABFLUSSWEG frei, da sonst doppelte Infos in der Infobox (Zeile drüber steht ja "Flussystem" (in diesem Fall dann identisch mit Fluss=Lemma), Zeile drunter steht "Mündung", dazwischen gibt es keinen anderen Abflussweg), richtig?

2. Abfluss ins Meer ist nicht gemeint eins der 7 Weltmeere aufzuführen, sondern die lokale Bezeichnung, oder? (z.B. bei Fly statt Pazifischer Ozean Golf von Papua) -- Der Regenbogenfisch 15:19, 8. Dez. 2011 (CET)

zu 1. Nein, du kannst den Abflussweg angeben, die Box lässt die Zeile selbstständig weg. Wird der Abflussweg nicht angegeben, dann wird der Ariktel auf der Wartungsseite gelistet.

zu 2. Das ist nicht genau geregelt. Golf von Papua geht aber in Ordnung

Gruß --SteveK ?! 11:06, 10. Dez. 2011 (CET)

Gemeinden

„Gemeinden entlang des Flusses (bei kleineren Flüssen). Gemeint ist die Ortschaft, nicht die Gemarkung.“ – Oft oder meist besteht eine Gemeinde ja aus mehreren Ortschaften. Ist gemeint, dass der Fluss durch den Ort mit Verwaltungssitz der Gemeinde fließen muss oder durch irgendeinen Ort der Gemeinde oder sollen einzelne Orte (Also Ortsteile einer Gemeinde) aufgeführt werden wie bei der Ilme, die mich gerade auf diese Frage brachte (dort sind nur Ortsteile unter „Gemeinden“ aufgeführt)? --Stuby 00:43, 29. Jan. 2011 (CET)

Besonders schlagendes Beispiel sind Gemeinden wie Seevetal oder Feldberger Seenlandschaft, wo es keinen Ort dieses Namens gibt. -- Olaf Studt 22:35, 7. Feb. 2011 (CET)

Relaunch der frz.Gewässerdatenbank (sandre.fr)

Wie ich gesehen habe, bietet sandre.fr seit einigen Tagen eine völlig neu gestaltete Oberfläche, die auch eine Menge an neuen Informationen enthält, u.a. Koordinaten von Quelle und Mündung, sowie Größe des Einzugsgebietes. Alle Feinheiten habe ich sicher noch nicht erkannt, aber ich wollte mal die Info weitergeben. Der Link aus der Infobox (GKZ), sowie die sandre-Vorlage führen automatisch auf die neue Ergebnisseite, das händisch anzusteuernde Auswahlmenü scheint noch alt zu sein... Grüße --Skipper69 07:58, 1. Feb. 2011 (CET)

Danke für die Info. Muss hier an der Verlinkung der DB etwas geändert werden? -- SteveK ?! 10:38, 1. Feb. 2011 (CET)

Wie es aussieht, ist die Verlinkung ok (oder führt zumindest zum erwarteten Ergebnis). Bloß die neue Anwendung scheint mir noch ein wenig instabil, da müssen wir wohl ein paar Tage abwarten, bis die Kinderkrankheiten behoben sind... --Skipper69 17:40, 1. Feb. 2011 (CET)

Jahresabfluss

Bei subtropischen Flüssen (wo der Abfluss in der Trockenzeit = 0 ist) habe ich es schon öfter erlebt, aber kürzlich auch – bei der Aiviekste – in den gemäßigten Breiten: dass der Abfluss pro Jahr angegeben wird. Auf einen Parameter mehr oder weniger kommt es bei dieser länglichen Vorlage ja nun auch nicht mehr an … -- Olaf Studt 22:39, 7. Feb. 2011 (CET)

Aber der MQ ist doch der durchschnittliche Jahresabfluß (über 5-100 Jahre), heruntergerechnet auf Sekunden!

Von daher eigentlich schon drin ... --Elop 01:52, 8. Feb. 2011 (CET)

Ach so:

Ein Jahr hat 31.560.000 Sekunden ... --Elop 01:56, 8. Feb. 2011 (CET)

In Australien etwa wird der Abfluss mit Megalitern pro Jahr angegen. Ärgerliche Rechnerei. --Matthiasb (CallMeCenter) 13:39, 8. Feb. 2011 (CET)

LÄNGE-SUFFIX

Wenn man dieses Feld in der Flussbox angibt, das nach der Dokumentation hier aber anscheinend nicht definiert ist, wird sein Inhalt vor den Längenwert gestellt. Warum das? Unterdrücken verstünde ich, nachstellen auch. -- Silvicola Diskussion Silvicola 23:36, 20. Mai 2011 (CEST)

ich seh keinen solchen Parameter, meinst du etwa LÄNGE-PREFIX? Dient dazu, um ein > oder ungefähr oder ähnliches vor den Zahlenwert zu schreiben. lg --Herzi Pinki 01:02, 21. Mai 2011 (CEST)

sehe das genauso wie Herzi Pinki. Gruss --SteveK ?! 21:17, 22. Mai 2011 (CEST)

Nicht in der Doku, sondern im Quelltext:

{{!}}{{#if: {{{LÄNGE-PREFIX|}}}|{{{LÄNGE-PREFIX|}}} }}{{Maß|{{#if: {{IstZahl|{{{LÄNGE|}}}
}}|{{#ifeq: {{#expr: {{{LÄNGE|}}} >= 1 }}|1|{{#expr: {{{LÄNGE|}}} round 1 }}|{{{LÄNGE|}}}}}|
{{{LÄNGE|}}}}}|km|1|m|1000}}{{#if: {{{LÄNGE-SUFFIX|}}}| {{{LÄNGE-SUFFIX|}}}}}

Einen Fehler sehe ich auf den ersten Blick nicht. --Matthiasb ^{(Wiederwahl? Ich bin dabei!)} 16:58, 5. Jun. 2011 (CEST)

Ist neu, mir gingen die "(mit X-Bach x km)" im Nachweisfeld auf den Geist. Deshalb hatte ich das vor kurzem implementiert. Und Entwickler dokumentieren doch nicht so gerne ;-) --SteveK ?! 18:12, 5. Jun. 2011 (CEST)

Dieser Parameter wurde jetzt implementiert und kann genutzt werden. Er wird durch die IB nach dem Nachweis der Längenangabe dargestellt. Damit ist das Thema hier erledigt.--SteveK ?! 21:57, 7. Jun. 2011 (CEST)

Fließgewässertyp

Wenn nichts dagegen spricht würde ich gerne den Parameter Fließgewässertyp zur Box hinzufügen. Für die meisten der (größeren bzw. im Sinne der WRRL bedeutsamen) Fließgewässer wurde inzwischen der Typ bestimmt, so dass viele der hiesigen Artikel um diese Information erweitert werden können. --HolsteinPommern 11:59, 11. Jun. 2011 (CEST)

Deutschlandlastig? --Matthiasb ^{(CallMyCenter)} 12:39, 11. Jun. 2011 (CEST)

Stimmt, ist nämlich etwas, was oft im Fließtext schlechter aufgehoben ist als in der Box.

Sinnvoll wäre aber eine Verlinkung mit Artikeln zu den Einzeltypen - vorläufig vielleicht zu den Abschnitten im Fließgewässertypen-Artikel.

Am praktischesten wäre es, man könnte in der Box "DE-5" angeben und daraus würde Grobmaterialreicher, silikatischer Mittelgebirgsbach.

Deutschlandlastig wäre das m.E. nicht - zumal die WRRL ja nichts rein Deutsches ist. Es müßte halt nur nach verantwortlichem Land gesplittet werden, wie ja auch die Kennziffern. --Elop 12:50, 11. Jun. 2011 (CEST)

Ja, das ist ja, worauf ich hinweisen will – nicht, daß es uns wieder so geht, als wir die Gewässerkennzahlen implementiert hatten und nach einigen Wochen merkten, daß das in anderen Ländern begrifflich nicht paßt. --Matthiasb ^{(CallMyCenter)} 12:55, 11. Jun. 2011 (CEST)

Laut Anhang 2 der WRRL konnten sich die einzelnen EU-Länder zwischen einem System A und einem System B entscheiden, wobei das in Fließgewässertyp beschriebene offenbar System A (mit deutschlandspezifischen Ökoregionen) ist. Die Tabellen fehlen leider in der HTML-Version, sodass man sich das PDF (888 KB im Falle de) runterladen muss. -- Olaf Studt 18:28, 11. Jun. 2011 (CEST)

Wenn man das umsetzen will, wie es Elop sich vorstellt, braucht man da einen mutmaßlich elend langen Switch, um die EU-Staaten entsprechend zu behandeln; abgesehen davon ist das, sovermute ich, EU-25, Rumänien und Bulgarien hängen bei Statistik-Kram hinterher (mW gibt es bspw. für beide Staaten noch keine LAU). Nicht-EU-Mitgliedsstaaten kann man wohl gar nicht "normen", weil es da vermutlich gar keine offiziellen Einteilungen gibt oder diese völlig abweichen. Ich würde das also einstweilen nur im EU-Raum anstreben. Wie macht das eigentlich die Schweiz? --Matthiasb ^{(CallMyCenter)} 18:44, 11. Jun. 2011 (CEST)

Ohwe, das hatte ich mir einfacher vorgestellt. Vielleicht macht es doch mehr Sinn, das in den Fließtext einzubauen statt in die Infobox. --HolsteinPommern 18:52, 11. Jun. 2011 (CEST)

Laß dich von uns nicht verschrecken: wir versuchen nur, alle Eventualitäten im voraus zu erörtern. ;-)

Kann jemand eine vollständige Liste für den EU-Raum erstellen? (Ich habe auf meinem System mit EULEX Probleme, mein Kasten ist zu alt.) --Matthiasb ^{(CallMyCenter)} 19:44, 11. Jun. 2011 (CEST)

Also, wenn man mich fragt würde ich liebend gerne drauf verzichten. Die meisten Ströme entstehen als Bach und werden dann mal Fluss. Wie soll man dass implementieren? --SteveK ?! 20:05, 13. Jun. 2011 (CEST)

Mit ganz wenigen Ausnahmen, wie D River und Ombla. -- Olaf Studt 17:26, 14. Jun. 2011 (CEST)

Okay, war keine gute Idee. Es gibt nicht überall bzw. nicht überall dieselben Fließgewässertypen und der Aufwand für eine Implementation in die Vorlage stünde wohl auch außer Verhältnis zum Nutzen. Danke für eure Diskussionsbeteiligung! --HolsteinPommern 18:12, 14. Jun. 2011 (CEST)

Mississippi River (Ontario) jetzt im Flusssystem Mississippi

Durch die neue automatische Kategorisierung ist der Mississippi River (Ontario) jetzt in der Kategorie:Flusssystem Mississippi River gelandet. Da bin ich ja mal gespannt, ob sich das ausbügeln lässt. -- Olaf Studt 17:53, 11. Jun. 2011 (CEST)

Mal eine Frage, weil es ja neulich beim Mississippi River um das "River" ging: Könnte man den Artikel nach Mississippi (Ottawa River) verschieben? Das entspräche der NK und würde gleich das Problem lösen. --SteveK ?! 20:21, 14. Jun. 2011 (CEST)

Das entspräche aber nicht Matthias’ NK. Aber ich bin froh, dass Du den Ol’ Man River (nicht zu verwechseln mit Oldman River) kein Klammerlemma verpassen willst. -- Olaf Studt 21:23, 16. Jun. 2011 (CEST)

Ich habe ja nur mal gefragt ob es gehen würde. Da die Kategorie:Flusssystem Mississippi River ja wohl so bleiben soll wie sie ist habe ich die Kategorisierung abgeschaltet. Das müssen wir dann für alle Mississippis machen. --SteveK ?! 21:30, 16. Jun. 2011 (CEST)

FLUSSSYSTEM redundant?

Ist der Parameter FLUSSSYSTEM inzwischen redundant? Bei Flüssen, die ins Meer fließen enthält FLUSSSYSTEM den Fluss selbst. Bei den anderen Flüssen sollte unter ABFLUSSWEG als vorletztes Parameterpaar das gleiche wie unter FLUSSSYSTEM stehen. Oder habe ich einen Fall übersehen? --Fomafix 12:53, 14. Jun. 2011 (CEST)

Eine Ausnahme habe ich gefunden: Die IJssel ist zurecht im Flusssystem Rhein. --Fomafix 13:26, 14. Jun. 2011 (CEST)

das dachte ich mir schon länger, wir sollten umbedingt diesen parameter auf hydrographische provinzen umstellen: so gliedert sich etwa österreich in :

Planungsräume nach WRRL (national)	Flussgebietseinheiten nach WKEV
Rhein (Rhein, RHI) Donau bis Jochenstein (DbJ, DBJ) Donau unterhalb Jochenstein (DuJ, DUJ) Elbe (Elbe, ELB) March (March, MAR) Leitha, Raab, Rabnitz (LRR) Mur (Mur, MUR) Drau (Drau, DRA)	Rhein Donau oberhalb Inn Inn bis Salzach Salzach Inn unterhalb Salzach Donau Inn bis Traun Traun Enns Donau Traun bis Kamp (ohne Enns) Donau Kamp bis Leitha (ohne March) March Leitha Rabnitz und Raab Mur Drau Elbe (Moldau)

das wäre, was ich mir vom parameter erwarten würde, den so ist die hydrographische fachliteratur (+onlinedatenbanken) strukturiert (gewässergüte, auch stehende gewässer, wasserbau, abfluss) - wir bräuchten nur die fachartikel dafür

jeweils auf Hydrographie der Schweiz-serie zielen (siehe dort zu den schweizer hydrographie-/wasserwirtschaftsregionen), und wie bei der gewässerkennzahl parameter gebeitseinheit nach Land, wär auch nicht schlecht

Alpenrhein etwa: FLUSSSYSTEM = CH/10 ''Rhein''/AT/1 (RHI) ''Rhein''

in IB → Flussgebiet | CH: 10 Rhein; AT: 1 (RHI) Rhein

mit erklärung im fachartikel --W!B: 16:23, 14. Jun. 2011 (CEST)

Und wie ist das in Venezuela, Kolumbien und Ecuador? -- Olaf Studt 17:28, 14. Jun. 2011 (CEST)

keine ahnung, schau beim zuständigen hydrographischen institut nach - und sonst, was man nicht weiß, einfach nicht eintragen, ich denke, die flusskennzahl des orinoco ist auch nicht dort eingetragen.. --W!B: 05:57, 15. Jun. 2011 (CEST)

Hinweis: Der Abflussweg wird seit der letzten Überarbeitung immer dann nicht dargestellt, wenn nur 2 Angaben (Beispiel: "Elbe//Nordsee") gemacht werden. Die Flusssystemkategorie wird aber weiterhin aus dem Abflussweg gemacht, weshalb man den Parameter nicht weglassen sollte. --SteveK ?! 10:55, 15. Jun. 2011 (CEST)

1. Fomafix Einwand gilt immer dann nicht, wenn es sich um einen Mündungsarm handelt; das wäre etwa beim Atchafalaya River der Fall, so es denn richtig eingetragen ist, der zum Flusssystem des Mississippi River gehört, aber eigentstndig ins Meer fließt.
2. W!B: Vorschlag funktioniert nur, wurde ich sagen, in Österreich richtig, weil da, bis auf ganz wönzge Gebiete in Vorarlberg und Oberösterreich alles in die Donau gelangt. Andererseits ist die Alpenrepublik auch hinreichend klein, sodaß diese Flußgebietseinheiten relativ kompakt sind. Aber ein Blick in die Liste der hydrologischen Einheiten in den Vereinigten Staaten verrät, daß das woanders so nicht hinhaut, man müßte also weiter runterbrechen, in den USA somit mindestens nach den 222 Subregionen. --Matthiasb ^{(CallMyCenter)} 12:36, 15. Jun. 2011 (CEST)

wieso, was sollte es für ein problem geben, US/01. New England Region (Hydrographie) einzutragen - statt dessen haben wir jetzt den - verzeihung für den ausdruck - unausgegorenen parameter FLUSSGEBIETSEINHEIT, der auf WWRL der EU eingeschränkt ist, also erst recht wieder nicht weltweit gültig ist? oder darf ich die hydrologischen Einheiten in den Vereinigten Staaten dort - entgegen dem beschrieb - auch eintragen? oder eben CH, die sind bei WWRL nur periphär dabei, weil die richtlinie dort nicht gilt, sondern nur konformitätsmitel ist --W!B: 01:48, 17. Jun. 2011 (CEST)

Die hydrographischen Einheiten in den USA fassen in vielen Fällen Flüsse zusammen, die gar nichts miteinander zu tun haben, sondern zufällig imselben Gebiet sind. Etwa im Beispiel Neuengland: Connecticut River -> Long Island Sound vs. Saint John River -> Bay of Fundy. --Matthiasb ^{(CallMyCenter)} 09:22, 17. Jun. 2011 (CEST)

ah jetzt hab ich gecheckt, von was wir reden, verzeihung ;) - natürlich, gemeint ist (das was jetzt der neue parameter tut) "HYDROGRAPHISCHE EINHEIT", also GEWÄSSERSYSTEM (planerisch), nicht GEWÄSSERSYSTEM (orographisch) - es ging anfangs um die frage, dass FLUSSSYSTEM und ABFLUSSWEG redundant sind, und ich wollte darlegen, dass hier ein bedarf besteht, und welche zukunft der hinfällige eintrag haben könnte - dass es so ausgegangen ist, ist schade, jetzt stehen wir wieder am anfang --W!B: 19:14, 17. Jun. 2011 (CEST)

Hoëgne jetzt im Flusssystem Weser

Die Hoëgne, Nebenfluss der Weser (Ourthe), ist durch die automatische Kategorisierung in der Kategorie:Flusssystem Weser gelandet. Im Prinzip das gleiche Problem wie oben beim Mississippi. -- Olaf Studt 22:52, 16. Jun. 2011 (CEST)

Es gibt den Parameter NOAUTOKAT, mit dem kannst du die automatische Kategorisierung ausschalten. Eine andere Lösung wäre, die Kategorie:Flusssystem Weser (Ourthe) anzulegen, weil die vorrangig zur Kategorie:Flusssystem Weser geprüft und vergeben wird. Gruß --SteveK ?! 09:33, 17. Jun. 2011 (CEST)

erledigt, alle Flüsse in Kategorie:Flusssystem Weser kontrolliert. --SteveK ?! 19:46, 18. Jun. 2011 (CEST)

Folgebox, dann Abfluss fett

typischerweise setzte ich die folgebox (in flussartikeln) dann, wenn ich einem minderwichtigen bächlein (etwa quelllauf) eine box im artikel seines hauptflusses spendiere - dann ist im abflussweg aber typischerweise auch der link auf den artikel selbst gesetzt, und unschön fett - unverlinkt wär besser: es sollte also eine option geben, den ersten eintrag mit angabe nach dem / zu entlinken, etwa mit NOLINK --W!B: 01:43, 17. Jun. 2011 (CEST)

Das ist mMn nicht der richtige Weg. Da jeder Bachlauf unabhängig von seiner Größe relevant ist wenn er auf einer Karte auftaucht, dann sollte er auch einen eigenen Artikel bekommen. Da stellt sich dann das Problem mit dem Link erst gar nicht. --SteveK ?! 09:39, 17. Jun. 2011 (CEST)

sorry, die artikel-atomisierfraktion ist nur eine der gruppen in der WP - guckstu Vallülabach, da den Oberen und Unteren Valülabach rauszunehmen wäre ein enzyklopädischer unfug - genauso ein unfug wärs denn auch, den bach und sein tal zu trennen: ein runder artikel ist immer mehr wert als notdürftiger "füllstoff" neben einer zwanghaften infobox (wegen dem fall hatte ich gefragt, das beispiel Fan aus der bedienungsanleitung führt den abfluss nicht)

ich weiß, die folgebox-junkies sind der natürliche feind der artikel-schnippsel-atomisierer ;)

aber sonst ginge natürlich einfach den abflussweg auskommentieren --W!B: 19:08, 17. Jun. 2011 (CEST)

Beziehungsweise unausgefüllt lassen (in den Folgeboxen), für den Leser ist das eh keine Mehrinformation. -- Olaf Studt 12:14, 18. Jun. 2011 (CEST)

Wäre bei dem Beispiel von W!B die richtige Lösung, die IBs sind in dem Punkt redundant. Und was "∞ Unterer Vallülabach" sein soll, das erschließt sich einem Leser auch nicht. --SteveK ?! 18:10, 18. Jun. 2011 (CEST)

erledigt, ganz ohne NOLINK. --SteveK ?! 19:30, 18. Jun. 2011 (CEST)

auch gut

zu "∞" aber, ich dachte das ist das internationale zeichen für "zusammenfluss" - wie macht ihr das? jedesmal ausschreiben? --W!B: 01:43, 19. Jun. 2011 (CEST)

Ich schreibe das aus, das finde ich besser als Zeichen, die nirgendwo erklärt werden. --SteveK ?! 21:24, 19. Jun. 2011 (CEST)

Poskarte?

ach ja, noch was - kann man die poskarte freischalten? oft finde ich einen überblick, wo das gewässer liegt, deutlich mehr wert und aussagekräftiger als das immer selbe bild "Bächlein mit Gebäumel", "am Spitz mit Schotterbank" oder "Megabrücke über Fluss" - nach dem 30. fluss schauen dann alle gleich aus.. --W!B: 19:18, 17. Jun. 2011 (CEST)

Positionskarten mit mehr als einem Punkt sind noch nicht implementiert. Man kann so etwas zwar händisch mithilfe von Vorlage:Positionskarte basteln, aber eben nicht automatisch. -- Olaf Studt 12:19, 18. Jun. 2011 (CEST)

ach so, klar, mein fehler, stimmt natürlich - allfällig könnte man den mittelwert hernehmen, dürfte sich selbst auf einer adm1st-skala wohl kaum auswirken, es wird ja wohl nur für kleingewässer oder exoten gebraucht werden - oder setzt das dann wieder eine geokoordinate automatisch, die unter umständen irgendwo fernab vom fluss im gemüse liegt? --W!B: 01:56, 19. Jun. 2011 (CEST)

Beim Mittelwert wird wohl eine Pampa-Koordinate rauskommen. Ich wäre für die Lösung zu haben, dass eine Relation in OSM dargestellt wird. Etwa so. Das sagt mehr als ein Punkt am Fluss. --SteveK ?! 21:21, 19. Jun. 2011 (CEST)

Ich habe inzwischen ja so einige Geopfade zu Flüssen. Wenn man die je in Poskarten integrieren könnte, wäre das sicher opti. Es müßte halt möglich sein, sowas wie "Karte/Luftbild des kompletten Flusssystems der Werra" in Poskarten einzubauen (dann natürlich nur den Hauptfluß "Karte/Luftbild der Werra" oder zumindest abgespeckt). --Elop 15:13, 20. Jun. 2011 (CEST)

wieso kann man eigentlich eine Positionskarte mit mehreren Markierungen nicht in die IB einbauen? wo liegen da die technischen probleme? --W!B: 05:05, 22. Jun. 2011 (CEST)

Man könnte doch Mündungs- und Quellkoordinaten nehmen. Sollte man mMn nur machen, wenn uber KARTE= keine Karte des Einzugsgebietes oder sowas eingebunden wird. --Matthiasb ^{(CallMyCenter)} 20:49, 24. Jun. 2011 (CEST)

Autokategorisierung dauert ewig

Die neue automatische Kategorisierung dauert ja ewig! Ich habe vor 24 Stunden die Kategorie:Flusssystem Swakop angelegt, und bis jetzt ist noch kein Fluss (bzw. Rivier) darin zu sehen (Stattdessen tauchen sie in Spezial:Linkliste/Kategorie:Flusssystem Swakop auf). -- Olaf Studt 19:14, 24. Jun. 2011 (CEST)

Nu sind sie da. Hat das jetzt vollautomatisch 25 Stunden gedauert, oder hat jemand mit Pseudoedits nachgeholfen? -- Olaf Studt 20:12, 24. Jun. 2011 (CEST)

Ich glaube, das hängt vom Zustand/Auslastung der Server ab. Aber mehr weiß ich nicht darüber. --SteveK ?! 21:01, 24. Jun. 2011 (CEST)

Anderthalb bis zwei Tage ist normal, hängt auch davon ab, was sonst so verbrochen wird. Würde jemand in EN Template:Cite web ändern, wäre die sog. Warteschlange eine Woche dich oder so. --Matthiasb ^{(CallMyCenter)} 21:16, 24. Jun. 2011 (CEST)

Genauigkeit bei Länge und EZG

Habe eben beim Setzen der Nachweise für den Laxbach gesehen, dass

• die Länge des Flusses (0,738 km) auf den angegebenen Meter hin in Metern wiedergegeben wird
• ähnlich beim Einzugsgebiet: in Hektar mit dem angegebenem Zehntel.

Ich habe wohl hier einmal erfahren, es würde (bei der Länge) auf alle Fälle auf volle 0,1 km gerundet. Anscheinend also nicht mehr. Unter der Hand die Darstellungsgenauigkeit zu ändern scheint mir gefährlich, weil mancher die volle Genauigkeit aus der Quelle nur übertragen hat, weil er sich auf die anschließende Rundung verließ.

Die geltende Rundung sollte man folglich auch in der Beschreibung der Parameter mit dokumentieren. Und jede Änderung daran hinausschreien.

Bei jeder Angabe von Daten auf eine einheitliche Genauigkeit hin fallen die Längen der dann allzu kurzen Gewässer(abschnitte) durch den Rost. Wenn man das verhindern und den Beiträgern auch in anderen Fällen die Möglichkeit geben wollte, die gewünschte Genauigkeit festzulegen, etwa weil der Längenfehler von vierlei Umständen außer der bloßen Länge abhängen könnte, dann bleibt nur übrig, in den sauren Apfel zu beißen und einen weiteren Box-Parameter hierfür einzuführen, vielleicht à la

LÄNGE-FORMAT= 0.x (auf hundert Meter genau)

EINZUGSGEBIET-FORMAT= 0.xx (auf Hektar genau)

Wenn man sich nicht einmal auf die Angabe der gültigen Stellenzahl beschränken und es noch genauer haben wollte, stattdessen vielleicht

LÄNGE-RASTER= 0.1 (auf hundert Meter genau)

EINZUGSGEBIET-RASTER= 0.02 (auf zwei Hektar genau)

Erlaubte Rastergrößen müsste natürlich die Einheit ganz teilen. Endziffer 1, 2, 5 (oder gar keine nach dem Dezimaltrenner) wie bei Münzen sollten i.a. reichen und umschiffen das Problem einer weiteren Möglichkeit zu fehlen.

Mit so einem Parameter würden künftighin semantisch intendierte Vorgaben der Genauigkeit nicht mehr bei einer willkürlichen Änderung der Standard-Rundungskonvention verloren gehen, da sie explizit ausgewiesen und damit unmissverständlich würden.

Ferner wundert mich, wieso man die Länge mal in Kilometern, mal in Metern angibt – oder in diesem Falle die Fläche in ha statt in km². Durch Vorlagenprogrammierung kann man das sicher machen, aber ist es auch sinnvoll? Ich glaube nicht. Für mich sind solche Daten begrifflich immer tabellarisch, und dann verrückt man besser nicht unnötig das Komma oder bürstet sie auf eine äußerlich andere Form hin – ich zumindest spähe zuerst auf die Mantisse und dann erst auf Exponent und Einheit. Um ein zugegeben viel ärgerlicheres, aber ähnliches Beispiel aus einem anderen Bereich zu nehmen: Datumsangaben für den gleichen Tag in Dateilisten „hilfreich“ von numerisch auf ein wörtliches heute oder gestern abzuwandeln mag ja auf den ersten Blick ungemein chic wirken, aber hält bei der Arbeit eher auf, weil man stutzt und in Gedanken dann oft genug rücktransformieren muss; noch gar nicht davon zu reden, dass morgen heute gestern sein wird.

Gruß -- Silvicola Diskussion Silvicola 09:01, 4. Jul. 2011 (CEST)

Hallo Silvicola,

ich habe jetzt nochmals im Code der Vorlage nachgeschaut. Es gilt Folgendes:

• LÄNGE: Die Länge wird, wenn >=1 km auf eine Nachkommastelle gerundet. Bei <1 km wird der genaue Wert übernommen und die Angabe erfolgt in Metern.
• EINZUGSGEBIET: Hier erfolgt keine Rundung. Wird weniger als 1 km² angegeben, dann erfolgt die Angabe in Hektar.

Ich bin gegen die Einführung von weiteren Parametern, das macht die Anwendung noch komplizierter. Ich würde aber folgende Rundung vorschlagen:

• LÄNGE: bei >=1 km wird auf eine Nachkommastelle (100 m Genauigkeit), bei <1 km auf zwei Nachkommastellen (10 m Genauigkeit) gerundet.
• EINZUGSGEBIET: bei >=1 km² wird auf zwei Nachkommastellen (1 ha Genauigkeit), bei <1 km² auf drei Nachkommastellen (0,1 ha Genauigkeit) gerundet.

Zu den verwendeten Einheiten: mMn sollten Angaben in vernünftigen Größenordnungen angegeben werden. Das heißt für mich, dass Längen unter einem Kilometer in Metern angegeben werden. Das Gleiche gilt auch für Flächenangaben, wobei die Angabe in m² sicher nicht sinnvoll ist. Deshalb würde ich Hektar bevorzugen, auch deshalb, weil wohl darunter keine genaue Messung mehr erfolgen kann.

Gruß --SteveK ?! 10:25, 4. Jul. 2011 (CEST)

Am besten wäre es ja, die Box rundete. Dann könnte man im Quelltext den Wert aus der Quelle ablesen, der aber ansonsten Spielerei ist. Wir sehen ja regelmäßig, daß an den Landesgrenzen HE, NW und RP da voneinander abweichen.

Ich trage übrinx bislang sowohl Länge als auch Einzugsgebiet immer mit einer Nachkommastelle in Fließtext und Tabellen ein und nur in die Box den Quellenwert. --Elop 11:59, 4. Jul. 2011 (CEST)

Machte ich auch so, nur habe ich mich zuletzt auf die 0,1-km-Rundung der Länge verlassen, weil ich den Wert aus der Quelle vordem zur Kontrolle in einem HTML-Kommentar dahintergesetzt hatte, das aber mit einem Tool nicht zusammenging.

Der Vergleich der Seekonturen nach TK25 und [www.geoportal-bw.de/viewer.html www.geoportal-bw.de] ist im Hinblick auf die Flächen kleiner Seen fast noch ernüchternder. -- Silvicola Diskussion Silvicola 13:19, 4. Jul. 2011 (CEST)

Nicht unter 10 Meter runterzugehen halte ich i.A. für sinnvoll. Der Sprung in der Behandlung des Quelleneintrags zwischen 0.999 und 1.000 scheint mir kontraintuitiv: gleich 2 gültige Stellen mehr. Wenn aber so, dann sollte das unbedingt in der Dokumentation stehen, weil ja – sofern überhaupt in Kenntnis der Umstände – dann doch eingetragen wird

• ≥1 km : wie es halt in der Quelle steht, ach, wird ja ohnehin noch gerundet!
• <1 km : jetzt muss es aber genau sein!

Diesen Wechsel der Interpretation finde ich irritierend. Übrigens, im Fall unter 1 km könnte die Box bei weniger angegebenen Nachkommastellen wenigstens auch nur soviele gültige angeben (und bei Meter-Angabe eben hinten entsprechend mit Nullen auffüllen) wie im Quelltext steht, da hätte man wenigstens als Autor noch mehr Kontrolle. Ohne dies wird ja einfach unterstellt, dass der Wert jetzt auf Meter genau ist.

Übrigens ist, was Beiträger in ihre Artikel geschrieben haben, seinerseits auch von der Interpretations-Konjunktur der Box abhängig, so wie sie sie erlebt und gedeutet haben, weil die sicher mit Bedacht darauf eingetragen haben. Jede Änderung verwischt das dann wieder.

Vernünftig ist jede Einheit, und günstig ist, wenn man immer dieselbe stehen hat, also nicht Parsec und Lichtjahr nebeneinander. Leider liegt aber m unter der üblichen Messgenauigkeit bei Gewässerlängen, weshalb dann gleich das Problem auftritt: soviele gültige NKS oder nur soviele angegebene. Also: bedeutet 700 m nun

• 700 ±50 m oder
• 700 ±0,5 m?

Bei Kilometerangaben ist diese Unsicherheit nicht da; man kann einfach aufhören mit den NKS, wenn es genug ist.

-- Silvicola Diskussion Silvicola 13:19, 4. Jul. 2011 (CEST)

Wir müssen beachten, das es in der WP sehr kurze Bäche gibt (vor allem in Bonn). Will man allen gerecht werden, dann muss man im Grunde für die kleinen Werte eine Öffnung der Genauigkeit machen. Das ist übrigens auch der Grund, warum die derzeitige Lösung entstanden ist. Es bleibt jedem Autor ungenommen, den 753 m langen Bach als 800 m lang anzugeben, der 123 m lange Bach wird wohl vom Autor als 123 m lang angegeben statt 100 m. --SteveK ?! 16:23, 4. Jul. 2011 (CEST)

Nebenthema:

Daß in Bonn die Bäche kürzer sind, glaube ich weniger. Hängt wahrscheinlich eher mit Artikelanlegern zusammen. Wenn man z.B. bedenkt, daß der Ennert ein einziger Hügel ist und 7 Bergartikel hat ... --Elop 17:55, 4. Jul. 2011 (CEST)

Zugegeben, mit dem Bonn habe ich etwas gestichelt. Wollte ja nur dran erinnern, das es auch Artikel mit Längen unter 200m Länge gibt. --SteveK ?! 21:20, 4. Jul. 2011 (CEST)

Und schon wieder gestichelt. -- Silvicola Diskussion Silvicola 21:46, 4. Jul. 2011 (CEST)

Ach, das kann ich ganz gut, vor allem wenn es die DB AG mal wieder nicht schafft, die Züge pünktlich fahren zu lassen. --SteveK ?! 22:43, 4. Jul. 2011 (CEST)

Flusssystem wird nicht angezeigt

Hallo, warum wird z.b. beim Wormsgraben das Flusssystem in der Box nicht angezeigt? --80.142.161.224 13:25, 24. Jul. 2011 (CEST)

In deinem Beispiel wird der Parameter zweimal angegeben, einmal leer und einmal "Elbe". Die Vorlage verwendet scheinbar den leeren Parmeter. Und will man die Autokategorisierung der Box ausschalten, so muss der Parameter NOAUTOKAT gesetzt werden. -- SteveK ?! 13:58, 24. Jul. 2011 (CEST)

Automatische Kategorisierung

Hier läuft etwas schief: vier verschiedene Dons in einem Flusssystem; eigentlich ist nur der in Russland gemeint. Bekommen die anderen 3 überhaupt eine Flusssystemkategorie? -- Amga 14:22, 29. Aug. 2011 (CEST)

Drei von den vier Dons sind nicht nach der NK benannt. Und die Kategorie heißt nicht so wie der Fluss. Deshalb ordnet die Software alle Dons in die Kategorie ein. Es gibt die Möglichkeit, mit der Angabe NOAUTOKAT=JA die Kategorisierung abzuschalten. Besser wäre es, die Kategorie analog zum Fluss zu benennen, dann funktioniert die Kategorisierung für die Nebenflüsse auch korrekt. Dann würde ich jedoch das Lemma auf Don (Schwarzes Meer) ändern und die Kategorie:Flusssystem Don (Schwarzes Meer) nennen. -- SteveK ?! 14:50, 29. Aug. 2011 (CEST)

Ob man mutig sein kann? --Amga 14:59, 29. Aug. 2011 (CEST)

Ich habe gerade festgestellt, dass der Don (Asowsches Meer) in ein Nebenmeer des Schwarzen Meeres mündet. Nach der NK müsste das dann Don (Asowsches Meer) heißen. Ob man das so machen sollte weiß ich nicht. Ich leite die Frage mal an das WP:WPG weiter. -- SteveK ?! 12:24, 31. Aug. 2011 (CEST)

Mehrere Geographische Quellorte

Bei der Donau werden für den Ursprung in der Regel 3 Möglichkeiten angegeben (Bregquelle, Zusammenfluss Brigach und Breg, Donaubachquelle). Wie könnte man diese Geographischen Orte direkt in der Infobox der Donau angeben? Für den Donaubach wäre ja eine extra Infobox (wie bei den Quellflüssen Fan (Fluss)) möglich, was aber wohl etwas übertrieben wäre. --Jocme 12:18, 12. Sep. 2011 (CEST)

Bilderwunsch nur, wenn Koordinaten bekannt sind

Hallo zusammen, wäre es möglich, die Vorlage:Bilderwunsch/encode nur zu setzen, wenn dabei Koordinaten übergeben werden? Ansonsten landen sämtliche Flüsse, bei denen nicht Quelle und Mündung angegeben ist in Kategorie:Bilderwunsch an beliebigem Ort. Danke und Gruß, --Flominator 19:27, 28. Sep. 2011 (CEST)

Ich halte die Implementation für die Einordnung in die Kategorie für überflüssig. Wir müssen nicht jeden Bach bebildern. Darüber hinaus ist sie auch noch fehlerhaft. Ich werde das jetzt erstmal auskommentieren -- SteveK ?! 12:08, 1. Okt. 2011 (CEST)

Wir müssen nicht jeden Bach bebildern, können es aber, wenn uns Bilder zur Verfügung stehen. Um Wikipedianer vor Ort vielleicht anzuspornen, ein Foto zu schießen und hier bereit zu stellen, ist der Bilderwunsch doch ein sehr hilfreiches Instrument. Und wenn diese in einer Kategorie zusammengefasst werden, sind sie auch noch leichter zu finden. -- Doc Taxon @ Discussion 11:20, 2. Okt. 2011 (CEST)

Nur zur Anmerkung, was ich dort vorher eingefügt hatte: Der Bilderwunsch wurde aktiviert, wenn sowohl kein Bild, als auch keine Karte vorhanden war. Zudem mussten Koordinaten angegeben sein (Flominator's Wunsch war also bereits erfüllt). Als weitere Bedingung musste der Fluss durch mind. eine Gemeinde oder größer Fließen. Später hatte ich das auf mind. Kleinstadt oder großer heraufgesetzt. Wegen der letzten Bedingung ist das von "jeder Bach" deutlich entfernt gewesen. Merlissimo 11:37, 2. Okt. 2011 (CEST)

Merlissimo deine Implementierung in Ehren, aber die hat den Quelltext ziemlich unübersichtlich gemacht. So etwas kann man sehr gut am Ende einfügen und nicht irgendwo dazwischen quetschen.

Bilderwünsche haben mMn nur dann einen Sinn, wenn man gezielt angeben wird, was denn für ein Bild gemacht werden soll. Pauschal die Mündung oder Quelle als Punkt als Bilderwunsch anzugeben halte ich für wenig zielführend. Da kommen tausende Bilderwünsche zusammen.

Auch die Beschränkung auf KLEINSTADT ist wenig hilfreich, da dieser Parameter oft genug gar nicht ausgefüllt wird. Ich jedenfalls nenne die Ortschaften im Fließtext und nicht in der IB. Damit fallen wieder zahlreiche potentielle Bilderwünsche weg.

Das Ganze vorher diskutieren um eine optimale Lösung zu erreichen, das wäre der mMn bessere Weg gewesen. (nicht signierter Beitrag von SteveK (Diskussion | Beiträge) )

Dann diskutieren wir doch jetzt ;) Meiner Meinung nach hat jedes Gewässer, das Artikel und Infobox verdient auch das Recht auf ein Bild. Was spricht dagegen? --Flominator 14:11, 16. Okt. 2011 (CEST)

Wir haben 1000de kleine Gewässer, die sich irgendwie ähneln. Wenn du dir Bilder zu Flüssen anschaust, dann wirst du sehen, das die oft genug kaum zu unterscheiden sind. Bei Flüssen ist es echt schwer, aussagekräftige Fotos zu machen. Zudem geben wir hier ja die Quell- und Mündungskoordinaten an. Wo dazwischen soll denn das Bild entstehen. Ich bin nicht gegen Bilderwünsche, aber gegen pauschale, unkontrollierbare Wünsche. --SteveK ?! 17:32, 22. Okt. 2011 (CEST)

Ich habe auch an anderer Stelle meine Skepsis über diese Art von Bilderwünschen geäußert, sie "spammt" nur die Wartungslisten voll. Explizit gesetzte Bilderwünsche sollten stets den Vorrang haben. --Atamari Datei:WhitePaperbag.jpg 17:49, 22. Okt. 2011 (CEST)

Ich dachte, das hätten sie auch. Soweit ich mitbekommen habe, waren die Flüsse nie in den Listen, sondern nur auf der Karte zu sehen. Den Einwand von SteveK kann ich dennoch nachvollziehen. Da stellt sich mir doch die Frage, ob wir überhaupt einen Parameter Bild in dieser Infobox haben sollten? --Flominator 17:55, 22. Okt. 2011 (CEST)

Der Parameter BILD dient letztendlich dazu, Bilder in der Infobox darstellen zu können. Speziell die Implementierung von BILD und KARTE ist ja so ausgelegt, dass das Bild oben angezeigt wird wenn der Parameter KARTE nicht angegeben wurde. Ist eine KARTE angegeben, dann wird die oben, das BILD unten in der IB dargestellt. Auf die optionalen Bilder könnte mal letztlich verzichten. --SteveK ?! 19:17, 22. Okt. 2011 (CEST)

Wie wäre es denn, hier den anderen Weg zu gehen und den Bilderwunsch optional als Infoboxparameter aufzunehmen? --Flominator 12:04, 27. Nov. 2011 (CET)

Das wäre ein gangbarer Weg. Habe aber gerade eine andere Baustelle.--SteveK ?! 18:28, 27. Nov. 2011 (CET)

Aubach (bei Schwerin) - automatisch vergebene Flusssystem-Kat falsch

Da sie wahrscheinlich über die Infobox vergeben wird, wie bekomme ich beim Aubach (bei Schwerin) die Kategorie:Flusssystem Stör raus? Es handelt sich dabei um die falsche Stör (Elbe), ich sehe aber nicht, wie es zu der Verknüpfung kommt, da diese nicht verlinkt ist. Gruß -- Niteshift 13:41, 10. Okt. 2011 (CEST)

Das geht so. NNW 14:00, 10. Okt. 2011 (CEST)

Aja, danke, trotzdem komisch, dass die Kat vergeben wurde. -- Niteshift 14:14, 10. Okt. 2011 (CEST)

In der IB wird die Stör erwähnt, darauf springt die Automatik an. NNW 14:34, 10. Okt. 2011 (CEST)

Dass der Ausgabetext und nicht der Link ausgewertet wird, ist eine potenzielle Fehlerquelle. Es ist ja keine Seltenheit, dass verschiedene Flüsse den gleichen Namen tragen. Da muss man, nicht du, was machen :-). Gruß -- Niteshift 14:52, 10. Okt. 2011 (CEST)

Die Realisierung ist so beschrieben, dass zuerst versucht wird, die Kategorie entsprechend dem Lemma des Flusses zu vergeben. Existiert keine solche, so wird das gleiche über den Anzeigenamen versucht. Dieses erfolgt, weil es zahlreiche Flusssystem-Kategorien gibt, anders heißen als ihre Flussartikel. Ich sehe an der Stelle gerade keinen Handlungsbedarf. --SteveK ?! 15:30, 10. Okt. 2011 (CEST)

Ich habe jetzt die Kategorie:Flusssystem Stör nach Kategorie:Flusssystem Stör (Elbe) verschoben, damit ist auch das NOAUTOKAT überflüssig. --SteveK ?! 19:46, 10. Okt. 2011 (CEST)

Danke. -- Niteshift 20:05, 10. Okt. 2011 (CEST)

Gemeinden / Gemarkungen / Flure

Nochmal eine Frage zur Klärung des "Gemeinden"-Parameters: Muss der Fluss dafür bebautes Gebiet (landläufig die Ortschaft genannt) durchfließen oder reicht es, dass er durch die Flure bzw. offiziellen Verwaltungsgrenzen der Gemeinde fließt? Wie ist es angedacht? Danke! Gruß --DB111 14:04, 23. Okt. 2011 (CEST)

Nachdem hier keiner antwortet muss ich das wohl machen. Meiner Meinung nach sind für den Fluss nur die Ortschaften interessant, die direkt am Ufer des Flusses liegen. Eine Besiedelung ist sowohl interessant für die Flussgestaltung als auch für die Umweltsituation des jeweiligen Flusses. Es wird aber oft anders gehandhabt und es werden alle Gemeinden eingetragen, durch die der Fluss fließt es wäre interessant darüber mal ausführlicher zu diskutieren. --SteveK ?! 19:14, 5. Nov. 2011 (CET)

Ich sehe es ähnlich wie Steve, hatte aber schon mal eine Diskussion (war glaubich bei der Lippe), wo sich mein Gegenüber am Begriff "Gemarkung", wie er bislang im Erklärungstext steht, aufhing. Obwohl das Ziel (= nur Orte mit Siedlung am Fluß) auch so herauslesbar sein dürfte.

Aber wichtig wäre auf jeden Fall schon einmal, einen eindeutigen Konsens dafür zu erzielen, daß es um bebaute Ortschaften am Fluß geht, nicht um Wiesen und Wälder, die theoretisch zu Icksdorf oder zur Verbandsgemeinde Üpsilonhausen gehören! --Elop 03:02, 6. Nov. 2011 (CET)

Danke, so hatte ich es auch vermutet, da hab ich mal eine ungefähre Hausnummer. Gruß --DB111 20:06, 6. Nov. 2011 (CET)

Gewässerkennzahl Frankreich

Ich möchte der Community nur mitteilen, dass die französische Gewässerdatenbank offensichtlich massiv die GKZ der einzelnen Flüsse geändert hat. Nach meinen bisherigen Nachforschungen handelt es sich zumeist nur um die letzte Stelle, an der ein anderes Zeichen gesetzt wurde (sehr oft wird ein Bindestrich gegen eine Null getauscht). Die Auswirkungen sind jedenfalls, dass der Link aus der IB zu einem als gelöscht markierten Eintrag führt (Statut: Gelé) und die Daten nicht mehr gelesen werden können.

Beispiel: alter Link Sedelle bei SANDRE (französisch), neuer Link Sedelle bei SANDRE (französisch)

Ein händisches Nachziehen ist sehr mühsam und braucht eine Ewigkeit. Vielleicht hat jemand eine Idee, wie wir das automatisieren könnten? Grüße --Skipper69 16:46, 17. Nov. 2011 (CET)

Das ist aber blöd. Ich weiß nicht mal, wie man bei der Vorlagenprogrammierung das letzte Zeichen gegen eine "0" tauschen kann. Einzigste was mir als Hilfe einfällt ist, einen Link aus eine Wartungsseite zu setzen um dann die vorhandenen Links manuell zu prüfen. Ich habe keine Idee wie man das automatisiert lösen könnte. --SteveK ?! 21:06, 17. Nov. 2011 (CET)

Vielleicht könnte man die Vorlage:Sandre so modifizieren, dass sie die letzte Stelle gegen eine Null tauscht, wenn nur "Gelé" zurückkommt. Aber ich versteh nix von Vorlagenprogrammierung...--Skipper69 12:07, 18. Nov. 2011 (CET)

Das "Gelé" bekommt man ja nur, wenn man dem Link folgt. Bei der Anzeige eines Links sieht man das Ergebnis ja noch nicht. Automatisch wird da nichts gehen. Arbeitsliste erstellen und von Hand abarbeiten. --SteveK ?! 12:24, 18. Nov. 2011 (CET)

Es wär aber schon ein Vorteil, dass man die Richtige Info bekommt, wenn man dem Link folgt. Für die reine Anzeige der GKZ sehe ich kein Problem, weil die alte GKZ ja immer noch dem Fluss zugeordnet ist - bloß als nicht mehr aktuell! --Skipper69 14:10, 18. Nov. 2011 (CET)

Ich habe mal eine Liste gemacht zum austragen der kontrollierten. Is schon ein Muff das ganze. --SteveK ?! 21:03, 19. Nov. 2011 (CET)

Könntest Du vielleicht ne Liste erzeugen, wo außer dem Namen auch die GKZ draufsteht (vielleicht auch selektieren auf letzte Stelle = "-" oder "A"). Das wäre sicher sehr hilfreich, weil man dann einmal einen Überblick über das Schadensausmaß bekäme... Grüße--Skipper69 10:20, 20. Nov. 2011 (CET)

Das geht mit meinem Bot gerade nicht, der kann nur Kategorien auslesen. Ich hatte in der Vorlage eine Kategorie gesetzt und anschließend ausgelesen. Nachdem es keine Erhöhung der Artikelanzahl gegeben hat habe ich die Liste erstellt und die Kategoriezuweisung aus der Vorlage entfernt. Habe mich eh gewundert, dass es keine Rückfragen gab. Müssen aber vielleicht kann mit der Liste ein anderer Bot was anfangen. --SteveK ?! 18:36, 22. Nov. 2011 (CET)

Ich vermute, dass das letzte Zeichen den Versionsstand des Datensatzes wieder gibt

• "-" erste Erfassung
• "A" erste Korrektur/Kontrolle
• "0" finaler Datensatz.

Wenn meine Vermutung zutrifft, dann würde das bedeuten, dass alle Datensätze die mit "A" enden nochmal geändert werden. --SteveK ?! 18:50, 26. Nov. 2011 (CET)

So, ich glaube, wir haben jetzt alle geänderten GKZ nachgezogen. Wenn Deine Vermutung zutrifft, was ich auch glaube, dann müssen wir die Gewässer mit GKZ-Endstelle "-" und "A" weiter im Auge behalten. Kannst Du nicht doch ein Bot auftreiben, das uns das ermöglicht? Vielen Dank für Deine Hilfe! Grüße --Skipper69 11:44, 28. Nov. 2011 (CET)

Abflusswerte

Hallo, hier habe ich mal die Idee für die Umgestaltung der Abflusskenngrößen probiert. Neu sind die Parameter:

• ABFLUSS-REIHE = Messreihe
• ABFLUSS-LoM = Lage des Pegels oberhalb der Mündung
• ABFLUSS-EZG = Einzugsgebiet oberhalb des Pegels

Kommentare sind erwünscht. Ziel ist es, mehrere Pegel anzubieten und auch die Quellschüttung (s.o.) damit zu formatieren. --SteveK ?! 21:49, 17. Nov. 2011 (CET)

Sieht bis jetzt ganz gut aus. Wie wäre denn dann die Darstellung der weiteren Pegel, um das Ganze übersichtlich zu gestalten? -- Freak-Line-Community 22:26, 17. Nov. 2011 (CET)

Ich hatte vor, die Pegel mit den Parametern:

• PEGEL1=<NAME>/<EZG>/<LoM>/<NNQ>/<NNQ-DATUM>/<MNQ>/<MQ>/<MHQ>/<HHQ>/<NNQ-DATUM>
• PEGEL1-REIHE=Messreihe (wegen "/" zwischen den Jahren als extra Parameter)

Die weiteren dann als PEGEL2 bis ... Ich habe aber keine Vorstellung darüber, wie viele man vorsehen sollte. Nur so als Idee ist mir gerade gekommen, dass man diese zwischen Quellangaben und Mündungsangaben machen könnte. Ich werde vor der Aktivierung hier auf alle Fälle zeigen wie es aussieht. --SteveK ?! 12:35, 18. Nov. 2011 (CET)

Gute Sache ersma - ich hatte ja bei Flüssen wie z.B. Hörsel immer von Hand formatiert und bei weiteren Flüssen immer die Formatierung kopiert. Theoretisch könnte man für Jahre bzw. Datum auch eine Extraspalte machen.

Ob wir mehrere Pegel in der Box brauchen, ist eine andere Frage. Wenn jemand fragt, wieviel Wasser die Ruhr führt, meint er ja in der Regel "in den Rhein" und nicht "aus Winterberg heraus".

Andererseits haben wir in Hessen von HLUG extrapolierte Werte für MQ und MNQ. Die würde ich - an der Mündung - immer zusätzlich zum letzten Pegel angeben.

Die Summe der Saale- oder Rheinpegel gehört dem gegenüber m.E. in einen tabellarischen Abschnitt im Artikel. --Elop 14:52, 18. Nov. 2011 (CET)

Das mit dem eigenen Parameter für den Stand der abgerufenen Daten finde auch ich gut. Weitere Pegel sollten wenn möglich schon untergebracht werden. Ich persönlich finde es sehr interessant z.B die Abflussdaten der Regnitz an ihrer Mündung mit dem Main vor der Regnitzmündung zu vergleichen. Wie man das aber im übersichtlichen Rahmen gestalten soll wird wohl das Hauptproblem sein. Wäre evtl. ein ausklappbarer Teil der Box möglich? -- Freak-Line-Community 15:59, 18. Nov. 2011 (CET)

Hast du schon mal eine teilweise ein-ausklappbare Box gesehen. Dann könnte man versichen es dort abzukupfern.

Elop, die Ruhr ist wohl ein eher schlechtes Beispiel. Die Blau oder auch die Alme haben Karstquellen, da ist schon die Schüttung interessant. Und dann verliert die Alme in einem Ponor auch noch Wasser, da halte ich mehrere Pegel schon für interessant. Gruß --SteveK ?! 22:31, 18. Nov. 2011 (CET)

Ich halte auch mehrere Pegel für interessant - gerade, damit man z.B. sieht, wie die Pader der Alme klammheimlich Wasser abgräbt. Ich meinte eben nur, daß in der Box besser nicht alle Rheinpegel stehen sollten, sondern der letzte vor der Nordsee plus u.U. eine offizielle Hochrechnung von MQ/MNQ/MHQ für die Mündung.

Freaks Beispiel von Regnitz und Main gehört z.B. explizit in beide Artikel, bringt jedoch in der Box wenig.

So Dinge wie Teil-Mqs (kann bei der Alme auch mal abschnittsweise negativ sein) finde ich in einzelnen Abschnitten mit detaillierteren Tabellen besser aufgehoben. Zumal die Box ja im Idealfalle kürzer sein sollte als der Artikel bzw. noch besser schon vor den größeren Tabellen enden sollte. --Elop 22:49, 18. Nov. 2011 (CET)

Soviel ich noch in Erinnerung habe hattest du mal die Abflussspende ins Gespräch gebracht. Die passt auch nicht wirklich gut in die IB rein. Bei der Anzahl der Pegel muss man sich auch begrenzen, in den meisten Fällen wird die Angabe des Abflusses an der Mündung ausreichen. --SteveK ?! 09:54, 19. Nov. 2011 (CET)

Ich habe da nochmal etwas an der Formatierung geändert. Bei der Lagebeschreibung des Pegels sollten wir mal Überlegen, wie es kürzer gehen würde damit kein Umbruch erfolgt, "km oberhalb der Mündung" ist etwas lang, "km oberh. d. M." eher fragwürdig. Hat jemand eine Idee? --SteveK ?! 11:40, 19. Nov. 2011 (CET)

Man könnte "vor Mündung" schreiben. Ansonsten besser ausgeschr. a. abg.

Die Abflussspende (Mq) wäre eigentlich eine schöne Größe, die die Box berechnen könnte. Ist immerhin eine globale Größe, die etwas über die entwässerte Landschaft aussagt, siehe auch Abflussspende#Typische Mq-Werte. Man erkennt dadurch auf einen Blick - und auch im Vergleich zum Hauptfluss - daß die Unstrut ein Flachlandfluß ist und die Pader ein Karstfluß.

Ich persönlich erwische mich immer, wenn ich mir eine Box anschaue, bei der Mq-Berechnung. --Elop 12:39, 19. Nov. 2011 (CET)

Ich habe die "Lage:" mal entfernt und "vor Mündung" geschrieben. Gefällt mir aber auch nicht so dolle.

Das Einzugsgebiet eines Pegels wird bei den Blättern des DGK-Jahrbuches mit "A_Eo" angegeben. Bei der Lage gibt es "oberhalb der Mündung" oder auch "unterhalb v. Werra u. Fulda" (1. Weserpegel). Wie wäre es, das auch so anzugeben? --SteveK ?! 12:56, 19. Nov. 2011 (CET)

Wie es jetzt ist, sieht es eigentlich ganz gut aus. --Elop 13:18, 19. Nov. 2011 (CET)

Sollte die Quellschüttung jetzt noch untergebracht werden? -- Freak-Line-Community 14:45, 19. Nov. 2011 (CET)

Die ist ja eigentlich keine wirkliche Kenngröße des Flusses, sondern nur eines kleinen Abschnitts bzw. Punktes ... --Elop 15:12, 19. Nov. 2011 (CET)

Stimmt! Trotzdem könnte man sie in die IB unterbringen. War ja auch schon der Wunsch anderer Benutzer. Muss ja keine eigene Zeile dafür vorgesehen werden. Ich denke da eher an etwas wie beim Einwohnerstand eines Ortes. So könnte bei Quelle z.B. auch Lautertopf (600 l/s) stehen. -- Freak-Line-Community 15:21, 19. Nov. 2011 (CET)

So, jetzt habe ich auch die Abflussspende implementiert. Wenn hier keine Einwände gegen die Implementierung bestehen werde ich die Umstellung in den nächsten Tagen machen. Mit der gleichen Vorlage wird dann auch die Quellschüttung implementiert. Anmerkung: Lässt man das EZG weg, dann wird auch die Abflussspende nicht erzeugt.--SteveK ?! 15:32, 19. Nov. 2011 (CET)

Und weiter gearbeitet: Die QUELLSCHÜTTUNG habe ich im Beispiel mal umgesetzt.

Das wird aber auf Deuer schon etwas lang. M.E. höchstens die mittlere Quellschüttung, und dann am besten in der Quellzeile.

Auch bei der Abflußspende reicht als Infobox-Wert der Mq. Ich persönlich würde den beim Abfluß mit unterbringen und "Mq" entsprechend verlinken. Ist ja noch der gleiche Pegel ... --Elop 21:32, 19. Nov. 2011 (CET)

Die Abflussspende passt nicht hinter den Abflusswert, ich hatte das probiert. Nur den Mq ist erst mal deine Meinung, ich warte mal auf andere Äusserungen. Totlegen kann man das recht schnell.

Die Quellwerte werden so angegeben. Wer nur den MQ angibt, der erhält auch nur die eine Zeile. Innerhalb der Angabe "QUELLE" lässt sich das nur schwer umsetzen, das wird einfach bei der Programmierung zu unübersichtlich. Halte es wegen der dynamischen Darstellung für fast unmöglich umzusetzen. Übrigens müsste die Quellhöhe dann auch in der gleichen Tabellenzelle stehen.--SteveK ?! 08:58, 20. Nov. 2011 (CET)

Ich würde die Abflussspende auch mit in die Abflusszeile nehmen, so dass dann NNQ, MNQ, MQ, MHQ, HHQ und Mq untereinander stehen (Reihenfolge evtl. auch anders). Ich glaube das war es auch was Elop gemeint hat. -- Freak-Line-Community 10:11, 20. Nov. 2011 (CET)

Genau so meinte ich das. Aber vielleicht gibt es da ja technische Probleme, da der automatisch berechnete Mq ja, wie auch der Höhenunterschied, ein von der Box und nicht vom Eingebenden erstellter Wert ist. --Elop 11:30, 20. Nov. 2011 (CET)

Die Reihenfolge wäre dann NNQ, MNQ, MQ, MHQ, HHQ, Mq oder NNQ, MNQ, MQ, Mq, MHQ, HHQ oder NNQ, MNQ, MQ, Mq, MHQ, HHQ ? Irgendwie sehe ich den Mq ja im Zusammenhang mit dem MQ--SteveK ?! 18:38, 22. Nov. 2011 (CET)

NNQ, MNQ, MQ, Mq, MHQ, HHQ wäre glaube ich am Besten. Kann die Box das dann berechnen? -- Freak-Line-Community 18:43, 22. Nov. 2011 (CET)

Ja, wenn das EZG des Pegels angegeben wird (Mq=MQ/A_Eo). --SteveK ?! 09:42, 23. Nov. 2011 (CET)

Ich habe das gerade mal umgesetzt, Verlinkung fehlt aber noch. --SteveK ?! 09:56, 23. Nov. 2011 (CET)

Für den Abfluss habe ich die Parameter ABFLUSS-EZG, ABFLUSS-LoM, ABFLUSS-REIHE eingeführt.--SteveK ?! 09:25, 11. Dez. 2011 (CET)

Sieht gut aus ... --Elop 12:08, 11. Dez. 2011 (CET)

Finde ich nicht. Der MQ-Wert klebt jetzt am rechten Rand der Box, siehe fast alle Flüsse in der neuen Kategorie:Flusssystem Sereth. -- Olaf Studt 15:29, 11. Dez. 2011 (CET)

Ich weiß ja, dass die Datenlage nicht immer so doll ist wie in Deutschland und wir froh sind überhaupt etwas zu haben. Die in der von dir genannten Kategorie aufgeführten enthalten die Abflüsse in einer minimalistischen Form. Sieht dort wirklich nicht so gut aus, das sehe ich ja ein. Wenn man die Jahreszahlen der Messreihe einfügt, dann wird es besser. Ich habe aber gerade keine Idee, wie das lösbar ist, ohne dass beispielsweise Möhne mit voller Angabe noch korrekt formatiert wird.--SteveK ?! 16:58, 11. Dez. 2011 (CET)

Parameter Gemeinden

Wie ist folgender Satz zu verstehen: Gemeinden entlang des Flusses (bei kleineren Flüssen). Gemeint ist die Ortschaft, nicht die Gemarkung. ? Werden bei diesem Parameter die Gemeinden selbst (also z. B. Wuppertal) oder die Ortsteile eingetragen (also z. B. Barmen) ? Falls letzteres, halte ich den Parametername "Gemeinden" für irreführend. 91.57.226.33 12:12, 31. Dez. 2011 (CET)

Gemeinden sind unterhalb von Städten angesiedelte, selbstständige kommunale Gebilde. Dein Beispiel hinkt etwas, den Wuppertal ist eine Großstadt und wird im entsprechenden Parameter angegeben. Nicht angeben werden Ortsteile (das sind ja keine Gemeinden), also auch nicht Barmen.

Gemeint ist mit dem Satz, das es für den Flusslauf und damit für die IB irrelevant ist, wenn er ein Gemeindegebiet durchfließt, ohne dass Ortschaften am Fluss liegen. Für einen Fluss ist die Besiedlung interessant, nicht die politische Einteilung der Gegend. Die IB soll nicht mit einer ellenlagen Liste von Gemeinden zugemüllt werden, die nur tangiert werden. Das kann man besser in einer Verlaufbeschreibung machen. Da kann man auch besser die Ortsteile erwähnen. Systematisch kontrollieren tut das aber meines Wissens nach keiner.

Ich wäre übrigens dafür, die Parameter aus der IB zu entfernen, genauso wie die Nebenflussparameter. --SteveK ?! 13:39, 31. Dez. 2011 (CET)

D. h., bei diesem Revert war die Wiedereintragung von Steinheid und gleichzeitige komplette Austragung von Neuhaus am Rennweg falsch, weil letztere Stadt beim Parameter "Kleinstädte" eingetragen werden müsste und Steinheid als Ortsteil gar nicht auftauchen dürfte? 91.57.239.233 14:35, 31. Dez. 2011 (CET)

<quetsch mich mal dazwischen>Wenn ich das bei OSM richtig gesehen habe fließt die Grümpen (Fluss) an dem zu Neuhaus am Rennweg gehörenden Weiler Neumannsgrund vorbei. Allein das würde mMn den Eintrag unter Kleinstadt rechtfertigen. Bei den Ortsteilen ist es so wie du sagst, die gehören nicht dort rein. Sprech doch mal Elop direkt an. Und Achtung, auf der kommunalen Ebene scheint sich dort etwas zum 1.1.2012 zu tun.--SteveK ?! 18:01, 31. Dez. 2011 (CET)

s. weiter unten --Elop 12:20, 1. Jan. 2012 (CET)

Liegt die Gemeinde Aarbergen an der Aar? Aarbergen ist nur ein Name. Ortsteile wie Michelbach liegen tatsächlich im Tal. Wichtig wäre aber aus meiner Sicht schon, eine Gemeinde zu erwähnen, die ihr Gebiet mit einer Kläranlage in den Fluss entwässert, auch wenn die Ortslage etwas weiter entfernt liegt. --Brühl 14:49, 31. Dez. 2011 (CET)

Das ist genau das Ansinnen was ich meinte, der Einfluss der Besiedlung auf ein Gewässer ist maßgebend. Nicht maßgebend ist der reine Durchfluss durch ein Gebiet. Das lässt sich aber in der IB nicht hinreichend darstellen. --SteveK ?! 18:01, 31. Dez. 2011 (CET)

Ich wäre auch dafür den Parameter ganz zu entfernen. Es sorgt doch immer wieder für Verwirrung wenn die durchflossene Gemarkung eingetragen wird. -- Freak-Line-Community 18:32, 31. Dez. 2011 (CET)

Das mit dem Einfluß der Besiedlung sehe ich zunächst genauso.

Genau deshalb halte ich es auch für Stuß, Neuhaus am Rennweg bei der Grümpen einzutragen, während der Weiler dort was zu suchen hätte, jedoch eben nicht selbständig ist.

Den Fall hatten wir mal bei der Werra, als Eisenach eingetragen wurde, welches eindeutig an der Hörsel liegt - nur OT Hörschel liegt an der Werra. Hörschel aber ist, trotz der Eingemeindung, ein abgetrennter Ort.

Überhaupt ist es blöd, Großstädte, Kleinstädte und Gemeinden getrennt einzutragen, da dadurch die Reihenfolge verloren geht.

Wenn Orte in die Box sollen, dann der Reihe nach. Da könnte man höchstens per nachgestellter Klammer nach Stadt, Gemeinde und Teilgemeinde unterteilen. Wobei aber "Stadt" nicht eine "Überordnung" von "Gemeinde" darstellt, sondern oftmal einen historischen Titel, der im Namen weiter geführt werden darf. Was dann mitunter kurios wird, wenn die Stadt eingemeindet wird.

Beispiel:

Wenn ich von Stadtallendorf zum OT Schweinsberg fahre, komme ich an einen Kreisel, wo unter geradeaus "Stadtmitte" eingetragen ist.

Schon merkwürdig, wenn man aus der Stadtmitte kommt, aber gemeint ist die Mitte der Stadt Schweinsberg. Übrinx liegt die an der Ohm, was Stadtallendorf null tut.

Man könnte also in der Box Städte und Gemeindeteile in einer der Reihenfolge nach geordneten Aufzählung per nachgestellter Klammer trennen. Sinnig wäre es aber v.a., die Box auf z.B. 10 (bei längeren Flüssen ausnahmsweise 20) Einträge zu reduzieren, wo man dann die größten bis wichtigsten Siedlungen/Städte nähme. Schweinsberg wäre dann mit 1000 EW oder so und sehr hohem Alter wohl noch in der Ohm-Box. Während Hörschel nicht in die Werra-Box gehört (was Eisenach selber sicherlich täte, läge es denn am Fluß).

Das mit "Gemeinde oder Teilgemeinde" ist nicht wirklich aussagekräftig, gerade wenn mehrere Bundesländer durchflossen werden. NW und HE haben nämlich großflächig eingemeindet, RP aber nicht. Für den historischen, abgetrennten Ort Icksdorf am Abach ist es aber unerheblich, ob er nun weiter selbständig ist, aber zur Verwaltungsgemeinschaft Üpsilonien gehört, oder ob er Stadtteil von Zetstadt ist.

Die Box soll bei der Orientierung helfen. Ist ja bei den dort eingetragenen Nebenflüssen nicht anders. Komplettaufstellungen helfen da, außer bei Kleinstbächen wie der Grümpen, zumeist wenig. Und der formale "Status" auch nicht immer. --Elop 12:20, 1. Jan. 2012 (CET)

Mein Revert der Änderung von Benutzer:Antonsusi

Ich habe die Änderungen von Benutzer:Antonsusi zurückgesetzt. Dafür habe ich folgende Gründe:

1. Die Verringerung der Breite bei gleichzeitiger Vergrößerung der Schrift führt zu mehr Umbrüchen und ist mMn damit unübersichtlicher.
2. Die ursprüngliche Formatierung der Bilder mit 326x326px hat den Sinn, dass die Bilder nicht übermäßig groß werden. Mit der Formatierung wird die längere Kante von quer- als auch hochformatigen Bildern gleich lang formatiert. Bei der von Antonsusi gewählten Formatierung sind die hochformatigen Bilder deutlich größer als die querformatigen Bilder.

Eine Eindruck, wie die Formatierungen aussehen, kann man sich derzeit hier anschauen. Gruß --SteveK ?! 17:53, 5. Jan. 2012 (CET)

1. Ich habe den Eindruck, dass du generell etwas gegen Änderungen durch Andere hast. Hauptautoren neigen gerne zu einem - meist unbewussten - Eigentumsgefühl. Es ist nicht "deine" Box, auch wenn du sie lobenswerterweise fleißig pflegst.
2. Die meisten Boxen in der WP haben Bilder mit 300px Breite, ich streite mich aber nicht um 26px. Eine Angabe wie NNNNxNNNN bewirkt eine unschöne schmalere Darstellung auch von gering hochkantigen Bildern. Die Box verträgt durchaus mindestens ein Bild im leichten Hochkantformat. Da man im Einzelfall die Breite angeben kann, ist diese Beschränkung auch unnötig.
3. Eine Fontsskalierung von 95% führt in vielen Fällen zu einer schlechten Text-Renderung, erspart aber fast nie einen Zeilenumbruch, da nur wenige Angaben so lang sind, dass umgebrochen werden muss. Außerdem gibt es nur bei 5% aller ausreichend langen Texte einen zusätzlichen Umbruch. Für eine wirkliche Platzersparnis müsste die Schrift auf 80% oder weniger skaliert werden, was zu klein ist. Das ist ein rein mathematischer Sachverhalt und daher eindeutig. 95% sind eine schlechte Idee. Das muss unbedingt weg.

Gruß von ÅñŧóñŜûŝî (Ð) 19:06, 5. Jan. 2012 (CET)

zu 1.: Dein Eindruck trügt. Ich habe mir den Revert überlegt und stelle vor Änderungen diese hier zur Diskussion. Was du leider nicht machst. Ein "Eigentumsgefühl" habe ich nicht, ich kann mich auch aus der Pflege der Box zurückziehen, falls das gewünscht wird.

zu 2.: Schau dir Hilfe:Bilder#Automatische_Skalierung an, da wird empfohlen, hochformartige Bilder mit "hochkant" zu formatieren. In der IB mit fester Breite sollte man sich auch daran halten. Bevor man das ändert sollte man es zur Diskussion stellen.

zu 3.: Du hast bei der von dir verwendeten Formatierung >15% der nutzbaren Breite entfernt und nicht 5%. Entsprechend mehr Umbrüche wird es geben. Bisher hat sich keiner an der Fontsskalierung von 95% gestört. Ob es Handlungsbedarf in dem Fall gibt, wage ich zu bezweifeln. Und was unbedingt weg muss, das entscheidest nicht du alleine.

Gruß --SteveK ?! 19:48, 5. Jan. 2012 (CET)

Das mit den 95 Prozent Schriftgröße ist bei Infoboxen fast Standard und ganz sicher keine schlechte Idee. --Matthiasb ^{(CallMyCenter)} 19:23, 5. Feb. 2012 (CET)

95% bringen praktisch keinen Vorteil, da den Parametern fast nie so lange Zeichenketten zugewiesen werden, dass es überhaupt einen Zeilenumbruch gibt und wenn doch, dann wird nur bei 5% von diesen längeren Zeichenketten ein Zeilenumbruch verhindert. Im Gegenzug ruinieren 95% aber die Schriftdarstellung für viele Browsereinstellungen. Wenn im Browser z.B. eine Schriftgröße von 12px voreingestellt ist, dann versucht der Browser, durch Rendering eine Schrift von 11,4 Pixel darzustellen, indem er z.B. Graustufen generiert. Dadurch verliert das Schriftbild aber an Qualität. Das diese 95% in der WP relativ verbreitet sind liegt daran, dass blindlings übernommen wird, ohne über die Sinnhaftigkeit nachzudenken. Es ist einfach qualitativ schlecht, 95% zu skalieren. Entweder man nimmt max. 80%, oder man bleibt bei 100%. ÅñŧóñŜûŝî (Ð) 22:40, 9. Mär. 2012 (CET)

Ein wenig Nachdenken und ich komme zu dem Schluss, dass auch 80% genauso blöd ist wie 95%, bei dem einen kommt eine Schrift von 9,6px, bei dem anderen von 11,4px raus. Will man aus einer 12px-Standardeinstellung eine Schriftgröße von 11px machen, dann müsste die Einstellung 91,666666% sein. Bei einer 14px-Standardeinstellung kommt dann aber 12,83px, bei einer 11px-Standardeinstellung 10,08px raus. Was bleibt ist, man kann für genau eine Einstellung eine gerade Pixel-Anzahl hin bekommen, alles andere ist wieder ungerade skaliert. --SteveK ?! 15:42, 24. Mär. 2012 (CET)

Wertangaben

Könnte man nicht in die Box einen Erläuterungstext etwa des Inhalts

Größenangaben richtet sich nach den benutzten Quellen. Die Größen müssen nicht auf die übernommene Stellenzahl genau sein.

aufnehmen? Dann könnte man die Größen ungerundet nach Quelle übernehmen, ohne damit eine Genauigkeit zu insinuieren, die gar nicht vorliegt. Es wäre vor allem auch vorteilhaft für Bearbeiter, die Größen aus verschiedenen Flussboxen aggregieren (Gesamtlänge eines Entwässerungsstrangs, EZG, vielleicht noch anders), weil man die Fehlerverschlechterung durch Weiterverarbeitung gerundeter Werte vermeiden könnte, ohne von Neuem mühselig vom Kleinen zum Großen aufaddieren zu müssen. (Bsp.: Basis-EZGs → Gesamt-EZG.)

Den Erläuterungstext könnte man anfangs mit einem versteckten Parameter nur zuschaltbar machen. --Silvicola ⇨⇦ 02:29, 24. Mär. 2012 (CET)

Bei der Längenangabe wird das schon gemacht. Eine Angabe von "1.12345" wird als "1.1 km" dargestellt. Beim Einzugsgebiet und den Höhenangaben muss ich nachschauen. Eine bessere Beschreibung dazu kann man sicher machen. --SteveK ?! 10:10, 24. Mär. 2012 (CET)

Beim Nachschauen ergibt sich folgendes Bild:

• Längenangabe wird gerundet auf eine Nachkommastelle, wenn >1 km, ungerundet wenn <1 km.
• Höhenangaben ungerundet, Formatierung erfolgt durch Vorlage:Höhe. Bei "1000.1" wird mit {{Höhe|1000.1|CH}} 1000,1 m ü. M. ausgegeben. Hier sollte man wohl auf ganze Meter runden, da zu viele Nachkommastellen bei der Koordinatenangabe zu Fehlern führt.
• Einzugsgebiet wird derzeit nicht gerundet. Formatiert wird mit der Vorlage:Maß.

--SteveK ?! 10:31, 24. Mär. 2012 (CET)

Ich habe mich unklar ausgedrückt. Ich meinte, von Rundung hinfort ganz abzusehen, ausgenommen vielleicht die Bereinigung offensichtlicher Eingabefehler (Bei einer Höhenangabe auf Mikrometer genau hat offenbar der Bearbeiter geschlampt, also ist Verkürzung auf die realistischerweise allenfalls in Quellen auftretende Mantissenlänge womöglich eine Verbesserung. Genau genommen muss aber gewartet werden, wer weiß denn, wie wild sich einer da verschrieben hat?!) . Man übernehme als Bearbeiter as-is aus der Quelle, vor Fehlinterpretation, dass die Stellenzahl unbedingt bis zu letzten gültig sei, schützt der vorgeschlagene Erläuterungstext – dessen Bedeutung salopp lautet: "Wir können nichts dafür und garantieren nicht für die Gültigkeit, aber so steht es halt da!" Den Leser auf die Fragwürdigkeit manches belegten Datums hinzuweisen ist ohnehin nicht gerade verkehrt.

Ich wurde auf den Vorschlag hingeführt in Verfolg rezenter EZG-Berechnungen durch Addition von Teil-EZGs. Dabei fiel auf:

• Manchmal laufen die EZG-Grenzen ziemlich neben den an den Höhenlinien erkennbaren Wasserscheiden, die bei meiner Hauptquelle Geodatenviewer BW übliche Mantisse von 3 NKS ist dann oft illusorisch.
• Andererseits hat man eine Fehleraufblähung, wenn man gerundete Werte addiert, die vermeidbar wäre.
• Was soll man nun machen, wenn man ein EZG berechnen will, das sagen wir mal 1000 Basis-EZGs enthält? Illusorisch! Man macht da Fehler. Man sollte zumindest die vorher schon berechneten EZGs der Nebenflüsse verwenden können, dann wächst der Aufwand nur linear in der Länge des Flusses (Teil-EZGs am Lauf + EZGs der Nebenflüsse) und nicht quadratisch (2-dimensional).
• Man könnte die genaue Länge per HTML-Kommentar dem gerundeten Eintrag hinzusetzen, das habe ich oft gemacht. Aber dann benutzt jemand den Vorlagenmeister - und schwupp sind diese weg! Man könnte zwar in der History wühlen … ach nein, nicht das auch noch!

Von diesen praktischen Aspekten für Bearbeiter ganz abgesehen – wenn man rundet, verletzt man immer die Invariante, dass das Ganze die Summe seiner Teile ist.

--Silvicola ⇨⇦ 13:49, 24. Mär. 2012 (CET)

Jetzt habe ich kapiert was du meinst. Ich bin da gespaltener Meinung. Zum Einen kann ich dein Anliegen verstehen, zum Anderen ist eine Längenangabe im Millimeterbereich als Schwachsinn zu bezeichnen. Wenn wir das anzeigen übernehmen wir unreflektiert Werte, was dann wohl dem Sinn einer Enzyklopädie widerspricht. Vielleicht äußern sich ja noch andere hier Mitlesende noch zu dem Thema. --SteveK ?! 15:25, 24. Mär. 2012 (CET)

Solche übergenauen Angaben kommen in die Quellen wohl auch nur deshalb, weil die dortigen Bearbeiter den Effekt der Fehlerverschlechterung durch Aggregation in Schranken halten wollen. Die schauen ihre Daten in Wahrheit wohl sehr realistisch an, etwa so

• Drei NKS - Schwachsinn, so genau können wir die Streckenzugpunkte gar nicht klicken, außerdem sind wir da schon im Bereich der Fotoverzerrungen. Naja, vielleicht eine NKS.
• Bei der und der Länge hat man wenigstens so und soviel Zwischenpunkte, mit der und der Ungenauigkeit pro Polygonzuglänge ist dann die Ungenauigkeit schon mindestens …
• Auch noch im Bereich der wilden Talmäander – da geht dann noch mal eine halbe Größenordnung zum Teufel
• Oh, und dann noch bewaldet – da sieht man ja auf den Fotos sowieso vor lauter Wipfeln das Wasserband nicht genau, sondern hält sich nur an die grobe Schneise
• Der Polygonzug wurde damals noch auf der Basis der TKs angefertigt und um Hintertupfing herum hat Herr Schluder die Karten gestochen – und der war ja ein besonders eifriger Generalisierer.

Diese nüchterne Expertise der täglich damit Befassten hat der gewöhnliche Leser nicht. Außerdem ist die Fehlerspanne im Einzelfall kaum genau auszuweisen. Drum dachte ich: Den Leser durch einen allgemeinen Kautelentext von jeder Genauigkeitsillusion abzubringen und die Werte wie sie sind zu übernehmen. Im Grunde erkennt der Leser die Genauigkeitsillusion ja gerade dann selbst, wenn die Stellenzahl besonders schreiend lang ist. Wenn wir „fürsorglich“ runden aber vielleicht nicht mehr, weil wir nach fester Rundungsregel im Einzelfall das Ziffernbild doch schönen, so dass er seine Illusion zu Unrecht behält. Ideal wäre im Einzelfall eine Fehlerspanne anzugeben, so und soviel Sigma – aber das ist nicht zu leisten.

Fundamental geht es m.E. um die Abwägung, ob man lieber wahrhaftig in Sachen der eigenen Unwissenheit sein soll, oder ob man lieber ein gefälliges Bild abgeben will. („Das fällt doch auf die WP zurück, wenn …“) Denn wer nicht verstört, der findet allemal das Zutrauen der Leichtgläubigen.

Das war jetzt etwas lang. --18:12, 24. Mär. 2012 (CET)

Versionsexponierung

Könnte man nicht einen versteckten Parameter für die Version der Flussbox einführen? Offenbar doch ist mit einer beständigen Weiterentwicklung der Box zu rechnen, da wäre es gut, den vorliegenden Versionsstand auf Anhieb zu erkennen, statt auf plausible Schlüsse aus diesem teils durcheinandergemengten Parameter-Salat angewiesen zu sein, der für mich zumindest gar nicht mehr überschaubar ist. Durch manuelles Hinzufügen von Parametern kann die Version zwar neuer geworden sein als angegeben, aber wenigstens würde man die Mindestversion erkennen. --Silvicola ⇨⇦ 02:29, 24. Mär. 2012 (CET)

Hier verstehe ich dein Anliegen nicht so ganz. Bisher ist die Box aufwärtskompatibel, d.h. die Verwendung der Parameter wird für vorhandene Einträge nicht geändert. (Beispiel: Längenangabe: Alt war Text / Neuer ist Zahl). Ein Parameter Version würde nicht ausgewertet werden. --SteveK ?! 10:08, 24. Mär. 2012 (CET)

Mein Ausgangspunkt: Ich würde gerne bei Flussbearbeitungen die neue Box en passant einsetzen, aber nur, wo das wirklich nötig ist. Denn ein leeres Template neueren Stils einzufügen mit anschließendem Umkopieren, nur um am Ende vielleicht festzustellen, dass ja alle Parameter schon da waren, ist mir zu viel des unnützen Aufwandes. Wenn nun ein Parameter

VERSION= X.Y.Z

o.ä. im Quelltext stünde, und ich wüßte, aktuell ist schon Version X.Y.(X+1), dann würde ich mich darauf einlassen.

Vielleicht macht der Vorlagenmeister das ja automatisch mit, aber von dem lasse ich die Finger, schon um keine HTML-Kommentare zu verlieren. Außerdem müsste ich dann JavaScript erlauben, und wenn ich da sehe, wie lange allein der Interface-Icons-Aufbau beim Bearbeitungsfenster dauert …

Ich denke mir, die Artikel mit veralteten Boxen zu finden wäre damit auch einfacher als derzeit. Du scheinst ja solche Aktualisierungen nach meinem Eindruck zuweilen systematisch abzuarbeiten. Wie findest Du denn die veralteten? Mit Insider-Wissen im Stile von "Wenn derundder Parameter noch nicht da ist, dann ist die Box alt" ? Eine explizit ausgewiesene Version wäre wohl besser, weil dann jeder leidlich Vertraute nach gelegentlichem Blick auf die Vorlagenseite sähe: Hier muss aktualisiert werden.

--Silvicola ⇨⇦ 14:23, 24. Mär. 2012 (CET)

Im Prinzip kannst du ohne weiteres einen Parameter verwenden. Ich würde von der Versionierung absehen wollen, denn jede Bearbeitung ergibt eine neue Version. Ich könnte mir aber vorstellen, dann man ein Datum setzt (STAND = JJJJ-MM-TT). Dann hättest du den gleichen Effekt. Solche Parameter müssen jedoch in die Beschreibung und die XML-Beschreibungsseite aufgenommen werden, damit sie nicht immer wieder entfernt werden.

Ja, ich arbeite manchmal systematisch Fehler der IB ab. Dazu gibt es ja die Wartungsseiten. Kategorien fände ich besser (dann kann man sich räumlich begrenzen), aber so geht es auch. Zur Zeit bearbeite ich die falschen Flusssysteme. Ferner schaue ich im Template-Tiger hin und wieder die Parameter durch, um Falschschreibungen zu korrigieren.

--SteveK ?! 15:18, 24. Mär. 2012 (CET)

Nein, wir sind immer noch nicht zusammen. Mit Version meine ich nicht eine Versionierung der einzelnen Box und ihres Inhalts,, da wäre ein Timestamp wirklich besser. Sondern eine Versionierung, auf welchem Ausbaustand die Box-Struktur schon ist, also etwa: schon mit Parametersatz Dingsda/Dingsda-PREFIX/Dingsda-POSTFIX/NACHWEIS-Dingsda für die zu belegenden Dingsdas usw. So etwas wie die Version in <?xml version="1.0">. Oder kann ich das etwa schon am Ensemble der Wartungskategorien erkennen, mit denen eine Seite gespickt ist? --Silvicola ⇨⇦ 17:16, 24. Mär. 2012 (CET)

Letzteres: Nein. Es gibt derzeit keine Versionierung.

Wenn ich dich richtig verstanden habe: Derzeit haben die Parameter die Version 1.0.0, du schreibst also in die Parameter VERSION=1.0.0 rein, was aber derzeit nirgendwo verwendet wird. Du kannst aber bei der Bearbeitung sehen, ob es der aktuelle Parametersatz ist.

Jetzt könnte man ja diesen Parameter vergleichen. Ist die Versionsnummer im Artikel gleich der der Box, dann ist alles ok. Wenn nicht setzt man einen Link auf eine Wartungsseite. Ich glaube ich habe dich doch verstanden.--SteveK ?! 19:23, 24. Mär. 2012 (CET)

Voilà. Wobei ich dachte, hin und wieder die Aktualisierung nicht bloß anzumahnen, sondern gleich mit zu erledigen. Und dass ein Botlauf, der nur diesen neuen Meta-Parameter VERSION inspizierte, unschwer eine Liste von Artikeln mit veralteten Boxen pflegen könnte; leichter zumindest, als wenn er dazu den vollen Satz vorhandener Parameter inspizieren und darauf eine diffizilere Diagnoselogik anwenden müsste – „hat schon den, hat aber den noch nicht“. VERSION ist übrigens kein guter Name, weil er zum Missverständnis Anlass gibt, er sei – objektorientiert gesprochen – ein Attribut der Instanz und nicht der Klasse; das würde dann zum Herumdoktern an diesem Parameter verleiten („Jetzt noch die Version eins weiter zählen, da ich ja einen Parameterwert eingefüllt habe“), von dem man tunlichst abhalten sollte. Besser VERSION-BOXSTRUKTUR o.ä. Einen konkreten Aufbau der Versionsnummern (X.Y.Z oder einfach fortlaufend gezählt oder alphanumerischer Merkmalsvektor oder …) hatte ich noch gar nicht im Sinn. Das dreigliedrige Beispielschema diente nur der Verdeutlichung durch Assoziation mit Bekanntem. --Silvicola ⇨⇦ 20:18, 24. Mär. 2012 (CET)

Es gibt eigentlich nur zwei Möglichkeiten:

• Parameter wird als Zahl angegeben, die Vorkommastelle ist die Hauptversion, die Nachkommastelle die Nebenversion. Bei Änderung der Hauptversion (Parameter geändert) kann man das oben beschriebene machen, bei Änderung der Nebenversion passiert nichts.
• Parameter wird als Text angegeben. Hier gibt es nur die Möglichkeit auf eine Änderung zu reagieren, da es keine Möglichkeiten gibt, die Zeichenkette auseinander zu nehmen.

Ich wäre für die erste Lösung. --SteveK ?! 21:48, 24. Mär. 2012 (CET)

Mir ist beides gleich ziemlich gleich recht; ich wollte nur nicht unnütze Diskussionen begünstigen wollen, „ob das jetzt wirklich ein Hauptversionswechsel ist“. Aber bei den derzeit hier sich Beteiligenden sehe ich die Gefahr eines solchen Streits um des Kaisers Bart eigentlich nicht.

Was soll eigentlich dann der Nebenversionswechsel anzeigen? Irgendwie ist das denn doch in Bezug auf die oben angesprochene Zweckbestimmung dieser Boxstruktur-Versionierung unnütz, oder nicht? Denn wenn sich die Parameter-Menge nicht geändert hat, ist die Struktur ja gleich geblieben. Dachtest Du an eine Nutzung als Bearbeitungszähler? (Soundso oft seit dem letzten Strukturwechsel irgendeinen Parameterwert geändert.) Ich prophezeie Dir, der wird von kaum einem der selteneren Bearbeiter je konsequent inkrementiert werden. Und wenn man alle dahin bringen wollte, wäre es sicherer, die Hauptversion separat in einem Parameterfeld zu haben. Denn sonst wird mancher zweifellos auch daran herumfummeln. Außerdem hat man für die Bearbeitungen die History, wieso doppelt moppeln, und dann noch nach auferlegter und oft nicht beachteter Konvention, wo doch bei der History alles so schön automatisch läuft, man Diffs hat usw. --Silvicola ⇨⇦ 23:51, 24. Mär. 2012 (CET)

Nebenversion wäre ein Bearbeitung der Box. Wenn ich beispielsweise die Rundung ändern würde, dass wären die Parameter der Box nicht betroffen, aber man kann die Änderung in der Version dokumentieren.--SteveK ?! 19:12, 25. Mär. 2012 (CEST)

Das hätte einen Nutzen nur dann, wenn man die Parameter mit Rücksicht auf die spezifische Darstellung so oder anders eintragen würde, sozusagen listig statt getreu. Davon sollte man aber gerade wegkommen. Nur weil sich die View auf sie ändert, sollten nicht die Daten geändert werden müssen. Vielmehr muss die gerade geltende Verarbeitung in der Vorlagenbeschreibung dokumentiert werden und sonst nirgends, und am besten wäre es dazu noch, wenn dort zu allen Parametern stünde: "Trag mal ein, was du findest, und trage es genauso ein, wie du es findest – die Darstellungslogik macht dann schon was Vernünftiges draus!" Sonst hätte man einen Wartungs-Alptraum. --Silvicola ⇨⇦ 19:38, 25. Mär. 2012 (CEST)

Normalisierung durch Bot

Hilfreich wäre es, wenn durch Botläufe leidlich sichergestellt würde, dass die Parameter in allen Flussboxen in einer kanonischen Reihenfolge sortiert würden. Dann wäre man zumindest diesen Fluch der freien Editierbarkeit los. --Silvicola ⇨⇦ 02:29, 24. Mär. 2012 (CET)

Ich normiere immer mit dem Vorlagenmeister. Da kann man dann auch erkennen, ob Parameter doppelt oder falsch eingetragen wurden. So was ähnliches müsste der Bot dann leisten. --SteveK ?! 10:00, 24. Mär. 2012 (CET)

Wg. Vorlagenmeister s.o. "So was ähnliches" – ja, wenn denn dieser auch Parameter sortiert. Wenn nicht, etwas mehr. Und ein Petitum, s.o.: HTML-Kommentare nicht tilgen. Wegen der satt mit Trennern gespickten Struktur wohl kein Problem, man muss am ersten "=" zerschneiden und den hinteren Teil einfach nur lassen wie er ist.

Automatische Kategorisierung

Bei automatischer Kategorisierung wird die SORTIERUNG-Option nicht berücksichtigt.--Slimguy 18:33, 17. Jan. 2012 (CET)

Die automatische Kategorisierung in der Teilvorlage Vorlage:Infobox Fluss/ABFLUSSWEG setzt gezielt Sortierungsparameter für die Kategorien. Hast du ein konkretes Beispiel, wo das deiner Meinung nach falsch ist? --TMg 13:51, 15. Jul. 2012 (CEST)

Länge eines Flusses

Wie an der Diskussion über die Quellhöhe des Ganges abzuleiten ist, scheint es keine Wiki-weite einheitliche Definition der "Quelle" eines Flusses zu geben. Ich persönlich würde dafür plädieren, wenn der Ort als Quelle bezeichnet wird (bei Fließgewässern, deren Quellfluss nicht den Namen seines Mündungsgewässers hat), der entweder von der zuständigen Behörde als Quellort bezeichnet wird, oder die Quelle des längsten Zuflusses darstellt. Siehe auch Quellen der Wilde Gera. Vielleicht gibt es auch brauchbare Hinweise in anderssprachigen Wikis. Hiermit möchte ich einen Gedankenaustausch anfachen mit dem Ziel, dass in der Beschreibung der Infobox Fluss eine verwendbare Definition darüber steht.--Claus Diskussionsseite 18:30, 5. Feb. 2012 (CET)

Neben der Quelle des hydrologischen Hauptstranges (über die an jedem Zusammenfluss jeweils größere Wasserführung) gibt es noch die Quelle des längsten Fließweges und die des namentlichen Hauptflusses (meist – oft auch nicht! – mit dem hydrologischen identisch). Bei namentlich verschiedenen Quellflüssen gibt es auch oft eine traditionell benannte Hauptquelle, die mal den wirklichen Hauptfluss nennt (Breg) oder auch nicht (Rote Saar, Vorderrhein, Bhagirathi). Sinn machen würde auch der höchste Wasseraustritt des Einzugsgebietes.
Das rührt wieder mal an die Frage, was ein Flussartikel umfasst: den lemmaidentisch benannten Fließweg (engerer Sinn) oder den hydrologisch beschriebenen Fließwasserkörper mit typischen Bezügen zum gesamten Einzugsgebiet (weiterer Sinn). Ich neige zu letzterem, da besser systematisierbar und eher das „Ding an sich“, den Fluss, betreffend, sicher nicht ohne die kulturelle Sachebene. Der engere Sinn impliziert aber ein Primat der kulturellen Ebene, die allein qua Namengebung einen Fließstrang aus dem Gewässerfächer isolieren würde. Ich fände eine Orientierung von Artikel und Infobox an zunächst gewässerkundlichen Merkmalen angenehm, an Dingen, wofür der Flussname primär steht, selbst wenn der Namensstrang weiter flussaufwärts oder im Mündungsbereich (Rhein-Maas, Ganges-Brahmaputra) mal eigentümliche Wege geht. Da wäre „höchste Quelle“ genauso interessant wie „offizielle“ oder „tradierte Quelle“. Der errechnete Höhenunterschied lässt dann schon erahnen, wie zahm oder ungestüm der Fluss daherkommt. -- WWasser 20:27, 5. Feb. 2012 (CET)

Das hast du jetzt aber schön dargestellt. Ich hatte mir die Weser als Beispiel rausgesucht. Dort wird gezeigt wie man es in der IB darstellen kann. Die IB ist ja nur der Ort für die Darstellung der Sachlage. Welches jetzt der "richtige" Quellfluss ist, dass sollen die Hydrologen unter sich aus machen. Für die in der IB angegebene Quellhöhe sollte gelten, dass sie der Höhe der Quellkoordinaten entspricht. Mich würde interessieren, was an der Beschreibung zu ändern ist? --SteveK ?! 21:01, 5. Feb. 2012 (CET)

Da bin ich - wieder einmal - eng bei Steve und WWa!

Wenn jemand die Weser mit der Ems oder der Elbe vergleichen will, denkt er an den Fluß, nicht an den Flußabschnitt, der jenen Namen trägt. In D-Land haben wir hierzu meistens "offizielle" Daten darüber, wo nach Stationierung und Kennziffer der Anfang liegt.

Wenn ich das jetzt genau am Namen festmachen würde, erschiene die Weser - irreführenderweise - kürzer als Main und Mosel. Und das genau im "ersten Überblick", für den ja gerade die Box ausschlaggebend sein sollte.

Übrinx stimmt es bei der Weser momentan genau nich, da dort irgendwann wohl jemand die "116,5" Höhenunterschied von Namensgründung bis Mündung unter "Quellhöhe" eingetragen hat. War mir nie aufgefallen, da die Weser merkwürdigerweise nicht mehr auf meiner Beo war (wo ich sie gewähnt hatte). --Elop 23:08, 5. Feb. 2012 (CET)

Um die Frage von SteveK aufzugreifen: Könnte man nicht generell Folgendes anbieten (Klammerbeispiele: jeweils für Mississippi, Amazonas, Ganges, Rhein, Donau und Weser):

• Wassereichster (hydrologischer) Hauptstrang (Allegheny–Ohio, Lauricocha–Marañon, Chambal–Yamuna, Aare (beim Alpenrhein: Dischmabach−Landwasser−Albula−Hinterrhein), Ova da Bernina–Flaz–Inn; Eder–Fulda)
• abweichender längster Fließweg (Red Rock–Beaverhead–Jefferson–Missouri, Lloquera–Callamayo–Hornillos–Apurímac–Ene–Tambo–Ucayali, Chambal–Yamuna, Medelser Rhein–Vorderrhein, Breg, Saar–Werra)
• namentliche Strecke: (Itascasee–Meer, Quellflüsse–Brasil. Grenze + Manaus–Meer, Devprayag–Grenze Bangladesh, Chur–Lobith, Donaueschingen–Tulcea, Hann.-Münden–Meer)
• ggf. symbolische Quelle (Itasca-See, -, Gaumukh (Bhagirathi), Tomasee, Donauquelle, evtl. gefasste Fulda-Quelle)
• Höhe der höchstgelegenen Quelle im Einzugsgebiet laut Karten

Für jeden Beginn der jeweiligen Fließwegtypen (also zumeist deren Quelle) sollte Koordinatenangabe möglich sein. Berechnung des Höhenunterschiedes ab höchster Quelle. Es könnte sich angesichts noch sehr vieler anderer Beispiele lohnen, das Thema in der Weise zu systematisieren und hier und da auch zu entemotionalisieren. „Die“ Quelle ist immer ein Kopfprodukt, ein Definitionsergebnis.

Sorry, SteveK, für die späte Einlassung, wo Du gerade schon die Infobox aufwändig systematisiert hast. Von daher könnte ich eine eher reservierte Reaktion ganz gut nachvollziehen... -- WWasser 11:42, 6. Feb. 2012 (CET)

Werra längster Quellfluss
Abfluss über	Saar → Werra → Weser

Ich weiß ja nicht wie es dir geht, aber ich bin bei den Flüssen nur hobbyist. Sinnvolle Ergänzungen stehe ich immer aufgeschlossen gegenüber, wenn sie nicht schon durch vorhandene Möglichkeiten abgedeckt wäre. Gegenfrage von mir: Kann man das nicht mit einer 2. IB als Nebenbox lösen (siehe rechts)?--SteveK ?! 13:54, 6. Feb. 2012 (CET)

Da ist es doch wohl besser, eine einfache Tabelle zu machen. Unter Misshandlung der Infobox ist nämlich bloß das herausgekommen:

Hauptstränge des Flusssystems Weser
Hydrologischer Hauptstrang (nach Wasserführung)	Eder → Fulda → Weser
Quellhöhe	maximal um 900 m
Längster Fließweg	Saar → Werra → Weser
Namensstrecke Weser: Hann.-Münden – Nordsee

Grüße -- WWasser 20:18, 6. Feb. 2012 (CET)

Wie wäre es mit so einer einfachen Tabelle, die in jeden Flussartikel mit abweichendem längsten und/oder wasserreichsten Fließweg z.B. unter Verlauf eingebaut werden kann. --Freak-Line-Community 09:46, 7. Feb. 2012 (CET)

		Länge	Quellhöhe (maximale im Strang)
Längster Fließweg	Saar → Werra → Weser	752 km	800 m ü. NN
Hydrologischer Hauptstrang (nach Wasserführung)	Eder → Fulda → Weser	673 km	850 m ü. NN

Bewertung meinerseits:

1. Eine integrative Umsetzung des Vorschlages in die IB mit entsprechenden Parametern ist möglich, die IB wird aber dadurch deutlich länger.
2. Mit einer zweiten IB ist die Umsetzung möglich, entspricht aber nicht unseren Vorstellung.
3. Die von Freak-Line-Community finde ich persönlich für den Artikel geeignet und flexibel einsetzbar. Die Bildung der Stränge ist aber gerade das Format, was wir in der IB abgelöst haben weil ziemlich umständlich zu bilden.

Ich stehe einer Realisierung nicht im Wege. Ihr müsstet nur mal sagen, wo das denn eingefügt werden soll und wie es aussehen soll. Gruß --SteveK ?! 10:32, 7. Feb. 2012 (CET)

Um noch mal zur ursprünglichen Frage nach der Länge und Quellhöhe zurück zu kommen: Was ist am Beispiel Weser nicht in Ordnung? Ich kann doch alle Daten herauslesen (Quellhöhe Werra, Fulda, Höhe des Zusammenflusses, Länge mit und ohne Werra). --Freak-Line-Community 11:47, 7. Feb. 2012 (CET)

Ich hatte mich da wohl vom Begriff "Quellhöhe" verwirren lassen (und von der Gleichheit zwischen "Quellhöhe" und "Unterschied", die ich als Binnenflußpferd halt nicht gewohnt bin). Der paßt ja bei den 116,5 nicht wirklich. Andererseits steht drüber ja "namentlicher Beginn", insofern wohl schon OK. --Elop 12:25, 7. Feb. 2012 (CET)

Ich habe leider gerade wenig Zeit, daher schnell und ungenau: Die Tabelle von Freak-Line-Community finde ich gut und in Kapiteln wie Flusssystem, Einzugsgebiet oder Nebenflüsse gut platzierbar. Die IB würde wohl wirklich mit all den Informationen überborden. Es bleibt trotzdem ein Teilprogramm überlegenswert, um die Unklarheiten hinsichtlich der Quelle und der Höhenunterschied- und Längen-Bezüge loszuwerden.

• Länge als <Lemmaname>
• Nennung abweichender Hydrologischer Hauptstrang mit Teilabschnitten, aber ohne Länge und Quellhöhe (Quellkoord. kann man ja auf diese Weise leicht über Wikilink finden)
• Nennung abweichender längster Fließweg mit Teilabschnitten (Quelle wie oben)
• Länge längster Fließweg
• Quelle/Beginn des Namensstrangs mit Bezeichnung u. Koordinaten wie bisher
• Nennung eventueller Symbolischer Quelle (ohne Koordinaten und Höhe)
• Höhe der höchsten Quelle des Einzugsgebietes (evtl. mit Koordinaten)
• Höhenunterschied berechnen von Beginn Namensstrang, wenn aber Angabe höchster Quelle vorhanden, dann von dieser Quellhöhe (für den Fluss charakteristischer als Ortshöhe des Namensbeginns)

Wär das noch OK? Diese genannten Fälle kommen doch sehr oft vor, gerade bei großen Flüssen, deren Artikel oft gelesen werden. Gruß -- WWasser 13:31, 7. Feb. 2012 (CET)

Dann müsste die Länge Lemmaname aber weiter nach oben in die Box. Die von WWasser aufgezählten Neuerungen als Zusatzinfo weiter nach unten, um den Leser nicht zu verwirren. Im Artikel Main würde bei Länge 527 km und bei Länge längster Fließweg dann 553 km stehen. Da kann man schon mal durcheinander kommen. Es ist vielleicht sogar zu überlegen, die IB in "Abschnitte" zu unterteilen, wie es bei den Planeten oder den Elementen gehandhabt wird. --Freak-Line-Community 15:13, 7. Feb. 2012 (CET)

Wie wäre es, den Parameter LÄNGE so umzusetzen: "Länge als "<Name/Lemma> (Beispiel: "Länge als Weser"). Über die Positionierung innerhalb der Box werden wir wohl eine Lösung finden. --SteveK ?! 16:27, 7. Feb. 2012 (CET)

Könntest du das mal in einer deiner Beispielbox darstellen? --Freak-Line-Community 13:49, 8. Feb. 2012 (CET)

Mittlere Quellschüttung

Bei vielen Quellen ist die mittlere Schüttung nicht bekannt, aber z.B. der MHQ. So wie es aussieht muss aber der MQ immer angegeben werden, dass die IB auch andere Schüttungswerte angezeigt. Ließe sich da was machen? --Freak-Line-Community 19:49, 15. Feb. 2012 (CET)

Ich hab das mal versucht zu fixen. Habe eine Klammerung falsch gesetzt. Danke für den Hinweis.--SteveK ?! 22:01, 15. Feb. 2012 (CET)

Kein Problem. --Freak-Line-Community 22:16, 15. Feb. 2012 (CET)

Weitere Pegel

Hallo zusammen,

ich habe jetzt mal drei weitere Pegel implementiert. dazu sind jeweils 3 Parameter erforderlich:

   PEGEL1= <NAME>/<LoM>/<EZG>/<NNQ>/<NNQ-DATUM>/<MNQ>/<MQ>/<MHQ>/<HHQ>/<HNQ-DATUM>
   PEGEL1-REIHE= Messreihe 
   NACHWEIS-PEGEL1 = <Nachweis>

für den zweiten und dritten Pegel jeweils die "1" durch "2" oder "3" tauschen. Kommentare erbeten. Ach ja, Dokumentation und VM habe ich noch nicht ergänzt. --SteveK ?! 21:53, 9. Mär. 2012 (CET)

Es lebe das vollklatschen von Infoboxen mit Parametern, welche bei weniger als 10% aller Artikel eine Wertangabe bekommen werden... ÅñŧóñŜûŝî (Ð) 22:42, 9. Mär. 2012 (CET)

Wenn du im Archiv geschaut hättest, dann wäre dir die Diskussion zu dem Thema aufgefallen. Es gibt den Bedarf, was ich aus einigen Flussartikel bei der Anwendung der Abflussparameter selbst gesehen habe. --SteveK ?! 21:02, 10. Mär. 2012 (CET)

Die Zukunft wird es zeigen. Die Infobox ist ca. 10400 (!) mal eingebunden. Du musst also 1040 Seiten manuell "nachrüsten", um auf nur 10% zu kommen... Das wirst du nicht schaffen. ÅñŧóñŜûŝî (Ð) 21:34, 13. Mär. 2012 (CET)

Neue Parameter

Spräche etwas gegen die Einführung von Parameter analog zu en.wikipedia (Primary source, Secondary source, Source confluence)? siehe dazu die Box von Rhine.--Anarabert (Diskussion) 00:16, 24. Mär. 2012 (CET)

Schlimmstensfalls besteht bei mehreren Zusammenflüssen Unklarheit, welcher Oberlauf nun „der richtige“ ist. Vgl. auch Donauquelle.

Pragmatisch bei nur einer Gabel für den Leser übersichtlicher, in der Verarbeitung wohl eine Hypothek durch weitere Fallunterscheidung / einen weiteren Sonderfall.

Nur nach der Template-Dokumentation ist für mich unverständlich, wie die secondary source da überhaupt hineinkommt. Kann man bei Infoboxen beliebig Name-Wert-Paare hinzunehmen, die dann eben ggf. unverarbeitet je in ein zusätzliches Zellenpaar verpackt werden?

--Silvicola ⇨⇦ 03:01, 24. Mär. 2012 (CET)

Im Prinzip habe ich nix gegen eine Weiterentwicklung einzuwenden, es sollte jedoch hier klar werden, was gewollt ist.

@Silvicola: Man kann vieles mit den Parameter, man kann sie beispielsweise auch gar nicht verwenden. Aber so richtig verstehe ich deine Frage auch nicht. --SteveK ?! 09:55, 24. Mär. 2012 (CET)

An der bisherigen Situation finde ich schlecht, daß bei Zusammenflüssen von zwei Quellflüsse/bäche die Parameter z.T. regelrecht mißbraucht werden (siehe beispielsweise bei der Weser). Daran zeigt sich für mich, daß ein Bedarf für zusätzliche Parameter existiert. Es wäre also gut, wenn die Box die Möglichkeit bieten würde, außer der Höhe und den Koordinaten des Punktes am Zusammenfluss der beiden Quellflüsse/bäche, auch noch die Namen, Koordinaten und die Quellhöhen der beiden Quellenflüssse/bäche eingeben werden könnte. Optimal wäre natürlich, wenn die Box bei Eingabe des Names des Gewässers, sich die Daten für Quellhöhe und Koordinaten automatisch aus schon bestehenden Artikeln holen würde (vielleicht auch erst nachträglich per Bot).--Anarabert (Diskussion) 18:49, 24. Mär. 2012 (CET)

Einschätzung meinerseits zur "optimalen Lösung": Das dürfte sehr schwer werden. Vorlagenprogrammierung ist ja keine wirkliche Programmierung. Schön wäre das aber schon, man gibt einen Artikel an und automatisch wird der Rest geholt.

Zum Anderen: Ich habe nix gegen eine Weiterentwicklung, auch nicht gegen eine optische. Was haltet ihr eigentlich von der Optik der en-Box?--SteveK ?! 19:10, 24. Mär. 2012 (CET)

Die Einrückung der „gebündelten“ Slots-Titel finde ich gut. Andererseits gibt es nach meinem Geschmack zu wenige horizontale Trennstriche, mindestens zwischen den thematischen Bündeln sollte man welche ziehen. Und bitte keine alternativen Maßangaben in mittelsumerischen Hohl-, neuangelsächsischen Längen- und altchinesischen Flächenmaßen. Es genügt, wenn Satelliten abstürzen, keine Not, dass auch noch Holland absäuft, weil ein fauler Programmierer beim Rijkswaterstaat vielleicht hier mal spickt.--Silvicola ⇨⇦ 19:37, 24. Mär. 2012 (CET)

Mit der nun eingefügten Weser wurde es klarer.

Für den Leser übersichtlicher ist es sicher, wenn man Wiederholungssätze mit den gebündelten Eigenschaften der verschiedenen diskutablen Quellorten wie bei Rhine hintereinander stellt, als wenn man Einträge in die Einzelparameter hat, die sie zu Wiederholungsfeldern machen. Zumal die parallele Reihenfolge in diesen Parametern (immer erst zu Hann. Münden, dann zu Werra, dann zu Fulda) ja manuell gesichert werden muss.

Andererseits waren ja die Parameter Soundso-SUFFIX gerade dazu gedacht, die Schmuddelfälle nach Diskretion des Bearbeiters zu erledigen.

Bei wievielen der an einem Zusammenfluss entstehenden Gewässer wäre das Problem denn mit einer Lizenz für zwei weitere Quellorte (Quellen von 2 Oberläufen) abzuhandeln? Davon hängt ab, ob sich der Umbau lohnt. Es gibt bei den Flussverläufen nämlich noch viel pathologischere Fälle mit weiteren strittigen Gabelungen flussaufwärts, und in die beliebig rekursive Oberlauf-Dendrologie will man ja sicher nicht einsteigen.

Was bedeutet eigentlich das primary und secondary? Ist es irgend etwas gewässerwissenschaftliches oder doch nur eine schiere Nummerierung von abzuhandelnden Fällen? --Silvicola ⇨⇦ 20:50, 24. Mär. 2012 (CET)

Das mit dem Hauptzweig (primary source) und den Nebenzweig (secondary source) ist auch so eine Sache. Ist damit der längste oder der wasserreichste Quellfluss gemeint? Gewässerwissenschaftlich ist wohl beides relevant. Haben wir keinen Wissenschaftler in unseren Reihen der uns das beantworten kann? --SteveK ?! 21:28, 24. Mär. 2012 (CET)

Bei der Festlegung, ob es sich bei einem Quellfluss/bach um den Hauptzweig oder um einen Nebenzweig handelt, werden oftmals auch nicht rein hydrologische Aspekte berücksichtigt, andernfalls würde der Ursprung der Regnitz und der Ursprung des Mains zusammenfallen. Für Deutschland (He, BW, NRW) würde bei der Entscheidung, ob Haupt- oder Nebenzweig uns (meistens) die GKZ einen Hinweis geben. Gleiche GKZ deutet auf Hauptzweig (Weißer Main, wasserreicher: GKZ 24, Roter Main, länger: GKZ 2412) hin. Wenn also die größere Wassermenge das entscheidende Kriterium ist, dann sind bei vielen Fließgewässern keine (oder nur sehr schwer aufzufindende) Angaben erhältlich. Besser wäre es also, man würde den Parameter mit Rechter bzw. Linker Quellzweig benennen. Wie nützlich diese neuen Parameter wären, zeigt ein kurzer Blick auf die bisherige Praxis (Rhein, Main, Regnitz)--Anarabert (Diskussion) 10:31, 25. Mär. 2012 (CEST)

R/L ist unbedingt besser als 1/2. Wo ein und derselbe Fluss beginnt oder aufhört, entscheidet letztlich die Konvention, der einen „Schubs“ in Richtung auf das den Hydrologen Bequemste sie sich bei kleineren Gewässern gelegentlich trauen, bei größeren aber nicht. Es ist ähnlich wie bei Rechtschreibreformen.

Wenn ich Dich richtig verstanden habe, Anarabert, würdest Du gerne an der Rotmain/Weißmain-Gabel ansetzen, vermutlich, weil beide nun mal den Main explizit im Namen tragen. Die scheinen auch unumstrittene Quelläste und Quellen zu besitzen. Aber sobald sich einer der Quellflüsse flussauf nochmals gabelte, wie es etwa die Regnitz tut, stellt sich die Frage: welchen Ursprung beim Main eintragen, den Zusammenfluss zur Regnitz? den längsten / rekursiv wasserreichsten Zweig? Ich fürchte, diese lokalpatriotisch gegründeten Streitereine, wer den nun den "richtigen" Ursprung hat, werden gerade bei den größeren Kalibern nicht selten sein, vgl. Donau. Dergleichen Wirrsal wie dort (Abschnittsnamen) lässt sich wohl nur in Textform überhaupt leidlich verständlich darstellen. --Silvicola ⇨⇦ 14:48, 25. Mär. 2012 (CEST)

Ich bin mir nicht sicher, ob ich alles bisher angesprochene verstanden und zuende gedacht habe. Es ist ein Problem von Sprach- und Namenskonvetionen und auch von Denkfiguren. Die Quelle ist ja Fiktion; alle Flüsse setzen sich aus Wasseraustritten von einem Joghurtbecher/sek. zusammen, eine davon trifft es, wenn man den hydrologischen Hauptstrang nach oben verfolgt, eine (vielleicht andere) trifft es bei der Identifikation des längsten Fließweges und wieder eine beim jeweils größten Einzugsgebiet, womöglich aber mehrere bei namentlichen Quellen. Ausgewertet werden die Quellangaben aber nur beim Gesamtgefälle. Hier aber ist jede davon irgendwie willkürlich. Mehr Sinn machen würde hier theoretisch eine weitere Quellart, die höchstgelegene. Die wandern mit der Gletscherschmelze derzeit immer höher hinauf, ihr Wasser taucht talab vielleicht wieder unter andere Gletscherzungen, kurz, es bringt auch nichts. Ist es nicht überhaupt sinnvoller, das Gesamtgefälle aus dem höchsten Punkt des Einzugsgebietes abzuleiten? Dann hat man stressfrei 3 annähernd gleichrangige Standardquellarten, die sich bei großen Flüssen sehr oft unterscheiden, also Beginn Hauptstrang, Beginn Längster Fließweg, Beginn Namensstrecke, letztere am Zusammenfluss von bspw. Rotem und Weißem Main, dazu optional eine symbolische Quelle. Dass der weiße Main von hier an den Hauptstrang und der Rote den längsten Fließweg darstellt, würde ich dann nur im Text erwähnen. In der Infobox erscheinen die beiden anderen am Beginn der Fränk. Rezat. Beim Rhein wäre Namensbeginn in Reichenau (GR), Längster Fließweg begänne mit dem Medelser Rhein, Hauptstrang am Oberaargletscher, symbolischer Beginn am Tomasee. Wenn gewünscht, kann ich mal eine Liste zusammenstellen, die zeigt, dass das nicht einen Haufen Leerstellen produzieren würde, sondern nur den lokalpatriotischen Kleinkriegen Boden entzieht. Den Namensbeginn kann man insofern steuern, als man unter der Lemmazeile den optionalen Zusatz hat Mit Abschnitten x, y, z, also beispielsweise Yarlung Tsangpo, Dihang, Dibang, Jamuna, Padma, Lower Meghna, wenn man den Brahmaputra nicht in Assam beginnen lassen will, sondern in Westtibet. Und bei ganz komplizierten Fällen wie dem Nil kann man ja auch noch mit Nebenboxen arbeiten. Diese 3 Standardstränge relativieren, denke ich, auch die fiktionale Quellenverbissenheit in vielen Artikeln, teils mit Bildern immer ähnlicher Tröpfelrohre mit Schild dran. -- WWasser (Diskussion) 16:05, 25. Mär. 2012 (CEST)

Du könntest ja mal Deine Vorstellungen am Beispiel der Flüsse Rhein, Main, Regnitz, Donau und Weser demonstrieren.--Anarabert (Diskussion) 17:16, 25. Mär. 2012 (CEST)

Ja, mach mal vor, klingt interessant, vor allem weil das nach objektiven Kriterien statt nach bloßer Arriviertheit einer Konvention und eines Lokalpatriotismus schmeckt, aber ich verstehe es nicht ganz.

• "Eine (trifft es) beim jeweils größten Einzugsgebiet" – denkst Du hier an eine nicht flächenhafte, nicht linienhafte, sondern Punktquelle, der dann das dorthin schüttende Einzugsgebiet zuzurechnen wäre? Typischer Fall: Karstquelle? Vermutlich aber ist in diesem Falle die Schüttung meist besser definiert (konzentrierte Quellschüttung, die man leicht messen kann) als das EZG (Schichten drüber, und in so dichtem Raster macht man meistens keine Färbungsversuche), mit diesem öhnlichen Kriterium hieße es dann: am stärksten schüttende Punktquelle. Muss es aber gar nicht geben.
• Oder meinst Du, dass man an den Zusammenflüssen nach diesem Kriterium eben in Richtung des größten Teil-EZG aufsteigt, genau wie sonst nach Oberlauflänge bzw. Zufluss??

Bitte auch im Auge behalten:

• Jahreszeitlich schwankende bis hinzu ausbleibender Schüttung, betrifft besonders auch das mögliche Kriterium Höhenlage.
• Unterschiedliche Schüttungsrichtungen je nach Stockwerk

(nicht signierter Beitrag von Silvicola (Diskussion | Beiträge) SteveK ?! 10:00, 27. Mär. 2012 (CEST))

Schnell zwischendurch, da zeitlich gerade etwas in Problemen: Ja es war so schlicht gemeint mit dem flussauf paarweisen Vergleich der Teil-EZGs analog zu den anderen Kriterien. Ich habe das vielleicht etwas pathetisch aneinandergereiht, sollte nur heißen: die drei Kriterien bieten im Allg. genug Eindeutigkeit, anders als manchmal bei den kulturbürtigen Kriterien wie Flussnamen und offiziellen/üblichen/symbolischen Quellbenennungen. Die weiteren Fragen/Überlegungen von Silvicola gehen übrigens schon in Richtung einer Infobox Quelle. Vielleicht schaffe ich die kleine Liste heute abend. -- WWasser (Diskussion) 13:03, 27. Mär. 2012 (CEST)

Hallo Anarabert, SteveK, Silvicola, ... Es hat leider etwas gedauert mit der Liste. Die ersten Versuche waren zu radikal geraten und wichen zu sehr ab vom Aufbau der bisherigen Liste. Das Grundproblem ist weiterhin, dass die Flusslemmata eine Doppelbedeutung haben: zum einen die entsprechend benannte Flusstrecke, zum anderen das Flusssystem, für das der Name auch steht. Das wird auch weltweit wild durcheinander gehandhabt. Daher meine Hauptuntergliederung in Namentlichen Strang und Flussystem. Was beidem zuzuordnen ist, steht wie bisher unter dem Namentlichen Strang. Beim Flusssystem stehen jetzt nur der höchste Punkt des Einzugsgebietes (nicht ganz so wichtig), der Verlauf des hydrol. Hauptstranges und der des längsten Stranges mit Längenangabe. Immer noch nicht „im Griff“ sind Mündungsverzweigungen mit echtem Bifurkationscharakter (wie im Ganges-Brahmaputra-Delta, Hwanghe-Delta), selten, aber leider auch vor der Haustür vorhanden mit dem Rhein. Dessen Längenangabe bis hinab nach Rotterdam impliziert, dass die Maas eigentlich dazugehört (seit 1970, Bau des Haringvlietdammes); anders herum hat die IJssel nach der Gabelung keine Berührung mehr mit dem fluvialen Geschehen der anderen Rheinarme, es ist eine Bifurkation. Die Abflusswerte unterschlagen dagegen das gesamte Mündungsareal; sie müssten um die IJssel (280 m³/s) vermindert und um die Maas (350 m³/s) vermehrt werden, also mindestens 2400 m³/s. Das kann man auch mit dieser Systematik nicht erfassen, die immer nur flussaufwärts blickt, auf das untere Ende des betrachteten Fließgewässerabschnitts und seines EZG bezogen ist. Vielleicht aber zu selten, um in einer Infobox Berücksichtigung finden zu können.

Zum Sprachlichen: um die nicht so seltenen Flussabschnitts-Lemmata und Situationen mit Quellflüssen leichter mit umfassen zu können, fände ich Beginn und Ende sinnvoller als Quelle und Mündung. Von den jetzigen 3 optionalen Pegeln sind übrigens je 1 dem Beginn und Ende zugeordnet, dessen MQ extra-/interpoliert werden kann. Unter Abflusswege oberhalb und unterhalb trägt man dann angrenzende Quellflüsse, Mündungsarme und andere Flussabschnitte ein.

Leider habe ich die Tabelle ungeschickt begonnen, gedreht wäre sie besser. Sorry für die schlehte Lesbarkeit!

Lemma	übergeordn. Flusssystem	Namentl. Strang:	Höhe Beginn	Abfluss Beginn	Abfluss Pegel Beginn	Abw. Symb. Quelle	Höhe Ende	Abfluss Pegel Ende	Abfluss Ende	Länge	Abflusswege oberhalb	Abflusswege unterhalb	EZG	Höchster Punkt	Hauptstrang Flusssystem: Abflussweg	Längster Str. Flusssystem: Abflussweg	Länge
Rhein	Rhein-Maas	Reichenau – Lobith	599	113,4	Domat/Ems	Tomasee	12	Lobith	2330		Vorderrhein, Hinterrhein	siehe auch: Waal – Merwede – Nieuwe Merwede – Noord, Lek – Neuwe Maas – Nieuwe Waterweg, Ijssel		4274 (Finsteraar- horn)	Aare – Rhein – Waal – Merwede – Nieuwe Merwede – Hollands Diep – Haringvliet	Medelser Rhein – Vorderrhein – Rhein – Waal – Merwede – Noord – Nieuwe Waterweg	1235
Alpenrhein	Rhein-Maas	Reichenau – Lustenau	599	113,4	Domat/Ems	Tomasee	395				Vorderrhein, Hinterrhein	Rhein, Waal, Merwede, Nieuwe Merwede, Noord, Lek, Neuwe Maas, Nieuwe Waterweg, Ijssel			Dischmabach – Landwasser – Albula – Hinterrhein	Medelser Rhein – Vorderrhein
Main	Rhein-Maas	Kulmbach – WI-Mz.-Kastel	298	93,3		Weißmain-quelle	82	Frankfurt Osthafen	225	472	Weißer Main, Roter Main	Rhein	27292	1051(Schneeberg)	Fränkische Rezat – Rednitz – Regnitz – Main	Fränkische Rezat – Rednitz – Regnitz – Main	553
Regnitz	Rhein-Maas	Fürth–Bamberg	283	26			231,2	Pettstadt	51,3	58,9			7523,34	6526(Poppberg)	Fränkische Rezat – Rednitz – Regnitz	Fränkische Rezat –Rednitz – Regnitz	162,1
Donau		Donau-eschingen – Tulcea	680	9,32		Donaubach-quelle	1		6700	2811	Breg, Brigach	Kilia-Arm, St.-Georgs-Arm, Sulina-Arm	817000	4049(Piz Bernina)	Flaz – Inn – Donau – Kilia-Arm	Breg – Donau – Kilia-Arm	2857
Weser		Hann.-Münden – Deutsche Bucht	116,5	117,9			0	Bremen	390		Fulda, Werra	-	41094	982(Gr. Beerberg)	Eder – Fulda – Weser	Fehrenbachsche Quelle – Werra – Weser	750
Mississippi		Itasca-See – Golf v. Mexiko	450	1			0		18400	4070	Nicollet Creek, Abfluss Elk-Lake	(Passes, max.20km)	2981076	4399 (Mt. Elbert)	Allegheny – Ohio – Mississippi	Red Rock – Beaverhead – Jefferson – Missouri – Mississippi	6051
Amazonas		Quellflüsse – Bras. Grenze; Rio Negro – Atlantik	100	28400			0		209000	3780	Lauricocha – Marañón, Apurimac – Ene – Tambo – Ucayali	–	6112000	6768 (Huascarán)	Lauricocha – Marañón – Amazonas	Apurimac – Ene – Tambo – Ucayali – Amazonas	6448
Ganges	Brahmaputra–Meghna	Devprayag – Farakka	475	690	Farakka	Gaumukh (Bhagirathi)	6		12037	2620	Alaknanda, Bhagirathi	Padma – Lower Meghna, Bhagirathi – Hugli	975000	8848 (Mt. Everest)	Chambal – Yamuna – Ganges – Padma – Lower Meghna	Yamuna – Ganges – Bhagirathi – Hugli	2870

Jedenfalls dürfte die Häufigkeit eines abweichenden längsten Fließweges und eines abweichenden hydrol. Hauptstranges nicht nur bei größeren Flüssen erahnbar sein. Ob man dem Beginn aller dieser Fließwege die jew. Koordinaten zuordnen sollte, weiß ich nicht, zumeist helfen da die Wikilinks ja weiter. -- WWasser (Diskussion) 19:55, 1. Apr. 2012 (CEST)

Hallo WWasser, Deinen Ansatz finde ich im Großen und Ganzen recht gut.

Im Einzelnen: Es fehlt tatsächlich noch ein Parameter Übergeordnetes Flusssystem, um die Sachlage bei Maas-Rhein bzw. Ganges-Brahmaputra angemessen darzustellen. Auch eine Aufteilung von namentlich tradierten und hydrologischen Aspekten ist zu begrüßen. In den Parameter Höhe Beginn wird die Höhe bei Stelle des Zusammenflusses der Quellflüsse/bäche eingetragen. Woher allerdings die Werte für Abfluss Beginn kommen, ist für mich nicht transparent. In den Parameter Abw. Symb. Quelle soll wohl die "offizielle" Quelle des Gewässers (also der Kampfplatz der Lokalpatrioten) eingetragen werden. In den Parameter Abflusswege unterhalb sollten nur die Arme aufgeführt werden in das sich das Gewässer aufteilt und dabei seinen Namen (Lemma) einbüßt. Beim Rhein also Waal und Nederrijn. Der Höchste Punkt im EZG ist wohl eher nicht so wichtig. Wichtiger sind dagegen die beiden folgenden Parameter Hauptstrang Flusssystem: Abflussweg und Längster Str. Flusssystem: Abflussweg (mit Länge).--Anarabert (Diskussion) 19:16, 12. Apr. 2012 (CEST)

Diese Box ist doch schon unübersichtlich genug. Was wollt ihr noch alles? (nicht signierter Beitrag von 80.187.107.87 (Diskussion) 19:53, 12. Apr. 2012 (CEST))

Hallo Anarabert, Antwort erst jetzt wegen Krankenhausaufenthalt: Abfluss Beginn ist entweder die Quellschüttung oder die Summe der MQ's beider Quellflüsse (MNQ wird man auch noch addieren dürfen, die anderen Q's besser nicht). Generell d'accord. Höchster Punkt war nur eine Überlegung für den Rechenwert des Gesamtgefälles, um hier gar nicht erst Quellenfindungsprobleme zu haben. Ist wirklich nicht vorrangig. Wahrscheinlich ist Deine reduzierte Liste das einzig Realistische, weil es die Box nicht überfrachtet. -- WWasser (Diskussion) 18:22, 27. Apr. 2012 (CEST)

Änderung für Lagewunsch

Benutzer:Merlissimo hat eben eine Änderung gemacht, damit bei fehlender Koordinatenangabe (Bsp. Mündungskoordinate angegeben, Quellkoordinate fehlt) diese als Lagewunsch gesetzt wird. Im Prinzip halte ich das für sinnvoll, wobei ich vermute, dass es genügend Flüsse ohne Quellkoordinaten gibt. Bisher war es so, dass Lagewunsch nur gesetzt wurde, wenn keine Koordinaten angegeben sind. Wie ist eure Meinung? --SteveK ?! 21:20, 25. Mär. 2012 (CEST)

Sehe ich tw. problematisch. Die Quellkoordinaten lassen sich nicht immer genau feststellen (Quellgebiet; längster, stärkster Arm, Schwerpunkt? Unterirdische Verläufe? Im GNIS werden nur Mündungskoordinaten angegeben. --Matthiasb ^{(CallMyCenter)} 21:25, 25. Mär. 2012 (CEST)

Meine Änderung hatte ich gemacht, damit ich mit Eingabe des Region-Codes den Lagewunsch aktivieren kann. Ohne Region-Code gibt es weiterhin auch keinen neuen Lagewunsch. Ein Region-Code ohne Koordinate hat keine Verwendung, insofern fand ich das einen sinnvollen "Schalter". Merlissimo 21:40, 25. Mär. 2012 (CEST)

Sinnvoll ist die Ergänzung durchaus, aber es hat an der erforderlichen Dokumentation gefehlt. Ich habe jetzt mal was eingebaut und hoffe, daß das so stimmt und verständlich ist. Leider habe ich zu spät gesehen, daß es den Text "Koordinaten fehlen..." jetzt auch innerhalb der Box gibt, was man vielleicht auch dokumentieren sollte. --Telford (Diskussion) 15:54, 26. Mär. 2012 (CEST)

Ich hatte mit Merlissimo ja schon drüber gesprochen. So wie er das darstellt funktioniert die Funktion. Will man keinen Lagewunsch für die Quelle/Mündung, dann bleiben die Parameter für die Koordinaten leer. Will man einen Lagewunsch, dann füllt man den REGION-Parameter aus. Koordinatenangabe geht wie bisher. Ich bin der Ansicht, dass kann man so lassen. --SteveK ?! 19:28, 26. Mär. 2012 (CEST)

bin mir nicht sicher. Die Region ist meist leicht zu bestimmen, auch wenn die Quelle unbekannt ist. Daher auch oft eingetragen. Was nützlich ist, und auch verwendet werden könnte, um mit der ISO Region allerhand Spaßetteln zu machen. Dass ich die jetzt weglöschen muss, um den Lagewunsch wegzubekommen, gefällt mir nicht. Außerdem werden dadurch Autoren eventuell veranlasst, lieber ungenaue als keine Koordinaten einzutragen. Wenn der Quellbach aber undefiniert ist, dann ist das falsch. Nur viel schwieriger zu finden. lg --Herzi Pinki (Diskussion) 01:33, 27. Mär. 2012 (CEST)

Übersetz mal bitte "Spaßetteln" ist Hochdeutsche. Eigentlich sollte die Quellkoordinate den Ort der in QUELLE angegebenen Stelle widerspiegeln. Solange in QUELLE nichts drin steht wird auch kein Lagewunsch gesetzt, also bleibt die ISO-Angabe dann ohne Wirkung. Man könnte das auch anders implementieren. --SteveK ?! 09:54, 27. Mär. 2012 (CEST)

Spaßetteln (könnte ich, so würde ich)? Frei etwa 'unsinnige, aber harmlose Scherze' (Irgendein Diminutiv von Spaß) (a la automatische Kategorisierung in Kategorie:Gewässer ohne Koordinate in Bayern, aber nicht Kategorie:Gewässer ohne Koordinate im Landkreis Ruhpolding!). Jedenfalls aber Kategorie:Wikipedia:Lagewunsch (DE-BY). Siehe auch mein Anfangsbeispiel Taurach, die QUELLE ist eine Beschreibung der Lage der Quelle und kann bald angegeben werden, auch wenn die Koordinaten aufgrund vieler Quellbäche nicht sinnvoll bestimmbar sind. lg --Herzi Pinki (Diskussion) 18:40, 27. Mär. 2012 (CEST)

Auslöser für meine Änderung war Rambach. Weil die Mündung in Italien liegt, wurde kein Lagewunsch CH (wo die Quelle liegt) ausgelöst. Laut Beschreibung und anderen Karten, sollte man eine Quellkoordinate bestimmen können. Wie du vielleicht weißt, setze ich gerne viele Lagewünsche, die dann von den Spezialisten erfüllt werden können.

Keinen Lagewunsch hingegen sollte die Quelle von Magliasina erzeugen. Mit der jetzigen Implementierung werden beide Fälle korregt umgesetzt. Mir ist aber jede Lösung recht, sofern ich den Lagewunsch nach manueller Entscheidung für Quelle und/oder Mündung "auslösen" kann. Dies durch des Setzen Region-Codes auszulösen, fand ich zweckmäßig, da der reine Code ohne Koordinaten keine Bedeutung für die Infobox hatte. Merlissimo 19:17, 27. Mär. 2012 (CEST)

Ich sehe die Koordinate eher so, dass man schnell auf einer Karte in die Gegend kommt. Gibt man keine Koordinaten für die Quellen an, dann muss man sich von der Mündung aus hochhangeln, was auch nicht prickelnd ist. Man kann ja aus "Quelle" aus "Quellgebiet" machen. Ein Punkt innerhalb eines Gebietes ist immer ungenau. --SteveK ?! 19:40, 27. Mär. 2012 (CEST)

Es muss für den Sonderfall Rambach kein Lagewunsch gesetzt werden, sondern einfach die Koordinate an der Schweizer Karte eruiert werden. Was du willst, Merlissimo, ist ein Schalter Lagewunsch ein/aus, diesen an die Existenz der region zu koppeln ist schlechtes Design und nicht benutzerfreundlich. Gerade dann, wenn keine Region gesetzt ist, sollte wohl auch ein Lagewunsch erzeugt werden. Die Semantik vorher war eine andere, beide Koordinaten fehlen -> Lagewunsch (auf der Mündung, weil die in den allermeisten Fällen leicht zu finden ist), wenn Mündungskoord gesetzt, dann kein Lagewunsch mehr. Man muss sich hochhangeln, wie SteveK oben bemerkt. Ist ein Nachteil. Vielleicht könnte man den Lagewunsch bei Quelle ja still erzeugen? Aber wenn, dann sollte das nicht von der Existenz der Region, sondern vom Fehlen der Koordinaten abhängen. Wir wollen Quellkoordinaten immer -> Lagewunsch unbedingt, wir wollen sie nicht so unmittelbar einfordern, dann Lagewunsch nicht auf Quellkoordinaten. Es sei denn, wir haben Flüsse ohne Quellkoordinaten (der Nil ist es nicht, aber die Donau).

Ich habe aber nicht wirklich Stress damit, bin nur wegen der round 0 von unten und der damit verbundenen Parameterfehler drüber gestolpert. lg --Herzi Pinki (Diskussion) 20:40, 27. Mär. 2012 (CEST)

Es gibt mehrere Parameter, die zusammen eine Koordinate definieren: Region/Länge/Breite/Höhe (u.a.). Die Frage ist einfach, ob deren einzelne Existenz alleine gewünscht/sinnvoll ist. Vorher wurde eine Koordinate nur angezeigt, wenn die Länge (auch ohne Breite) vorhanden war. Nur die Breite hat keinen Effekt. Genausowenig hatte vorher nur Region keinen Effekt.

Die Situation jetzt ist also: "Wenn ein bisschen Koordinate vorhanden ist, dann entsteht ein Lagewunsch um sie zu vervollständigen." Die war also keine wirkliche inhaltliche Änderung.

SteveK's Vorschlag auch eine "Gebiets-Koordinate" einzuführen ist eine inhaltliche Änderung, mit der ich mich aber sehr gut anfreuden könnte. Bei Städten und Ländern wird auch eine Punkt-Koordinate verwendet. Merlissimo 21:28, 27. Mär. 2012 (CEST)

Bei Länge und Breite hast du Recht, es ist einfach ein Fehler, wenn nur einer der beiden Werte angegeben ist. Und an vielen Stellen wird nur auf einen geprüft, weil angenommen wird, dass man beide gemeinsam bestimmt und bestimmen kann. Im Gegensatz etwa zur Region, die man bestimmen kann, ohne die Koordinaten kennen zu müssen. Das Koordinatenpaar könnte auch durchaus ohne Region leben, das zu koppeln war eine (schleichende) Designentscheidung, die an vielen Stellen Vorteile bringt. Aber was heißt das jetzt für die Donau? Muss man dort jetzt die Quell-Region rausnehmen? Oder einen der beiden Quellflüsse zum alleinigen definieren? lg --Herzi Pinki (Diskussion) 21:55, 27. Mär. 2012 (CEST)

Das war eigentlich kein Vorschlag, sondern geht heute schon. Es gibt oft genug mehrere kurze Wasserläufe, die durch zusammenfließen das eigentliche Gewässer bilden. Bei der Alme (Fluss) gibt es in einem kleinen Gebiet, dass dazu auch noch überstaut ist, zahlreiche Quellen. Dann kann man in der Infobox aus "Quelle" "Quellgebiet" machen. Und die Festlegung einer Koordinate ist innerhalb eines Gebiets halt immer willkürlich. Wollte aber nichts neues implementieren. --SteveK ?! 22:02, 27. Mär. 2012 (CEST)

die ersten Konsequenzen --Herzi Pinki (Diskussion) 01:14, 29. Mär. 2012 (CEST)

round 0

Hi, die letzte Änderung von SteveK führt zu Fehlern, wenn die QUELLHÖHE nicht angegeben ist. z.B. Taurach. Ich halte die Änderung nicht für sinnvoll, es sollte nicht gerundet werden, nur weil Coordinate einen Fehler für elevation ab zwei Nachkommastellen ausgibt. Sondern die Zahlenwerte sollten an der Quelle (und Mündung :-), d.h. in der Box korrigiert werden. Die Zahlenwerte an dieser Stelle sind lt. Dokumentation in Metern und sollten ganzzahlig sein. Wasserstandsmessungen bei Flüssen auf Meter reichen wohl. Man kanns mit der Genauigkeit auch übertreiben. 45° 27′ 0″ N, 16° 16′ 0″ O45.4516.266666666667 lg --Herzi Pinki (Diskussion) 01:18, 27. Mär. 2012 (CEST)

(man kann das schon richtig implementieren, …) habs mal rausgelöscht, die Anzahl der Kategorie:Wikipedia:Koordinaten-Parameterfehler geht bereits zurück. --Herzi Pinki (Diskussion) 01:34, 27. Mär. 2012 (CEST)

Ich hatte das nur reingesetzt, weil die Angabe von mehr Nachkommastellen zu der Meldung "keine Zahl" führt. Habe aber gestern abend nicht weit genug gedacht. Warum die Koordinatenvorlage das ab 3 Nachkommastellen so macht bleibt ist mir ein Rätsel, denn 3.453 ist auch eine Zahl. Es ging mir übrigens nicht um die Genauigkeit der Angabe, da ist spätestens bei Dezimeter Schluss mit einer sinnvollen Angabe. Aber bei Berechnungen kommt sowas {{Höhe|1000.1|CH}}=1000,1 m ü. M. vor. --SteveK ?! 09:34, 27. Mär. 2012 (CEST)

aktuell gibt es keinen Flussartikel, wo die Höhe mit drei Nachkommastellen angegebenen ist. Sonst würde sie unter Kategorie:Wikipedia:Koordinaten-Parameterfehler auftauchen (habe ich ausprobiert). Ich weiß auch nicht, warum die Koordinatenvorlage das so macht, aber ich denke: erstens ist bei Dezimeter Schluss und zweitens um Kommafehler a la 3.400 (meint 3400 Meter) abzufangen. Sowohl unsinnige Genauigkeit als auch der Kommafehler sollten entdeckt und gefixt werden und nicht durch ein round 0 unterbunden werden. Das mit der Höhe schaue ich mir an. lg --Herzi Pinki (Diskussion) 18:28, 27. Mär. 2012 (CEST)

Höhe gefixt, irgendein Rundungsproblem an den billigen Dezimalstellen, siehe {{#expr:(1000.1mod1000)-(trunc 1000.1)+1000.1}} = 0.10000000000002, ist rechnerisch nicht nachvollziehbar. Danke herzlichst für den Hinweis. lg --Herzi Pinki (Diskussion) 22:01, 27. Mär. 2012 (CEST)

Ich vermute, dass es die Rechengenauigkeit der intern verwendeten Zahlendarstellung ist. Sieht nach einer 8 Byte Floating-Point-Darstellung aus. Ich halte den Punkt hier für erledigt.

Abschaltung Lagewunsch

Die von mir bearbeiteten Flüsse Sabahs haben keine genau definierbare Quelle, da sie zumeist in den Dschungel- und Mittelgebirgsregionen der Interior Division liegen. Der "Lagewunsch" suggeriert, dass es eine solche genau festlegbare Quelle gäbe. Das ist Unsinn. Bitte einen Parameter einfügen, mit dem dieser Lagewunsch abgeschaltet werden kann. --cefalon (Diskussion) 07:55, 25. Apr. 2012 (CEST)

Dazu ist kein neuer Parameter erforderlich. Ich habe mal am Beispiel Sungai_Padas die Abschaltung vorgenommen. Beschrieben ist das auch unter Vorlage:Infobox_Fluss#Artikelkoordinaten_und_Lagewunsch.--SteveK ?! 09:30, 25. Apr. 2012 (CEST)

Sehr schön! Damit ist die Welt wieder in Ordnung. DANKE! --cefalon (Diskussion) 09:36, 25. Apr. 2012 (CEST)

Bekannte Brücken

Hallo Infobox Fluss-Bastler, ich halte den Punkt bekannte Brücken für die Infobox nicht geeignet. Wer legt fest, welche Brücken bekannt sind und welche nicht, und wie lang soll die Infobox werden, wenn der Punkt bei langen Flüssen (z.B. Rhein) konsequent durchgezogen wird. Ich meine, in eine Infobox gehören nur quantifizierbare Angaben oder Texte, die in ihrer Art von vornherein genau definiert und auf wenige Punkte beschränkt bleiben. Ich schlage vor, den Begriff Bekannte Brücken aus der Infobox zu streichen. Beste Grüße --Martin Geisler (Diskussion) 10:06, 9. Jun. 2012 (CEST)

Stimmt prinzipiell. Wobei wir bei den Orten ja auch, je nach Flußlänge, selektiv Listen. Nur sind Ortsgrößen objektivierbar.

Und wenn man Brücken aufführt, könnte man auch noch bekannte Talabschnitte oder Schleifen anführen.--Elop 14:09, 10. Jun. 2012 (CEST)

Der Parameter ist schon länger in der Box. Ich halte ihn für genauso überflüssig wie Linke und Rechte Nebenflüsse. Beides kann man im Artikeltext nennen, ggf. in Tabellenform. Das ist bei den Nebenflüssen eh übersichtlicher. Ich werden den Parameter entfernen, wenn sich hier eine Mehrheit dafür ausspricht. --SteveK ?! 17:37, 10. Jun. 2012 (CEST)

Bei Nebenflüssen ist die Krux, dass die Zuflussrichtung nicht dabei ist, die Ordnung nach fallender Bedeutung oder nach Fließrichtung verstanden werden kann, die Ordnung zwischen den Gliedern beider Teillisten ohnehin offen bleiben muss und viele in diese Felder gar nichts einfüllen. Ich ertappe mich dabei, hier regelmäßig nur Verweise auf einen Abschnitt Zuflüsse einzufügen, im Grunde redundant. Weg damit! Die Box ist fett genug. Brücken habe ich gewiss noch keine zehn eingetragen, eher nur so gegen eine. Bekanntheit heißt wohl zunächst einmal, überhaupt einen Eigennamen zu haben; das ist selten genug.

Irgend jemand wollte mal mit einem konkreten Vorschlag kommen, wie man auseinanderfallende Ursprünge

• nach längster Fließstrecke im Flusssystem (Bsp. Rhein/Aare)
• nach rekursiv größtem Quell-EZG
• nach höchster Quelllage
• nach Taufname/Konvention (Donauquelle Sigmaringen)

ohne unnötiges Gebastel in der Infobox unterbringen könnte. Ist daraus denn was geworden?

--Silvicola ⇨⇦ 18:59, 10. Jun. 2012 (CEST)

Ich schließe mich meinen Vorrednern an. Brücken und Zuflüsse raus. --Freak-Line-Community (Diskussion | Beiträge) 19:03, 10. Jun. 2012 (CEST)

Wobei man bei den Zuflüssen noch fallweise erwägen könnte, die nach objektivierbaren Kriterien (am besten EZG) wichtigsten reinzunehmen. So min. Möhne/Lenne/Volme bei Ruhr und Eder/Haune bei Fulda und beim Rhein bis EZG Neckar.

Dann wäre aber besser "Zuflüsse ab <Parameter> EZG" flussabwärts und mit (r) oder(l).

Die - in natürlicherweise ausführlicheren - Listen im Artiekelabschnitt sind ja auch meistens ab EZG x, alle kleineren dann in einer ausgelagerten Liste. --Elop 19:38, 10. Jun. 2012 (CEST)

"Zuflüsse ab <Parameter> EZG" verstehe ich nicht. Vorschlag zur Parameterumbenennung? (Wozu genau?) --Silvicola ⇨⇦ 01:00, 11. Jun. 2012 (CEST)

Bei der Lahn stehen z.B. alle ab 30 km² im Artikel selber und in der Box könnten alle ab 200 oder so oder aber nur die beiden ganz großen (Ohm und Dill) stehen. Objektivierbarerweise wären Ohm und Dill z.B. ausgesucht, weil sie mehr als 10 % des EZG entwässern. Aber das könnte man auch, je nach Sachlage, offen lassen. Einen Verweis "siehe Liste unten" kann man ja eh easy in die Box einfügen ...

Auf jeden Fall halte ich eine komprimierte Darstellung der wirklich wichtigen Nebenflüsse für weitaus weniger unsinnig als die Rubrik "Bekannte Brücken" ... --Elop 01:27, 11. Jun. 2012 (CEST)

Den Parameter Nebenflüsse würde ich nicht herausnehmen, da wir dabei jede Menge an Informationen verlieren würden. Natürlich ist es bei großen Flüssen nicht sinnvoll, auch nur die bedeutendstens Nebenflüsse in die IB aufzunehmen, in diesem Fall ist sicher eine eigenen Tabelle im Text sinnvoller. Bei der großen Menge an kleineren Flüssen ist der Parameter linker bzw. rechter Nebenfluss sehr praktisch und ich verwende ihn laufend. --Skipper69 (Diskussion) 08:44, 11. Jun. 2012 (CEST)

Wenn der Parameter fallen sollte, müssten natürlich die Einträge in den Artikeltext übernommen werden, sofern da nicht schon abgehandelt. Wegwerfen sollte man nichts. --Silvicola ⇨⇦ 12:21, 11. Jun. 2012 (CEST)

Wenn ich mir den Diskussionsstand anschaue, dann spricht wohl nichts dagegen, den Parameter "BEKANNTE BRÜCKEN" zu entfernen. Mache ich dann mal.

Die Nebenflussparameter werden unterschiedlich verwendet, eine Änderung ist noch nicht abgeschlossen. --SteveK ?! 12:11, 11. Jun. 2012 (CEST)

Bitte ohne Informationsverlust, d.h. doch vorhandene Brücken in den Artikeltext translozieren.--Silvicola ⇨⇦ 12:21, 11. Jun. 2012 (CEST)

Der Parameter wird durch die Vorlage nicht mehr dargestellt. Im Quelltext der Artikel ändere ich nix, die Information bleibt, wenn auch verdeckt, erhalten. --SteveK ?! 12:24, 11. Jun. 2012 (CEST)

Halte ich nicht fur richtig, aber was solls. Was die Nebenflüsse angeht, so ist es sicher sinnvoll, sich bei diesen in der Infobox auf solche zu beschränken, die von Größe und Bedeutung nur eine oder maximal zwei Stufen niedriger liegen als die des Flusses selbst. Wenn man sich da an Flußordnungszahlen nach Strahler orientiert, liegt man da nicht falsch. Und wie immer nicht allzu stur vorgeht. So bekommt man dann beim Rhein Beckar, Mosel, Main und Lahn, nicht jedoch Leimbach, Moder oder Dreisam. --Matthiasb ^{(CallMyCenter)} 17:55, 24. Jun. 2012 (CEST)

Durchflossene Stauseen

Der Parameter "STAUSEEN" führt Autoren beim Editing in die Irre, denn der produzierte Text der Vorlage ist "Durchflossene Stauseen". Entweder ändert man den Parameter (sicher schwer, da die Vorlage x-fach verwendet wird) oder streicht "durchflossene" im von der Vorlage produzierten Text. Es gibt auch nebenschlussbetriebene Stauseen, bei denen der Hauptstrom seitlich des Flusses entlang läuft, und nur ein Nebenarm des Flusses selbigen durchfließt. Dieser Nebenarm kann lediglich der Speisung des Stausees dienen, aber auch weitere Funktionen haben, etwa den Betrieb von Mühlen.

Autoren differieren in den Auffassungen darüber, ob nebenschlussbetriebene Stauseen nun zu den vom Fluss "durchflossenen" Stauseen zählen, oder nicht. Mögliche Ausgestaltungen sind

• nur vom Hauptarm des Flusses gespeiste Stauseen sind Stauseen im Sinne der Vorlage
• vom Hauptarm und Nebenarmen des Flusses gespeiste Stauseen sind Stauseen im Sinne der Vorlage

--Cmuelle8 (Diskussion) 12:17, 12. Jun. 2012 (CEST)

Wenn ein Autor die Infobox anwendet und die Anwendung einzelner Parameter nicht kennt, dann sollte er die Beschreibung der Vorlage lesen und anschließend ggf. nachfragen. Das ist zumutbar. Der Parameter "STAUSEEN" soll die vom beschriebenen Gewässer durchflossenen Stauseen enthalten. Würde man das "Durchflossene" streichen, dann wären alle Stauseen im Einzugsgebiet gemeint. Und genau das ist nicht gewollt. Ich halte eine Änderung für unnötig. --SteveK ?! 12:38, 12. Jun. 2012 (CEST)

Das ist keine Antwort auf meine Frage. Für die Stauseen im Einzugsgebiet sind die bis jetzt genannten Mengen klar zu trennen.

''alle Stauseen im Einzugsgebiet von F'' (1) >= ''von Haupt- und Nebenarmen von F gespeiste Stauseen'' (2) >= ''vom Hauptarm von F gespeiste Stauseen'' (3)

Viele Nebenarme sind unbenannt, gerade wenn sie nur dem Anschluss eines Stausees dienen. Die Dokumentation der Vorlage streicht mit ihrer Darstellung zwar klar Menge (1), lässt aber Spielräume zwischen (2) und (3) offen. Es ist eine Frage der Betrachtung, ob Nebenarme zu F zählen, oder nicht. Zählt man sie dazu, ist die Menge 'durchflossener Stauseen' identisch mit (2), ansonsten mit (3).
Ich stimme Dir zu, dass ein einfaches Streichen des Adjektivs die Sache nicht löst, da dann zusätzlich auch (1) als Deutung möglich ist. Nur wie kann man die Mehrdeutigkeit zwischen (2) und (3) lösen - vom Hauptarm durchflossene Stauseen ist zu lang. --Cmuelle8 (Diskussion) 13:34, 12. Jun. 2012 (CEST)

Ein Fall für (2)\(3) wäre der Dutenhovener See zwischen Wetzlar und Gießen bei der Lahn. Der wird nämlich eher umflossen. Bei der Werra gibt es recht viele solcher "Neben"seen. --Elop 13:55, 12. Jun. 2012 (CEST)

Danke für das Beispiel, ein weiteres ist der Röthaer Stausee, der im Nebenschluss der Pleiße betrieben wird (ursprünglich Anlass für diesen Abschnitt). --Cmuelle8 (Diskussion) 13:57, 12. Jun. 2012 (CEST)

Die IB lässt hier ganz bewusst einen Spielraum, der Autor soll entscheiden können was er da rein schreibt. Bei der Lahn gibt es in der IB keine Angabe der Seen/Stauseen lieber Elop. Eine Lösung, die haargenau festlegt was geht und was nicht, die sehe ich hier jedenfalls nicht. Die Information der IB sollte ja, möglichst detailierter, im Artikeltext erwähnt werden. Da geht mehr als in einer IB möglich ist. --SteveK ?! 16:18, 12. Jun. 2012 (CEST)

Duuu. Steeeeve,

Es geht ja genau um diesen Spielraum!

Als ich mein obiges Statement verfaßte, ging ich intuitiv davon aus, der Dutenhovener sei drin (was er halt nich iss - für und gegen beide Varianten spricht sicher je vergleichbar viel).

Spontan dachte ich mir danach, daß er für die Lahn letztlich auch eben eine Stufe weniger bedeutend sei als Eder-, Bigge-, Möhne- und Diemelsee für ihre jeweiligen Namensgeber.

Bei den Letztgenannten stellt sich die Frage null, wohl aber bei den klassischen Abzweigseen, die zwar Wasser vom Hauptfluß kriegen, jedoch eigentlich in zweiter Reihe stehen. Z. B. auch bei den Borkener (Hessen) Seen. --Elop 01:11, 13. Jun. 2012 (CEST)

Eigentlich Haarspalterei, denke ich so für mich. Man kann auch definieren, dass ein See hineingehört, wenn er vom Hauptstrom Wasser bezieht und wieder an diesen abgibt. Ich kann mir auch vorstellen, dass Umfluter von einem Flusssystem zum anderen Flusssystem fließen lassen und auch noch durch einen See fließen, was aber letztlich ein eigenes Gewässer darstellt. --SteveK ?! 16:28, 14. Jun. 2012 (CEST)

Linke und rechte Nebenflüsse

Da es mit Vorlage:Fluss-Set-Doku bereits eine gute Variante für die Darstellung rechter und linker Nebenflüsse gibt, wäre ich dafür die Parameter aus der Vorlage zu entfernen. Damit schließe ich mich Argumenten meiner Vorredner weiter oben an, welche die Aufnahme in die Infobox aus Gründen der Übersichtlichkeit ablehnen und stattdessen lieber auf die Erwähnung im Artikel setzen. Evtl. könnte man auf längere Sicht versuchen, die einklappbare Version der Fluss-Set-Vorlagen in die Infobox Fluss zu integrieren - z.B. an der Stelle, wo jetzt die linken und rechten Nebenflüsse als Text gezeigt werden. Ein Beispiel einer Seite, welche sowohl die Fluss-Set Vorlagen als auch die Infobox Fluss verwendet ist Reuss (Fluss). Hier erscheinen die zwei Boxen losgelöst untereinander. gruß --Cmuelle8 (Diskussion) 13:55, 12. Jun. 2012 (CEST)

Von dem bei den Pufferküssern und Straßenfans abgeschauten Konstrukt halte ich gar nix. Es wird af Jahre hinaus an Benutzern, ja selbst an Quellen fehlen, diese flächendeckend einsetzen zu können. --Matthiasb ^{(CallMyCenter)} 16:16, 12. Jun. 2012 (CEST)

Ich stimme hier Matthias zu. Die Karte in der IB wie die im Artikel Pleiße halte ich für informativer als die schematische Flussdarstellung. Die Wupper ist ähnlich lang wie die Reuss, aber die Flussdarstellung sprengt dort den Rahmen dessen was mir sinnvoll erscheint. --SteveK ?! 16:22, 12. Jun. 2012 (CEST)

Ich habe mich auch mal an einer schematischen Flussdarstellung versucht und festgestellt: das wird zu lang. Polemisch gesagt, in der wesentlichen Wirkung nur eine Methode, Leser auch noch vom Ausdrucken abzuhalten, denn lesen wird so etwas ohnehin kaum einer. Für die Veranschaulichung von Flüssen sind mindestens ebenso wichtig wie die Zulauffolge der Nebenflüsse und Siedlungsanrainer die Richtungswendungen, die sie nehmen. (Die Bundesstraßen-Brücken u.ä. waren schön, zugegeben.) Jedes schematische Darstellen, das repräsentativ sein will, muss Platz für Möglichkeiten vorhalten, die dann zumeist gar nicht genutzt werden; es ist wie bei dünn besetzten Datenbanksätzen mit fixen Feldlängen, viel Luft für wenig Stoff. Wenn dann doch noch etwas Wichtiges gesagt werden müsste, ist gerade das nicht vorgesehen. Dichterer Text plus wenn möglich Karte taugen allemal besser. --Silvicola ⇨⇦ 17:42, 12. Jun. 2012 (CEST)

Könntest Du das ausführen? Der Vergleich hinkt. Die Fluss-Set-Vorlagen sind nicht sparse, sondern dense - da gibt es keinen unnötigen Zwischenraum für Zeilen die nicht gebraucht werden. --Cmuelle8 (Diskussion) 21:43, 12. Jun. 2012 (CEST)

Um im gewählten Englischen zu bleiben: Zuviel real estate auf der Seite.

Ich schiebe noch nach: die Schablonen-Events (querende Straße, Kanalab- und zuläufe, Zuflüsse usw.) häufen sich oft auf kurzem Abschnitt so, dass ein längenverzerrender Eindruck über den Flussverlauf entsteht. Bei Beschreibung mit Worten fügt man dagegen mehr oder weniger bewusst eine Milieubeschreibung ein, die erstens korrigierend „zerdehnt“ – „Der Fluss durchzieht hier auf einem vollen Drittel seines Laufes ein ausgedehntes Karstgebiet, in dem ihm von keiner Seite bedeutende Zuflüsse erreichen. Etliche Täler laufen zu, sind aber regelmäßig trocken. Jedoch entspringen hier in der Talaue vor allem am linken Hangfuß zahlreiche ungewöhnlich stark schüttende Quellen …“ o.ä. – und zweitens auch noch Zusatzinformation bringen. (Gibt's ein Schema-Rechteck für kurze Quellenzuflüsse? Wieviel nimmt man davon, wenn es etliche sind und ihre Zahl ohnehin nicht genau zu erfahren?)

Doch ich will Dir nichts ausreden oder gar verbieten. Versuch's und schau Dir das Ergebnis an. Aber rechne mit Arbeit, die Dich am Ende reut! --Silvicola ⇨⇦ 23:43, 12. Jun. 2012 (CEST)

Da hast Du zweifelsfrei recht - ich würde für einen Fluss-Artikel auch nicht ausschließlich auf die maßstabsverzerrende Darstellung durch dieses Schema setzen. Es muss ein Zusatz bleiben. In der Hauptsache sollte eine maßstabsgetreue Karte den Verlauf zeigen, bzw. der Text aussagekräftig sein. Die schematische Darstellung bleibt optional und ist aus den Gründen, die Du ansprichst sicher nie perfekt, aber wofür gilt das schon? grüße --Cmuelle8 (Diskussion) 01:32, 13. Jun. 2012 (CEST)

Vor ausklappbaren Partien in der Infobox rate ich grundsätzlich ab. Gerahmte Boxen lassen unveränderliche Größe erwarten, das sollte man besser nicht enttäuschen. --Silvicola ⇨⇦ 17:42, 12. Jun. 2012 (CEST)

Um's nochmal zu verdeutlichen: ein solches Schema ist eigentlich nur dann angebracht, wenn es im Artikel ausführlich um die Hydrographie eines Flusses geht und diese entsprechend ausführlich dargestellt wird. Im Detail nennt man Zuflüsse aber eher im Abschnitt Verlauf im Fließtext.¨Ansonsten finde ich Übersichten, wie sie der USGS erstellt (Beispiel auf S. 167, das ganze gibt es aber auch farbig) unter Umständen für zielführender. (Dort geht's um die Verteilung von Pegelstationen.)

Ausklappbare Artikelelemente würde ich am liebsten verbieten, Wikipedia soll Wissen vermitteln und nicht verstecken. --Matthiasb ^{(CallMyCenter)} 18:27, 12. Jun. 2012 (CEST)

Gefühlt ist hier eine ganze Menge Rigidität und m.E./imho dabei. Schreibt SteveK oben, beim Abschnitt Stauseen Den Spielraum gibt es bewußt, Autoren sollen selbst entscheiden., wird hier ein anderer Maßstab angelegt, um sich dem Thema zu entledigen. Ich kann eure prinzipiell negative Haltung gegenüber den Fluss-Set-Vorlagen nicht nachvollziehen. Natürlich leistet es nicht das gleiche, was eine maßstabsgetreue Karte liefert. Das will und soll es nicht. Schemata und Karten vermitteln hier einfach verschiedene Aspekte (für die DB'ler 'Views') ein und desselben Themas. Man muss zwischen beiden nicht Position beziehen, sondern sollte es wie mit den Stauseen auch, den Autoren der Artikel überlassen, welche Elemente zur Wissensvermittlung genutzt werden. Es ist ja auch nicht so, dass jeder Parameter der Infobox gefüllt sein muss, um sie benutzen zu können! Es geht um die Möglichkeit - wer sie nicht nutzen will, lässt es eben. --Cmuelle8 (Diskussion) 21:43, 12. Jun. 2012 (CEST)

Die Flussverlaufsboxen sind Geschmacksfrage. Sie sind deutlich breiter als die IB. Über die Breite der IB wurde auch schon heftig gestritten, die jetzige Breite wurde von einigen als zu breit empfunden. Da mit der Integration der Verlaufsboxen die Breite der IB deutlich vergrößert werden muss, auch für die Artikel, die keine Verlaufsbox nutzen, bin ich gegen eine Integration. --SteveK ?! 16:32, 14. Jun. 2012 (CEST)

Zweierlei Kompositionsregel verhindert korrespondierende Nachweise

Dingsbach
Daten
Quellhöhe	QP 500 mNQ QS
Mündungshöhe	MP 100 mNM MS
Höhenunterschied	400 m
Sohlgefälle	40 ‰
Länge	LP 10 kmNL LS

Dingsbach
Daten
Quellhöhe	QP1 500 mNQ1 Fall 1 QP2 Q2NQ2 Fall 2
Mündungshöhe	MP1 100 mNM1 Fall 1 MP2 M2NM2 Fall 2
Höhenunterschied	400 m
Sohlgefälle	4 ‰
Länge	LP1 100 kmNL1 Fall 1 LP2 L2NL2 Fall 2

Wieso ist die Kompositionsregel für den Aufbau des

X-Feldes

aus den Parameterwerten

X-PREFIX, X, X-SUFFIX, NACHWEIS-X

verschieden, je nachdem

• ob X = LÄNGE
• oder ob X = QUELLHÖHE / MÜNDUNGSHÖHE

ist?

Illustration hier rechts oben. M.E. ist nur die Regel passend, die für die LÄNGE implementiert ist, denn:

Ich schleife manchmal notgedrungen Varianten durch mit zwei möglichen Ursprüngen

1. Zusammenfluss, ab dem das Gewässer wirklich so heißt

2. Mündungsfernste Quelle, i.d.R. = Q. des längsten Quellbachs

und korrespondierend bei den Längen, jeweils mit zugehörigen Nachweisen, für die Nebenvariante zusammengebastelt in X-SUFFIX. (Ich weiß die Einwände: nicht 1-NF, da Wiederholungsfeld, aber was soll man denn machen? Man tut gut daran, die Werte auszuweisen für die Fließstrecke, in der das Gewässer wirklich so heißt, aber die hydrologisch wichtigere Gesamtfließlänge sollte man auch ausweisen. Und die Ursprünge dann nicht korrespondierend mitzuteilen, ist mir zuwider. Und die Nachweise auszulassen ebenso.)

Bei Quellhöhe und Mündungshöhe rückt nun der Nachweis für die Hauptvariante semantisch falsch nach hinten. Gegen die Semantik der Parameter tricksen, also alles ab dem Nachweis für die Namenssstrecke in SUFFIX zu stecken und das NACHWEIS-Feld leer zu lassen, will ich nicht. Siehe rechts unten.

Ob man nun mein Rattenschwanz-Procedere billigt oder nicht, jedenfalls verletzen die zweierlei Regeln das Prinzip minimaler Überraschung, und ich wüsste nicht, aus welchem plausiblen Grund. --Silvicola ^Disk 08:45, 11. Jul. 2012 (CEST)

Der Einwand ist irgendwie berechtigt und mir noch nicht aufgefallen. Die Werte für Länge, Quellhöhe, Mündungshöhe sollten Zahlen sein, die durch die Nachweise zu belegen sind. Was das im jeweiligen Suffix noch angehängt wird sollte keine Rolle spielen und ist dann auch nicht durch den angegeben Nachweis gedeckt. --SteveK ?! 09:57, 12. Jul. 2012 (CEST)

Ich habe das mal versucht zu korrigieren. Wenn es nicht korrekt sein sollte muss ich nochmal dran. --SteveK ?! 10:24, 12. Jul. 2012 (CEST)

Sieht jetzt gut aus, danke! Mich wundert ohnehin, wie man diese entsetzlichen Klammergebirge in Vorlagen überhaupt überschauen und ggf. sogar auch noch korrigieren kann. --Silvicola ^Disk 15:16, 12. Jul. 2012 (CEST)

Vorlage:Infobox Fluss/GKZ

Hallo, könnte jemand die Gewässerkennzahl (Finnland) einbinden und mit dem Artikel Gewässerkennzahl (Finnland) verlinken? --Slimguy (Diskussion) 07:41, 14. Jul. 2012 (CEST)

Erledigt. --TMg 18:16, 14. Jul. 2012 (CEST)

Koordinate

Die Infobox erzeugt automatisch einen Koorinateneintrag oben rechts mit der Koordinate der Mündung (über den Aufruf der Vorlage:Coordinate). Nun ist ja ein Fluss kein punktförmiges Objekt, sondern besteht schon in der Infobox aus mindestens zwei Punkten (Quelle und Mündung). Im Artikel können weitere Koordinaten (z.B. eines Wasserfalls) hinzukommen. Wäre es da nicht sinnvoller, statt der Vorlage:Coordinate die Vorlage:All Coordinates einzubinden? Grüße --axel (Diskussion) 20:48, 16. Aug. 2012 (CEST)

Das geht so glaube ich nicht, da die Vorlage:Coordinate für die Angabe der Koordinaten notwendig ist. Die Vorlage:All Coordinates liefert lediglich die Links für das Abrufen der Karte und kann auch außerhalb der IB gesetzt werden. Wenn ich das richtig verstanden habe, dann kann man damit keine Koordinaten angeben. --SteveK ?! 22:23, 16. Aug. 2012 (CEST)

Noch besser wäre es, wenn man komplette Geopfade einbinden könnte. Vielleicht mit dem Wachsen von Wikidata einst möglich ... --Elop 22:26, 16. Aug. 2012 (CEST)

Axel wollte ja nur, die im Artikel angegebenen Koordinaten in der Karte anzuzeigen. Das ist jedoch erstmal kein Problem der IB sondern des Artikels. Man könnte jedoch die Vorlage:All Coordinates generell durch die IB setzen, das spart die Arbeit innerhalb der Artikel.

Für die Darstellung wäre es toll, wenn man die Karte von OSM mit der entsprechenden Relation ([http://www.openstreetmap.org/?relation=364754 Beispiel Ruhr) einbinden könnte. --SteveK ?! 09:36, 17. Aug. 2012 (CEST)

Tausenderpunkte

Ich finde es störend, dass die Infobox bei vierstelligen Höhenangaben einen Tausenderpunkt setzt. Gem. WP:SVZ sollen die erst ab 5 Stellen auftauchen. Diese sind bei den Höhenangaben in Meter, wie sie in dieser Box vorkommen, aber nicht denkbar. Ich bin daher dafür, dass wir dies ändern. Ursache ist die - m.E. völlig überfrachtete - Vorlage:Höhe. Ich schlage daher vor, diese durch eine Vorlage, welche WP:SVZ beachtet, zu ersetzen. Ich biete an, diese bei Bedarf zu erstellen.

Analoges gilt für die Einbindung von Vorlage:Maß. Auch hier sollte erst ab 5 Stellen ein Tausenderpunkt auftauchen. wir haben aber weder bei der Höhendifferenz noch bei der Flusslänge 5-stellige Werte. ÅñŧóñŜûŝî (Ð) 16:27, 19. Aug. 2012 (CEST)

Da für die Höhenangaben die Vorlage:Höhe verwendet wird, solltest du dort die Diskussion führen und nicht hier. Die IB verwendet die Vorlage ja genau darum, dass die richtige Formatierung damit durchgeführt wird. Hier ist keine Änderung erforderlich. --SteveK ?! 17:26, 19. Aug. 2012 (CEST)

Habe ich schon am 15. Juni in die Vorlagenwerkstatt gegeben. Bisher hat sich dort keine erbarmt... Grüße --axel (Diskussion) 18:23, 19. Aug. 2012 (CEST)

Ok, dann weiter dort. ÅñŧóñŜûŝî (Ð) 18:48, 19. Aug. 2012 (CEST)

Einzugsgebiete

Wenn ich mir die Angaben über Einzugsgebiete anschaue, dann bekomme ich den Eindruck, dass viele Autoren nicht wissen, wie man mit Messwerten und deren Genauigkeit umgeht, oder dass sie einfach blind abschreiben. Es ist niemals möglich, bei einem Einzugsgebiet von mehr als 10.000 km² dieses auf einen Quadratkilometer genau zu ermitteln. Ursache dafür ist die Tatsache, dass sich Wasserscheiden nur selten zentimetergenau (bei sattelartigen Passhöhen nicht mal metergenau) ermitteln lassen. diese absoluten Fehler addieren sich über jeden Messpunkt in der Landschaft. Daher sind maximal vier sigifikante Stellen sinnvoll. ÅñŧóñŜûŝî (Ð) 16:43, 19. Aug. 2012 (CEST)

Die Diskussion um die Genauigkeit der Angaben müsstest du mit den entsprechenden Ämtern führen, die die Zahlen herausgeben. Ich habe die Anzahl der NK-Stellen auf 3 begrenzt. --SteveK ?! 17:23, 19. Aug. 2012 (CEST)

Wohl kaum eine Frage der Ämter, wenn es um einen "Fluss durch den Dschungel" geht. Hier haben irgendwelche Leute Werte addiert und das veröffentlicht. außerdem ist genau diese "Ämter-Argumentation" eine billige Ausrede für Abschreiben ohne Nachzudenken. hier wäre eine Begrenzung der signifikanten Stellen sinnvoll (Bei einer 7-Stelligen Zahl also Rundung auf ganze Tausend). ÅñŧóñŜûŝî (Ð) 18:39, 19. Aug. 2012 (CEST)

Ich schreibe gerne quellengetreu ab und denke dabei sehr wohl nach. Was, folgt hier.

Dass die Werte in einer Genauigkeit angegeben sind, die meist nicht erreicht werden kann, geschenkt! Wenn man aber rundete, dann auf welche Genauigkeit? Um da nicht danebenzuhauen, muss man nämlich im Einzelfall prüfen, wie „wacklig“ die Wasserscheide auf Hochebenen ist und je nachdem auf so oder soviel Stellen runden. Offensichtlich geht das nicht ohne Willkür ab, die man billigkeitshalber dann rechtfertigen müsste. Um sie zu vermeiden, müsste man vielleicht das EZG mehrfach abmessen und dann Mittelwert und Streuung angeben XXX ± YYYm km². Dann hängt man aber immer noch von der Zuverlässigkeit des Höhenlinienbildes ab, davon, dass man die Sonderabflüsse in anderes EZG über Kanalisation nicht übersieht usw.

Vorzug davon, irgendwo auf der Seite den amtlich-genauen EZG-Wert stehen zu haben, ist übrigens, dass man EZGs von Vorflutern aggregieren kann, ohne weitere numerische Fehler einzuschleppen, wie im Falle, dass man sich dabei auf schon gerundete Werte stützte. Genau das umgekehrte Verfahren wie bei den Behörden, die nach und nach Einzugsgebiete weiter zerschnippeln. Ich vermute, die hohe (scheinbare) Genauigkeit dort hat genau den Grund, diese Fehlerfortpflanzung bei der Reaggregation zu vermeiden. Wer wird noch aggregieren, wenn er die Teilgebiete eines Vorfluters zuvor selber rekursiv aggregieren muss? (Hierfür täte es auch ein HTML-Kommentar auf der Seite als Depot für dem genauen Wert. Bitte aber nicht in der Flussbox, weil die teilweise mit Software bearbeitet wird, die solche Kommentare schlankweg löscht!)

Wer selbst nur ein Bisschen nachdenkt, der kommt gar nicht in die Versuchung, die Nachkommastellen oder bei großen EZGs selbst die letzten Vorkommastellen für bare Münze zu nehmen. Damit sich aber kein Naiver Illusionen hingibt, sollte an der Box ein genereller Kautelentext stehen oder besser noch verlinkt sein, der das grundsätzliche Problem anspricht und erklärt („ … da nur ungenau festgelegt … nicht notwendig auf die angegebene Stellenzahl exakt … “ o.Ä.), weil das Problem allen Flüssen gemeinsam ist und es deshalb jedem Leser nur einmal dargestellt werden muss und danach in einer visuell unaufdringlichen Ecke verschwinden darf. In jedem Flussartikel lang und breit wiederholt, wäre das nur gedroschenes Stroh. (Manchmal sollte aber etwas explizit dazu stehen, bsp. bei Karstgewässern mit ihren oft starl abweichenden oberirischen und Karstleiter-EZGs.)

Analoges gilt für die Genauigkeit von Flusslängen. Die Willkür der Längenangabe kann bei kleineren Gewässern da sogar noch größer sein, wegen der jahreszeitlich stark schwankenden Oberlauflängen. (Der qualitative Begriff der Quelle ist oft illusorisch.) Da die Behörden teilweise auf ihrem Karten und in ihren Datenbanken recht rücksichtslos den Hauptstrang einheitlich bezeichnen und zusammenfassen, selbst wo TKs und der Sprachgebrauch verschiedene Teilabschnitte verschieden benennen, muss man hier oft für die diesen Konventionen genügenden Längenangaben für Abschnitte diese Hauptstränge erst einmal zerschneiden. Zugegeben, hier ist das Rechnen nicht so fürchterlich aufwendig – da nur eindimensionale Zerlegung nötig ist – wie bei EZGs, wo es um zweidimensionale Aggregation geht. Das Rundungsfehlerproblem ist aber dasselbe.

--Silvicola ^Disk 19:43, 19. Aug. 2012 (CEST)

Danke für die genaue Ausführung. Was es die "gewisse Willkür" angeht: Im Zweifelsfall eine Stelle mehr behalten und nur klar unsichere Stellen entfernen. Eine Angabe wie "3.730.470 km²" im Artikel über den Kongo sind aber unsinnig genau. Bei einem derartigen Fluss sind vermutlich selbst 5 sign. Stellen gewagt. Eine diskrete Methode für die Info über die Interpretation ist eine Fußnote am ende des Artikels. Dazu kann eine Vorlage erstellt werden. ÅñŧóñŜûŝî (Ð) 20:43, 19. Aug. 2012 (CEST)

Ach weist du Antonsusi, die in RLP geben die Einzugsgebiete mit zahlreichen Stellen an, die dann Messtechnisch sicher Schwachsinn sind. An die hatte ich bei meiner Antwort gedacht. Ich gebe sie aber dennoch an, weil ich wie Silvicola der jeweiligen Quelle treu bleiben möchte. Leider gibt die Vorlage:Maß nur die Begrenzung der Nachkommastellen her, nicht aber die Begrenzung der signifikanten Ziffern. Ob man deswegen ein Fass aufmachen sollte? Wie oben bei den Höhen schon gesagt, so was sollte in der Vorlage gemacht werden, nicht aber in der anwendenden IB. --SteveK ?! 09:23, 20. Aug. 2012 (CEST)

Eine Vorlage, welche teilweise mit signifikanten Stellen arbeitet, ist Vorlage:FormatZahl. diese würde hier nicht ganz passen, aber eine allgemeine Vorlage für signifikante Stellen ist gut machbar. Es gibt in der WP-Software die notwendigen Funktionen (eine Logarithmusfunktion, diverse Rundungsprozeduren u.A.) mit denen man das durchführen kann. ÅñŧóñŜûŝî (Ð) 21:06, 20. Aug. 2012 (CEST)

Du hast ja ein allgemeines Problem der Messgenauigkeit hier angesprochen, dass man genauso auf die Längen erweitern kann. Da jeder Messwert eine Messtoleranz aufweist, sind die Zahlen ja alle entsprechend ungenau. Bei einer angenommenen Messtoleranz von 5% schwankt ja ein Wert von 200 um ± 10, man hat also 2 signifikante Stellen. Und ich nehme mal an, dass die in Europa erfassten Werte nicht genauer sind. Ich würde vorschlagen, dass man das mit der Genauigkeit bei der Vorlage:Mass diskutiert, da das doch ein allgemeines Problem ist.--SteveK ?! 09:27, 21. Aug. 2012 (CEST)

• Das ist mal wieder eine typische absurde Diskussion. Wenn ein Amt eine solche Zahl bekanntgibt, dann beruht das immer auf Ermittlungen am Meßtisch, und dann ist auf dem Papier die Größe des Einzugsgebietes zentimetergenau festgelegt. Wie's im Feld aussieht, interessiert nicht, weil eben alle möglichen Kennzahlen – etwa die an verschiedenen Stellen ermittelten Abflußmengen sich eben auch auf dieses am Meßtisch ermittelte Einzugsgebiet beziehen. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 09:58, 21. Aug. 2012 (CEST)

MNq und MHq, Vorlage:Abflusstabelle

Inzwischen tendiere ich fast dahin, auch die Niedrig- und Hochwasserabflussspenden automatisch zu generieren. Ich vermute nämlich, daß man auf Dauer auch dadurch auf Dauer diese Werte einzuschätzen weiß, daß man sie regelmäßig bequem anlesen kann - wie man ja auch inzwischen weiß, wo der Mq bei 5 und wo er bei 30 liegt.

Was die Felder zu den Pegeln 1-3 anbetrifft, so habe ich bei der Werra mal alle komplett ausgefüllt, ebenso bei der Ulster (Werra). Das macht die Boxen natürlich lang und bei der Werra fehlen immer noch Pegel.

Meine Idee wäre daher, im Zweifel nur max. 2 Abflüsse in die Box zu stellen (z. B. letzter Pegel und Extrapolation) und dafür eine Vorlage:Abflusstabelle zu generieren. Diese könnte nicht nur die Abflusspenden am Pegel selber generieren, sondern auch Differenzen zum je vorherigen.

In der Werrabox sieht man jetzt z. B. den Mq-Verlauf:

• 21.3 → 12.1 → 10.5 → 9,2

Dieses sind aber je Summen, die Teilabschnitts-Mq sähen anders aus:

Pegel	LoM	EZG	Diff-EZG	MQ	Diff-MQ	Mq	Diff-Mq
Eisfeld-Bahnbrücke	283,0	51,2	51,2	1,09	1,09	21,4	21,4
Ebenhards	260,0	220,8	169,6	2,60	1,51	11,8	8,9
Schleuse/Rappelsdorf			256,0		4,50		17,6
Hasel/Ellingshausen			327,0		4,65		14,2
Werra abz. Schleuse und Hasel			366,2		2,35		6,4
Meiningen	223,0	1170,0	949,2	14,1	11,5	12,0	12,1
Schmalkalde/Mittelschmalkalden			153,0		2,15		14,1
Felda/Dorndorf 2			214,0		2,32		10,8
Werra abzgl. Schmalkalde und Felda			709,0		5,03		7,1
Vacha	164,8	2246,0	1076,0	23,6	9,5	10,5	8,8
Ulster/Unterbreizbach			399,0		5,04		12,6
Weihe/extrapoliert			64,0		0,344		5,4
Werra abzgl. Ulster u. Weihe			330,0		1,816		5,5
Gerstungen	137,8	3039,0	793,0	30,8	7,2	10,2	9,1
Hörsel/Summe Eisenach			731,3		6,26		8,6
Werra abzgl. Hörsel			444,1		3,54		8,0
Frankenroda	90,5	4214,4	1175,4	40,6	9,8	9,6	8,3
Heldra	77,3	4302,0	87,6	40,1	-0,5	9,3	-5,7
Frieda/extrapoliert			171,8		1,339		7,8
Wehre/Niddawitzhausen			430,0		3,55		8,3
Berka/extrapoliert			37,3		0,363		9,7
Werra abzgl. Frieda, Wehre u. Berka			225,9		1,248		5.5
Allendorf	40.7	5166,0	864,0	46,6	6,5	9,0	7,5
Gelster/extrapoliert			60,6		0,771		12,7
Werra abzgl. Gelster			260,4		3,029		11,6
Letzter Heller	2,3	5487,0	321,0	50,4	3,8	9,2	11,8

Eine Vorlage:Abflusstabelle bräuchte für obiges Beispiel folgende Parameter:

• Pegel1-Name
  • Pegel1-LoM
  • Pegel1-EZG
  • Pegel1-MQ
• Pegel2-Name
  • Pegel2-LoM
  • Pegel2-EZG
  • Pegel2-MQ
  • Pegel2.1-Name
    • Pegel2.1-Fluss
    • Pegel2.1-EZG
    • Pegel2,1-MQ
  • Pegel2.2 (in diesem Falle die Hasel) analog
• Pegel 3ff analog

Das alles dann noch ergänzt um die Parameter Nachweis, Reihe, Lage über NHN sowie die sonstigen Abflusswerte (aber ohne Diff-MHq/MNq) - Differenzwerte und alle Abflusspenden automatisch generiert.

So eine Tabelle stünde dann in einem Extraabschnitt, der dem Uneingeweihten im Idealfalle die Bedeutung der Zahlenwerte erklärte (z.B.: Schleuse und Hasel greifen so gut ab wegen Luvseite des Thüringer Waldes, Hasel schon etwas schlechter wegen Windschatten der Rhön, Rest des Prä-Meiningen-Abschnitts noch mauer als Eisfeld-Ebenhards, Heldra negativ wegen [differierende Abflussjahre, Abzapfen, Versickerung]). --Elop 16:22, 1. Okt. 2012 (CEST)

Eingabewerte nunmehr zur besseren Übersicht gefettet - alle anderen Werte sind aus den fetten Werten berechnet ... --Elop 01:54, 3. Okt. 2012 (CEST)

Die "q"-Werte könnte man recht einfach implementieren. Habe ich bisher nicht gemacht, weil sich hier keine weiteren Wortmeldungen ergeben hatten. --SteveK ?! 18:31, 6. Okt. 2012 (CEST)

Bitte bei Änderungen von Vorlage:Abflusstabelle erst mal mich ansprechen, damit wir nicht in BKs und doppelt gemachte Arbeit geraten. morty 19:03, 6. Okt. 2012 (CEST)

Ich glaube, der Steve sprach von der Box und den Werten MNq und MHq. Oder hat er gar meine Diskus von der Beo genommen? Dann wären meine ständigen Provos dort ja für die Katz ... --Elop 19:54, 6. Okt. 2012 (CEST)

Ich lese längst nicht alle Diskussionen lieber Elop. Wenn man hier diskutiert, dann sollte das mit Bezug auf diese Vorlage erfolgen. Man kann die Abflussspenden in der Infobox relativ einfach implementieren oder auch wieder entfernen. Eine Änderung der Vorlage:Abflusstabelle käme mir ohne dortige Rücksprache eh nicht in den Sinn lieber Morty. --SteveK ?! 21:42, 6. Okt. 2012 (CEST)

Ich werde morgen mal im Gewässerportal Mortys Tabelle vorstellen, daß dort insbesondere noch Anmerkungen gemacht und Wünsche geäußert werden können.

Bei MNq und MHq könnte ich mir vorstellen, daß sogar ich Flasche die in die Box einbauen könnte - könnte ja mehr oder weniger den Quelltext zum Mq kopieren.

@Morty:

Sehe ich das richtig, daß es bislang 9 Hauptpegel gibt, von denen die ersten 8 bis zu 3 Nebenpegel haben können?

Sollte dann ja auch entsprechend auf Doku und Kopiervorlage ... Wobei es eigentlich reicht, über oder unter der Kopiervorlage anzugeben, von wo bis wo mögliche Parameter geben. Selbst wenn man auf 20 oder 30 Hauptpegel (Rhein) aufstockte, bräuchte man ja selten mehr als 10 ... Und auch beim Rhein wären vielleicht fünf Zehnertabellen (Übersicht; Alpen/Hoch, Ober, Mittel, Nieder) besser als eine Endlostabelle. Ganz zu schweigen von der Donau ... --Elop 23:59, 6. Okt. 2012 (CEST)

Jep, Du siehst das rchtig. morty 01:07, 7. Okt. 2012 (CEST)

Abflusskenngrößen

Ich habe gerade die Änderung beim Fluss Ems mitbekommen und habe erst gedacht, was ist denn nun los? Die Abflusskenngrößen etc. bei zig Pegeln mögen ja Spezialisten interessieren. Der normale Leser kann m.E. mit dieser Informationsflut wenig anfangen. Könnte man nicht mal darüber nachdenken, diese Werte in der Normalversion zu verbergen (Einklappen = Default). Interessierte könnten sich dann bei Werte bei Bedarf durch Ausklappen anschauen. Beispiel ist z.B. der „Straßenverlauf“ in der Infobox bei den Bundesautobahnen. Gruß --WHVer (Diskussion) 20:55, 15. Okt. 2012 (CEST)

Siehe auch Portal Diskussion:Gewässer#Abflußtabelle. Leider diskutiert kaum jemand mit. --Elop 00:40, 16. Okt. 2012 (CEST)

Im Gewässerjahrbuch sind noch zwei weitere Pegel enthalten ;-) Ich bin gegen ein verstecken von Informationen. Wenn ein Leser damit nichts anfangen kann, dann wird er die Abflusszahlen einfach ignorieren. Entweder wir stellen Informationen dar, oder aber wir lassen sie ganz weg. Den Straßenverlauf von Autobahnen, Eisenbahnlinien, etc. kann man damit nun wirklich nicht vergleichen. --SteveK ?! 10:21, 16. Okt. 2012 (CEST)

„Entweder wir stellen Informationen dar, oder aber wir lassen sie ganz weg“. Alles oder nichts! Warum gibt es nichts dazwischen? Die Informationen sind durch das Einklappen doch nicht weg, sondern sie werden zu Gunsten einer übersichtlicheren Infobox erst mal verborgen. Eine Stichwortzeile wie Pegeldaten, Abflusskenngrößen (bei der Infobox Autobahn = Straßenverlauf) bleibt ja dauerhaft sichtbar und macht auf die Informationen aufmerksam. Gruß --WHVer (Diskussion) 16:42, 16. Okt. 2012 (CEST)

PS: „…kann man damit nun wirklich nicht vergleichen.“ Frage: Wieso nicht?

Ich meine auch, dass eine derart überfrachtete Infobox das Gegenteil von dem bewirkt, was sie eigentlich sollte, nämlich eine kompakte Übersichtsdarstellung. Die Details kann man meiner Meinung nach im Text ausführen oder bei Bedarf zuschaltbar in der Box. Grüße --Skipper69 (Diskussion) 18:02, 16. Okt. 2012 (CEST)

Falls es nicht angekommen sein sollte:

Es soll ja auf Dauer nur der je letzte Pegel in die Box und der Rest in die Tabelle (an der noch gefeilt werden soll). Aber die Abflußwerte des letzten Pegels sind durchaus signifikante Kenngrößen. Eher würde ich tendenziell die Quellschüttung weglassen, da sie 1.) nicht den Gesamtfluß betrifft, 2.) nur selten bekannt ist, 3.) die meisten Flüsse nicht genau eine Quelle haben. Spannend ist die wirklich nur bei Karstquellen. --Elop 19:10, 16. Okt. 2012 (CEST)

Die Quellschüttung ist für Karstquellen angelegt worden, für nichts außer das. Ich habe weder an der Möhne-, Ruhr-, Lenne-, Lahn-, Eder- oder Dillquelle eine Messstation für die Quellschüttung gesehen, jedoch beim Blautop bspw. wird gemessen.

Warum man Verlaufkarten nicht mit Pegeldaten vergleichen kann, die Frage kannst du dir auch selbst beantworten. Bei der mit 40 km Länge recht kurzen A661 ist die Länge höher als ein Bildschirm bei mir. Die vier Pegel der Ems passen alle auf eine Seite (+weitere Kenndaten).

Macht was ihr wollt, ich habe derzeit keine Zeit und Lust hier was zu ändern. --SteveK ?! 20:52, 16. Okt. 2012 (CEST)

@Elop: Bei mir war das nicht angekommen – Was ist denn nun geplant? Pegel in der Infobox oder Tabelle im Artikel. Wenn die Pegel sowieso aus der Infobox herausgenommen werden sollen, dann brauchen wir ja nicht mehr über das Ausklappen bzw. Einklappen zu diskutieren.
@SteveK: Ich kann verstehen, wenn Du nach Deiner Infoboxänderung auf mehrere Pegel keine Lust auf weitere Änderungen hast. Allerdings sollte man die Diskussion m.E. erst mal ergebnisoffen führen und sich dann Gedannken über die Umsetzung machen. So könnte man auch die Vorlagenwerkstatt um eine evtl. Änderung bitten. Aber wie gesagt: Was ist denn nun geplant? Pegel in der Infobox oder Tabelle im Artikel. --WHVer (Diskussion) 19:39, 18. Okt. 2012 (CEST)

Daß man bis zu vier Pegel in die Box eintragen kann, heißt ja nicht, daß man das nennenswert oft tun würde. Aber bei Rhein und Donau könnter man das schon nutzen, um z. B. an bestimmten Staatsgrenzen Eckwerte zu haben. So hätte man z. B. einen Vergleich der beiden Flüsse an der Stelle, wo sie je D verlassen. Während selbst beim recht großen Main der unterste Pegel für einen Überblick (und genau den soll ja die Box bieten) ausreicht.

Die Vorlage:Abflußtabelle soll hingegen in einen Abschnitt, der die Werte auch kommentiert und interpretiert. --Elop 15:37, 19. Okt. 2012 (CEST)

Aber bei der "kleinen" Ems sind jetzt vier Pegel eingetragen, obwohl der Fluss Deutschland nie verlässt. Das war ja der Auslöser, warum ich hier überhaupt mal nachgefragt habe. Gruß --WHVer (Diskussion) 22:35, 19. Okt. 2012 (CEST)

Datum

Macht so eine Formatierung in der Box eigentlich Sinn? Auf jeden Fall sollte die Formatierung überall gleich aussehen. --Elop 15:35, 18. Okt. 2012 (CEST)

Wenn du mich nach meiner bescheidenen Meinung fragen tust: Nein! Eine Abkürzung der Monatsnamen ist nach der Datumskonvention soviel ich weiß nicht vorgesehen. Das Zahlenformat in Listen und Tabellen wie wir es eingetragen haben jedoch schon. --SteveK ?! 20:50, 18. Okt. 2012 (CEST)

Gewässerkennzahl

Die Box verlinkt da auf die (deutsche) Fließgewässerkennziffer, obwohl es eine eigentlich passendere Begriffsklärungsseite Gewässerkennzahl gibt. Ich sehe allerdings das Problem, dass bei Verlinkung der BKS tausende von Artikeln auf eine Begriffsklärungsseite verweisen würden und man MerlBot & Co. dann umprogrammieren müsste, damit sie das ignorieren. -- Olaf Studt (Diskussion) 11:37, 19. Okt. 2012 (CEST)

Es gibt meiner Meinung nach zwei Möglichkeiten:

1. Wir entlinken einfach die Erläuterung. Die Verlinkung erfolgt ja durch die Ländercodes auf den länderspezifischen Artikel.
2. Eleganter wäre mMn die Lösung, die BKL Gewässerkennzahl zu verschieben und einen Artikel Gewässerkennzahl zu erstellen. Damit könnte man die verschiedenen Artikel zur Gewässerkennzahl zusammenfassen. Damit gönnte man dann die Verlinkung auf den korrekten Artikel umändern.

Mehr fällt mir dazu nicht ein. --SteveK ?! 14:51, 19. Okt. 2012 (CEST)

Variante 1 wäre die einfachste und schnellste Lösung. Analog zu Variante 2 gibts bereits einen ähnlichen Versuch beim Lemma Flussgebietseinheit. Aber ganz so toll finde ich den auch nicht...Grüße--Skipper69 (Diskussion) 12:15, 20. Okt. 2012 (CEST)

Ich werde mal die Entlinkung umsetzen, da der verlinkte Artikel nicht der korrekte ist. Verlinken geht ja genauso schnell umzusetzen.--SteveK ?! 15:08, 20. Okt. 2012 (CEST)

Hin und Her bei Quellkoordinaten

Ich habe in letzter Zeit bei diversen Fließgewässern QUELLE und QUELLE_REGION ausgefüllt, im Vertrauen darauf, dass das „Hilf mit!“ in der IB und die Wartungskategorie erscheint – jetzt sehe ich allerdings Spezial:Linkliste/Vorlage:Infobox Fluss/QUELLKOORDINATE fehlt, das ist in der Tat ein Fortschritt gegenüber dem Zustand vor der „Hilf mit!“-Phase und für Gelegenheits-Flussautoren nicht so verwirrend wie die Wartungskategorie. -- Olaf Studt (Diskussion) 10:39, 1. Dez. 2012 (CET)

Obwohl Bauwerksartikel nicht so meine Sache sind, fülle ich dort häufig fehlende Koordinaten ein, eben weil ihr Mangel schon am Kopf des Artikels angemahnt wird und nicht erst ganz weit unten hinter dem Apparat. Insbesondere jede gewöhnlich klickbare Fläche zieht wohl die Aufmerksamkeit stark auf sich. Ähnlich vermutlich bei Gewässern. --Silvicola ^Disk 12:58, 1. Dez. 2012 (CET)

Ausflüsse von Seen und Flussarme

Bei Gewässern, die nicht irgendwo aus der Tiefe quellen, sondern an einem Stillgewässer oder einer Bifurkation beginnen und somit Wasser aus einem anderen Gewässer weiterleiten, klingt „Quelle“ ziemlich unsinnig.

Darum sollte die Vorlage alternativ Dateneingabe und -Präsentation für den Ursprung oder Abgang eines Fließgewässers möglich machen.

Da in Südwestdeutschland der „Begriff“ Ursprung auch für Quellengebraucht wird, käme man theoretisch allein mit dieser Bezeichnung aus. Da aber schon tausende von Flussartikeln Eingaben zur Quelle verwenden, ist es sinnvoller Quelle zu belassen aber die Formulare um die Eingabe- und Darstellungsmöglichkeit Abgang zu erweitern.--Ulamm (Diskussion) 18:11, 25. Dez. 2012 (CET)

Hallo Ulamm, ich sehe Dein Problem nicht ganz. Mit den Parametern "BEZEICHNUNG-QUELLE" und "BEZEICHNUNG-MÜNDUNG" kannst Du ja ohnehin einen abweichenden Begriff Deiner Wahl in die IB stellen. Kein Problem also anstelle des Begriffes "Quelle" den Begriff "Bifurkation" anzuführen und statt "Mündung" eine "Versickerung". Grüße --Skipper69 (Diskussion) 18:35, 25. Dez. 2012 (CET)

Sehe ich genauso. SteveK ?! 20:39, 27. Dez. 2012 (CET)

Kleine Anregung und großer Vorschlag

1. Die Flussbox rückt die Längenangabe ein (vmtl. per NBSP), die EZG-Angabe dagegen nicht. Wieso mal so und mal so? Ich meine, man sollte nichts vorsetzen – wer das unbedingt will, kann dann immer noch Layout-Feinschnitzereien selber anstellen. Etwas was immer da ist, wird man dagegen gar nicht mehr los.

2. Oft hat man bei Flüssen zwei Längen anzugeben, nämlich die hydrologische Länge (ab oberste Quelle / ab Quelle auf Hauptast / …) einesteils, die in Betrachtung von außen wichtigster Längenwert ist ; und anderesteils die Länge des letzten Abschnittes, auf dem er wirklich seinen Namen trägt. Manchmal sogar mehr als zwei Werte, vgl. etwa Main / Regnitz / Rednitz / Rezat. D.h., in Wirklichkeit ist – in Datenbanksprechweise gesagt – die Länge ein Wiederholungsfeld. Derzeit muss man aber diese Wiederholungen durch Layout-Künsteleien realisieren. Will man sinnvollerweise jede Angabe mit einer Erläuterung dazu, was dieser Wert meint, auf eine eigene Zeile setzen, dann muss man mit expliziten Zeilenumbrüchen arbeiten, für jede außer Zeile außer dem einen Wert, der zur Ehre des „infobox-offiziellen“ Hauptwert kommt, Rundung, Beleg-Annotierung und Erläuterung selbst vornehmen und dann den ganzen unleserlichen Kladderadatsch möglichst sinnvoll auf PREFIX und SUFFIX verteilen. Dabei dann bitte auch das Leerzeichen (s.o. 1.) nicht vergessen, sonst bekommt man im Feld eine unschön franselige linke Textkante. Was für ein Gefeile, bis das endlich stimmt!

3. Ein Fluss hat oft genug mehrere Quellen – sei es, dass die Meinungen üner den Ursprung traditionell auseinandergehen, sei es, dass man rekursiv nach Länge / EZG / Abfluss bergwärts voranschreitet und damit eben sachlich nach verschiedener Art eine Quelle auszeichnen kann. Auch das ist wieder ein Fall eines Mehrfachfeldes, für das nur ein offizielles Parameter-Fach vorgesehn ist, nur kommt hier nun noch der Koordinaten-Klumpatsch dazu. Ohne typischerwiese je gesehen zu haben, wie eigentlich die Box aus den einschlägigen Feldern ihren Quell-Guß formatierend zusammensetzt, muss man das im Falle man eine andere Quelle mit den entsprechenden Angaben versehen will, wieder von Hand per Versuch&Irrtum hindrehen. Vier Wochen später beim nächsten Fall, wenn man etwa nicht mehr weiß, dass die Vorlage:Coordinate das nun mal eine Nummer zu groß formatiert, dann wieder von neuem mit &lz;small> umklammern.

4. Man sieht, das Problem, dass doch Mehrfaches hinein müsste, obwohl eigentlich ein einfaches Datum als Eintrag unterstellt wird, kann in der Box an einigen Stellen vorkommen. Die Behandlung dieses Datendesign-Problems obliegt dann dem einzelnen Schreiber, der sich dazu in hinbiegenden Layout-Basteleien ergehen muss. Mich stören dabei nicht einmal so sehr Unrundheiten beim Satz, die man nicht oder nur schwer los wird. Was tun?

5. Gibt es nicht die Möglichkeit, die Box modular aufzubauen? Unter LÄNGE würde sie dann etwa eine Folge von Einbindungen anderer Vorlagen aufnehmen können. Diese – sagen wir einmal – Vorlage:Einfachlänge würde dann vielleicht enthalten: Präfix, Länge in km, Belegref, Postfix, Erläuterungstext. Analog könnte man für eine Parameter Quelle in Vorlage:Infobox Fluss eine Folge von Einbindungen der neuen Vorlage:Einfachquelle akzeptieren mit ihren Parametern: Name, Art, Höhe, Höhenbelegref, Koordinate, Erläuterungstext.

6. Ich kenne mich zugegebenermaßen in der Vorlagenprogrammierung nicht aus. Wäre so ein geschachtelter Vorlagen-Aufbau machbar? Nach meinem Eindruck würde die Infobox damit auch leichter wart- und befüllbar und ünersichtlicher, diese ganzen derzeitigen Wiederholungsparameter BILDn, PEGELn usw. könnte man damit auf jeweils nur einen Parameter eindampfen, der eben optional mehr aufnehmen darf. Als Einwand kommt sicher zuerst, dass der Höhenunterschied nun nicht mehr automatisch berechnet werden könnte, weil es keine priviligierte Quellhöhe mehr gibt und vielleicht auch weil der eigentliche Höhenwert nun eine Vorlage tiefer steht, wo er für die einbindende Vorlage technisch nicht greifbar ist. Aber wenn es mehrere „Quellhöhen“ gibt, kann es die Angabe eindeutig nun mal auch nicht geben. Will man doch eine eintragen, ist nur eine kleine Subtraktion nötig. Und der geschenkte Gaul hat nicht immer gute Zähne.

--Silvicola ^Disk 21:04, 28. Dez. 2012 (CET)

zu 1.

Hier verstehe ich dein Problem nicht, bei mir werden die Werte linksbündig angezeigt. Das scheint kein Problem der IB zu sein. Zeig mal bitte ein Beispiel. --SteveK ?! 23:18, 29. Dez. 2012 (CET)

Zuletzt: Herrgottsbach. --Silvicola ^Disk 04:47, 30. Dez. 2012 (CET)

Die Formatierung der IB macht "<PREFIX> <LÄNGE> <SUFFIX>". Du versuchst die IB zu überlisten und stolperst über das Leerzeichen zwischen Prefix und Länge, denn wenn du einen nicht vorgesehenen Umbruch in Prefix einfügst, dann wird das Leerzeichen in der nächsten Zeile dargestellt. Ich habe das mal so formatiert wie du es dir gedacht hast, ist aber nicht im Sinne der IB. --SteveK ?! 12:14, 30. Dez. 2012 (CET)

Danke für die Aufklärung!

Ich würde liebend gerne auf das Tricksen verzichten – aber mir scheinen beide Längen gleichermaßen relevant; der kleinere Wert, weil er nun einmal die wahre Länge ist, der größere, weil er etwa in der Quelle so steht (die gleichwohl implizit über wechselnde Beschriftung auch den anderen liefert), wo man wohl Bedacht hat auf die relative Bedeutung verschiedener Zuflüsse, vgl. dazu den scheinbaren Kümmerling Laxbach. Man trickst also wohl besser, indem man den anderen Wert ins Suffix stopft – ein nachhängendes Leerzeichen stört weniger als ein vorhängendes.

Was stört Dich am figure space (&#8199;)? --Silvicola ^Disk 13:56, 30. Dez. 2012 (CET)

Letzteres braucht man nicht und ich habe das Zeichen nicht kapiert. Bin froh wenn ich die ASCII-Zeichen noch halbwegs hin bekomme.

Es gibt ganz unterschiedliche Ansichten, wie man einen Flusslauf mit verschiedenen Namensabschnitten darstellen soll. Das krasseste Beispiel was ich kenne ist in NRW der Knochenbach (Werre), hier widerspricht die Stationierungslinie der DGK5. Das mag aus hydologischer Sicht korrekt sein, ist aber aus historischer und kultureller Sicht zu verneinen. Und dann hat der Oroginallauf noch einen Oberlauf mit anderem Namen. --SteveK ?! 16:31, 30. Dez. 2012 (CET)

zu 2.

Da haben wir schon mehrmals drüber nachgedacht, aber keine Lösung gefunden. Ein modularer Aufbau hilft da erstmal wenig weiter, wenn man nicht das passende Konzept für eine Darstellung hat. --SteveK ?! 23:27, 29. Dez. 2012 (CET)

Einfachste Möglichkeit: verschiedene Teilblöcke untereinander, mit vielleicht nicht ganz randbündigem waagerechtem Strich getrennt. Oder Teilblöcke wenig eingerückt mit senkrechten Randstrich, die Blöcke dann mit bündigem waagerechtem Strich getrennt. Aber vielleicht stößt man bei bedingten Elementen – Darstellung von Feldern nur, wenn Parameterwerte nicht leer; Trennstrich nur, wenn noch etwas kommt; usw. – an Grenzen dieses Wiki-Textersatz-Konzepts. --Silvicola ^Disk 04:47, 30. Dez. 2012 (CET)

zu 3.

Vorlagenprogrammierung geht nicht rekursiv (sich selber aufrufend), da man die Parameter ja nur einmal vorgeben kann. Eine halbwegs dynamische Form geht mit de "/" als Trenner, so wie es die IB beim Abflussweg macht. Die Box will auch nicht jedes Detail eines Quellgebietes darstellen, sie ist eigentlich schon kompliziert genug.--SteveK ?! 23:37, 29. Dez. 2012 (CET)

Rekursiv war falsch ausgedrückt von mir. Ich dachte an evt. wiederholte Einschachtelung von (anderen) Hilfsvorlagen.

Strukturell ist sie derzeit wirklich kompliziert genug, und zwar, weil sie kleinfitzelig ist. Gerade deshalb dachte ich ja an Modularisierung. Die Verwendungen würden aber bei Lizenz für Wiederholungsfelder wie beschrieben nicht wesentlich größer, da sie ja ohnehin immer nur sporadisch ausgefüllt wird und die Möglichkeiten nicht bis zum Anschlag genutzt würden; wo gibt es denn z.B. wirklich Abflusswerte? --Silvicola ^Disk 04:47, 30. Dez. 2012 (CET)

Abflusswerte gibt es häufig genug, nur nicht im vollen Umfang. Ich wollte ja mit den neueren Parametern für die Pegel die Einzelparameter ABFLUSSWERTE auslaufen lassen. Habe aber schon bemerkt, dass die BEKANNTEN BRÜCKEN ziemlich umständlich zu entsorgen sind.

Das Grundprinzip, dem ich bisher hier gefolgt bin, ist die Kompatibilität zur Vorversion der IB. So waren bei Änderungen keine Arbeiten notwendig geworden, dass will ich auch so weiter handhaben, schließlich ist die Box >10000x eingebunden.

Das ich den Vorlagenmeister nutzbar halten will, sollte selbstverständlich sein.

Ich könnte mir vorstellen, dass man die Formatierung der Länge, des Einzugsgebietes und der Höhenangaben (sind alles Zahlenwerte mit Beschreibung, Prefix, Wert, Nachweis, Suffix) in eine Untervorlage auslagert (Vereinfachung des Quelltextes der IB). Wenn man dann einen Parameter hinter der Länge einfügt, der den Inhalt einfach nur einfügt, dann wäre dir bei der Länge geholfen. Oder? --SteveK ?! 13:36, 30. Dez. 2012 (CET)

Du meinst, einen zusätzlichen Parameter mit frei formatierbarem, ungefiltertem Wert, der wie er ist einfach nur hinter dem zusammengesetzten Pre-We-Na-Su-Konstrukt angeklebt wird? – Damit wäre als Schreiber etwas leichter zu leben, weil das hauptwertbezogene Suffix/Präfix nicht mit den Wiederholungskonstrukten aufgebläht würde; allerdings hat man dann schon wieder einen Parameter mehr pro L/E/HH.

Wieso dann nicht gleich, am Bsp. der LÄNGE, einen neuen Parameter LÄNGEN mit dieser Verwendung

{{Infobox Fluss

| …

|LÄNGE-PREFIX = …

|LÄNGE = …

|NACHWEIS-LÄNGE = …

|LÄNGE-SUFFIX = …

|LÄNGEN= {{Flusslänge|PRÄFIX=…|WERT=…|NACHWEIS=…|SUFFIX=…}} (evtl. Wdh. mit Trenner )

| …

}}

Die modular eingebettete Vorlage Flusslänge macht die umfassende Vorlage eher leichter zu verstehen und zu gebrauchen als bisher, schon weil der Parameternamensgebrauch lokaler wird und auch dadurch diese mal durch Präfigierung (NACHWEIS-), mal durch Suffigierung (''-PREFIX) gewucherten Parameterungetüme fallen können, deren Überlänge doch nur der namespace-pollution abhelfen soll. Langfristig könnte man nämlich auch den bisherigen Längenparametersatz zu so einem neuen Flusslänge-Päckchen zusammenbacken und in den neuen Parameterwert schieben / diesem vorstellen. Erst wenn nirgendwo in WP mehr etwas in LÄNGE steht, würde man dann die Kompatibilität brechen müssen und das alles wegwerfen. (Aber besser schon mal frühzeitig die Parameter fürs alte Konstrukt als deprecated markieren.) Die Sache mit dem Trenner für die aufeinanderfolgenden Einbindungen ist mir noch unklar, am einfachsten wohl <br />, was aber die Formatierung schon festlegt; ein nur deklaratives Element wäre wohl hinsichtlich der Formatierung flexibler.

Für den Fall, dass Du dem Verständnis oder der Disziplin der Schreiber im Umgang mit der Neuerung nicht traust, könnte man ja auch erst mal die neue eingebettete Vorlage Flusslänge für den Gebrauch im neuen Anklebe-Parameter LÄNGEN anheimstellen, dann erkennt man bald, ob das so akzeptiert wird. Ich weiß auch nicht, ob das Einschachteln mit dem Vorlagenmeister überhaupt zusammengeht, den ich nie benutze (Skriptfeind). --Silvicola ^Disk 15:23, 30. Dez. 2012 (CET)

Automatische Kategorisierung

Nachdem ich die Vorlage:ISO Kat gefunden habe, kam mir die Idee, diese für das Setzen der Fluss-In-Kategorien zu nutzen. Da die Automatische Flusssystemkategorisierung noch das Problem hat, die Einordnung mit dem Seitennamen zu machen und DEFAULTSORT nicht greift, habe ich auch gleich den Parameter SORTNAME implementiert. Getestet habe ich an einem neuen Artikel. Damit wird elegant die Doppelkategorisierung erledigt. Bei Rhein und Donau geht das natürlich nicht vollständig. Ausgeschaltet wird die Funktion mit NOAUTOKAT- oder NEBENBOX-Angabe. Meinungen und Kommentare gerne --SteveK ?! 20:47, 27. Dez. 2012 (CET)

Ich sehe nicht ganz ein, warum nun bei allen französischen Flüssen, die ohnehin mit der "Kategorie:Fluss in Region" versehen sind, nun auch noch automatisch die "Kategorie:Fluss in Frankreich" angegeben wird. Das ist eine unnötige Doppelkategorisierung, weil ja die eine Kategorie Teil der anderen ist... Grüße --Skipper69 (Diskussion) 16:28, 28. Dez. 2012 (CET)

Die Ursache liegt in den verwendeten ISO-Vorlagen, die nicht vollständig ausgefüllt wurden. Ich habe diese jetzt für die vorhandenen Unterkategorien korrigiert, für die jetzt noch in der Kategorie:Fluss in Frankreich stehenden Artikel gibt es derzeit noch keine passenden Unterkategorien. (Beispiel der gemachten Korrektur: [1])

Bei der Betrachtung kann man natürlich auch fragen, ob die gewählten Kat-Lemmas geschickt gewählt sind. Wäre nicht Kategorie:Fluss im Département Ain nicht besser als das aktuelle Kategorie:Fluss in Rhône-Alpes? --SteveK ?! 13:43, 29. Dez. 2012 (CET)

Ich verstehe zwar von der Vorlagen-Programmierung nichts, kann aber nicht nachvollziehen, warum Du zB beim Allier (Fluss) keine passende Unterkategorie finden kannst. Eine Umstellung der Kategorien von Fluss in der Region auf Fluss im Département könnte ich mir durchaus vorstellen, wenn das für die automatisierte Kategorisierung etwas bringen sollte... Grüße--Skipper69 (Diskussion) 14:29, 29. Dez. 2012 (CET)

Ich habe nicht gesagt, dass ich mir alle FR-xx ISO-Vorlagen angeschaut habe. Beim Doubs (Fluss) jedenfalls kommt die Kategorie:Fluss in Frankreich durch die "FR"-Angabe bei den Koordinaten. --SteveK ?! 15:54, 29. Dez. 2012 (CET)

Ich habe das jetzt durchgeackert und auch die restlichen Flüsse (bis auf den in Neukaledonien) in Unterkategorien gestopft.--SteveK ?! 17:28, 29. Dez. 2012 (CET)

Danke, ich glaube jetzt passt es! Grüße --Skipper69 (Diskussion) 17:44, 29. Dez. 2012 (CET)

Bisherige Erfahrungen/Erkenntnisse:

1. Die verwendete Technik stützt sich auf die Vorlage:Info_ISO-3166-2:xxx Vorlagen, wobei "xxx" durch den jeweiligen ISO-Kode zu ersetzen ist. Die Vorlage sollte unter "in" den Teil des Kategorielemmas liefern, der "Fluss " folgt. Passt das nicht zusammen, dann wird der Artikel eine Ebene (Staat) höher eingeordnet.
2. In den Artikel ist bei den Koordinaten teilweise nur der ISO-3166-1-Kode (Staat) angegeben. Hier kann natürlich keine automatische Einordnung in Unterkategorien erfolgen. Hier müssen die Artikel korrigiert werden.
3. Für die Kontinentalgrenze Europa/Asien gibt es das Problem, dass für die Verwaltungseinheiten, die auf beiden Kontinenten liegen, unter "continent = Eurasien" einzutragen ist, damit keine fehlerhafte Kontinentalzuordnung erfolgt. Das ist vor allem in Russland ein Problem.
4. Bei Kategorieverschiebungen muss auch die "in"-Angabe der Vorlage:Info_ISO-3166-2:xxx geändert werden. Ggf müssen alle darauf aufbauenden Objektkategoriene anderer Zweige mit angepasst werden. Hier sehe ich vor allem in Frankreich ein Problem (da gibt es bspw. die Kategorie:Fluss in Burgund, die wohl Kategorie:Fluss im Burgund heißen müsste.)
5. Die Kontinentalbezeichnung für den 5. Kontinent ist unterschiedlich angegeben: Australien, Ozeanien, Australien und Ozeanien. Wenn unter "continent" nur "Australien" angegeben ist, dann landen fremde Artikel in der Staatenkategorie Kategorie:Fluss in Australien, wenn "Ozeanien" angegeben wurde wird keine Kontinantalkat gesetzt.

Liste kann gerne erweitert werden. --SteveK ?! 23:15, 29. Dez. 2012 (CET) +1--SteveK ?! 16:36, 30. Dez. 2012 (CET)

Hallo SteveK, wenn ich es recht verstehe, nimmst Du für Frankreich aus der IB die beiden ISO-Codes der Départements, übersetzt sie verbal in den Namen der Region, ergänzt diesen um die Konstante "Fluss" und die variablen Verbindungswörter in, im, in der, auf und erstellst somit automatisch die Kategorie:Fluss <Verbinder> <Region>. Diese kann je nach ISO für Quelle und Mündung unterschiedlich sein. Das Problem, wenn ein Fluss durch mehr als 2 Regionen verläuft (zB Loire) lässt sich so natürlich nicht automatisch behandeln. Meine bisherigen Tests haben gezeigt, dass Du das Problem mit den in Frankreich so variablen Verbindungswörtern super gelöst hast, mir ist jedenfalls noch nichts Gegenteiliges aufgefallen. Die Geschichte mit dem Burgund solltest Du lieber nicht aufrühren, da hats schon früher mächtige Diskussionen gegeben, wobei die Version Kategorie:Fluss in Burgund gewonnen hat. Grüße--Skipper69 (Diskussion) 19:09, 30. Dez. 2012 (CET)

Hi Skipper, ich habe nicht vor, die Kategorie "in Burgund" zu verschieben, sie taugt aber als Beispiel weil mein Sprachgefühl "im Burgund" sagt.

Es gibt eine Vorlage:ISO Kat die das auf einer ganzen Reihe von weiteren Vorlagen macht. Ich füttere die nur mit den ISO-Codes der Koordinatenangaben und schon hat man drei Kategorien richtig gesetzt. Klar ist, dass die Zwischenkategorien weiterhin von Hand gepflegt werden müssen. Speziell bei kürzeren Gewässern sparen wir uns eine Menge Arbeit und die Kontinental-Kategorie Kategorie:Fluss in Europa wir gleich mit gesetzt. --SteveK ?! 23:07, 30. Dez. 2012 (CET)

Wie arbeitet Vorlage:ISO Kat eigentlich in Oblast Tscheljabinsk, Oblast Orenburg, Westkasachstan und Atyrau (Gebiet)? Eigentlich darf dort keine automatische Kategorisierung nach Kontinent erfolgen, wegen der innereurasischen Grenze. Aber wie ich den Laden kenne … Olaf Studt (Diskussion) 21:51, 6. Jan. 2013 (CET)