Portal Diskussion:Gewässer/Archiv/2022

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

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

[[Portal Diskussion:Gewässer/Archiv/2022#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Portal_Diskussion:Gew%C3%A4sser/Archiv/2022#Thema_1

LD zur Kategorie:Meerenge nach Kontinent samt Unterkategorien (erl.)

 Info: LD unter Wikipedia:WikiProjekt Kategorien/Diskussionen/2022/Januar/4#Kategorie:Meerenge nach Kontinent --Didionline (Diskussion) 15:08, 4. Jan. 2022 (CET)

 Info: LAZ, damit hier erledigt --Didionline (Diskussion) 18:01, 5. Jan. 2022 (CET)

Rangordung von Nebenflüssen

Viele Zubringer der Donau münden nicht direkt in die Donau, sondern in die Donauau, so beispielsweise die Schmida (Fluss) oder der Göllersbach, die beide in das Krumpenwasser fließen, ein nach den Donauregulierungen im 18/19. Jahrhundert entstandenes Begleitgewässer. Auch der Weitenbach (Donau) und der Kamp (Fluss) münden seit dem Bau von Kraftwerken nicht mehr direkt in die Donau, sondern in Kanäle oder Seitenarme, der erst unterhalb der Kraftwerke in die Donau abfließen. Wie genau soll in den Artikeln die tatsächliche Situation wiedergegeben werden? Das hat dann Konsequenzen auf alle beteiligten Flüsse, deren Rangordung und Einkategorisierung sich ändert. --Kellerkatze (Diskussion) 14:11, 22. Mär. 2022 (CET)

Im Prinzip gibt es beide Möglichkeiten: Den alten Donauarm nur als Nebenarm der Donau auffassen und dann dessen Zuflüsse in der Box direkt in die Donau münden lassen; oder das Krumpenwasser als eigenständiges Gewässer auffassen, dann auch mit eigenem Flusssystem, wovon etwa das der Schmida udn des Göllerbachs wieder ein Unter-Zuflusssystem wäre. Ich traue mich micht zu sagen, was in diesem Falle besser wäre; die Entscheidung scheint mir am ehesten pragmatisch zu entscheiden zu sein, und da Du die Ecke im großen Donau-Flusssystem mit Gewässerartikeln befüllst, vielleicht am besten durch Dich.

In jedem Falle aber sollten die Abflussketten in den Artikelboxen und die getroffene Flusssystem-Gliederung stimmig zusammenpassen. Wie derzeit den Göllersbach in der Box direkt in die Donau münden lassen, die Schmida aber in das Krumpenwasser = Stockacher Arm, ist ebenfalls inkonsequent.

Was meint @Olaf Studt: ? --Silvicola ^Disk 18:43, 22. Mär. 2022 (CET)

Nicht Fisch - nicht Fleisch

Hallo zusammen. Ich bin da auf einen (möglichen) Wiederspruch in den Kategorien der Gewässer gestoßen. Feuchtgebiete und Gletscher werden einerseits in die Terrestrischen Geografien, andererseits in die Gewässersysteme einsortiert – was ja auch beides Sinn macht. Allerdings fehlt da irgendwo der Link von der Terrestrischen zur Aquatischen Geografien bei diesen Zwittern. Ich habe versucht mich über Benutzer:Didionline, der mich weiterführend auf die Portale hinwies, schlau zu machen. Bei den Kollegen in en und fr ist dies, wenn ich es richtig sah, auf Umwegen vorgesehen. Aus meiner Sicht wäre eine Einsortierung in Geografie und Gewässer bei diesen beiden Sinnhaft. Wenn ihr anderer Meinung seid aber einen Vorschlag habt der dieses Paradoxon auflöst würde ich mir das gerne anhören. Gruß --Peter in s (Diskussion) 14:59, 4. Jan. 2022 (CET)

@Peter in s: Ich hätte ja gerne von Anfang an Gletscher in Kategorie:Gewässer kategorisiert, aber offenbar ist die Auffassung, dass Gletscher gefrorene Gewässer sind, nur eine Minderheitenmeinung – und in die WP:Objektkategorie Kategorie:Gewässer kommt nur hinein, was Gewässer ist. -- Olaf Studt (Diskussion) 22:10, 25. Apr. 2022 (CEST)

Wahrscheinlich bestanden Bedenken wegen der vielen Skistöcke in den Gletschern; für viele sind diese deshalb sozusagen Skistock-Muren. Aber Moment, Murgänge sind ja auch in der Kategorie:Fließgewässer.

Wahrscheinlich ist das Beharren dann wohl ein Fall von „So haben wir einmal angefangen, weshalb sollten wir jetzt etwas an alten Festlegungen ändern?!“ --Silvicola ^Disk 22:30, 25. Apr. 2022 (CEST)

Die WikiCon 2022 in Stralsund steht vor der Tür!

Neben den allgemeinen Wikipedia-Themen liegt dieses Jahr der Fokus auf dem Themenfeld Umwelt, Natur, Nachhaltigkeit und Maritimes. Euer Portal ist geradezu prädestiniert, um mit einem Beitrag dabei zu sein! Vielleicht zu konkreten Aspekten oder zur generellen Darstellung eurer Arbeit? Auch Externe mit einem thematischen Bezug sind eingeladen, an der WikiCon mitzuwirken. Programmpunkte können bis zum 14. August eingereicht werden. Alle Infos findet ihr hier: Wikipedia:WikiCon_2022 Danke für's Weitersagen und liebe Grüße von eurem Orga-Team – DomenikaBo – Aspie|Disk💬|WikiMUC|🎔 11:57, 4. Aug. 2022 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Lupe (Diskussion) 14:13, 18. Okt. 2022 (CEST)

GKZ-Änderung

@Bungert55, Elop, Olaf Studt, SteveK:

Benutzer:PaulSch hat jüngst damit begonnen, in den Infoboxen von Artikeln über bayerisch-fränkische Flüsse verlängerte GKZs auf ungerade Endzifferfolge einzutragen, offenbar um anders benannte höhere Flussabschnitte auch per GKZ von den anders heißenden Unterläufen zu scheiden. Meines Erachtens sind GKZs auf ungerade Endziffer (außer bei den paar Strömen mit nur einziffriger GKZ) immer nur Teileinzugsgebiets-, aber nicht Gewässerkennziffern. Das mag man vielleicht auch anders sehen. Aber wenn man diese „Umcodierung“ nur in einem kleinen Revier betreibt, entsteht in jedem Falle eine Inkonsistenz im System zwischen hie und da. Das müsste also hier diskutiert werden, denn selbst bei Einigung auf die Zulassung ungerader Endziffern wird das konsequente Umstellen im Bestand kein Einzelner wuppen wollen.

Nach meiner Erfahrung schert sich das GKZ-System aber ohnehin nicht um Namensabschnitte, sondern will auf Gesamtstränge und deren Zerlegung nach physisch-geographischen Kriterien hinaus. Es kann also (onomastische) Gewässer mit mehreren GKZs geben wie auch umgekehrt Namenabschnitte, die nur einen Teilabschnitt einer GKZ-„Strecke“ (auch mit ungeradziffrigen Ende) umfassen. --Silvicola ^Disk 16:08, 2. Aug. 2022 (CEST)

Hier (Weißmain = 2411) könnte das durchaus Sinn machen, da genau mit dem Rotmain (2412) dieser Name aufgegeben wird. Auch die Rednitz ist nur ein Abschnittsname und verfällt exakt an dem Punkt, wo die Regnitz beginnt.

Wo ist denn das Problem?

Nur ein Bruchteil unserer Flußartikel ist auf namentliche Abschnitte beschränkt.

Solange die Weser die 4 behält und nicht zu "43-49" umetikettiert wird, ist das doch kein frei von großen Tücken. --Elop 16:36, 2. Aug. 2022 (CEST)

Hier die Vorgeschichte: Bei der Ilz (Donau) schien es mir sinnvoll, die GEWKZ 178 durch 1787 und 1789 zu ersetzen, s. Diskussion:Ilz (Donau)#Gewässerkennzahl. Silvicola hat mich aber überzeugt, dass ich da Gebiets- und Gewässerkennzahlen durcheinandergebracht habe. Ich habe mir daraufhin die LAWA-Richtlinie genauer angeschaut und bin wie Silvicola zu dem Schluss gelangt, dass GEWKZs, abgesehen von einigen wenige einstelligen, stets gerade sind. Allerdings steht die Werra mit 41 in der Übersichtskarte der LAWA-Richtlinie (und unwidersprochen im Artikel). Meine Folgerung: Die LAWA-Richtlinie ist eine Richtlinie und kein streng eingehaltenes Gesetz. Dann habe ich in der bayerischen Gesamttabelle nach weiteren Ausnahmen gesucht und bin an 13 Stellen fündig geworden (drei größere und zehn kleinere). Dabei handelt es sich meist (immer?) um den Zusammenfluss zweier Gewässer, wobei beide Namen aufgegeben werden (Werra + Fulda --> Weser, Weißer Main + Roter Main --> Main, Großache + Prien --> Alz, …). Auch bei der Breg liegt eine Ausnahme dieses Typs vor, s. Diskussion:Breg#Gewässerkennzahl. Dort hat sich Silvicola wieder zu Wort gemeldet. Auf meine ausführlichere Argumentation, die ich am 18. Juli mit Konnte ich dich überzeugen? abgeschlossen hatte, hat er sich aber nicht mehr gemeldet, was ich als stillschweigende Zustimmung verstanden habe. Ich habe jetzt die mir bekannten ungeraden GEWKZs in die jeweiligen Artikel eingetragen.

Übrigens steht die 2411 für den Weißen Main in der entsprechenden LfU-Tabelle gleich auf der ersten Seite in der Spalte Gewässerkennzahl. Meiner Meinung nach ist die Sache damit geklärt. --PaulSch (Diskussion) 18:57, 2. Aug. 2022 (CEST)

Entschuldige, ich hatte die Breg-Sache vergessen. Der Nachtschlaf ist bei dieser Hitze vor allem unterm Mansard-Dach nicht sehr gut …

Da es ein grundsätzliches Problem ist, wollte ich, Deine weiteren Überarbeitungen bemerkend, es hier vor größerem Publikum ansprechen.

Zu den Praktiken der Ämter gebe ich zu bedenken, dass man dort manchmal nicht sehr grundsätzlich und manchmal sogar nachlässig vorgeht. Das Motiv, den Oberlauf gegenüber dem Unterlauf auch „GKZ-technisch“ zu trennen, waltet dort natürlich auch.

--Silvicola ^Disk 19:58, 2. Aug. 2022 (CEST)

Man lernt einfach nicht aus bei dem Thema. Ich hatte auch gedacht, dass Gewässer selbst gerade Nummern haben und die kleinste gerade Nummer im Strang der hydrologische Strang des Gewässers ist. Dass das die Behörden jetzt in einigen Fällen anders handhaben, ist mir neu. Ist aber ein gangbarer Weg, solange da nicht Überhand nimmt. ----SteveK ?! 21:24, 2. Aug. 2022 (CEST)

Das ändert ja alles nichts an den Konventionen! Und ich halte "Weißmain = 2411" nicht deshalb für sinnvoll, weil. "das Amt" das so sieht, sondern weil es allem entspricht, was im Namen gemeint ist.

Flüsse haben ja weiterhin sinnvollerweise gerade Endziffern - nur eben Abschnittsnamen nicht! --Elop 22:36, 2. Aug. 2022 (CEST)

Naja, meine Erkenntnis ist, dass die GKZ des Mains auch gleich gesetzt werden kann mit der des Einzugsgebietes. Und das Gebiet 24 ist dann die Summe der Gebiete 24x. Deswegen kann man als GKZ für den Weißen Main als GKZ seine Gebietskennzahl nehmen, auch wenn die jetzt ungerade ist. Die geraden Nummer sind in der Regel die Gebiete eines Zuflusses mit eigener Stationierung. Bein Main sollte die Stationierungslinie mit GKZ=24 eigentlich über den Weißen Main führen, da der Rote Main eine gerade Nummer und damit eine eigene Stationierung hat. Soweit mein Halbwissen. ----SteveK ?! 19:21, 3. Aug. 2022 (CEST)

Das sind ja rein praktische Konventionen. Man hat einen der beiden Maine als Zähl-Quellfluß ausgesucht, um einen Längenzähler für den Gesamtmain zu haben. Das mit geraden und ungeraden Nummern ist ja auch nicht zwangsläufig, sondern halt praktisch.

"Main bis Regnitz" kann auch durch eine ungerade Nummer ausgewiesen werden, hat aber keinen Namen und keinen Artikel. In einer Tabelle allerdings u. U. ein interessanter Kennwert. In Ruhr#Tabelle der wichtigsten Nebenflüsse kann man den Abschnitt oberhalb je mit z. B. der Neger oder der Lenne vergleichen. Nur fließt dem Namen nach nicht die Hille in die durch die Neger gespeiste Namenlose, welche dann in die Lenne mündet. --Elop 09:01, 4. Aug. 2022 (CEST)

Der "Main bis Regniz" heißt Abschnittsweise "Weißer Main" und "Main". Wenn man das Gebiet meint muss man für einen Gewässerabschnitt eben eine genauere Bezeichnung wählen "Main von Quelle bis Regnitz". Beim gesamten Main braucht man dass eben nicht. Was soll's, ist so und wir können das nicht ändern. Die Gewässerstationierung Bayern spukt auch die 2411 als GKZ für den "Weißen Main" aus, weshalb man das ja auch im Artikel so lassen kann. ----SteveK ?! 11:59, 4. Aug. 2022 (CEST)

Neuer aufgetretener Fehler in Vorlage:Infobox Fluss

Keinfluss
Daten
Länge	Was aus „5+6+7+8“ wird:  26 km
Einzugsgebiet	Was aus „1+2+3+4“ wird:  10 km²

Eben bemerkt: Die Infobox berechnet offenbar den Ausdruck nicht mehr, wenn in den Parametern LÄNGE und EINZUGSGEBIET statt eines Wertes ein Ausdruck steht. Keine Ahnung wieso, weder an der Infobox noch an den relevanten Unterseiten wurde jüngst herumgeschraubt. Das hatte alles bisher tadellos funktioniert. Vermutlich liegt das Problem also tiefer und auch andere rechnende Infoboxen sind betroffen.

Testeinbindung rechts, Beispiele aus dem Bestand:

• Wieslauf fürs EZG
• Rötelbach (Jagst) fürs EZG
• Ziegelbach (Jagst) für die Länge

--Silvicola ^Disk 05:08, 5. Sep. 2022 (CEST)

Naja, die Doku der Vorlage und ihre Programmierung fordern, dss der Parameterwert eine Zahl („Nummer“) sein soll.

• Das sind solche arithmetischen Ausdrücke erstmal nicht.
• Der WP:HW/Vorlagenmeister beanstandet diese Werte schon seit einem Dutzend Jahren und lässt die Bearbeitung nicht zu.
• Der VisualEditor wird irgendwann in ein paar Jahren die Abspeicherung solcher Werte verweigern.
• Da steht ja bei beiden ganz brav und exakt: „und mit Dezimalpunkt vor dem gebrochenen Anteil“

Kann ich gerne entsprechend lösen, aber das muss dann auch sauber programmiert und dokumentiert sein.

• Die erforderliche Programmierung dafür liegt bereits auf WP:BETA und kann in den nächsten Tagen hier aktiviert werden.
• Das braucht aber einen gewissen Vorlauf, weil vor dem Transfer von BETA nach hier produktiv mit einer halben Million Einbindungen über vorherige Erprobung die bestimmungsgemäße Verwendung an Testfällen durchgespielt werden muss. Die sind noch nicht da.

Es muss in der Doku als „Zeile“ deklariert werden, und es muss präzise beschrieben werden, was für Zahlen in welcher Formatierung („Dezimalpunkt vor“) oder ersatzweise auch arithmetische Ausdrücke erlaubt sind.

• Und in der Programmierung kann dann eine Variante gewählt werden, die genau diese Bedingung zulassen wird.

Für die nächsten Tage kann als Zwischenlösung versucht werden, die optische Fehlermeldung auszukommentieren.

VG --PerfektesChaos 08:05, 5. Sep. 2022 (CEST)

1. Na ja, vorher hat es klaglos funktioniert, jetzt nicht mehr. Ich hoffe, es gibt nicht noch mehr solcher „Verbesserungen“.

2. Was ist denn eigentlich wo genau verändert worden, das jetzt die Fehlermeldung auslöst?

3. Wenn ich das richtig sehe, muss doch der Parameterwert nur als Parameter in ein #expr geschoben werden und fertig. Und der Ausdruck ist zulässig genau dann, wenn #expr ihn frisst, Punkt. Bei einem so simplen Datentyp spricht m.E. nichts gegen Specification by Implementation.

4. Gibt es bei den Parametertypen für Vorlagen nicht einen Ausdruck, damit auch deklarativ alles proper ist, wenn das denn so wichtig ist?

5. Soll man wirklich etwas abschaffen, was sinnvoll ist und funktioniert, nur weil irgend so eine funktionsreduzierte Krücke wie der Vorlagenmeister nicht damit klarkommt? Ich sage ja nichts gegen Verbesserungen, aber Verschlechterungen sind doch wenig sinnvoll. Zumal auch durch die hohle Gasse Vorlagenmeister nicht mehr an fleißigen Flusspferden ankommen werden. Ich habe hierzu inzwischen bald 15 Jahre Erfahrung: Es gibt immer mal wieder einen Hereinschnupperer, aber kaum einer bleibt dabei, nachdem er die drei Bäche um seinen Kirchturm (unzureichend und so dass man heftig nachbessern muss) behandelt hat. Wieso dann die Arbeit der bestehenden Truppe schwerer machen?

6. Das Grundproblem ist, dass man oft Einzugsgebiete (und seltener Längen) von Fließgewässern nicht fertig ausgerechnet in den amtlichen Quellen findet, sondern diese aus Teileinzugsgebietswerten aufsummieren muss, oft auch noch rekursiv und mit Werten, die sich um zwei bis drei Größenordnungen unterscheiden können. Man übersieht also bei zu grob gewähltem Maßstab auf den entsprechenden Karten die kleinen Brocken recht leicht. Einmal erfasst, steht aber wenigstens die Zerlegungsstruktur schon mal (fast) felsenfest. Zugleich werden die Flächenwerte (immer noch recht oft) von Zeit zu Zeit deutlich verändert. Man muss also (noch) kontrollieren. Trüge man aber nur den Endwert der Addition ein, müsste man zur Kontrolle auf Verdacht wieder den Zerlegungsbaum neu aufbauen, dann neu addieren und ganz am Ende die Summe alt/neu vergleichen, eine Umständlichkeit, zu der natürlich niemand Lust hat. Beim Blick auf den Ausdruck, aus dem die Summe vom Parser erzeugt wird, erkennt man aber Veränderungen auf einen kurzen Blick. Fügte man andererseits ersatzweise die Zerlegung irgendwo zur Dokumentation in einem XML-Kommentar in den Artikel ein, müsste man mit Schlaubergern rechnen, die das wieder rauslöschen, „weil der Wert doch schon in der Infobox steht“. Ich kenne meine Verschlimmbesserer! Der „Schutz“ durch Eintrag des Ausdrucks in den Parameter ist deshalb recht hilfreich. Und von Mitarbeitern, die selbst diese primitive Ausdruckssyntax (iterierte Summe) nicht verstehen, ist ohnehin nichts zu erhoffen.

Gruß --Silvicola ^Disk 08:50, 5. Sep. 2022 (CEST)

7. Ja, stelle auf alle Fälle die Fehlermeldung ab, damit ich nicht unbedarften „Verbesserern“ vulgo Löschern hinterhereditieren muss. --Silvicola ^Disk 08:55, 5. Sep. 2022 (CEST)

Sag Bescheid, wenn die Sache steht. Die zulässige Syntax in der Vorlagendokumentation kann ich dann menschenverständlich spezifizieren. --Silvicola ^Disk 08:57, 5. Sep. 2022 (CEST)

@PerfektesChaos:

Scheint wieder zu funktionieren, oder täusche ich mich? Trage Du in die Zeile der Infobox-Vorlage zu den jeweiligen Parametern den richtigen Datentyp ein, dann werde ich den Erklärungs-Sermon hinzufügen.

Eben ist mir noch eingefallen, das die/weitere EZGs und Längen teilweise auch mit den Untervorlagen Vorlage:Infobox Fluss/EZG und Vorlage:Infobox Fluss/Länge eingebettet werden, für diese gilt dann Entsprechendes. --Silvicola ^Disk 08:01, 6. Sep. 2022 (CEST)

Nu stelln wa uns ma janz domm. Wat isn dat, eine Zaaaal?

• Fängt mit möglichem Plus- oder Minuszeichen (auch typografisch) an, dann kommen meistens Ziffern, aber nicht notwendig US-Amerikanisch kleiner eins, bei nicht-ganzen Zahlen ein Dezimaltrennzeichen und dahinter weitere Ziffern, die Ziffern ggf. gruppiert durch Gliederungszeichen (Tausender). Alternativ das Exponentialformat.

Der Wizard und unser guter alter Vorlagenmeister beanstanden Eingaben, die nicht der (sogar computergerechten) Syntax entsprechen, bereits heute, und die Formulare in VisualEditor und dem entsprechenden „Wikitexteditor 2017“ werden irgendwann folgen.

• Krankt momentan auch noch daran, dass es keine Spezifikation für die Unterscheidung in ganze Zahlen, Zahlen für Berechnungs-Syntax, lokales (deutschsprachiges) Format gibt.
• Sind insgesamt vier Systeme, die interaktive Formulare zur Eingabe von Vorlagen-Werten anbieten. Newbies arbeiten nur damit. Ist nicht mehr so wie in den 2000ern mit dem Quelltext.
• 1,234.567
  • lesen US-Amerikaner als thousand two hundred etc. point five etc.
  • Deutschsprachige hingegen als Eins Komma Zwo Drei usw. mit zulässiger Zifferngruppierung der Nachkommastellen.

Auf jeden Fall ist ein arithmetischer Ausdruck keine Zahl.

• Darüber hatte man sich vor einem Dutzend Jahren noch keinen Kopf gemacht, aber bei der Vielzahl an Vorlagen und einzutragenden Werten und Berechnungen bedarf es expliziter Syntax und Gültigkeitsregeln.

Ich habe die entsprechende Stelle interimistisch gerollbacked.

• Bereits programmiert sind die Mittel, um im Bestand die einschlägigen Vorlagen zu identifizieren und auf die Umstellung vorzubereiten.

Die überkommene Programmierung bot wesentlich weniger Möglichkeiten als die Neufassung, und sie ist auch weniger performant.

• Da stehen fünf Parserfunktionen drin.
• Besonders übel ist der historische Hack, einfach mal eine Dummy-Berechnung zu versuchen und wenn die abstürzt könne es keine „Zahl“ gewesen sein. Das arbeitet mit dem Effekt, dass dann eine Fehlermeldung enthalten ist, und deshalb wird das Berechnungsergebnis textlich durchsucht ob darin <span> oder <div> enthalten wäre und mit class="error" (und auch nur mit diesen Anführungszeichen und nicht mit den genauso zulässigen ' ) versehen wäre. Das ist Bastelei aus der Kindergartenzeit der Wiki-Software, aber keine robuste und zukunftsfähige Lösung, und effizient auch nicht gerade. Es ist (bis 2013 nicht anders verfügbar gewesenes) Schulkind-Gefrickel, mal was auszuprobieren und wenn das einen Crash gibt dann halt nicht. Sauber würde jeder Absturz als ein zu beseitigender Fehler angesehen werden und nicht als einkalkulierter Normalzustand.

Haben Flüsse eigentlich immer eine Länge größer gleich Null?

VG --PerfektesChaos 17:57, 7. Sep. 2022 (CEST)

@ Länge ≥ 0: Nach meinem gegenwärtigen Eindruck ja. Aber wer weiß&nbsp…

Wir wäre es denn mit einem weiteren Datentyp (numerischer) Ausdruck? Den kann man sicher noch öfter brauchen.

Die Infobox Fluss kann gewiss noch verbessert werden.

• Zum Beispiel werden derzeit Längen ≥ 1 km auf eine Kilometer-Nachkommastelle gerundet, während alle Längen darunter in Metern (!) angegeben werden. Eine heftige „Rundungs-Unstetigkeit“! Da will aber keiner von den Infobox-Betreuern ran. Vermutlich wäre ein weiterer Parameter nötig, um die gewünschte relative Genauigkeit steuern zu können.
• Jede zusätzliche Angabe eines alternativen Ursprungs (z.B. bei Gewässern mit wg. andersnamigen Oberlaufs vom Namenslauf verschiedenem Gesamtlauf) macht Formatierungsgefrickel nötig. Vgl. etwa die Ursprungsangaben von Dahenbach. Will man im Nachhinein eine andere „Hauptquelle“ erkiesen, muss man erst mal wegen der asyymmetrischen Spezifikation wieder umschrauben.
• Sinnvollerweise müsste wohl eine Untervorlage Quelle / Mündung definiert werden, jeweils mit Angabe der Koordinate, der verbalen Lokalisierung, der Höhe, von welcher Untervorlage man dann auch mehrere Einbindungen in eine Wiederholungsfeld QUELLEN einstellen könnte. Dann könnte man fertige „Quellpakete“ einfach tauschen ohne umzufrickeln. Aber wie bekommt man dann die Angaben zur Quellhöhe und Mündungshöhe aus den Untervorlagen in den Hauptvorlagenparameter für das absolute Gefälle? Diese Textersatz-Programmierung verhindert brauchbare Datenflüsse wie bei einer Attributgrammatik, weil man nichts aus einer Untervorlage abfragen kann, sondern nur diese in toto irgendwo einkleben. Textersatz ist ein vermurkstes Programmierungmodell.

--Silvicola ^Disk 20:18, 7. Sep. 2022 (CEST)

Bierbachteich

Hallo, bitte bei oben genannten Artikel vorbei schauen und den Abfluss richtig verlinken. Ich bin der Meinung, das es Bierbach (Gersprenz) sein müsste. Als alternative steht auch Bierbach (Rodauer Bach) im Raum --Vielen Dank und viele Grüße Benutzer:Woelle_ffm (Diskussion) 16:54, 15. Sep. 2022 (CEST)

Wenn LAGIS nicht täuscht, stimmt das schon so. Abflusskette eben ergänzt. Fraglich ist eher, ob nicht der Bierbach auch dem Teich zuläuft, denn einen Oberlauf im Wald vor dem Teich scheint es zu geben. Es gibt auch einen Bierbach (Gersprenz), der gar nicht mal weit weg liegt und der direkt in die Gersprenz mündet, siehe Bierbach (Begriffsklärung). --Silvicola ^Disk 22:01, 15. Sep. 2022 (CEST)

Orientierungsrätsel für Gewässerfreunde

Hier gibt es eine grobe Gewässerkarte von ganz Deutschland, ohne Städte, ohne Namen, gerade mal mit einer Färbung nach den großen Einzugsgebieten (Maas, Rhein, Ems, Weser usw.). Wer ist wer? --Silvicola ^Disk 18:29, 17. Okt. 2022 (CEST)

Alles abseits der Küsten ist supereinfach. Die Küstenflüsschen richtig zu erkennen hingegen superschwer!--Plantek (Diskussion) 14:36, 29. Okt. 2022 (CEST)

Das hängt vielleicht von der Region ab, in der man gewöhnlich arbeitet. Vielleicht sind die Friesen an der Küste besser. In „meinem“ Revier erkenne ich sogar auf Anhieb, wo Oberläufe weggelassen wurden. --Silvicola ^Disk 16:26, 29. Okt. 2022 (CEST)