Portal Diskussion:Gewässer/Archiv/2019

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/2019#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Einträge modellierter (errechneter) Werte in den Parameter PEGEL1 der Infobox Fluss

Auf Vorschlag von Silvicola diese Diskussion von meiner Seite nach hier verlegt.--Anarabert (Diskussion) 21:19, 7. Jan. 2019 (CET) -================================================================================================================================== Meines Wissens sind die Werte von Gewässerknoten alle per Modell („HQ-Regionalisierung“) errechnet, gehen also nicht auf wirkliche Messungen zurück. Die echten Messpegel sind alle in der Übersichtskarte von LUBW-AB sichtbar, es sind landesweit recht wenige, allenfalls etwa 200. Im Bereich der mittleren Bühler gibt es m.W. nur einen in Bühlertann an der Bühlerbrücke, in Obersontheim gab es vor vielen Jahren mal so eine Messlatte an einem Steg über das Wehr für die Herrenmühle (Obersontheim) kurz vor der Bühlerbrücke, also etwas weiter abwärts als nun eingezeichnet. (Vielleicht, wenn ich irgendwann mal wieder dort vorbeikomme und der angebliche Pegel nicht auf Privatgelände steht, kann ich schauen.) Selbst der einzige Pegel an einem Nebenfluss, nämlich am einzigen grö0eren Zufluss Fischach (Bühler) bei Kottspiel scheint wegen Unzuverlässigkeit aufgehoben zu sein.

Die Modellrechnung dürfte so vorgehen: Je nach Meereshöhe für die Teileinzugsgebiete, Windschatten durch Berge usw. setzt man variable Niederschläge an, je nach Bodenbeschaffenheit (Karst usw.) nimmt man verschiedene Versickerung an, je nach Bewaldung und Bodennutzung unterschiedliche Verdunstung. Und dann bricht man die gemessenen Pegelwerte für größere Teileinzugsgebiet entsprechend auf die Teileinzugsgebiete herunter. Also sind das in dem Fall nur künstlich errechnete Werte. --Silvicola ^Disk 09:54, 7. Jan. 2019 (CET)

Die genauere Vorgehensweise findet man hier.

Hier eine Übersicht über die tatsächlich vorhandenen Pegel in BW.

Man kann ja in der Anmerkung noch Modellierter Abfluss setzen, damit es nicht zu Mißverständnissen kommt. Die Werte für die kleineren Gewässer in der Schweiz und in Hessen werden ja auch nur errechnet.--Anarabert (Diskussion) 10:18, 7. Jan. 2019 (CET)

So, die haben jetzt alle den Hinweis bekommen, das es sich um keine gemessenen Werte, sondern um modellierte Werte handelt.--Anarabert (Diskussion) 11:24, 7. Jan. 2019 (CET)

Ich würde trotzdem vorschlagen, solches Vorgehen bei modellierten Anflüssen erst mal auf Portal Diskussion:Gewässer vorzustellen, ehe Du im größeren Stile Ergänzungen vornimmst, die am Ende dann vielleicht doch wieder herausfliegen könnten. --Silvicola ^Disk 16:10, 7. Jan. 2019 (CET)

Denn vielleicht ist ja auch eine Ergänzung von PEGEL1 usw. in der Infobox sinnvoller („Modellschalter“ o.ä.), damit die ganz andere Datenquelle nicht erst in der Fußnote sichtbar wird, die ohnehin nur wenige lesen werden. --Silvicola ^Disk 16:16, 7. Jan. 2019 (CET)

-=============================================================================================================================== Ich habe da überhaupt keine Bedenken, denn schließlich wurden schon jahrelang hunderte modellierte Werte bei hessischen und Schweizer Fließgewässer eingetragen, ohne irgendwelche Beschwerden.--Anarabert (Diskussion) 21:19, 7. Jan. 2019 (CET)

Nachtrag: In Fließgewässer von Elsaß und von Lothringen übrigens auch.--Anarabert (Diskussion) 21:35, 7. Jan. 2019 (CET)

Ich halte die Werte zu nennen selbst für sinnvoll, allerdings auch den Zusatz, dass die Werte modelbasiert sind und nicht direkte Messwerte. Am besten wird das in der Infobox selbst angezeigt, um keine falschen stillschweigenden Annahmen beim Leser zu begünstigen. --Silvicola ^Disk 22:56, 7. Jan. 2019 (CET)

Für mich sind die Abflusswerte an der Mündung, egal ob nun modelliert oder gemessen, sehr viel interessanter als die tatsächlich gemessenen Werte eines Pegels irgendwo im Flussverlauf.--Anarabert (Diskussion) 23:12, 7. Jan. 2019 (CET)

Dicht an der Mündung wirst Du aus technischem Grund wohl kaum einen Messpegel für den Zufluss finden. Der Messpegel muss höher am Lauf sitzen, sonst führte jedes Hochwasser im Vorfluter durch Rückstau im Zufluss zu höheren Pegelwerten, selbst wenn der Zufluss selbst gar kein Hochwasser hat.

Es stimmt allerdings leider, dass man oft einen Pegel nur sehr weit oben am Lauf hat, so dass der für den Abfluss aus dem gesamten EZG alles andere als repräsentativ ist. --Silvicola ^Disk 01:54, 8. Jan. 2019 (CET)

Das stärkste Argument für die Verwendung gerechneter Werte ist für mich, dass das Ergebnis Mündungspunkte betrifft (betreffen sollte); die anderen Daten wie Länge, Einzugsgebiet oder Höhenspanne beziehen sich ja auch darauf. Und diese Korrespondenzfähigkeit der Mündungs-Q-Werte macht erst den Reiz und den Infogehalt der Infobox aus. Die reinen Pegelwerte hängen nämlich irgendwie beziehungsarm in der Luft, weil sie sich nur auf zufällige oberstromige Teilmengen der Gewässerdaten beziehen können.

Es kommt ein weiterer Aspekt hinzu, der von regional unterschiedlicher, mitunter aber essenzieller Bedeutung sein kann: Besonders bei größeren Flüssen ist die Ableitung von Pegel-Abflusswerten fehlerträchtig. Sogar der für die Steuerung der niederländischen Deltawerke so wichtige Referenzwert des Pegels Lobith am Rhein wurde nach der Überprüfung mittels flussgebietsweiter Korrekturrechnungen von einem MQ von 2200 m³/s auf 2300 m³/s geändert. Das oberhalb gelegene Emmerich liefert dagegen etwas zu hohe Q-Werte. Ähnliches zeigt sich bereits nach hausbackener eigener Überprüfung auch an Pegeln der Weser und Donau. Manche Pegel haben auch erst sehr kurze Messzeiträume, sind also vorerst nur eingeschränkt repräsentativ. Gerechnete Werte können also „korrekter“ als die Originalwerte sein, das ist also kein prinzipieller Makel. Es sollte allerdings, wie in WP ja meistens auch der Fall, die Quelle angegeben werden oder der Berechnungsweg. Grundsätzlich sollte für das unterstromige Restgebiet nicht extrapoliert werden, sondern, da nicht gebietsfremd, aus dem betreffenden Zwischeneinzugsgebiet interpolierend ermittelt werden. Die verbleibenden Unsicherheiten sind marginal gegenüber den Fehlern aus unreflektierter Übertragung von Pegelwerten weit oberhalb der Mündung auf den gesamten Fluss, wie leider sehr oft netzweit und selbst in wissenschaftlichen Arbeiten festzustellen ist. Ein Hinweis zusätzlich zur Referenzangabe wie (modelliert) oder (errechnet) kann also sein, wirklich dringlich erscheint es mir nicht zu sein. -- WWasser (Diskussion) 09:29, 9. Jan. 2019 (CET)

Jeder dort angegebene Wert ist eine Interpretation von Messwerten, mit Ausnahme einer direkt angegebenen Pegelmessung zu einem konkreten Zeitpunkt. Für die Interpretation einer Zeitreihe müsste ich auch wissen, wie lange dort gemessen worden ist. Ein aussagekräftiger Wert wäre ggf. der Maximal- oder der Minimalpegel, alles andere ist eben aus irgendwelchen Eingangsdaten errechnet. Vielleicht schreibt ja mal jemand den Artikel Niedrschlags-Abfluss-Modell. Bis dahin reicht den meisten Lesern wohl der Zahlenwert. Denjenigen mit tiefergehendem Interesse muss eben, rückverfolgbar, angegeben werden, wo er jeweils herkommt.--Meloe (Diskussion) 10:04, 9. Jan. 2019 (CET)

Rödelbach Bifurkation

Könnte mal wer über den Rödelbach schauen? Die Infobox versagt beid er der Bifurkation. Das ist ncith verwwunderlich,a ber möglicherweise ja lösbar.--Sarkana _{frag den ℑ Vampir}^{bewerte mich} 23:56, 12. Jan. 2019 (CET)

Du denkst an die Abflussfolge usw.? Man könnte eine Nebenbox einstellen und dann jede der beiden Boxen mit den Daten eines der Äste befüllen. Die Kategorisierung nach der Hauptbox könnte man

• entweder abschalten und im Artikel händisch für beide Äste kategorisieruen
• oder für beide Äste Weiterleitungen dorthin einrichten und stattdessen diese kategorisieren.

Beides ist natürlich umständlich. --Silvicola ^Disk 05:24, 13. Jan. 2019 (CET)

Ja die Abflußfolge ist ja jetzt nur die des kürzeren Arms, der dafür den längsten Abfluß hat. Das gilt ja auch für den Mündung, ist bislang nur eine drin. Die Kategorisierung hab ich erst mal händisch drin, daß ist das geringste Problem. Und Nebenbox - also für beide Arme nochmal ne extra Box erstellen? Das wäre ne Variante.--Sarkana _{frag den ℑ Vampir}^{bewerte mich} 15:32, 13. Jan. 2019 (CET)

Mhm, nee. Da spielt die Infobox nicht mit. Mehr Infoboxen gehen, aber die zweite gibt Fehlermeldungen, weil die Koordinaten nicht mehrfach drin sein dürfen. Auf Pseudobifurkationen ist die Box eindeutig nicht vorbereitet. Irgendwie is das doof.--Sarkana _{frag den ℑ Vampir}^{bewerte mich} 15:56, 13. Jan. 2019 (CET)

Dass es nur im einen Behelf geht, ist schon klar, weil in ein „Loch“ (rechts oben) nun einmal nicht zwei Tauben passen.

Wenn Du die Koordinaten in den Nebenboxen haben willst, aber nicht einer willkürlich das Prävenire rechts oben geben, gäbe es noch eine andere Möglichkeit: DU trägst in die virgesehenen Parameter MÜNDUNG_LAT_GRAD und MÜNDUNG_LONG_GRAD gar nichts ein und befüllst stattdessen unter Verwending der Vorlage:Coorcinate den Parameter MÜNDUNG händisch zusätzlich mit der konventionskonform formatierten Koordinate. Ich mache das zuweilen für eine zusätzliche QUellkoordinate (wenn etwa ein Bach einen anders heoßenden Oberlauf hat und ich dann sowohl Länge-mit als auch Länge-ohne in der Box anzeigen lassen will, dann gehören für meinen Geschmack beide korrespondierenden Ursprünge (Quelle des Oberlaufs und Beginn des NAmenslaufs) in die Box. Ich sehe nicht, wieso der Trick für nur eine Mündung nicht auch funktionieren sollte; die Box analysiert schließlich nicht alle Einträge in allen Parametern, sondern nimmt einfach MÜNDUNG_LAT_GRAD und MÜNDUNG_LONG_GRAD für rechts oben, vielleicht wenn das fehlt stattdessen die QUellkoordinaten.

Beispiel dazu hier: Gründelbach (Neckar), wie gesagt im Feld QUELLE.

Man trüge also etwa Folgendes (Werte einfach erst mal aus dem obigen Beispiel übernommen, also noch nicht für Dein Mündel passend) in den Parameter MÜNDUNG ein:

MÜNDUNG= Erstzweigmündungsort Blabla<br /> <small>{{Coordinate|NS=48/54/55.87/N|EW=09/09/44.22/E|elevation=240|region=DE-BW|type=waterbody|name= Erstzweigmündungsort Blabla|text=DMS}}</small><br />

Denkbar, aber vielleicht nicht sinnvoll, ist dann auch, die Informationen zu beiden Mündungsästen in eine Box „manuell einzufalten“. Wie man die Wartungskategorie abschaltet (denn für die Box sieht es ja so aus, als ob gar keine Koordinate geliefert wurde), findet man entweder in deren Beschreibung oder Du solltest auf der dortigen Diskussionsseite die „Boxenpfleger“ ansprechen, die hierzu besser Bescheid wissen als ich. Dem ArtiKel kann man dann wie bei anderen Artikeltypen üblich manuell am Quelltextende eine Koordinate für rechts oben geben, falls das denn sinnvoll wäre.

Gruß --Silvicola ^Disk 11:23, 14. Jan. 2019 (CET)

Vorlage:Infobox See ist veraltet

Diese inzwischen fast 13 Jahre alte Box weist einige Eigenschaften auf, welche nicht mehr dem heute üblichen Erscheinungsbild entsprechen. Es gibt Parameter, welche man als überflüssig betrachten kann und solche, welche nicht benötigt werden, um eine optimale Darstellung zu erhalten (zurzeit 6662 Einbindungen im ANR):

Überflüssige Parameter

Parameter, welche nicht von mind. 10 % der Einbindungen genutzt werden, sind in der Regel überflüssig, bei weniger als einem Prozent ist das gewiss der Fall.

• Die Parameter BILD5 mit BILD5-BESCHREIBUNG, BILD4 mit BILD4-BESCHREIBUNG und BILD3, BILD5-BESCHREIBUNG werden trotz ihrer mehr als zehnjährigen Existenz de facto nicht oder fast gar nicht benutzt (unter einem Prozent). Sie fügen Bilder unten an die Box an und ziehen diese bei Nutzung extrem in die Länge. Eine Infobox sollte aber nicht unnötig in die Länge gezogen werden. Außerdem haben wir inzwischen das Gallery-Tag, mit dem wir die Seiten viel besser gestalten können. Ich plädiere daher dafür, diese Parameter zu entfernen.
• Der Parameter MAPTYPE wird nicht genutzt. Die Reliefkarte ist auch völlig ausreichend.

Zweifelhafte Parameter

• Der Parameter KEINGEOARTIKEL ist nicht erklärt und wird nur bei ca. 50 von 6662 Seiten verwendet. Dürfte wohl auch entbehrlich sein. Da gibt es gewiss bessere Lösungen.
• Der Parameter PH-WERT wird viel verwendet, aber er bezieht sich auf eine sich im Laufe der Zeit ändernde Eigenschaft, Hier bedarf es einer regelmäßigen Pflege.

Geo-Hack

Die Parameter BREITENGRAD und LÄNGENGRAD sollten Pflichtparameter werden.

Positionskarte

Die Einbindung sieht sehr unübersichtlich aus. Wäre ggf. zu vereinfachen. Eine einfache Lagekarte kann auch anders integriert werden.

Liste

Parameternutzung

---

Anzahl	Name	Vorkommen in Artikel
15	BILD3
15	BILD3-BESCHREIBUNG
24	GEMEINDE
25	BILD2-BREITE
27	ANMERKUNGEN
33	KEINGEOARTIKEL
40	KARTE
41	GKZ
61	BILD1-BREITE
65	BILD2-BESCHREIBUNG
78	BILD2
90	BILD-BREITE
199	PH-WERT
286	ALTERNATIVNAME
298	NACHWEIS-HÖHE
303	BILD1-BESCHREIBUNG
327	NACHWEIS-UMFANG
351	POSKARTE
378	BILD1
471	NACHWEIS-VOLUMEN
536	NACHWEIS-SEEBREITE
546	NACHWEIS-MED-TIEFE
563	NACHWEIS-EINZUGSGEBIET
590	INSELN
608	NACHWEIS-SEELAENGE
838	UFERSTADT
843	EINZUGSGEBIET
855	NACHWEIS-MAX-TIEFE
1075	UMFANG
1174	VOLUMEN
1232	UFERORT
1308	NACHWEIS-FLÄCHE
1450	BESONDERHEITEN
1547	MED-TIEFE
1815	NAHERORT
2819	NAHESTADT
2956	SEEBREITE
3042	MAX-TIEFE
3228	HÖHE-BEZUG
3262	SEELAENGE
3365	ZUFLUSS
4304	HÖHE
4381	BILD
4465	NAME
4694	ABFLUSS
4747	FLÄCHE
5063	BILDBESCHREIBUNG
5778	LAGE
6087	REGION-ISO
6087	BREITENGRAD
6087	LÄNGENGRAD

Vorlage:Infobox See ist veraltet - Diskussion

Vorlage:Infobox See ist veraltet - Diskussion Teil 1

Als ersten Schritt würde ich die Entfernung von BILD3 bis BILD5 und MAPTYPE vorschlagen. ÅñŧóñŜûŝî (Ð) 19:05, 20. Apr. 2019 (CEST)

Als Service die verschiedenen Parameter die so im ANR vorkommen (da sind veraltete und falsche auch dabei) und deren Anzahl. --Wurgl (Diskussion) 20:48, 20. Apr. 2019 (CEST)

Danke. Ich habe das mal nach rechts verschoben, weil das sehr lang ist und man das besser zur Hand hat. ÅñŧóñŜûŝî (Ð) 20:53, 20. Apr. 2019 (CEST)

Da sind jede Menge Karteileichen dabei. ÅñŧóñŜûŝî (Ð) 20:55, 20. Apr. 2019 (CEST)

Ja! Aber das ist der Status, sieht bei anderen Vorlagen nicht anders aus. Ich könnte an der Abfrage ein wenig drehen und auf das Datum mit ausgeben, wo der Parameter aus der Vorlage entfernt wurde. Mal sehen. --Wurgl (Diskussion) 20:58, 20. Apr. 2019 (CEST)

Bei weniger als zehn Einträgen wäre es super, wenn du den/die Artikel auflisten könntest. ÅñŧóñŜûŝî (Ð) 21:06, 20. Apr. 2019 (CEST)

Veflixt. Geht leider nicht. Ich hab momentan Vorlagen ausgenommen, die #invoke verwenden. Ich muss erstmal gucken, wie ich aus diesen Lua-Modulen die verwendeten Parameter rauspfriemeln kann. Sorry, zuviel versprochen :-( --Wurgl (Diskussion) 21:10, 20. Apr. 2019 (CEST)

Die Artikel kann ich aber liefern. Bin dran. --Wurgl (Diskussion) 21:10, 20. Apr. 2019 (CEST)

Macht nichts. Habe bereits einen Wartungslink für die Exoten gesetzt. Die Tippfehler etc. mache ich schonmal weg.. ÅñŧóñŜûŝî (Ð) 21:15, 20. Apr. 2019 (CEST)

Wirklich nur einmal ist eine Breite definiert?! Da stimmt wohl mit der Zählung etwas nicht. --Silvicola ^Disk 21:16, 20. Apr. 2019 (CEST)

SEEBREITE gibt es ja auch und das ist 2956 mal gesetzt. Ich zähle übrigens nur Parameter, die auch einen Wert zugewiesen haben. --Wurgl (Diskussion) 21:34, 20. Apr. 2019 (CEST)

Die genutzten Namen sind nicht besonders systematisch, aber eindeutig. Ich habe die o.g. Seiten abgeklappert. Tabelle jetzt ausklappbar. Wir sollten uns der Frage zuwenden, ob wir die von mir erwähnten Parameter entfernen sollten. ÅñŧóñŜûŝî (Ð) 22:34, 20. Apr. 2019 (CEST)

KEINGEOARTIKEL dient dazu, bei mehreren Infoboxen auf einer Seite die Ausgabe der Artikelkoordinate zu unterdrücken. Alternativer Parameter in anderen Boxen ist NEBENBOX. @W!B:: hats erfunden. Zum Da gibt es gewiss bessere Lösungen. wäre es nett, wenn du uns wenigstens eine nennen würdest. --Herzi Pinki (Diskussion) 21:26, 21. Apr. 2019 (CEST)

KEINGEOARTIKEL – Um Gottes Willen, wie soll man aus dem Namen des Parameters seine Funktion verstehen und sich merken können?! Schnell raus damit und im Sinne der Einheitlichkeit über verschiedene Boxen hinweg durch NEBENBOX ersetzen, auch wenn der Name ebenfalls zumindest nicht ideal ist.

Ein Parameter mit dieser Funktion wird wohl gebraucht, denn es dürfte zuweilen das Bedürfnis geben, zwei oder mehr Seen zusammen abzuhandeln und dabei vielleicht Flächen usw. einzeln „einzuboxen“. Schaut Euch dazu mal diese Karpfenteichlandschaft an; nie wird da jemand jedem Einzelteichen einen Artikel spendieren, allenfalls Teichgruppen mit gemeinsamem Namen etwa auf -weiher (Plural!), eher noch nur Gruppen von Gruppen. --Silvicola ^Disk 21:52, 21. Apr. 2019 (CEST)

Welches konkrete Problem hast du mit der Einbindung der Positionskarte? Was ist dein konkreter Änderungsvorschlag? --Herzi Pinki (Diskussion) 21:26, 21. Apr. 2019 (CEST)

Den Parameter KEINGEOARTIKEL in NEBENBOX umbenennen ist bei nur 33 Einbindungen nicht allzuviel Arbeit. Bei Positionskarte habe nur das Problem, dass der Quelltext wohl viel aufwändiger gestaltet ist als bei anderen Infoboxen Insoweit war das mehr eine Anfrage von mir, ob man das nicht einfacher codieren kann. Das sieht sehr nach Workarround aus. POSKARTE wird z. B. in der Vorlage dreimal abgefragt. In diesem Zusammenhang würde ich auch den Parameter MAPTYPE entfernen, denn der wird gar nicht genutzt. Es gibt wohl keinen Bedarf dafür und es trägt zur Übersichtlichkeit bei. Andere Kartentypen werden besser außerhalb der Box und damit gezielter platziert. Ebenso werden die Paramewter für ein viertes und fünftes Bild nicht genutzt. Die würden die Infobox auch extrem lang machen und den Platz für quelltextbezogene Thumbplatrzierungen wegnehmen. wir haben ja inzwischen die Gallery-Funktion. BILD4 und BILD5 sollte auch weg. ÅñŧóñŜûŝî (Ð) 22:42, 21. Apr. 2019 (CEST)

@Antonsusi: was ist dein Vorschlag für eine bessere Lösung bei KEINGEOARTIKEL? Umbenennen ist ja nur umbenennen und keine bessere Lösung. Zur POSKARTE: ist einfacher gestaltet bei welchen Infoboxen (bitte eine weltweit gültige, nicht eine nationale, da ist es ja einfacher)? {{Infobox Berg}} ist im Prinzip genauso. lg --Herzi Pinki (Diskussion) 00:42, 22. Apr. 2019 (CEST)

1. Jeder See hat eine Stelle, an der er sich befindet /befand / befinden wird. Ich würde daher z.  BREITENGRAD und LÄNGENGRAD zu Pflichtparametern erklären. Der Aufruf von check im Modul TemplatePar ermöglicht eine gute Fehlerwartung auch bei angegebenen aber nicht existenten Parametern. Dann muss man das nur einmal machen
2. In der Infobox Berg wird z. B. auf die aufwendige und m. E. auch bei Seen nicht notwendige Berechnung des werts für dim (für POSKARTE und Coordinate) verzichtet und ein mittlerer Wert vorgegeben. Niemand ist zu dumm, um im Geohack die Karte zu zoomen, wenn es mal nicht gut passen sollte. Alternativ kann man die immer weitgehend gleiche Berechnung des optimalen Werts für dim auch in eine separate Vorlage schreiben und diese dann in allen vergleichbaren Infoboxen mit Geohack nutzen.
3. Bei KEINGEOARTIKEL würde ich einfach den üblichen Parametenamen NEBENBOX einsetzen, nur diesen dokumentieren und KEINGEOARTIKEL sukzessiv ersetzen, um verständlichere Einbindungen - das ist auch ein Vorteil - zu erhalten.

Bleibt noch die Frage nach MAPTYPE, BILD4 und BILD5. Soll ich die mal auskommentieren? Dann zeigt sich, ob sie vermisst werden. Ob man ein viertes Bild (=BILD3) benötigt, ist ebenfalls zweifelshaft. Wird auch nur 15 mal genutzt. ÅñŧóñŜûŝî (Ð) 21:45, 23. Apr. 2019 (CEST)

Ich würde es ja besser finden, wenn jeder parameter einzeln diskutiert werden würde

• BREITENGRAD und LÄNGENGRAD sind Pflichtparameter, ihr Fehlen erzeugt einen Lagewunsch (als Anzeige im Artikel und entsprechenden Kategorieeintrag) und die Pflichtigkeit wird damit in {{Coordinate}} komplett abgehandelt. Keine Aktion notwendig. Eine Prüfung würde dem informatischen Prinzip von coupling und cohesion zuwiderlaufen.
• Die Prüfung auf korrekte Himmelsrichtung (etwa Spezial:Linkliste/Vorlage:Infobox_See/Wartung/Länge) und entsprechend für Breite ist erstens falsch implementiert (O ist eine gültige Himmelsrichtung, könnte man in Frage stellen, aber wenn, dann zentral) und wird zweitens auch in {{Coordinate}} abgehandelt. Kann daher in der Infobox entfernt werden.
• Zur Umbenennung (nicht Verbesserung!) von KEINGEOARTIKEL in NEBENBOX würde mich ein statement von @W!B:: interessieren.
• die Berechnung vom dim in eine eigene Vorlage auszulagern, erhöht die Komplexität. Nicht für jeden Einzeiler ist eine eigene Untervorlage notwendig. If it ain't broke, don't fix it. Welches wären die vergleichbaren Infoboxen, bitte keine Mutmaßungen, sondern konkrete Auflistung, wo aus einem flächigen Objekt mittels LÄNGE, BREITE, UMFANG & FLÄCHE eine dim berechnet wird? Ich denke nicht, dass es dass außerhalb von {{Infobox See}} gibt.
• @Antonsusi: Der Unterschied zwischen einem Berg und einem See ist, dass ein Berg ein willkürliche Dimension hat und ein mittlerer Wert bisher ausreichend schien, dass aber ein See so unterschiedliche Dimensionen wie der Baikalsee oder ein 100m Teich im Wald haben kann. Ein Berg hat einen eindeutigen Gipfel, ein See ein eindeutiges Ufer. Das Argument, dass BenutzerInnen sich die dim einstellen können, wie sie wollen, weil sie ja nicht dumm sind, ist ein Scheinargument. Dann braucht es auch keine Koordinaten, BenutzerInnen können die selbst googlen.
• BILD4 und BILD5 werden aktuell nicht verwendet und könnten gestrichen werden. BILD3 kann erst gestrichen werden, wenn die Bilder aus der Box in den Artikel ausgelagert werden und BILD3 nicht mehr vorkommt.
• MAPTYPE kommt aktuell nicht vor. Spezial:Linkliste/Vorlage:Infobox_See/Wartung/MAPTYPE. Ein Auskommentieren zeigt nicht unmittelbar, ob Parameter vermisst werden, vermisst können Parameter auch in Monaten und Jahren werden. Ich bin aber der Meinung, dass Seen als Objekte der physischen und nicht der politischen Geografie wie sonst auch die Reliefkarte verwenden sollen, so es eine gibt. Das macht die {{Positionskarte}} automatisch. Die Festlegung einheitlicher Standards durch Infoboxen vereinheitlicht ja das Look&Feel der Verwendungen, etwas was ich als positiv erachte.
• Wenn man die Box schon angreift, dann sollten die Parameterprüfungen auf Modul TemplatePar umgestellt werden, und die Wartungslinks durch Wartungskategorien ersetzt werden.

Insgesamt empfehle ich die Anwendung von WP:Korrekturen auch auf Infoboxen. Ich finde es gut, dass die Änderungen hier vorher diskutiert werden. lg --Herzi Pinki (Diskussion) 08:24, 24. Apr. 2019 (CEST)

@dim, Berg, See:

Es ist schon ein Unterschied, ob man Mitschreibern hier zumutet, ein geeignetes dim zu ermitteln (wozu sie im Zweifelsfall in der Lage wären, wenn sie nicht zu faul dazu sind) oder ob man passiven Wikipedianutzern zumutet, Koordinaten selbst zu ermitteln (wozu sie im Zweifelsfall eben nicht in der Lage wären). Wir Altiven bedienen die Passiven, und bei der Frage „dim händisch“ oder „dim,per Algorithmus ermittelt“, geht es alleine um eventuelle Arbeitserleichterungen auf unserer Seite. Das genannte Argument sticht also nicht.

Vielmehr müsste man sich hierbei dazu Gedanken machen:

• mit welcher Rate mangels Ausgangsparametern kein dim automatisch ermittelt werden kann
• mit welcher Rate bei automatischer Ermittlung das dim daneben ginge
• mit welcher Rate bei händischer Einsetzung diese unterlassen würde
• mit welcher Rate bei händischer Einsetzung diese falsch eingesetzt würde

Ich habe keine AHnung, mit welchen Raten man jeweils rechnen muss, vermute aber, der Hauptpunkt ist wie so oft die Faulheit: Wenn jemand einen ersten dim-Wert einsetzt, kontrolliert er ihn dann mittels Kartenprobe – oder belässt er es ungeprüft bei ihm, nach dem Motto „Wird schon stimmen“?

--Silvicola ^Disk 09:38, 24. Apr. 2019 (CEST)

Es ging um Niemand ist zu dumm, um im Geohack die Karte zu zoomen, wenn es mal nicht gut passen sollte. also auch um ein Service für die Passiven. --Herzi Pinki (Diskussion) 10:10, 24. Apr. 2019 (CEST)

Aber der Vergleich mit den Koordinaten war daneben. --Silvicola ^Disk 11:31, 24. Apr. 2019 (CEST)

Ok. Ich setze die Entfernung der unerwünschten Parameter dann um. ÅñŧóñŜûŝî (Ð) 19:17, 24. Apr. 2019 (CEST)

Welcher genau? --Herzi Pinki (Diskussion) 23:16, 24. Apr. 2019 (CEST)

Betreff Umfang, Fläche, Breite und Länge:

1. Der Umfang ist ein fraktales Gebilde und nur zusammen mit der Messvorschrift und damit hier gar nicht nutzbar.
2. Die Fläche ist nur bei einem weitgehend kreisrunden See (z. B. Maar) als Grundlage sinnvoll. Lässt sich nur schwer automatisieren.
3. Länge und Breite sind Definitionssache. Welche Richtung definiert, dass es die Länge ist, und welche, dass es die Breite ist? Hier wäre die Maximale Ausdehnung der wirklich nützliche Wert. Ich würde daher Breite und Länge aus der Dokumentation nehmen (zwecks Abwärtskompatiblität aber nicht entfernen) und stattdessen "ABMESSUNG" oder "AUSDEHNUNG" einführen.

ÅñŧóñŜûŝî (Ð) 19:36, 24. Apr. 2019 (CEST)

Den Blödsinn mit dem fraktalen Umgang hatten wir schon, bitte lass das. Der Umfang wird in diversen Seenbeschreibungen als Wert angegeben. Wir beschreiben nicht, was wir messen, sondern das was die Literatur hergibt. Meine Frage war, wo die Kombination aus LÄNGE, BREITE, UMFANG & FLÄCHE noch vorkommt. Offensichtlich nirgends, sonst hättest du ja die Stelle erwähnt. Insoferne braucht es mit der Argumentation auch keine Auslagerung in eine Untervorlage. Die Parameter heißen SEELAENGE und SEEBREITE und werden in der Infobox ausgegeben, du kannst sie nicht einfach entfernen. Die einzig legitime Frage ist, ob aus SEEBREITE und SEELAENGE dim abgeleitet werden kann, werden soll, oder ob es dafür einen zusätzlichen Parameter braucht. ME braucht es keinen zusätzlichen Parameter, da das Maximum (SEELAENGE; SEEBREITE) die dim für die Karte ausreichend genau bestimmt und durchaus nachvollziehbar verständlich ist. Ob die Fläche sinnvoll ist, ist eine andere Frage, aber auf die Fläche wird ja nur rückgegriffen, wenn SEELAENGE / SEEBREITE nicht angegeben sind. Es geht bei der dim um einen ungefähr sinnvollen internen Wert, der π mal Daumen richtig sein soll, wie du oben mit den Dummen geschrieben hast, … Was du tun kannst, ist in allen Verwendungen der Infobox, wo die Fläche für die Berechnung der dim herangezogen wird, SEELAENGE / SEEBREITE entsprechend zu eruieren und einzutragen, dann wird die Fläche nicht mehr für die Berechnung von dim herangezogen, bleibt aber als Rückfalllösung. lg --Herzi Pinki (Diskussion) 23:16, 24. Apr. 2019 (CEST)

das beträfe etwa folgende Verwendungen (FLÄCHE ohne SEELAENGE) --Herzi Pinki (Diskussion) 23:27, 24. Apr. 2019 (CEST)

Entfernt habe ich MAPTYPE, BILD5, BILD4 und nach Umbau der 15 Artikel auch BILD3. Drei Bilder sind jetzt noch möglich und das reicht zusammen mit der Positionskarte offensichtlich aus. Darüber hinaus war der undokumentierte Parameter NACHWEISE nirgendwo genutzt und ist deshalb jetzt auch weg. Seitdem es Mehrfach-Refs gibt, ist er auch nicht mehr sinnvoll. ÅñŧóñŜûŝî (Ð) 23:41, 24. Apr. 2019 (CEST)

tut mir leid, war ein paar tage offline:

• ja, von mir stammte das "KEINGEOARTIKEL" sicher nicht ursprünglich, das hab ich auch nur von wo anders übernommen, aber keine ahnung von wo. aber natürlich ist "NEBENBOX" heute standard, also weg damit (es gibt noch "FOLGEBOX", da könnten wir auch mal weiter harmonisieren: die beiden drücken eigentlich dasselbe aus).
• bezgl. "BREITENGRAD und LÄNGENGRAD sind Pflichtparameter": klare sache, natürlich sollte sowohl NEBENBOX=ja wie auch POSKARTE=none den Lagewunsch unterdrücken, auch das ist inzwischen standard in geoboxen: es gibt immer sonderfälle: etwa historische seen, deren mitte man nicht mehr ermitteln kann; oder seen, die wandern – ausschalten muss man immer jeden "pflichtparameter" können, geographie ist komplex
• bzgl. dim aus LÄNGE, BREITE, UMFANG & FLÄCHE wäre ich pragmatisch:
  • auch die fachliteratur gibt typischerweise nur bei halbwegs runden bis ovalen länge und breite nicht an (eben genau drum, weil man dann auch diskutieren müsste, was davon die "länge" wäre), sondern den umfang (wenn es eine halbwegs "hübsche" küstenlinie gibt: bilderbuchsee)
  • während bei langgezogenen seen (fjordartig, stauseen) typischerweise nur die länge über alles und eine maximalbreite angegeben werden, nicht aber der umfang (der eben wegen der vielen nebenfluss-verästelungen wie bei stauseen wirklich zunehmend fraktal wird)
  • während bei völlig irregulären seen meist nur die fläche angegeben wird
  • aber wegen der wasserstände bei stauseen, oder sehr flachen steppenseen mit temporär extrem schwankenden werten oft gar keine eckdaten angegeben sind (oder ein "von bis")

  daher ist ein fallback sicherlich sinnvoll:

  • dim zuerst aus Max(LÄNGE, BREITE) – für den fall, dass jemand eine "kürzere" länge entlang einer durchflusslinie ermittelt
  • sonst aus U=d·π → DIM=UMFANG – faktor 3 als unschärfe ist hier ok, siehe oben
  • sonst aus A=d²π → DIM=WURZEL(FLÄCHE) – die wurzel(π) kann man hier ebenfalls vergessen, 1,5 deckt dann die "ovalen" fälle ab, für langezogene fälle ist wie gesagt eh meist eine länge zusätzlich in den quellen ermittelbar
  • dann dürfte man nur in vereinzelten fällen die wurzel-rechnung beanspruchen müssen. und wenn gar nichts davon angegeben ist (respektive die werte keine brauchbaren zahlen sind, sondern verbales), ein wartungslink. eine maximal- oder nominellausdehnung lässt sich aus jeder karte ermitteln. um dann aber nicht zu TFln, was die "länge" sei, könnte man auch unspezifisch einfach "DIM" sic aus dem standard-IB-satz angeben können. das ist nur für den koordlink, wird aber in der IB nicht angezeigt: das wär doch eine "diplomatische" lösung (und damit entfällt auch die suche nach weiteren notnägeln ala "ABMESSUNG" oder "AUSDEHNUNG")

und ja, d'accord Herzi Pinki: gut, dass wir zuerst drüber reden, an den IBs wird zu viel nur herumgebastelt.
und d'accord auch zu Look&Feel: ich persönlich finde den sinnvollsten ansatz, wenn man eine "Infobox:Geoobjekt" im hinterkopf behält: langfristig könnte man die layouts aller geo-IBs zentralisieren. also sind kompatible ansätze (parametersätze ebenso wie layouts) jedenfalls ein vorteil: die IB:See ist unser prototyp für alle flächenobjekte, so wie die IB:Fluss der prototyp aller linienobjekte ist. aus denen lassen sich dann automatismen für andere IBs übernehmen, alles, was sich hier bewährt, wird wo anders gute dienste leisten. die dim-berechnung wäre z.b. für gebirgsgruppen, aber auch wälder oder schutzgebiete, und sogar für verwaltungseinheiten interessant: denen könnte man langfristig denselben optionssatz spendieren. also dabei weniger über konkret seen, sondern flächenobjekte allgemein in ihrer vielfalt – aber auch ihre gemeinsamkeiten – nachdenken. vielleicht wird aus der dim-berechnung ein untermodul, das man in alle IBs übernehmen kann. --W!B: (Diskussion) 07:17, 25. Apr. 2019 (CEST)

@W!B:: Gute Ideen von dir.

A): Die Mathematik wäre - schon wegen der besseren Syntax - in einem Modul gewiss besser aufgehoben. Ein Modul "Geoobjekt" wäre sicherlich von Vorteil. Es gibt ja Flächenobjekte (See, Gebirge, Staat, Naturschutzgebiet etc.), Linienobjekte wie Flüsse, Punktobjekte wie Quellen oder Berggipfel und Jombnationen daraus, wie z.B. Berge, bestehend aus Punktobjekt(rn) Gipfel und Flächenobjekt(en) Bergflanken. Sowas komplexes geht nur mit einer Programmiersprache. Das ist aber eine längere Sache und muss separat bearbeitet werden. Hier für diese Box müsste es ein kleineres Modul sein. Die Formeln müssen so Extremfälle wie Tanganjikasee und Tschadsee richtig erfassen.

B):Parameternamen: Für den CactusBot gibt es ein Skriptpaar, mit dem man die Parameter in eine Tabelle schreiben und nach Korrektur wieder zurückschreiben kann. Bedingung dafür, dass Cactus26 seinen Bot schreiben lässt, ist eindeutige Zustimmung derer, die am Thema arbeiten. "FOLGEBOX" suggeriert, dass eine Sortierung möglich ist, was nicht immer de Fall ist. "Im Artikel weiter unten" ist ein schwaches Sortierkriterium. Daher ist NEBENBOX m. E. besser. Hierbei wäre auch zu überlegen, ob wir nicht mit einem Botzugriff gleich alle Macken der Parameternamen beheben:

• Abklären, ob wir BILD-BREITE überhaupt brauchen. Ein Bild sollte die Breite der Box möglichst gut nutzen. Wenn es nicht zu hoch wird, ist die Innenbreite der Box genau die richtige Breite. ein konstantes XXXxYYYpx reicht m. E. aus. zu sehr hochkantige bilder sind oben in der Box sowieso ungeeignet.
• Gemischte Vewrwendung von Umlauten (Ä Ö Ü versus AE OE UE), also SEELAENGE in SEELÄNGE ändern.
• Redundanz zwischen UFERSTADT und UFERORT sowie NAHESTADT und NAHERORT (letzterer undokumentiert).

ÅñŧóñŜûŝî (Ð) 20:22, 25. Apr. 2019 (CEST)

Zur Breite der Infobox: Wir haben mal, weiß der Geier wann, festgelegt, daß Geographieinfoboxen immer die Breite 300px haben (und haben gleichzeitig festgelegt, daß die Flußinfobox davon abweichend 330px hat). Das war übrigens zu Zeiten, als die Defaultbreite von Thumbs 150px war. Warum ie Fluß-IB breiter sein durfte, daran erinnere ich mich nur noch dunkel; hatte irgendwas damit zu tun, daß diese 30px die Zeilenumbrüche im Bereich Abflußweg signifikat verringerte) Ohne feste Breite zu arbeiten, ist nicht zielführend, weil bei den Flüssen der Abflussweg und allgemein geographische Lageangaben wie Rhein-Neckar-Kreis, Baden-Württemberg und Landkreis Ludwigshafen, Rheinland-Pfalz nicht umbrochen werden. In der Praxis folgt ddaraus eine Bildbreite von 280 oder 290px. Die Angabe einer Bildgröße ist dennoch erforderlich, cf. Chile-Problem – wir können uns das net aussuchen.

Ich persönlich halte die Dim-Bestimmung bei Seen für ziemlich trivial.

Ist Länge > Breite, dann Dim=Länge, else Dim=Breite

Alle anderen Sonderfälle sind mMn zu vernachlässigen. Artikel-IBen ohne Länge und Breite halte ich sowieso für mangelhaft.

Ach ja, und können wir bitte diesses Minigescchreibsel in Teilen der IB abschaffen, sondern, wie in Geographieinfoboxen generell auf 90 Prozent gehen?

Die Herkunft des Paramters "KEINGEOARTIKEL" ist eine Verballhornung von "Kein WP:GEO durch diese IB im Artikel". (WP:GEO = WikiProjekt Georeferenzierung); ich glaube wir hatten das erstmalig bei Artikeln, wo es IBen für Staumauern und (Stau-) Seen gibt. Die generelle Umstellung auf "NEBENBOX" unterstütze ich, zumal dadurch ja in bestimmten Kombinationen die komplette IB als nachgordneter Abschnitt in eine andere IB eingefügt werden kann (außerdem hab ich's erfunden). Wobei ich gerade net weiß, ob wir ein konkrets Beispiel in der Praxis haben; in Vorlage:Infobox Brücke habe ich das experimentielle implementiert fürVorlage:Infobox NRHP, aber Firefox13 hat mW nie die dort notwendigen Anpassungen vorgenommen.

Allerdings frage ich mich, ob wir Infobox See als Nebenbox wollen. Die Frage ist also, ob nicht Flüsse, Berge, Seen und dergleichen immer primäre Eigenschaften sind, der sich andere Eigenschaften (Nationalpark, NSG und dergleichen) immer unterordnen müssen, oder ob wir das mal so mal so zulassen wollen. --01:47, 28. Apr. 2019 (CEST) (incognito signierter Beitrag von Matthiasb (Diskussion | Beiträge) )

Vorlage:Infobox See ist veraltet - Diskussion Teil 2

Es gibt - wenn ich mich richtig erinnere - seltene Fälle, bei denen eine Gruppe von Seen einen gemeinsamen Artikel haben, weil sich einzelne Artikel wohl nicht lohnen. Insoweit ist "NEBENBOX" wohl dann sinnvoll.

Die Breite der Box sollte sich an den Möglichkeiten der Bilder orientieren. Das sich ein Bereich von 300 bis 330 Pixel etabliert hat, liegt wohl auch an den möglichen pers. Einstellungen. Bei den Einstellungen kann ein User die Standard-Thumbbreite u.A. auf 220,250,300 oder 400 Pixel einstellen. Bei einem HD-Monitor sind 300px ein gut passender Wert. Wenn wir für die Bilder in der Box also eine Breite von ca. 300 Pixel nehmen, dann hat die Box je nach Padding ca. 310 Pixel. Dadurch passen die oftmals direkt darunter befindlichen Thumbs gut ins Bild. Ich bin daher dafür, dass wir den Parameter BILD-BREITE wegnehmen (siehe mein Beitrog oben) und dafür den Standard 300x600px vorgeben. Bilder, welche mehr als doppelt so hoch wie breit sind, dürften bei einem naturgemäß flachen Geoobjekt selten sinnvoll sein. Dadurch wird die IB-Breite optimal genutzt.

sofern keine weiteren großen Einwände kommen würde ich als nächsten konkreten Schritt die Umbenennung von KEINGEOARTIKEL in NEBENBOX vornehmen (ca. 30 mal, geht also von Hand). ÅñŧóñŜûŝî (Ð) 12:27, 28. Apr. 2019 (CEST)

Zwar eine Meeresbucht, aber einem langgezogenen See nicht unähnlich

Würde man wohl beschneiden und käme dann an 1:2 nahe heran oder gar darüber hinaus: Gardasee

Ich bin mir da nicht so sicher, was deine Annahme der Bildformate angeht. Typische Fälle für Hochkantbilder wären längliche Seen, bei denen die Perspektive längs des Sees veläuft, der Aufnahmepunkt aber deutich höher liegt, etwa von einem Berg, vom Flugzeug oder einem Satelliten aus. Allerdings dürfte man in solchen Fällen mit einem 1:2-Seitenverhältnis weitgehend zurechtkommen. --Matthiasb – ^{(CallMyCenter)} 21:44, 28. Apr. 2019 (CEST)

Bei mehr als 1:2 ist das Bild dann halt automatisch schmaler. Wichtig ist, dass das obere Bild nicht zu hoch wird. Wenn 600 Pixel zu viel ist, dann kann man auch 300x480, also 5:8 (1,6) nehmen. ÅñŧóñŜûŝî (Ð) 21:53, 28. Apr. 2019 (CEST)

Der Parameter KEINGEOARTIKEL lautet jetzt NEBENBOX. ÅñŧóñŜûŝî (Ð) 23:39, 30. Apr. 2019 (CEST)

Alle bisher 90 Einbindungen von BILD-BREITE sind von mir "abgeklappert". Es gab entweder Angaben von ca. 300px bei Querformat oder unnötigerweise kleinere Werte auch bei Querformat. Nur eine handvoll Artikel hatten reduzierte Breiten bei Bildern mit Hochkantformat. Ich habe diese Artikel so gestaltet, dass man diesen Parameter nicht mehr benötigt. Zusammen mit der von mir eingebauten Möglichkeit für nicht allzu extremes Hochformat wird BILD-BREITE zurzeit nicht mehr benötigt. Als Beispiel möge die Box vom Tachinger See dienen (aufklappen).

IB für den Tachinger See

---

vorher (plus 2. Bild zur besseren Vergleichbarkeit)	nachher	nachher mit Thumb
Tachinger See Taching und Tachinger See Geographische Lage bayer. Alpenvorland Zuflüsse Tenglinger Bach, Tachinger Mühlbach Abfluss Waginger See → Götzinger Achen → Salzach → Inn → Donau Orte am Ufer Tettenhausen (Gemeinde Waging am See) Ufernaher Ort Taching am See, Tengling Daten Koordinaten 47° 57′ 57″ N, 12° 44′ 36″ O47.96583333333312.743333333333442.1 Gewässer/Archiv/2019 (Bayern) Höhe über Meeresspiegel 442,1 m Fläche 2,36 km² Breite 888 m Volumen 21.600.000 m³ Umfang 9,25 km Maximale Tiefe 16,5 m Mittlere Tiefe 9,2 m pH-Wert 7,9 Einzugsgebiet 31,8 km² Besonderheiten verbunden mit dem Waginger See Der See in seiner Umgebung	Tachinger See Der See in seiner Umgebung Geographische Lage bayer. Alpenvorland Zuflüsse Tenglinger Bach, Tachinger Mühlbach Abfluss Waginger See → Götzinger Achen → Salzach → Inn → Donau Orte am Ufer Tettenhausen (Gemeinde Waging am See) Ufernaher Ort Taching am See, Tengling Daten Koordinaten 47° 57′ 57″ N, 12° 44′ 36″ O47.96583333333312.743333333333442.1 Gewässer/Archiv/2019 (Bayern) Höhe über Meeresspiegel 442,1 m Fläche 2,36 km² Breite 888 m Volumen 21.600.000 m³ Umfang 9,25 km Maximale Tiefe 16,5 m Mittlere Tiefe 9,2 m pH-Wert 7,9 Einzugsgebiet 31,8 km² Besonderheiten verbunden mit dem Waginger See Taching und Tachinger See	Tachinger See Der See in seiner Umgebung Geographische Lage bayer. Alpenvorland Zuflüsse Tenglinger Bach, Tachinger Mühlbach Abfluss Waginger See → Götzinger Achen → Salzach → Inn → Donau Orte am Ufer Tettenhausen (Gemeinde Waging am See) Ufernaher Ort Taching am See, Tengling Daten Koordinaten 47° 57′ 57″ N, 12° 44′ 36″ O47.96583333333312.743333333333442.1 Gewässer/Archiv/2019 (Bayern) Höhe über Meeresspiegel 442,1 m Fläche 2,36 km² Breite 888 m Volumen 21.600.000 m³ Umfang 9,25 km Maximale Tiefe 16,5 m Mittlere Tiefe 9,2 m pH-Wert 7,9 Einzugsgebiet 31,8 km² Besonderheiten verbunden mit dem Waginger See Taching und Tachinger See
2. Bild zum Vergleich ergänzt.	Dies war das "hochformatigste" Bild	2. Bild als Thumb

---

Ich finde, wir können BILD-BREITE ganz entfernen. Es findet sich gewiss für jeden See-Artikel eine gute Lösung ohne diesen Parameter. ÅñŧóñŜûŝî (Ð) 16:33, 1. Mai 2019 (CEST)

Um eine einheitliche Schreibweise der Parameter zu erreichen, habe ich das einzige Parameterpaar SEELAENGE und NACHWEIS-SEELAENGE, welche das Ä mit AE umschreiben, abwärtskompatibel um SEELÄNGE und NACHWEIS-SEELÄNGE ergänzt. Damit kann man diesen Parameter im Laufe der Zeit oder im Rahmen eines Botlaufs austauschen. ÅñŧóñŜûŝî (Ð) 09:12, 4. Mai 2019 (CEST)

ÅñŧóñŜûŝî: gut so. und ausserdem  Pro IB für den Tachinger See: nachher mit Thumb: es gibt auch hier keinen grund, seen andes als andere geo-IBs zu behandeln, übertrieben hohe bilder sind sowieso in allen IBs ein problem und daher prinzipiell ungeeignet: für die IB ist immer ein breitformat zu wählen. selbst bei kirchen – auch unsere denkmalfotographen haben schon gemerkt, dass, wenn man eine kirche besucht, man nicht jedesmal nur ein bild vom turm hochkant knippst, sondern immer auch eines breit (und für die listen braucht mans auch): ein hochkantbild bringt man später immer irgendwo im artikel unter – wenns denn sein muss, die machen sowieso auch im fliesstext gerne probleme (wegen der kapitelung, sie schieben dann oft die themen-bilder unmässig weiter). daher bin ich sowieso prinzipiell für 300x200px (ca. klassisch DIN-A/Filmfoto-quer), maximal 300x300px (moderneres quadratformat der handy-generation). und wenn das eine briefmmarke wird, nimmt man halt ein anderes bild. oder erkennt klar einen bildwunsch, wenn es partout kein anderes bild gibt (die einzige ausnahme dürfte die IBs:Hochhaus sein, die hat fast immer ein hochkant-bild, aber selbst türme, kirchen oder bäume kommen quer im umgebungskontext immer besser).

und daher bin ich auch dafür, prinzipiell alle BILD2 ff aus den geo-IBs zu entfernen: "weitere deko" gehört als thumb in den artikel, die IB ist kein platz für gallerien. 1 bild und 1 karte reicht. ausnahmslos. weitere primär-illu kann man inzwischen sowieso auf wikidata deponieren (einzige ausnahme hier vielleicht berge, die zwei hochprominente ansichten haben: aber auch da ist es sinnvoller, diese beiden nebeneinander in einem querformatbild zu präsentieren, das ist schnell erstellt, anstatt erst recht wieder eine ansicht "vorrangig" zu stellen. aber einmal vor blauem himmel und einmal mit alpenglühen braucht wirklich nicht in die IB) --W!B: (Diskussion) 10:00, 4. Mai 2019 (CEST)

So radikal wollte ich das nicht umsetzen. Daher habe ich das Weglassen von BILD3 bis BILD5 mit einer moderaten Grenze für hochkant teilweise kompensiert. Wenn es hier genug Zustimmung gibt, dann kann man das gewiss auch noch reduzieren. Je kleiner die Grenze, umso mehr weiße Seitenflächen tauchen auf, was ich nicht so gut finde. Es gibt zurzeit viele Bilder mit Hochformat 4:3. Denen würde ich die volle IB-Btreite gerne noch "genehmigen". ÅñŧóñŜûŝî (Ð) 10:10, 4. Mai 2019 (CEST)

naja, auch Hochformat 4:3 käme mit 300x300px noch akzeptabel: wir müssen "thumb" mit "fixpix" nachbilden, und thumb rechnet schon eine zeitlang über die bildfäche, um übermässig große bilder zu vermeiden. daher ist nicht die IB-max-breite das kriterium, gerade bei hochkant. und wo die "weißen" flächen auftauchen, hängt nur vom endgerät ab. bei großteil aller gestubs bei mir auf einem normalen desktop-bildschirm zwischen ende des textchens und der navileiste (weil die IB dreimal länger ist als der artikel). oder weil die IB die textbilder weiterschiebt. drum hab ichs eher mit "radikal". die IB soll in erster linie eine schnelle übersicht über die eckdaten geben, nicht die artikelillustration formatieren. --W!B: (Diskussion) 14:47, 5. Mai 2019 (CEST)

@W!B:: Das zweite Bild (also Parameter BILD1) ist oft eine Detailkarte. Die kann man schlecht "herausschieben". Ansonsten muss man im Artikel eine Gallery einsetzen. Das ist evtl. viel Arbeit. Mir ist außerdem noch aufgefallen, dass der Parameter UFERSTADT redundant zu UFERORT und der Parameter NAHESTADT redundant zu NAHERORT ist, denn "Ort" ist ein Oberbegriff zu "Stadt". Um diese immer noch überladene Box noch weiter zu verschlanken würde ich diese jeweils zusammenlegen. ÅñŧóñŜûŝî (Ð) 21:51, 5. Mai 2019 (CEST)

Vorlage:Infobox See ist veraltet - Botlauf

Ich möchte in nächster Zeit folgende Änderungen per Bot umsetzen:

1. Parameter SEELAENGE wird in SEELÄNGE geändert, ebenso NACHWEIS-SEELAENGE in NACHWEIS-SEELÄNGE
2. Parameter KEINGEOARTIKEL wird in NEBENBOX geändert
3. Parameter BILD2 bis BILD5 und BILD2-BESCHREIBUNG bis BILD5-BESCHREIBUNG werden entfernt.
4. Parameter TOPO-KARTE wird entfernt.
5. Parameter UFERORT versus UFERSTADT:
   • UFERSTADT leer: UFERSTADT entfernen.
   • UFERORT leer UFERSTADT nichtleer: UFERSTADT in UFERORT ändern.
   • UFERORT nichtleer UFERSTADT nichtleer: unverändert lassen (Handarbeit).
   • Mit NAHERORT und NAHESTADT genauso verfahren.
6. Es gibt dann genau folgende Parameter:

• ABFLUSS * ALTERNATIVNAME * BESONDERHEITEN * BILD * BILD1 * BILD1-BESCHREIBUNG * BILDBESCHREIBUNG * BREITENGRAD * EINZUGSGEBIET * FLÄCHE * HÖHE * HÖHE-BEZUG * INSELN * KARTE * LAGE * LÄNGENGRAD * MAX-TIEFE * MED-TIEFE * NACHWEIS-EINZUGSGEBIET * NACHWEIS-FLÄCHE * NACHWEIS-HÖHE * NACHWEIS-MAX-TIEFE * NACHWEIS-MED-TIEFE * NACHWEIS-SEEBREITE * NACHWEIS-SEELÄNGE * NACHWEIS-UMFANG * NACHWEIS-VOLUMEN * NAHERORT * NAME * NEBENBOX * PH-WERT * REGION-ISO * SEEBREITE * SEELÄNGE * UFERORT * UMFANG * VOLUMEN * ZUFLUSS

@W!B:: Bitte um Stellungnahme dazu. ÅñŧóñŜûŝî (Ð) 19:59, 11. Mai 2019 (CEST)

Ein Testlauf mit ca. 50 Seiten ist durchgeführt. Wortmeldungen dazu? ÅñŧóñŜûŝî (Ð) 00:05, 23. Mai 2019 (CEST)

Ein halbes Dutzend Aufschläge in meiner BEO, anscheinend nur recht große Seen, darunter nichts Auffälliges. Wieviele tausend werden's denn sein? --Silvicola ^Disk 02:37, 23. Mai 2019 (CEST)

Muss ich zählen lassen. Es ist nicht so einfach, alles in einen AWB-Edit zu packen. ÅñŧóñŜûŝî (Ð) 21:30, 23. Mai 2019 (CEST)

Ein Glück, dass Du über einen Bot gebieten kannst. --Silvicola ^Disk 23:15, 24. Mai 2019 (CEST)

Es ist ein halbautomatischer Editor und kein echter Bot. ÅñŧóñŜûŝî (Ð) 23:51, 24. Mai 2019 (CEST)

Dann mein Beileid. Ich habe mal in einer ähnlichen „Fleischbot“-Massenaktion zwischen fünftausend oder zehntausend Edits von Hand in einer Woche auf mich genommen. Mach nur fleißig Pausen, sonst wirst Du verrückt! Ich werde Dir gleich mal ein paar Edits wegnehmen, aber in Maßen nur. --Silvicola ^Disk 01:48, 25. Mai 2019 (CEST)

Einen Bot hätte man von der Beobachtungsliste nehmen können, diese Aktion leider nicht. Immer dasselbe Theater. NNW 12:58, 26. Mai 2019 (CEST)

Ein Bot wäre weniger Mühe für mich, aber den habe ich nicht. ÅñŧóñŜûŝî (Ð) 13:22, 26. Mai 2019 (CEST)

Und es gibt ja auch keine Anlaufstelle, wo man um einen Botlauf anfragen kann. NNW 13:42, 26. Mai 2019 (CEST)

Das mit dem Zusammenlegen von zweimal zwei Parametern wollte ich lieber selbst kontrollieren. ÅñŧóñŜûŝî (Ð) 15:58, 26. Mai 2019 (CEST)

dein ping hab ich übersehen: sieht aber alles sehr sinnvoll aus. danke dir. auf der disk der IB wäre noch ein hinweis zu setzen, dass hier diskutiert wurde. --W!B: (Diskussion) 14:58, 1. Jun. 2019 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 18:45, 7. Jun. 2019 (CEST)

Infobox Fluss

habe in Loopebach ein Bild eingefügt (keine Ahnung, ob richtige Größe). Die Vorlage für den Bilderwunsch habe ich nicht gefunden. Wo kommt der Hinweis her und wie kann man ihn entfernen? --Schnabeltassentier (Diskussion) 12:35, 2. Jun. 2019 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Schnabeltassentier (Diskussion) 08:08, 10. Jun. 2019 (CEST)

Bach mit zwei Mündungen, wie eintragen

Hallo,

ich hab heute mal den Artikel Lockwitzbach (Coswig) erstellt. Der Bach hat 2 Mündungen in die Elbe. Wie trägt man sowas in die Infobox ein? --mw (Diskussion) 10:50, 18. Mär. 2019 (CET)

Die nominelle Hauptmündung kommt in die Box (ist sie schon). Den Nebenarm, der unterhalb mündet, reicht es im Fließtext zu beschreiben.

Übrinx sollte man schon im Intro sehen können, daß und wo wir in Sachsen sind (Coswig (Sachsen) gehört natürlich verlinkt ins Intro, ebenso der Kreis).

Die Quelle würde ich eher relativ zu Auer (Moritzburg) verorten, da das entferntere Dippelsdorf (Moritzburg) ja nichts mit dem Bach zu tun hat. Sie liegt im Grunde zwischen beiden Orten, der Bach entscheidet sich aber für Auer - welches als einziges freistehendes Dorf am Bach Erwähnung finden sollte. --Elop 11:23, 18. Mär. 2019 (CET)

Welches Lemma für Giesbach (Rhein)

Hallo und guten Tag,

bitte schaut euch mal bei Gelegenheit den Giesbach (Rhein) an. Er entwässert nicht, wie das Lemma fälschlicherweise vermuten lässt, in den Rhein. Vielmehr versickert er in zwei Teichen. Einen Klammerzusatz braucht er dennoch, denn es gibt noch mehrere Flüsse mit dem Namen, siehe Giesbach. Welches Lemma wäre korrekt? Giesbach (Fluss)?.

Danke für Hinweise und Grüße --Assenmacher (Diskussion) 19:47, 30. Apr. 2019 (CEST)

Müsste er dann folgerichtig nicht auch aus der Kategorie:Flusssystem Rhein entfernt werden? Grüße --Didionline (Diskussion) 20:23, 30. Apr. 2019 (CEST)

Da bin ich mir nicht so sicher, denn nach der GKZ ist es nach wie vor das Flusssystem Rhein. Grüße --Assenmacher (Diskussion) 20:27, 30. Apr. 2019 (CEST)

Also für Bäche, die im Einzugsgebiet eines Flusses versickern und offenbar direkt zu diesem hin, würde ich bedenkenlos den Fluss selbst in die Disambiguierungsklammer des Bachlemmas stellen. Ich habe Ähnliches auch schon bei einem anderen solchen „Versickerer“ in der Kölner Bucht gesehen und selbst schon bei Gewässern so gehalten, die in der Donauaue in einem abgehängten Altgewässer enden, das nur einen Grundwasserabfluss hat.

Der Usus empfiehlt sich auch deshalb, weil man es doch bei Zuflüssen über einen kurzen Mühlbach, der gewöhnlich nie einen Artikel bekommen wird, ganz genauso hält. (Es gibt auch längere Seitenkanäle etwas längs der Isar, da dann anders, da man diese auch wie gewöhnliche Fließgewässer behandelt.) Das passt auch besser zu „wiki-kategoriellen“ Flussordnungszahl nach der Abflusskette, siehe den Erklärungsvorspann der Flusssystemkategorien: Mühlkanäle usw. sind dort unter "0" aufgeführt, damit das zusammenpasst. "0" wird sozusagen disambiguierungstechnisch übersprungen. Hielte man es nämlich anders, würden die relative Position in der Abflusskette und die Einordnung unter den Flusssystemkategorien nicht mehr zusammenpassen.

Überhaupt, was sollte man denn sonst für einen Vorfluter in die Klammer schreiben, wenn nicht Rhein? Vielleicht Grundwasserstrom Rhein oder so etwas Ähnliches? Das gäbe mit Recht ziemlich offene Münder bei den suchenden Lesern.

--Silvicola ^Disk 22:15, 30. Apr. 2019 (CEST)

Bitte auch noch eine Vorlage:Infobox Fluss in den Artikel aufnehmen und soweit möglich ausfüllen; eine kopierbare Formatvorlage dazu steht auf der Vorlagen-Seite. --Silvicola ^Disk 22:20, 30. Apr. 2019 (CEST)

Ok, wird bei Gelegenheit erledigt. Danke an alle und Grüße --Assenmacher (Diskussion) 15:40, 3. Mai 2019 (CEST)

Pfinz-Entlastungskanal und nicht Pfinz

Die Pfinz

• mündet in den Rhein

→ Kategorie:Flussysstem Pfinz

• hat einen Zufluss Krämpelbach (Fluss)
• bekommt demnächst noch weitere „ordentliche“ direkte Nebenflüsse

→ Kategorie:Flussysstem Pfinz mit 1

• hat einen rücklaufenden Zweig Heglach

→ Kategorie:Flussysstem Pfinz mit 0

• hat einen nicht zurücklaufenden Abzweig Pfinz-Entlastungskanal

→ Kategorie:Flussysstem Anderes

Aber

• hat einen Abzweigweig Gießbach (Weidgraben), der über 4 andere Stationen zeitweilig/überwiegend rückfließt

→ Kategorie:Flussysstem Pfinz mit 5; ist das korrekt so?

Was macht man ganz allgemein kategoriell mit diesen Gräben mit Abfluss/Entlastung in multiple Richtungen? --Silvicola ^Disk 01:21, 7. Jun. 2019 (CEST)

Pfinz-Entlastungskanal würde ich als künstlicher Arm eines (theoretischen? fikitiven?) Flussdeltas ansehen und unter "0" sortieren. Albkanal hab ich mal so einsortiert. --Hozro (Diskussion) 08:29, 7. Jun. 2019 (CEST)

Name eines Stausees gesucht

Hallo, weiß hier jemand, ob der Stausee des Nils zwischen dem Alten Assuan-Damm und dem (neuen) Assuan-Hochdamm einen eigenen Namen hat, und falls ja, welchen? Nassersee scheidet aus, da dieser ja erst hinter dem Assuan-Hochdamm liegt. Gruß --Zollwurf (Diskussion) 08:08, 10. Jun. 2019 (CEST)

Hallo, vielleicht hilft dir OSM--Vielen Dank und Grüße Woelle ffm (Uwe) (Diskussion) 14:39, 10. Jun. 2019 (CEST)

Lanty Tarn und Lanty’s Tarn

Offensichtrlich das gleiche Gewässser. Mag das jemand zusammenführen? ÅñŧóñŜûŝî (Ð) 14:06, 26. Mai 2019 (CEST)

Durch Zusammenführen erledigt. ÅñŧóñŜûŝî (Ð) 02:36, 12. Jul. 2019 (CEST)

Stauseen, Talsperren, Dämme

Ich habe zwei Fragen zu dem Themenbereich:

a) In der DE-WP wird die Beschreibung von Stauseen+Dämmen meistens innerhalb eines einzigen Artikels abgehandelt: Der Artikel behandelt sowohl das Absperrbauwerk, als auch den See sowie alle weiteren dazugehörigen Anlagen. In anderen Sprachversionen hingegen gibt es häufiger separate Artikel zum Absperrbauwerk und zum See. Beispiele:

• en:Edersee Dam und en:Edersee vs. Edersee
• en:Esch-sur-Sûre Dam, en:Upper Sûre Lake vs. Esch-sur-Sûre-Talsperre.

Warum trennen wir unsere Artikel nicht (bzw. nur sehr selten) nach See und Damm?

b) Außerdem fällt auf, dass einige der Stauseen als "See" lemmatisiert werden (Edersee, Biggesee, Diemelsee), andere als "Talsperre" (Talsperre Bütgenbach, Möhnetalsperre, Aartalsperre). Haben wir dazu eine Vorgabe, oder macht das jeder Autor wie er möchte? Dem allgemeinen Sprachgebrauch scheint dabei nicht überall gefolgt zu werden, denn sonst würde die "Esch-sur-Sûre-Talsperre" unter "Obersauer-Stausee" stehen, die "Talsperre Bütgenbach" stünde unter "Bütgenbacher See" und die "Aartalsperre" stünde unter "Aartalsee" (um bei den vorgenannten Beispielen zu bleiben). Grüße--Plantek (Diskussion) 10:40, 9. Jul. 2019 (CEST)

Die Vorlage:Infobox Stausee legt es nahe, Talsperre und Stausee gemeinsam zu behandeln. Interessanterweise steht in der Box zum Edersee als Name "Edertalsperre", obwohl es sich um die Infobox Stausee handelt.

Da wir praktisch nie in 2 Artikel trennen, hielte ich es für sinnvoll, dem See stets das Lemma zu lassen und der Talsperre den Redirect. Dieser Redirect wäre dann natürlich als Talsperre zu kategorisieren. --Elop 10:49, 9. Jul. 2019 (CEST)

D.h. es gibt keine Vorgabe für die Lemmawahl? Gruß--Plantek (Diskussion) 11:43, 9. Jul. 2019 (CEST)

Doch, es gelten die allgemeinen Namenskonventionen: es ist der gebräuchlichste bzw. offizielle (z.B. in amtlichen Karten) Name als Lemma zu wählen. Ob etwas -see, -stausee, -speicher oder anders genannt wird, ist ja regional unterschiedlich, z.B. Gepatschspeicher, aber Silvretta-Stausee.

Zu a): Die Artikel in Stausee und Absperrbauwerk zu trennen, erscheint mir nicht sinnvoll. Die englischen Artikel zum Edersee bestätigen das ja nur. --Luftschiffhafen (Diskussion) 14:49, 9. Jul. 2019 (CEST)

Und wenn für das Absperrbauwerk der Name "Aartalsperre" am gebräuchlichsten ist und für den zugehörigen Stausee der Name "Aartalsee"? Wo soll der Artikel dann stehen? Viele Grüße--Plantek (Diskussion) 15:09, 9. Jul. 2019 (CEST)

Auf einem der beiden, je nachdem, welcher gebräuchlicher ist. Der andere leitet dann auf den entsprechenden Abschnitt im Artikel weiter.--Meloe (Diskussion) 15:13, 9. Jul. 2019 (CEST)

Danke! Aartalsperre (7160 Google-Treffer) müsste also auf Aartalsee (51.900 Treffer) verschoben werden. Grüße--Plantek (Diskussion) 15:25, 9. Jul. 2019 (CEST)

Ich wäre dafür, hier einen Konsens dafür zu erzielen, nach Möglichkeit immer den See zu nehmen. Er ist ja fast immer auch der Gefragtere. Und wenn jetzt ein Landkreis penetrant immer nur von "Talsperre" reden sollte - etwa weil der zuständige Bearbeiter das Wort "cooler" fände - sollte das keine Sonderbehandlung nach sich ziehen.

Und speziell in Listen stiftet das von Plantek angedeutete Phänomen tendenziell Verwirrung.

Übrinx hatte ich mal als Kind gedacht, "Talsperre" sei eine bestimmte Seenart. man badet und fährt Boot in der Talsperre. Dieses Mißverständnis dürfte nicht selten sein, da der Normalbürger ja nicht an ein Bauwerk, sondern an ein Gewässer fährt.

Wenn ich über die B 255 am Aartalsee vorbeifahre, sehe ich auch keine Sperre, sondern einen See. Übrinx auch keinen "Tal"-See, sondern einen kleinen Randbereich des Niederweidbacher Beckens. Anders als bei Eder- und Biggesee, die ganze Täler füllen. --Elop 15:38, 9. Jul. 2019 (CEST)

Es gibt Fälle, da knirscht´s: Eckertalsperre sollte bleiben. Solange in der Systematik das Hochwasserrückhaltebecken Salzderhelden bei den Staussen stehen muss, sollten kleine Inkonsequenzen dieser Art zu verschmerzen sein.--Meloe (Diskussion) 15:48, 9. Jul. 2019 (CEST)

Was ist mit dem Nassersee? Über 500 km langer Stausee. Soll der besser wikipedisch nur unter Assuan-Staudamm stehen? Eigenartige Fragestellung. --Zollwurf (Diskussion) 17:00, 9. Jul. 2019 (CEST)

Einer der ganz wenigen Fälle, wo Damm und See getrennt behandelt werden. Wie oben bereits gesagt, andere Sprachversionen machen das auf breiter Front so. Grüße--Plantek (Diskussion) 17:09, 9. Jul. 2019 (CEST)

Wieso sollte eine, sinnvolle, Regel keine Ausnahmen haben dürfen? Wir schreiben hier doch kein Gesetzbuch.--Meloe (Diskussion) 07:59, 10. Jul. 2019 (CEST)

So ist es. Ich nehme mit aus der Diskussion hier, dass es (wider Erwarten) keine starre Spezialvorschrift für die Behandlung von Stauseen gibt und dass das Lemma dem allgemeinen Sprachgebrauch folgen darf. Und ich werde zumindest ein paar der "-Talsperren" auf "-seen" verschieben. Danke an alle--Plantek (Diskussion) 08:33, 10. Jul. 2019 (CEST)

Was mich noch stört, ist die Interwiki-Verlinkung:

• Für den Bütgenbacher See gibt es 8 andere Sprachversionen, unser Artikel verlinkt aber nur zu einer (für den Damm).
• Für den Obersauer-Stausee gibt es 10 andere Sprachversionen, unser Artikel verlinkt nur zu vier.
• Für den Kaptschagai-Stausee gibt es 15 andere Sprachversionen, unser Artikel verlinkt nur zu vier.

Das liegt natürlich an unserer Zusammenfassung der Artikel für Damm und Stauraum. Kann man das irgendwie günstiger lösen? Grüße--Plantek (Diskussion) 09:43, 11. Jul. 2019 (CEST)

Ich blick da ja selber nicht durch, aber war es nicht früher so, daß wir die Interwikilinks manuell setzten, und das heute WikiData machen soll?

Beim arabischen und chinesischen Artikel kann ich das nicht beurteilen, aber beim Bütgenbacher See gehen ansonsten alle Interwikis zum See - nur in D ist es die "Talsperre".

Lasse ich den ar-Artikel übersetzen, so heißt das Lemma "See Buchenbach", beim zh-Artikel "Bitgenbachsee" mit Intro "Der Bergenbach ist ein belgischer See".

M. E. ist die Talsperre da falsch und die Interwikis sollten zum See-Redirect gehen. Besser natürlich auch hier eine Verschiebung zum Seenlemma auf de. Allerdings behandelt unser Artikel bislang mehr das Bauwerk als das Gewässer. Und im Intro steht der Name des Sees überhaupt nicht - nur in der Stauseenbox. --Elop 10:24, 11. Jul. 2019 (CEST)

Es ist doch möglich, eine Weiterleitung zu kategorisieren. Im Biobereich machen wir das auch ständig, um die Doppelung Trivalname (Löwe) und wiss. Name (Panthera leo) angemessen abzubilden. Wäre es nicht möglich, die Kats, die sich spezifisch auf das Gewässer beziehen, also Stausee in Europa etc., hier auf die WL Bütgenbacher See zu legen? Analog könnte verfahren werden, wenn der See das Hauptlemma ist, also die Kategorisierung als Bauwerk auf die WL zu verschieben (etwa Kats Bauwerk in ... und Staumauer in ... auf die WL Edertalsperre anstelle des Artikels Edersee). Würde m.E. zur Übersichtlichkeit beitragen.--Meloe (Diskussion) 09:49, 12. Jul. 2019 (CEST)

Ein analoges Vorgehen für die Interwiki-Verlinkung (WLs bei WikiData hinterlegen) scheint leider nicht zu funktionieren. Grüße--Plantek (Diskussion) 11:03, 12. Jul. 2019 (CEST)

Ein generelles Problem scheint die "zwanghafte" Verwendung von Infoboxen zu sein. In der Vorlage:Infobox Stausee suggerieren Parameter zur Höhe der Stauanlage, selbst wenn der aufgestaute See riesig ist, dass man da unbedingt was einzutragen hat. Die Vorlage ist für kleine und mittlere Stauseen eventuell tauglich, für sehr große mE nicht (mein Beispiel oben). Womöglich könnte in der Vorlage:Infobox See ein Parameter ergänzt werden... --Zollwurf (Diskussion) 15:53, 12. Jul. 2019 (CEST)

Google Earth / Maps als Referenz

Diese Diskussion habe ich kopiert von Benutzer_Diskussion:Jonas_aus_Großwechsungen2#Google_Earth_/_Maps_als_Referenz, da eine Dritte Meinung eingeholt werden soll und das nicht im Benutzernamensraum geschehen soll. --Superbass (Diskussion) 15:59, 12. Jul. 2019 (CEST)

Ich habe mir einige deiner Artikel angesehen und festgestellt, dass du Google Earth / Maps als Nachweis für die Länge von Gewässern angibst. Google Earth / Maps ist geeignet, um Längen abzuschätzen, aber nicht als Quelle. Wenn du eine Länge in einem amtlichen Verzeichnis findest, dann trage das als Nachweis ein, sonst lass den Parameter einfach unbefüllt. --Rennrigor (Diskussion) 01:28, 8. Jul. 2019 (CEST)

Hallo Rennrigor, danke für deine Nachricht. Ich habe festgestellt das man über das Satellitenbild von Google den Verlauf haargenau nachzeichnen kann. Diese selbst erfassten Längenangaben sind oft genauer als solche in amtlichen Verzeichnissen. Beispielsweise ist die Helme durch einen anderen Wikipedianer durch einen GPS Track nachgemessen worden. Dieser ist 20km länger als andere offizielle Angaben. Aber ich lasse Google als Quelle in kommenden Artikeln außen vor. Viele Grüße. Jonas aus Großwechsungen2 (Diskussion) 14:46, 8. Jul. 2019 (CEST)

„Diese selbst erfassten Längenangaben sind oft genauer als solche in amtlichen Verzeichnissen.“ Genau das ist das Problem. Selbst erfasst heißt automatisch OR, und das ist in der WP nicht erlaubt. Daher: als Abschätzung ja, als Quelle nein. Btw: Größen von Gewässern sind eigentlich trivial, müssen also nur explizit bequellt werden, wenn sie angezweifelt werden. --Rennrigor (Diskussion) 15:08, 8. Jul. 2019 (CEST)

Ich danke für deine Antwort. Jonas aus Großwechsungen2 (Diskussion) 16:45, 8. Jul. 2019 (CEST)

Ist ja bemerkenswert, daß ein Neuzugang vom 14. Mai meint, uns hier neue Regeln diktieren zu können. --Elop 17:14, 8. Jul. 2019 (CEST)

@Elop: ja, ja... --Rennrigor (Diskussion) 17:19, 8. Jul. 2019 (CEST)

Nana, kein Stress :) Er hat ja schon recht das Google keine offizielle Quelle ist, ein anderer Nutzer hat mir diesbezüglich schon mal geschrieben. Nur hat es anscheinend bis jetzt niemanden gestört, dass ich Earth als einzelnachweis eingefügt habe. Grüße. Jonas aus Großwechsungen2 (Diskussion) 17:24, 8. Jul. 2019 (CEST)

Wenn wir eine Zahl angeben, dann müssen wir auch angeben, wo wir sie her haben. Die Referenz läßt uns dann problemlos erkennen, ob sie "amtlich" oder privat ermittelt ist.

Ist ein Pfad angegeben, kann man sogar insbesondere überprüfen, ob dessen Zeichner da nicht ein Fehler unterlaufen wäre.

Wenn irgendwo beim Amt eine völlig falsche Zahl von 60 steht, eine für jeden nachvollziehbare Messung jedoch z. B. 83 ergibt, gehört sogar beides rein. Denn eine falsifizierbare "offizielle" Angabe ist keine, die wir unkommentiert zu übernehmen hätten, sobald uns das bekannt wäre.

Eine nicht referenzierte, aber korrekte 83 würde ansonsten auch jederzeit wieder mit dem falschen Wert überschrieben werden. --Elop 17:48, 8. Jul. 2019 (CEST)

@Jonas: das ist kein Stress. Jedenfalls nicht für mich. Wenn Elop gerne eine OR als Beleg in einem Artikel hätte (wie jetzt, da er meine Entfernung in Helme zurückgesetzt hat), dann lasse ich ihm halt seinen Willen. Er muss sich halt ggf. irgendwann dafür rechtfertigen. Du solltest nur nicht die gleiche Schiene fahren. Früher (in den Anfangsjahren der WP) war das vielleicht noch ok, heute ist es das sicher nicht mehr. Und wenn es es in einem amtlichen Verzeichnis ggf. einen Fehler gibt, dann ist das durchaus Anlass für eine Quellenkritik, aber sicher nicht für eine OR-Quelle im Artikel selbst. --Rennrigor (Diskussion) 17:52, 8. Jul. 2019 (CEST)

Wie soll denn eine "Quellenkritik" aussehen, wenn gar keine Widerlegung angegeben ist?

Jo, irgendwann werde ich mich vor dem Jüngsten Gericht rechtfertigen müssen.

Wenn ein "Neuzugang", der angeblich weiß, wie die "Anfangsjahre der WP" ausgesehen hatten, Regeln für die Flußartikel einführen will, so sollte er hierfür Wikipedia Diskussion:WikiProjekt Geographie oder Portal Diskussion:Gewässer ansteuern. --Elop 18:06, 8. Jul. 2019 (CEST)

Ja, ja... --Rennrigor (Diskussion) 18:09, 8. Jul. 2019 (CEST)

Ich werde Earth nun nicht mehr als Quelle verlinken. Allerdings muss ich Elop mit dem selbs gezeichneten Pfad recht geben, zumal es bei den meisten kleinen Bächen keine offizielle Liste gibt bezüglich GKZ, Länge, Einzugsgebiet, Zuflüsse,...

Also werde ich in Zukunft auch versuchen "Pfade" anzulegen und somit die Angaben verständlich zu bestätigen. Und Google nur noch in die Nachweisspalte unter dem Bearbeitungsfenster eintragen. Jonas aus Großwechsungen2 (Diskussion) 18:13, 8. Jul. 2019 (CEST)

Wichtig ist doch wohl, daß jeder Leser nachvollziehen kann, woher eine Zahl kommt.

Ich kenne die "Anfangszeit" nicht, wohl aber die Jahre 2006 ff. Da hatten vielerorts Bearbeiter einfach mal so Kilometerzahlen geschätzt und diese dann eingetragen. Und 100 Edits weiter weiß kein Schwein mehr, wo die Zahl herkommt. Und im ungünstigsten Falle wird die dann auf externe Websites übernommen, die dann später hier als "Quelle" nachgetragen werden. Zumal z. B. Kommunen und Landkreise gerne mal von der WP abschreiben.

Übrinx war das in den Portalen bereits mehrfach diskutiert worden. Ich schließe natürlich nicht aus, daß Rennrigor das bekannt ist und er möglicherweise unter altem (jetzt gesperrtem?) Account beteiligt war. --Elop 18:27, 8. Jul. 2019 (CEST)

Jede Angabe, die nachvollziehbar und überprüfbar belegt ist, ist besser als gar keine Angabe oder eine Angabe, die amtlich, aber völlig falsch ist. Wir sind doch keine Juristen, für die der Grundsatz gilt (und anscheinend im Studium gelernt wird), „das Grundbuch ist immer richtig, auch wenn es falsch ist“. Und wer sich irgendwann einmal die Mühe macht, die zuweilen arg zackig über den auf Karten und Luftfotos erkennbaren geschlungenen Verlauf gelegten und Anfangsabschnitte auslassenden amtlichen Polygonzüge mit der klar erkennbaren Wirklichkeit zu vergleichen, der wird sich auch keine Illusionen der Art „amtlich, also korrekt“ mehr machen. Durch den (notwendigen) Einzelnachweis wird dann auch keinem Leser etwas vorgemacht. Eher durch blinde Adoration. --Silvicola ^Disk 01:39, 12. Jul. 2019 (CEST)

Von "amtlich, also korrekt" habe ich nichts geschrieben. Im Gegenteil: Quellenkritik ist bei berechtigtem Anlass auch bei amtlichen Quellen angesagt.

Ich mache mal eine 3M auf, auch wenn das für eine BD ungewöhnlich ist. Aber hier hat die Diskussion nun mal begonnen. --Rennrigor (Diskussion) 01:54, 12. Jul. 2019 (CEST)

3M

Wenn eine Angabe durch OR ermittelt wurde, dann sollte OR ganz klar auch als Beleg angegeben werden. Ansonsten kann der Eindruck entstehen, die Angabe wäre ordnungsgemäß belegt: Sie könnte einer Literaturangabe oder einem Weblink entstammen, der EN könnte im Verlauf der Versionsgeschichte verlorengegangen sein, er könnte verrutscht sein oder ein anderer EN wird der Angabe fälschlich zugeordnet.

Ob OR hier akzeptabel ist, ist natürlich eine ganz andere Frage. Bei der Messung einer Länge gibt es an sich wenig zu interpretieren, aber ich muss da an das Küstenparadox denken. Wenn es das nicht ist, dann ist jedenfalls die Angabe zu entfernen, nicht bloß der Beleg. --Universalamateur (Diskussion) 09:24, 12. Jul. 2019 (CEST)

Das Küstenlängenargument trifft nicht zu, da ein Bach eine reale Breite hat. Erfahrungsgemäß liegen die Abweichungen zwischen verschiedenen Messungen dieser Art bei etwa einem %. Wobei die "amtlichen", rein virtuellen "Kilometersteine" oftmals weniger genau sind als das, was man bei ganz besonderer Sorgfalt messen würde (dann können es auch 2 % werden), aber die nehmen wir natürlich gegebenenfalls.

Gelegentlich messen die Ämter auch über einen Nebenstrang, siehe z. B. Nuhne oder Kuselbach/Pfeffelbach (Kuselbach) (in beiden Fällen nicht gut deklariert - bei der Nuhne aber auf der Disk nachlesbar). Dann müssen wir aus deren Teilästen denjenigen berechnen, der der landläufigen Bedeutung nachkommt. --Elop 11:43, 12. Jul. 2019 (CEST)

3M: Die Wikipedia-Regeln sind eindeutig. OR ist nicht erlaubt, und das hat auch seinen Grund, denn wenn die Zahlen falsch sind, sind wir für den Fehler verantwortlich. Wenn amtliche Zahlen falsch sind ist das egal, da die Zahlen trotz allem amtlich sind. Da wir den Fehler nur wiedergeben, sind wir für den Fehler nicht verantwortlich. Das ist wie bei einer richterlichen Zu-Tod-Erklärung. Da bist du offiziel auch dann Tod, auch wenn du in Wirklichkeit noch am Leben bist.--Resqusto (Diskussion) 12:07, 12. Jul. 2019 (CEST)

Dürfte ich bei Deiner falschen Zu-Tod-Erklärung gegebenenfalls anmerken, dass Du lebst, da ich Dich noch nach Deinem vorgeblichen Tode gesehen habe? Wenn nicht, würde ich Dir natürlich auch nichts zu essen und zu trinken geben; wäre ja nochmal schöner, wenn so ein Toter auch noch CO₂ produziert!

Was soll ich eigentlich tun im Falle, den ich im Grenzgebiet DE-BW/DE-BY schon mehrfach festgestellt habe, nämlich dass beide zuständigen Länder abweichende Werte angeben? Muss ich dann behaupten, dass beide Werte stimmen? Aus der Situation einen angeblichen Widerspruch zu konstruieren, wäre doch logische OR, oder nicht?

Wer ersichtlich falsche Zahlen unkommentiert verbreitet, der täuscht willentlich. Eine sachlich begründete, darge- und belegte Abweichung von amtlichen Werten ist in jedem Falle eine Bereicherung. Anhand des Einzelnachweises bzw. der Diskussion im Text selbst kann auch jeder die Abweichung nachvollziehen und die Begründung wägen. Das ist in jedem Falle besser als Blindheit des Schreibers und Blendung des Lesers.

Haltet bitte die Leute nicht unnötig auf, die hier etwas arbeiten und nicht nur diskutieren wollen. --Silvicola Disk 12:29, 12. Jul. 2019 (MESZ)

persönliche Kommentare übereinander entfernt --Superbass (Diskussion) 15:59, 12. Jul. 2019 (CEST)

• 3M Ich rege an, auch diese Stelle in WP:BLG in die Überlegungen einzubeziehen: "Für allgemeinkundige Tatsachen (Beispiel: Die Erde ist annähernd kugelförmig und keine Scheibe) bedarf es keiner Herkunftsangabe – es sei denn, der Artikel widmet sich direkt dieser Frage. Entbehrlich sind Belege, wenn etabliertes Wissen wiedergegeben wird und auf der Hand liegt, wo man dieses nachlesen kann." Wenn es zu einer Gewässerlänge keine belegfähigen Angaben gibt und mit trivialer Methode und unstrittigem Ergebnis eine Angabe selbst ermittelt werden kann, kann man das ggf. auch als etabliertes Wissen, statt als Theoriefindung/OR bezeichnen. Dann wäre gar kein Beleg erforderlich und es diente lediglich der Transparenz, wenn auf eine Kartenmessung verwiesen würde. Wenn bei der Messung dagegen ein fachlicher Entscheidungsspielraum oder ein Dissens bestünde, wäre das ausgeschlossen. --Superbass (Diskussion) 16:11, 12. Jul. 2019 (CEST)

• 3M Eine Längenangabe, die aus einer öffentlichen Karte extrahiert worden ist, ist zunächstmal nicht unbelegt. Beleg ist die Karte. Damit ist die Belege-Anforderung schonmal erfüllt. Schließlich werden auch andere inhaltliche Angaben (z.B. Höhenangaben) in gleicher Weise unbeanstandet verwendet. Die Ermittlung der Länge eines Strichs ist keine Originalforschung, weil es schlicht nichts zu forschen gab. Es handelt sich um reines Handwerk. Das kann man falsch oder richtig gemacht haben (was objektiv prüffähig ist), aber wer es tut, gibt die "Theorie" eines anderen, nämlich des Kartenerstellers, wieder. Die Verwendung der Karte könnte als "primäre" Quellenangabe eingeschätzt werden. Das wäre allerdings die Verwendung des veröffentlichten Gewässerkatasters auch, das eine Datenbank, keine wiss.Veröffentlichung ist, und damit genauso primär. Gilt in gleicher Weise für andere Zahlenangaben: Einwohner, Wahlergebnisse, Flächengrößen usw usw). Das es sich bei sowas um eine Hilfskonstruktion handelt ist wohl allen klar.--Meloe (Diskussion) 16:23, 12. Jul. 2019 (CEST)

+1. Ja zur Verwendung von Kartenangaben + dazu zählen selbstverständlich auch Entfernungen und Streckenlängen. Grüße--Plantek (Diskussion) 16:48, 12. Jul. 2019 (CEST)

• 3M Die gestellte Frage ist doch, welche "Original Research" zulässig ist. WP:TF ist für andere Fälle gedacht. Gewässerlängen halte ich für triviale Angaben, auch wenn die Ermittlung an sich etwas an Mühe und Sachverstand benötigt. Für ein Koordinatenpaar ist es extrem trivial: Wenn ein Landesamt den Kirchturm 800m abseits einer real vor Ort gemessenen Position angibt, dann hat die Realmessung trotzdem Vorrang. Für aus mehreren Koordinatenpaaren abgeleitete Längenangaben gilt das auch, vorausgesetzt sie sind qualitativ gut. Benötigt wird also ein öffentlich einsehbarer Track (der Streit-Auslöser Helme ist ein Idealbeispiel), damit die Information direkt für jedermann überprüfbar ist. Wenn der Nachweis (hier also eine Kette von Koordinaten) von schlechter Qualität ist (zu stark generalisiert und darum irreführend kurz, oder mit willkürlichen Kurven innerhalb des Flussbettes und darum irreführend lang) dann kann jedermann dies feststellen und bemängeln. Wenn es aber nichts zu beanstanden gibt, sind anderslautende (auch amtliche) Angaben unrichtig. Dann kann man kleinere Ungenauigkeiten ignorieren (geographische Fehlmessungen passieren schnell), objektiv grob falsche Angaben kann man in einer Anmerkung erwähnen. Googles Kartenansicht halte ich übrigens für problematisch - ein Abgleich mit Satellitenbildern und/oder OSM ist im Zweifel nötig. Grüße --Enyavar (Diskussion) 17:50, 12. Jul. 2019 (CEST)

• 3M Falls eine Internet-Quelle nicht (mehr) als veritabler Beleg erachtet wird, was man durchaus verstehen kann, dann sollte eine neue Richtlinie, etwa Kategorie:Schwarzer Listeneintrag, angelegt werden, wo just die nicht akzeptierten Belege aufgelistet werden. Die Kategorie wird dynamisch sein, stets. --Zollwurf (Diskussion) 17:57, 12. Jul. 2019 (CEST)
• 3M OR steht wohl für "Original Research". Sobald ihr Eure Forschung veröffentlicht habt und diese rezipiert worden ist, gilt sie als Beleg ansonsten als Theoriebildung oder Theoriefindung, die ohne weiteres entfernt werden kann.--5glogger^Disk 22:13, 12. Jul. 2019 (CEST)

??? Was genau willst Du uns damit mitteilen? Du hast den Fall, der hier konkret diskutiert wird, zur Kenntnis genommen?--Meloe (Diskussion) 09:38, 13. Jul. 2019 (CEST)

Ich habe durchaus verstanden, dass in den Karten und sonstigen Quellen manchmal keine Gewässerlängenangaben zu finden sind. Das liegt daran, dass diese noch nicht veröffentlicht worden ist (vermutlich irrelevant wie so vieles andere Unveröffentlichte), oder ein Nutzer hat nicht ausreichend gesucht. Die sophistischen Verrenkungen "Hilfskonstruktion" (d.h. kein Beleg), "triviale Methode" (d.h. wieder kein Beleg), "gibt die Theorie des Kartenerstellers wieder" (Belegfälschung, dieser wollte ganz klar keine Angaben zur Länge machen, sonst stünden sie dort), "könnte als primäre Quelle eingeschätzt werden" (wäre das aber nicht) zeigt die ganze Bandbreite wie hier versucht wird nicht veröffentlichtes Wissen wiederzugeben, sondern die eigenen Fähigkeiten zu Ableitungen salonfähig zu machen oder sich die gründliche Recherche zu ersparen. Das geht in anderen Projekten WP ist explizit ein Projekt zur Darstellung veröffentlichten Wissens. OR ist inakzeptabel.--5glogger^Disk 20:40, 15. Jul. 2019 (CEST)

@Meloe;

Ich wollte schon vor Deiner Nachfrage vorschlagen, die Ausführungen von 5glogger einfach so stehen zu lassen. Hat ja schließlich keine Auswirkung aufs Ergebnis. --Elop 21:58, 15. Jul. 2019 (CEST)

„dass in den Karten und sonstigen Quellen manchmal keine Gewässerlängenangaben zu finden sind“ – Hier spricht offenbar der Wikipedia-Experte für topographische Karten, von dessen höherer Einsicht wir unbedingt profitieren sollten. --Silvicola ^Disk 23:36, 15. Jul. 2019 (CEST)

@Silvicola ich sprach davon, dass manche Nutzer nicht lange genug suchen, um die Angaben zu finden... @all: Wozu wollt ihr all die Verrenkungen des OR machen, wo ihr doch sowieso Belege habt und diese Diskussion jetzt als absurd abtut? Absurd ist die Frage, ob OR ein Beleg i.S. der WP ist. Jetzt störe ich die Diskussion unter Fachleuten aber nicht mehr weiter mit fachfremden Ausdrücken.--5glogger^Disk 05:51, 16. Jul. 2019 (CEST)

Dafür (letzter Satz) herzlichen Dank! --Elop 09:55, 16. Jul. 2019 (CEST)

In einer Diskussion argumentierte eine befreundete promovierte Philologin (!) einst damit, dass eine bestimmte Aussage in einem bestimmten Buch stehe, das sie zugegebenermaßen gar nicht gelesen hatte, ich aber durchaus, so dass ich wusste, dass sie nicht drin steht und das auch sagte. Daraufhin schmollte sie, weil ich mich eines unbilligen Vorteils in der Diskussion bedient hätte.

Bücher lesen. Sachkenntnisse haben. – Mit solchen arroganten Verhaltensweisen sollte man endlich einmal aufräumen! --Silvicola ^Disk 15:23, 17. Jul. 2019 (CEST)

Ich sehe hier mehrere Probleme: 1. Stellung der Belegpflicht Wenn ich grabe, dann stelle ich fest, dass das wichtigste bei WP die Belegbarkeit ist und nicht die Richtigkeit. Das halte ich für falsch. M.E. sollte die Darstellung richtiger Informationen das Ziel und die Belegbarkeit der Vorzugsweg zu diesem Ziel sein. Anders kann man sich schlecht beforschten Themen nicht nähern. Als praktisches Problem bleibt wie man die Richtigkeit ohne Belege aufzeigt. 2. Was ist "Own Research", genauer was ist "Research"? Ist ein vielleicht nicht trivialer Vorgang aber letztlich handwerklicher Vorgang wie hier das Messen eines recht übersichtlichen Flusses schon Research? Mein Vorschlag für die Helme wäre in einer Fußnote darzustellen: in der xy-Karte abgemessen. Damit ist nachvollziehbar woher die Information kommt und darauf kommt es an.--Hfst (Diskussion) 07:44, 25. Jul. 2019 (CEST)

Zu 1: Das bereitet mir zunehmend Sorgen, auch in gänzlich anderen Fällen. Wenn jedes Fitzelchen Information anhand von Sekundärquellen belegt werden muss, dann können wir etwa im Bereich Belletristik, Film und Fernsehen 99% der Handlungszusammenfassungen wegwerfen, weil sie direkt anhand der Primärquelle entstanden sind, und die Handlungsdetails nur in den seltensten Fällen in Sekundärquellen rezipiert sind. "Aber die Schlussszene des neuen Films ist genau so wie beschrieben, wieso löscht ihr das? -- Weil das Original Research ist - das kommt nur im Film vor, in keiner reputablen Rezension!". Zurück hierher, wenn ich Prioritäten setzen müsste: Am wichtigsten ist Relevanz (auch richtige und belegbare Information sollen nicht in die WP wenn irrelevant), danach Richtigkeit (zur Not mit Verweis auf Archivsurkunden / Primärquellen), danach Belegqualität (Sekundärquellen sind Primärquellen vorzuziehen). Eine Sekundärquelle, die (nachweislich einer Primärquelle) falsch liegt, sollte nicht als Beleg dienen dürfen. Wer Richtigkeit/Sekundärbelegbarkeit anders herum sieht, ist m.E. ein Wikijurist.

Zu 2, genauso ist es aktuell umgesetzt: Verlinkt ist ein digitaler Messpfad, der auf eine Online-Karte (((Korinthe: Onlinekarten sind natürlich keine Karten, sondern "Kartenverwandte Darstellungen", aber beides ist "publiziert"))) verweist. Natürlich kann man auch hingehen und ein Kurvimeter auf die TK 25 setzen, aber der Messfehler wird dadurch viel höher, und der Messpfad kann anschließend nicht mehr kontrolliert werden. Hier ist die digitale Technik der analogen Technik klar überlegen, zumindest im Heimanwenderbereich. --Enyavar (Diskussion) 14:59, 25. Jul. 2019 (CEST)

Das Problem ist m.E. ein selbst gemachtes. In Wikipedia:Belege ist nirgends von "primären" oder "sekundären" Quellen die Rede. Gefordert werden Quellen, die veröffentlicht sind. Diese sollen zudem zuverlässig sein ("reputable Belege"). Die Inhaltswiedergabe eines Films ist analog zur Verifizierung eines Zitats. Beides darf nicht nur anhand der Originalquelle verifiziert werden, es sollte sogar darauf beruhen. Belege sind immer Belege für irgendwetwas. Für die Länge eines Gewässers ist eine Kartendarstellung ebenso als Beleg verwendbar wie ein Film für dessen Handlung und Inhalt. Aber: eben nur dafür. Wer Cleopatra (1934) als Quelle für die Geschichte der Ptolemäer nutzen wollte, erhielte zu Recht einen Platzverweis. Die Forderung nach "Sekundärquellen" stammt eben nicht aus Wikipedia:Belege (wo ganz explizit und ausdrücklich mehrere Formen von Primärquellen innerhalb der Hilfsseite selbst als Beispiele verwendet werden) sondern sie wird aus Wikipedia:Keine Theoriefindung abgeleitet. Dem liegt im Regelfall schlicht ein Missverständnis zugrunde. "Theoriefindung" ist, wie auf der Seite selbst ausgesagt, dasselbe wie originäre Forschung ("Als Theoriefindung (originäre Forschung) gelten Aussagen ...). Wikipedia-Autoren sollen also nicht selbst forschen. Das ist völlig richtig und sollte unbedingt Grundsatz bleiben. Die Forderung nach Sekundärquellen wird im Rahmen des Grundsatzes der "Theoriedarstellung" getroffen und ist dort völlig unstrittig. Wikipedia-Autoren sollen nicht selbst Theorien aufstellen. Wenn es zu einem Thema eine umfassende sekundäre Literatur gibt (als Beispiel wird "Neuzeit" genannt) könnte auch die Auswahl veröffentlichter und reputabler Belege (die also in ihrer Verwendung, als Belege, zulässig und nicht zu beanstanden sind) einen unerwünschten inhaltlichen Schwerpunkt setzen. Wenn also Überfülle an Quellen das Problem ist, ist ihre Auswahl anhand der Qualitätskriterien des jeweiligen Faches selbst vorzunehmen (also nicht etwa die eine lobende Rezension aus einem See von Verrissen rauspicken). Wenn es nur wenige Quellen gibt, könnte dies ein Hinweis auf fehlende Relevanz sein. Nicht mehr und nicht weniger. Eine Formulierung wie "Dies gilt insbesondere dann ..." bei der "Sekundärliteratur" macht doch schon in der Wortwahl deutlich, dass es auch andere Fälle gibt. also a)die Zulässigkeit und Verwendbarkeit von Belegen ergibt sich aus Wikipedia:Belege. Danach sind "primäre" Belege mit besonderer Vorsicht zu behandeln, ihre Verwendung muss geprüft und gerechtfertigt sein. Untersagt ist sie nicht. b)die Auswahl und Verwendung von Quellen soll nicht der originären Forschung (Synonym: Theoriefindung) durch den Wikipedia-Autoren selbst dienen können. Dies ist der Aussagenbereich von Wikipedia:Keine Theoriefindung. Wenn ein Beleg nach Wikipedia:Belege zulässig ist und nicht der "Theoriefindung" dient, ist seine Verwendung zulässig. Dass jede Menge Wikipedia-Autoren daraus für sich selbst einfache Faustformeln abgeleitet haben, ist deren eigenes Problem. Damit ist, im Konkreten, zu Fragen, ob es sich bei der Messung der Länge eines Strichs um originäre Forschung des Wikipedia-Autoren handelt. Dann, und nur dann, müsste sie nach den Regeln untersagt werden. Das Problem ist m.E. nicht, dass die Regeln selbst hier zu starr wären. Meist ist es die Interpretation bestimmter Benutzer, die diese Starre erst dort hinein liest.--Meloe (Diskussion) 17:58, 25. Jul. 2019 (CEST)

Sind fünf Artikel zu einem Fluss legitim?

Da dieses Thema durchaus von grundsätzlichem Interesse sein könnte, verlagere ich es von Diskussion:Pölsbach einmal hierher. Zur Pöls im Oberen Murtal existieren momentan gleich fünf Artikel, nämlich:

1. Pöls (Fluss)
2. Pölsbach
3. Pölsfluss
4. Pöls-Seitenarm (1)
5. Pöls-Seitenarm (2)

Mein Problem damit ist, dass ich für die letzteren vier keinerlei Relevanz sehe, da es sich lediglich um Flussabschnitte (Pölsbach heißt der Oberlauf, Pölsfluss der Unterlauf gemäß WIS) bzw. Seitenarme handelt. Mein Vorschlag wäre, daraus Weiterleitungen zu machen und die – ohnehin kaum gegebenen – Mehrinformationen in den Hauptartikel einzuflechten. Ich will das nicht allein gegen den Autor @SteEis: entscheiden, daher beziehe ich alle bisher an der Diskussion Beteiligten ein: @Herzi Pinki: @W!B:: @Luftschiffhafen: Sorry an alle fürs Anpingen. --Clemens Stockner (Diskussion) 12:08, 28. Jul. 2019 (CEST)

Nr. 2 und 3 erscheinen mir wenig sinnvoll. Gibt es eigentlich einen Beleg für diese Namensteilung?

Die beiden Seitenarme sind vergleichsweise uninteressant, aber so gesehen eigenständige Objekte.

Übrinx funzt bei mir keiner der externen Links. --Elop 13:08, 28. Jul. 2019 (CEST)

(BK) Informativ ist das Ganze nicht. 2 und 3 sind redundant zu 1 und sollten eh dort abgehandelt werden. Und bei den kurzen Seitenarmen (Kraftwerkskanäle?) bin ich der Ansicht, die kann man auch im Hauptartikel beschreiben. --SteveK ?! 13:11, 28. Jul. 2019 (CEST)

Da der Hauptautor das nicht alleine entscheiden will und alle anderen ohnehin anderer Meinung als der Hauptautor sind, sehe ich kein Problem, das eine Zusammenlegung in Frage stellen könnte. Zusammenlegen und WL einrichten. lg --Herzi Pinki (Diskussion) 13:52, 28. Jul. 2019 (CEST)

Ich hab' das erst jetzt richtig nachgelesen. Der Hauptautor war offenbar zu "schnellentschlossen" und setzte gleich den ersten Hinweis in eine Lemmadifferenzierung um.

Übrinx hatten wir mal (bis 2010) 2 Artikel zur Asdorf, ohne daß die Autoren vom jeweils anderen Artikel wußten (s. dortige Disk). Denn im Siegerland kennt man die nur als Weibe. --Elop 14:17, 28. Jul. 2019 (CEST)

Alles vereinigen unter Pöls (Fluss), mit fetten Erwähnungen von 2. und 3. in einem Einleitungsabschnitt, der Rest des Artikels vertrüge Gliederung und Erwelterung; ein 54-km-Fluss darf ruhig etwas eingehender beschrieben werden: Laufrichtung(swechsel), Talnatur, Landschaften/Naturraüme/Gebirge, Ortschaften … Weiterleitungen für 2. und 3. einrichten, für 4. und 5. nicht, schon weil kein vernünftiger Lemmaname zu finden ist. --Silvicola ^Disk 17:59, 28. Jul. 2019 (CEST)

@4,5: die beiden nebengerinne sind eigenständig, und – entgegen dem vorredner – durchaus amtlich benannt, nur heissen sie in der aktuellen fassung Pölsfluß-Seitenarm (1) https://wis.stmk.gv.at/wisonlineext/wbo_dgk_auszug.aspx?GEW_CODE=3080 und Pölsfluß-Seitenarm (2) https://wis.stmk.gv.at/wisonlineext/wbo_dgk_auszug.aspx?GEW_CODE=3081, ausserdem gibts am oberlauf den Pölsbach-Seitenarm https://wis.stmk.gv.at/wisonlineext/wbo_dgk_auszug.aspx?GEW_CODE=3076. solche 200-m-nebengerinne sind laut RK relevant, da gibts nichts rumzudeuteln – und es werden auch aller orten in deutschland artikel zu sowas angelegt. etwas relevantes wieder einzudampfen, kommt bei geoobjekten gar nicht gut. jedenfalls aber WL (mitsamt koordinaten und kategorien) erhalten. cf. Kategorie:Bach der Münchner Stadtbäche, wie man das mit einigen sammelartikeln ganz sinnvoll gestaltet. hier wäre der "sammelartikel" natürlich Pöls (Fluss).

tatsächlich sind die WL-ziele später aber andere: für Pölsfluß-Seitenarm (1) nämlich das Klein-E-Werk Neuper (dessen werkskanal es ist), den würde man in Unterzeiring behandeln (https://www.ew-neuper.at), und (2) ist das E-Werk Hoffmann in Allerheiligen (Gemeinde Pöls-Oberkurzheim). das dritte nebengewässer ist das ehem E-Werk Franzlbauer. da hat Kollege:SteEis schlecht recherchiert, und substubs rausgeklotzt. genau für solche detaillierungen braucht man aber sinnvolle WLs später wieder. sei es im ort abgehandelt (als wichtiger wirtschaftsstandort ebenda), sei es, das kraftwerk selbst ist relevant (etwa wegen denkmalschutz): dort könnte man sogar die IB wieder einarbeiten, um die anlage komplett zu beschreiben. --W!B: (Diskussion) 18:18, 29. Jul. 2019 (CEST)

der Rhein ist mehr als 10 mal so lang. Es können durchaus geographische Entitäten, die amtlich unterschieden werden zusammen in einem Artikel behandelt werden. Möglicherweise ist das hier geraten und sinnvoll --Hfst (Diskussion) 21:33, 29. Jul. 2019 (CEST)

OK, danke für die Beiträge. Ich komme zu der Conclusio, dass die ersten drei Lemmata im Artikelnamensraum erhalten bleiben sollten, jedoch nur noch Pöls (Fluss) als eigener Artikel. Pölsbach und Pölsfluß werden zu Weiterleitungen. Wie W!B: richtig anmerkt, sind die Namen der beiden Seitenarme falsch, sollten also zu Pölsfluß-Seitenarm (1) und Pölsfluß-Seitenarm (2) – ebenfalls als Weiterleitungen – werden. Sollten die Kraftwerke dort relevant sein, kann man ja die beiden Artikel in Zukunft wieder anlegen, dann aber auch mit der entsprechenden Mehrinformation gegenüber Pöls (Fluss). Ich würde in diesem Fall aber eher für eine Anlage als Kraftwerksartikel plädieren, da ich nach wie vor nicht der Meinung bin, dass jedes x-beliebige künstliche Fließgewässer einen eigenen Artikel verdient. --Clemens Stockner (Diskussion) 21:50, 30. Jul. 2019 (CEST)

die kraftwerksartikel dürften an den RK dafür scheitern. kleinkraftwerke sind normalerweise nicht relevant (cf. das nicht durchgeführte MB dazu, da ist von min 1 MW – 10 MW je nach alter die rede). aber jetzt ein kraftwerk unter einem seiner sekundären bestandteile behandeln, nur weil die nach den RK aus einer anderen ecke relevant wären, finde ich patschert (und es führt eben zu genau so unnützen artikeln wie bei den beiden pöls-kraftwerken). aber diese unausgewogenheit gibts inzwischen sowieso überall, die gesamt-WP hat völlig den horizont verloren, wo die einzelnen abteilungen in ihrem erfassungsstand angekommen sind. wenn tatsächlich "jedes x-beliebige künstliche Fließgewässer einen eigenen Artikel verdient", gehört das zumindest mit den bauwerks-RK harmonisiert denn was künstliches ist, ist ein bauwerk (nach deren RK sind aber 200 m lange erdbewegungen kaum relevant), andererseits gelten bauwerke nicht als geographische objekte. beides würde also seitens dieses projektes ausgehebelt. ausserdem muss man sowieso irgendwo eine abgrenzung zu drainagekanälen von äckern oder der entwässerung von autobahen treffen, allzu "x-beliebig" dürfen die auch nicht sein. --W!B: (Diskussion) 17:54, 31. Jul. 2019 (CEST)

In diesem Fall halte ich beide Seitenarme für nicht-artikeltauglich, da – abgesehen von der Energiegewinnung – völlig uninteressant. Ohne jegliche Besonderheit muss die Erwähnung im Hauptartikel ausreichen. Ich bin prinzipiell nicht gegen die Idee, jedem Geoobjekt einen eigenen Artikel zuzugestehen, sehe aber Seitenarme, die ohne den Fluss nicht da wären, einfach nicht als eigenständige Geoobjekte. --Clemens Stockner (Diskussion) 19:20, 31. Jul. 2019 (CEST)

So allgemein würde ich due Bedeutsamkeit nicht ausschließen wollen.

Aber es kommt noch ein Weiteres dazu: Namen, die nur mit (1) / (2) differenziet sind, sind gar keine Namen, sondern offensichtlich Behelfsbezeichungen. Dass sie unzureichend Semantik tragen, muss den nicht besonders interessieren, der ohnehin über seine Datenbankanwendung auf sie Zugriff nimmt. Aber für unsere Leser schon. Not-Lemmanamen bei geographische Gegenständen sollten schon etwas mehr „Lokalisierungs-Fleisch“ bieten, wie wie in unseren Lemma-Klammerdisambiguierungen oder etwas ungefähr in der Form Mühlkanal zur DINGSBUMSMÜHLE / Mühlkanal zur DINGSBUMSMÜHLE (GEMEINDENAME). Ich kenne es aus DE-BW, dass solche Notnamen leider äußerst sorglos vergeben werden. (Unzählige Orthographiefehler, manchmal veruneigentlicht und mnachmal nicht, indem ein Teil der Bezeichnung in Anführungszeichen gesetzt wird, bei Naturschutzgebieten beginnt die Bezeichnung gelegentlich und offenbar willkürlich mit dem Wort Naturschutzgebiet usw. Wenn man in AT hierin umsichtiger und konsistenter wäre: Gratulation!) Wenn so ein sagen wir mal Amtshydrologe zehn Jahre auf seinem Posten sitzt, dann braucht er die semantische Differenzierung nicht, da er weiß, welcher der erste und welcher der zweite am Lauf oder der erstvergebene und der zweitvergebene ist, zumal wenn er sie selbst auch noch getauft hätte. --Silvicola ^Disk 22:20, 31. Jul. 2019 (CEST)

Ich habe das Pöls-Dilemma jetzt einmal gelöst, wie oben besprochen, indem ich alle Informationen in den Hauptartikel gepackt und die anderen vier auf Weiterleitungen umgemodelt habe, die letzteren beiden unter den Amtsnamen Pölsfluß-Seitenarm (1) und Pölsfluß-Seitenarm (2). --Clemens Stockner (Diskussion) 22:55, 31. Jul. 2019 (CEST)

Ich schlage vor, die vielen Zuflüsse aus der Box herausnehmen und, richtig links-rechts verzahnt nach Reihenfolge der Mündungen am Fluss, stattdessen in ein neues Kapitel Zuflüsse zu schreiben. --Silvicola ^Disk 23:12, 31. Jul. 2019 (CEST)

danke, gut so. und @Zuflüsse: auf jedem fall. drin bleiben kann die auswahl der bäche >10km laut ÖK resp. >10km² laut FVZ (was für österreich immer eine gute grundmenge ist): es wäre überlegenswert, für diese beiden parameter der IB eine byte-obergrenze einzubauen, um das zu forcieren: steht zu viel eingetragen, sagt die IB genau das, was Silvicola sagt. --W!B: (Diskussion) 10:13, 4. Aug. 2019 (CEST)

Im Artikel bleiben können die schon alle. Siehe Usa (Wetter)#Zuflüsse.

In D gibt es auch die Schwelle für 10 km² - das betrifft aber den Zwang an die Behörden, einen Bach in die Verzeichnisse aufzunehmen und Werte zu ermitteln. Hängt wohl mit der Wasserrahmenrichtlinie zusammen.

Aber relevant sind auch kleinere. Ich persönlich hätte nur die Tendenz, nicht gleich alle rot zu verlinken. Es sei denn, ich hätte vor, sie alle zu schreiben. --Elop 12:50, 4. Aug. 2019 (CEST)

ich hab die tendenz, sie alle zu verlinken: keiner sieht nach, ob die im jeweiligen oberartikel nachzuverlinken wären, wenn man was schreibt. ausserdem ist es beim schreiben höchst hilfreich, die whatlinks befüllt zu haben. die rot-link-panik ist eine unsitte, die nur wartungsleichen produziert. wen es stört, der kann sich per CSS problemlos das rot auf mittelgrau oder ganz schwarz umfärben. wir (die community) aber haben beschlossen, dass wir zu unseren ungeschriebenen artikel stehen: die übernächste generation soll auch noch motiviert sein. daher sind sie im standard-CSS rot. verlinkt wird aber danach, was relevant ist, nicht, was geschrieben ist. bei 2 millionen artikel schafft das keiner mehr je, alles nachzuverlinken, wenn mans nicht gleich macht. und das wird mit 10 millionen artikeln nicht besser. --W!B: (Diskussion) 13:20, 4. Aug. 2019 (CEST)

SteEis scheint damit begonnen zu haben, sie alle anzulegen. Bestehen in der Hauptsache aus den Boxen.

Prinzipiell sind Rotlinks so etwas wie Wunschzettel. Deshalb würde ich bei zig Nebenbächen die 5 bis 10 verlinken, die dringend benötigt werden. Zumal es für Anleger eine dankbarere Aufgabe ist, Artikel zu schreiben, die auch von Menschen gelesen werden.

Daß jemand einen Kleinbach anlegt und sonst gar nichts, kommt, ungeachtet von Rotlinks, immer mal wieder vor - auch bei Bergen. Die Artikel werden aber immer schnell aufgefunden und verlinkt. --Elop 17:30, 4. Aug. 2019 (CEST)

Kategorie:Fluss vs Kategorie:Kanal

+ "Bestandteil eines Gewässers"

übrigens haben wir bisher keinerlei sinnvolle präzise abgrenzung der beiden. aktuell [LD Kategorie:Fließgewässer in ..] wird gerade geklärt, dass "Fluss" im Sinne der WP jedes fliessgewässer vom strom bis zum bächlein ist, Kategorie:Fließgewässer in der form also nicht sinnvoll (wobei hier noch die frage offen ist, wohin mit Kategorie:Quelle und Kategorie:Wasserfall, imho eine fehlende ‎Kategorie:"Fliessgewässerabschnitt"). offen ist aber insbesondere die frage in die "andere richtung", da nämlich auch kanäle fliessgewässer sein können. konkret bezieht sich das auf die beiden in der vordiskussion genannten Pöls-Seitenarm (1) und Pöls-Seitenarm (2): das sind zwei werkskanäle von kleinkraftwerken. die kann man – selbst wenn sie irgendwann im mittelalter einmal natürliche nebenarme waren – kaum als "fluss" titulieren. die sind doch relativ eindeutig "kanal". nur, was sei jetzt das genauere kriterium. der artikel Kanal (Wasserbau) gibt uns da keine in der praxis sinnvolle handreiche, da dort von Wasserstraße die rede ist. das hat mit dem konzept der kategorie überhaupt nichts zu tun, siehe Kategorie:Bewässerungskanal‎: Kategorie:Schifffahrtskanal‎ ist nur eine spezielle unterkategorie. was also sei das kriterium, dass ein kanal ein "kanal" ist? auch das wird bisher nur per stadt-land-berg-spielen gemacht, nicht auf fachkundlicher basis, sei sie wasserbaulicher, sei sie limnologisch-ökologischer natur. --W!B: (Diskussion) 08:16, 30. Jul. 2019 (CEST)

Es gibt auch noch den Prototypen Leinakanal: Künstliches Fließgewässer zum Zwecke der Wasserversorgung Gothas, erbaut 1369. --Elop 08:37, 30. Jul. 2019 (CEST)

Ich sehe eigentlich kein prinzipielles Problem. Fließwasserkanäle mit entsprechender Gewässerreigenschaft gehören schlicht doppelt kategorisiert.--Meloe (Diskussion) 19:25, 30. Jul. 2019 (CEST)

Eine Kategorie:Fliessgewässerabschnitt, für einmal ganz unsachlich und arbeitsökonomisch betrachtet, könnte viel Ärger machen. So wie viele vor allem Neulinge naiv auf der kategoriellen Trennung von Bach und Fluss bestehen, dürfte damit endlosen Streitereien zum Thema „Ist der Krümelbach nun der linke Oberlauf des Wuchtflusses und also ein selbständiges Gewässer oder ist das nur der erste Namensabschnitt des Wuchtflusses, da ihn etwa die GKZ mit diesem identifiziert?“ Allein die notorische Gewässernamensflurbereinigungsneigung der entsprechenden Ämter und Quellen neben den stärker differenzierenden Beschriftungen auf topographischen Karten dürften für steten Nachschub an Streitfällen sorgen. Denn die Abschnitte mit zuflussfernen Anfangs- und Endpunkten, die weniger plausiblen Anspruch auf Fluss-Eigenständigleit begründen, sind gewiss nicht die Mehrzahl. --Silvicola ^Disk 21:09, 30. Jul. 2019 (CEST)

Wozu sollte sie nütze sein? Fließgewässer bilden von Natur aus verzweigte Fließgewässersysteme. Diese werden in bewährter Manier nach dem größeren Einzugsgebiet kategorisiert, in dem sie jeweils liegen. Alle Zweifelsfälle folgern nur aus der, willkürlichen, Benennung durch den Menschen, indem Ober- und Unterläufe verschiedene Namen erhalten, ein willkürlich ausgewählter Quellast den Namen des Hauptlaufs erhält, während die anderen nur Nebengewässer sind etc pp. Im Normalfall ist jedes benamte Fließgewässer also ein "Fließgewässerabschnitt". Was einen eigenen Namen erhalten hat oder genügend eigenständig berichteswerte Eigenschaften aufweist, erhält ggf. einen eigenen Artikel. Aber doch bloß nicht eine eigene Kategorisierung.--Meloe (Diskussion) 21:27, 30. Jul. 2019 (CEST)

Wo ist das Problem? Ein Kanal ist künstlich, ein Fluss natürlich (auch, wenn er begradigt wurde). Wenn es um die Kategorisierung geht, sollte man es möglichst einfach halten. Eine Kategorie:Fließgewässerabschnitt halte ich auch nicht für sinnvoll, zumal es, wie von meinem Vorredner angesprochen, bereits die Flusssystems-Kategorien gibt, die einen guten Überblick liefern. --Clemens Stockner (Diskussion) 21:58, 30. Jul. 2019 (CEST)

oft ist leider nicht bekannt, ob ein mühlbach "natürlicher" oder "künstlicher" provenienz ist, da mittelalterlich-frühneuzeitlich angelegt. kann ein alter nebenlauf genauso sein wie irgendwann völlig neu gegraben. oder abschnittsweise das eine oder das andere. wenn aber fliessende kanäle sowieso doppelt kategorisiert werden sollen (als Kat:Fluss und als Kat:Kanal), ist diese unterscheidung hinfällig. kommt letzters also in die beschreibung der kategorie (die ja jetzt noch irreführend ist, wegen dem fehlenden/eine andere aussage treffenden hauptartikel), oder bleibt das unter projektinterne tipps & tricks?

und auch sonst läuft das nicht so bilderbuchmässig wie gewünscht: ein naturiert neu angelegtes hochwasserentlastungsgerinne ist vollkommen künstlich angelegt, und trotzdem kein kanal, sondern ein fliessgewässer. wo soll sowas hin? oder soll das davon abhängen, ob ein verlandeter nebenarm wieder durchgängig gemacht wurde, oder das gerinne "gänzlich neu" ist? die hydrographie hat endlose grenzfälle.

bei "Fliessgewässerabschnitt" hätte ich auch nicht an benannte abschnitte gedacht (die auch eigene flüsse sein könnten), sondern, wie in der diskussion ansgesprochen, wirklich kurzes wie die Kategorie:Wasserfall und Kategorie:Quelle. charakteristikum von "wirklich kurz" ist wohl, dass die nur eine artikelkoordinate haben, also nur als punktobjekt erfasst sind, nicht linienobjekt. man würde vielleicht von "nicht eigenständiger wasserkörper" sprechen, sie haben charakteristischerweise auch keine kennzahl, nichteinmal nach WRRL, dort wären sie nur trennstellen zweier wasserkörper. die sollen also auch als eigenständige fliessgewässer gelten? wenn es für wasserfälle gilt, gilt es auch für schwälle und wehre? wenn es für quellen gilt, gilt es auch für versickerungsstellen? übrigens gehts dabei nicht um die Flusssystems-Kategorien (dort steht das sowieso alles, keine frage), sondern den eintrag in die typologischen objektkategorien. --W!B: (Diskussion) 17:37, 31. Jul. 2019 (CEST)

Für einen Limnologen ist eine Quelle gewiss kein Fließgewässerabschnitt, das Fließgewässer beginnt (mit dem Quellbach) unterhalb der Quelle. Und ein Wasserfall, als punktuelle Struktur, ist ebenfalls kein Abschnitt. Es ist eine zum Fließgewässer gehörige Struktur, wie etwa ein Kolk, eine Schnelle, eine Kiesbank oder -insel. Der Hauptunterschied kommt wohl daher, dass Wasserfälle oft benamt sind, die anderen Gewässerstrukturen oft nicht. Wenn´s künstlich ist (etwa ein Streichwehr oder ein Mühlwehr), wäre es ein Querbauwerk. Alle diese Fälle gehören eigenständig kategorisiert, eine Zusammenführung unter Fließgewässer ist nicht nur fachlich anfechtbar (auf welcher Grundlage soll zugeordnet werden?), ich kann auch keinen konkreten Nutzen erkennen. Eine Aufsplittung in "Bach" oder "Fluss" ist ebenfalls vermintes Gelände, da es mehrere Klassifikationsschemata nebeneinander gibt. In Europa wäre das noch lösbar, etwa indem man die Schwellenwerte der WRR übernimmt. International sieht´s aber trübe aus. Ich hatte das Problem vor einiger Zeit mal beim Gewässerbett, bei dem Bachbett und Flussbett letztlich WL wurden, weil es anders nicht lösbar war.--Meloe (Diskussion) 18:10, 31. Jul. 2019 (CEST)

Um wieder zum Thema zurückzukehren: Für meinen Teil könnte ich damit leben, dass in Kategorie:Fluss (mehr oder weniger) natürliche, fließende Gewässer einsortiert werden, in Kategorie:Kanal die künstlichen Gewässer mit länglicher Struktur (damit wären Talsperren raus, Schifffahrtskanäle drin). Und wie in der Diskussion schon genannt, Wasserfälle und Quellen sind für mich eigenständige Objekte und gehören auch so kategorisiert (Kategorie:Wasserfall bzw. Kategorie:Quelle). --SteveK ?! 21:36, 31. Jul. 2019 (CEST)

eigenständige Objekte sowieso, die frage ist, ob eigenständige Objektklasse, also eigenständiger kategorienzweig. wenn sie keine "fliess-"gewässer sind (das problem liegt ja nicht im "fliessen", das tun sie ja), sind sie auch keine Kategorie:Gewässer. sie sind eigenständige hydrographische objekte neben Kat:Gewässer. daher meine idee mit dem "Fliessgewässerabschnitt". oder, wie Meloe oben richtig sagt, soetwas muss nicht unbedingt ein "abschnitt" der länge nach sein; ausserdem, wenn man das auch auf stillgewässer erweitern würde (denn auch zu denen werden wir etlich kategorien relevanter teilkörper bekommen, insb. etwa Kategorie:Bucht), wäre es sowieso "Teil eines Gewässers". das entspräche irgendwie Kategorie:Bauwerksteil (unselbstständig: trakte, nebenbauten, höfe, auch einzelne zimmer) vs. Kategorie:Bauwerk. dort haben wir ja ähnliche problematik. und dort klappt das recht gut. --W!B: (Diskussion) 08:26, 2. Aug. 2019 (CEST)

Beim Wasserfall ist es jetzt schon ein eigenständiger Zweig, siehe Kategorie:Wasserfall. Die Einordnung in die Kategorie:Fließgewässer ist das, was für mich fragwürdig ist. Für die Auffindbarkeit ist die Einordnung "Fliessgewässerabschnitt" nicht notwendig, denn wer Wasserfälle über Kategorien finden will, der wird direkt Kategorie:Wasserfall aufrufen oder PETSCAN ab der Wunschkategorie starten. Und für Kategorie:Quelle gilt das gesagte analog. --SteveK ?! 10:38, 2. Aug. 2019 (CEST)

Momentan hat die Kat Gewässer folgende Unterkats:

• Hydronym‎ (1 K, 98 S)
• Bucht‎ (5 K, 11 S)
• Fließgewässer‎ (7 K, 28 S)
• Flussdelta‎ (17 S)
• Künstliches Gewässer‎ (5 K, 2 S)
• Lagune‎ (2 K, 66 S)
• Liman‎ (1 K, 5 S)
• Meer‎ (3 K, 5 S)
• Meerenge‎ (3 K, 8 S)
• Priel‎ (1 K, 18 S)
• Stillgewässer‎ (6 K, 62 S)

Warum sollte man dort nicht zügig Wasserfälle und Quellen finden? Beides sind Objekte, die man nicht unbedingt unter "Fließgewässer" erwartet. --Elop 11:05, 2. Aug. 2019 (CEST)

Liest eigentlich irgendwer die Einleitung zu den Kategorien? In der Kategorie:Gewässer sollen Artikel eingeordnet werden, die die Bedingung "ist ein Gewässer" erfüllt. Wenn ich dann höre (besser sehe), dass dort Kategorie:Hydronym‎ einsortiert wird, dann bekomme ich Pickel. Das gehört in die Kategorie:Gewässer als Thema einsortiert. Das ist mittlerweile alles nicht mehr nach einer Logik aufgebaut, die man auch durchschauen kann. Wenn ich mir das anschaue, dann müsste man auf die Struktur

• Gewässer

• Künstliches Gewässer

• Kanal
• Stausee

• Natürliches Gewässer (Wenn künstliches Gewässer, dann auch natürliches Gewässer)

• Fluss
• Meer
• See

• Fließgewässer

• Fluss
• Kanal (Graben)

• Stillgewässer (Wenn Fließgewässer, dann auch Stillgewässer)

• Meer
• See

• Stausee

kommen. "Bucht" ist so ein Ding, das würde ich ebenso wenig wie "Küste", "Ufer" als Gewässer titulieren, das sind Themen zu Gewässern. Sinnigerweise sollte das dann auch innerhalb einer Themenkategorie Kategorie:Gewässer als Thema auftauchen. Aber das zu diskutieren wird ziemlich aufwändig. Bei der Vorschau gerade gesehen: Stauseen sind Seen, aber halt künstliche. Wenn man die Stauseen wie bisher als Unterkat zu See führt, dann ist der Stausee auch ein natürlicher See. --SteveK ?! 16:16, 2. Aug. 2019 (CEST)

Soweit nachvollziehbar. Die Doppelkategorisierung unter Natürliches Gewässer vs. Still-/Fließgewässer gehört aber vermieden. Außerem ist das Meer kein "Stillgewässer" im Sinne der üblichen Def.

• Natürliches Gewässer
  • Meer
  • Binnengewässer
    • Fließgewässer
    • Stillgewässer

gefiele mir besser.--Meloe (Diskussion) 18:52, 2. Aug. 2019 (CEST)

Ich will das ja nicht machen, weil ich es nicht brauche. Ich gebrauche Kategorien nur, wenn ich etwas abarbeiten will. Der Versuch mit Kategorien die Welt abbilden zu wollen, führt immer wieder zu Problemen. Ich habe mal in deiner Struktur nur den Kanal (deswegen diskutieren wir in diesem Abschnitt eigentlich) hinzugefügt, und siehe da, wir haben da ein Problem weil es stehende und fließende Kanäle gibt:

• Natürliches Gewässer

• Meer
• Binnengewässer

• Fließgewässer

• Kanal (fließend)

• Stillgewässer

• Kanal (stehend)

Für meinen Teil brauche ich das nicht, denn ich weiß das ein Fluss ein mehr oder weniger natürlicher Wasserlauf ist / ein Kanal ein künstlich angelegtes Gewässer ist, dass je nach Nutzung fließend oder stehend ist, usw. (gehört meiner Meinung nach zur Allgemeinbildung). Und da wir hier nicht die Zuordnung noch mit Eigenschaften versehen können, entstehen immer wieder diese Probleme. --SteveK ?! 21:03, 2. Aug. 2019 (CEST)

das, was du weisst, ist aber irrevant. dann bräuchten wir auch die Kat:Gewässer nicht, denn ich weiß, dass ein fluss ein gewässer ist und ein berg nicht. der sinn der typologioschen objektkategorien ist in der gesamten WP nicht zum zwecke des findens (wozu sollte man einen mensch als "person" kategorisieren, man weiss, dass er einer ist). der sinn, das überhaupt zu machen, ist darauf aufbauendes Data-Mining.

das problem liegt aber umgekehrt, es geht nicht drum, wo man nachschlägt, sondern, was man konkret in die artikel einträgt: denn, ist ein typologischer ast erst einmal begonnen, muss ihn halbwegs vollständig umsetzen, damit er sinn hat. heisst, in jeden geoartikel (auch gewässerartikel) soll zumindest eine geowissenschaftliche (in dem fall: hydrologische) typologische kategorie. und wenn man eine klasse verfeinert, muss man das halt mit fachkunde machen. das zu diskutieren wird natürlich "ziemlich aufwändig", aber das ist der eigentliche sinn und zweck dieses projekts hier: gewässerartikel schreiben kann jeder, sie systematisieren ist fach-arbeit.

jedenfalls – langer rede kurzer sinn – sollte man tunlichst die einzelnen fachgebiete der hydrographie nicht vermatschen: basisstruktur ist:

• Fliessgewässer nach „Fliess-Eigenschaft“ (fliessend, stehend, ..)
• Fliessgewässer nach "Entstehung" (natürlich, künstlich, ..)

ist uns eh allen klar. aber die zwei gehören nicht verschnitten (aus genau dem grund splittet sich nämlich die Kat:Kanal). ungünstig bei gewässern ist ja nur, dass die hauptgliederungen nur immer je zwei, max drei diametrale gruppen umfassen (meer – binnen / salz- – süßwasser; stehend – fliessend, natürlich – künstlich, linienobjekt – flächenobjekt, usf), dass also eine menge irgendwie unnützer sortierstrukturen entsteht. die eigentliche frage ist eher, welche hierarchieebenen man rausstreichen kann. prekär ist diese frage insbesondere darum, weil die grundstruktur ja 100000fach in "nach Stadt-Land-Gemeinde", nach Kontinent und Meer, nach Region und anderem gespieglt werden muss: jede einzelne kategoire, die hier angesprochen wird, produziert sofort 10000 kinder: das ist der sozusagen fix in den kategorien verdrahtete teil des data-minings, jeder aus der heimatkunde-ecke will sich so schnell wie möglich "die seinen" rausklamüsern. das ist das kernthema: die frage, was sowohl fachlich korrekt wie auch effizent ist.

und dazu kommt, dass eben "ich weiß das ein Fluss natürlich / ein Kanal künstlich" ist, binsenweisheiten sind, nicht enzyklopädiearbeit. klar, ein paar fachleute kriegen das auch im einzelfall sicher hin, aufgabe des fachprojekts ist es aber, strukturen für die interessierten laien anzulegen (nämlich die, die die gewässerartikel dann auch wirklich schreiben). und, dass es leider betriebsblindheit ist, gerade in der hydrologie: je genauer man nämlich hinsieht, desto mehr sonder- und mischfälle gibt es bei gewässern, die so gar nicht in das o.g. diametrale schema passen wollen. und genau drum wirds halt schnell reines stadt-land-berg-spielen (das, was du "Allgemeinbildung" nennst). und genau so sieht der kategorienbaum dann auch schnell aus. und sein inhalt. wenn also die strukturen nicht fachlich fundiert sind, wirds der inhalt sowieso nie sein.

und "genauer hinsehen" tun wir halt, was vor 10 jahren für ein paar 1000 gewässerartikel geklappt hat, ist heutzutage schon lange keine garantie mehr. und wir werden die nächsten 10 jahre noch viel genauer hinsehen, keiner kann abschätzen, über was alles wir 2030 artikel haben werden. --W!B: (Diskussion) 09:46, 4. Aug. 2019 (CEST)

Data-Mining wie du so schön schreibst, wird mit der Technik die wir hier anwenden nicht wirklich funktionieren. Man kann halt hier nicht eine Eigenschaft bei der Kategorisierung anfügen, etwa [[:Kanal|fließend]]. Dafür ist eine Datenbank wie Wikidata besser geeignet als das Kategoisierungskonzept, dass in der WP gelebt wird. Und die Zeit, die verschwendet wird für die Anlage von 10000den Kinderkateorienen, die kann man sicher sinnvoller nutzen. Und das werde ich gewiss jetzt tun und die Diskussion hier nicht mehr weiter verfolgen.

Ein Hinweis: Fliessgewässer nach „Fliess-Eigenschaft“ (fliessend, stehend, ..) das ist ein Widerspruch in sich selbst, da ich keine stehenden und gleichzeitig fließenden Gewässer kenne.

--SteveK ?! 22:47, 4. Aug. 2019 (CEST)

oder WP:Facettenkategorisierung: "Kanal" + "Fliessgewässer" = "Kanal mit Strömung / durchflossener Kanal": unsere kategorien stellen die basisstruktur, über die sowas wie petscan datamining betreiben kann. je mehr schnittmengenkategorien, desto mehr unnützer ballast, aber je mehr facetten, desto reichhaltiger das bild. wikidata beruht schon genau auf diesem facettieren, zeigt aber auch schon wieder tendenzen zu verschnitten. keine ahnung, was daran so reizvoll sein soll.

und PS: 0 ist auch eine zahl ;) und auch du bist hier noch im stadt-land-berg-spielen unterwges: doch, ich kenne kaum ein gewässer, das nicht irgendwo stehende und fließende abschnitte hat. totwasser gibts überall. und selbst ein see hat einen durchfluss. nur halt sehr langsam. da sagt die limnologie, dass fließgeschwindigkeiten von einigen m / tag zwecks systematik auch nur als fließgeschwindigkeit = 0 gelten. sowas nennt sich mittelwertbildung und runden. das ist fachkunde anstatt "allgemeinbildung". --W!B: (Diskussion) 12:58, 5. Aug. 2019 (CEST)

Du erzählst mir hier nix neues. Ich habe schon vor Jahren aufgegeben bei den Kateorien auf die Schnittmengenbildung zu setzten. Leider lassen sich Facettenkategorien nicht durchsetzen. Und das du mich zu den Stadt-Lang-Berg-Spielern zählst, ist für mich beleidigend (ohne das es ein PA ist, du weißt schon warum). --SteveK ?! 22:23, 5. Aug. 2019 (CEST)

Relevanzkriterien

Hallo. Tipp an alle Freunde des Portals: Bitte die angeblich existierenden RKs auch austreichend verlinken. Irgendwelche RKs auf einer "Hinterzimmerseite" ohne das man von WP:RK dorthin finden kann, sind in ihrer Gültigkeit in Abrede zu stellen. Zur Legitimation gehört auch, den Werdegang (Diskussion) der RKs zu dokumentieren (Link dorthin). Wenn dann noch etwaige eigenmächtige Änderungen einzelner User wieder revertiert werden, dann sind diese RKs auch bindend. Gruß von ÅñŧóñŜûŝî (Ð) 10:34, 4. Aug. 2019 (CEST)

ÅñŧóñŜûŝî: die einzigen für gewässer relevanten RK sind die RK Geoobjekte "was benannt ist". dass die dort mit ihren kriterien die endlosen kleinstgewässer, die in modernen GIS-systemen eingetragen sind, als per-se-relevant deklariert haben, ist nicht unser problem. GIS gelten als "Landkarte / Nachschlagewerk / Fachliteratur" im sinne der WP. anfragen dazu in WP:GEO.

hier diskutieren könnten wir, ob eintrag "unbenanntes Gerinne" im Wasser-GIS schon "benannt im sinne der wp" ist ;) kommt sicher bald einmal wer auf die idee, uns Unbenanntes Gerinne (Donau, bei Hintertupfing) so spendieren. --W!B: (Diskussion) 13:32, 4. Aug. 2019 (CEST)

Das ist eine "viel zu wässerige" RK und das ist auch total veraltet. Ich kann mich auch nur an eine Diskussion um Orte erinnern. ÅñŧóñŜûŝî (Ð) 13:36, 4. Aug. 2019 (CEST)

Diese RK wurde am 13. Oktober 2008, tief in der Nacht, von Benutzer Gestumblindi mit dem Hinweis auf diese Diskussion ergänzt. Sie ist also gut zehn Jahre alt und es zeigt sich, dass sie so allgemein nicht mehr zeitgemäß sind. Es wird höchste Zeit, dass der Bereich Geografie präzisere RKs ausarbeitet. Im Unterschied zu den Orten, wo jeder sein kleines Kaff für relevant hält, weil der größte Misthaufen darin die Drei-Meter-Marke übersteigt, dürfe es bei Gewässer weniger emotional zugehen. Zumindest die Frage, wann man zusammenfasst, sollte man klären können. Niemand will ernsthaft Werra, Fulda und Weser in einem Artikel verschmelzen, aber es macht keinen Sinn, jeden Drainageauslauf mit mehr als zehn Liter pro Minute mit einem Artikel zu versehen. ÅñŧóñŜûŝî (Ð) 14:01, 4. Aug. 2019 (CEST)

das mag sein, aber es ist seit 10 jahren usance auf den löschseiten: viele unserer regeln werden durch die gelebte praxis tradiert. wir haben bei weitem nicht alles niedergeschrieben, was gilt. das ist in jeder sozialstruktur so, auch der wp. solche regeln erkennt man erst, wenn man dagegen verstößt. also einen LA auf etrwas stellt, der dann einfach schlicht einen LAE mit hinweis darauf bekommt, und keiner wiederspricht dem. respektive ein BNS angehängt bekommt, wenn man doch widerspricht. dann weiss man, dass es da doch eine regel gab. ist im alltag ja auch nicht anders. wir sind nur eine horde gepimpter primaten ;) --W!B: (Diskussion) 13:06, 5. Aug. 2019 (CEST)

Der Drainageauslauf hat in der Regel keinen Namen. Mich würde interessieren, ab wann denn für dich ein Gewässer relevant ist. --SteveK ?! 22:54, 4. Aug. 2019 (CEST)

Man kann jedem Trainageauslauf einen Namen geben und die Eintragung bei der Kommune beantragen. Kommt der Antrag durch, was je nach Laune des Sachbearbeiters sein kann, dann hat der Trainageauslauf einen offiziellen Namen... Zum Thema wann Relevanz (Zahlenwerte vorläufige Schätzungen)

• nat. stehendes Gewässer:
  • exponierte Lage (mitten in einer Metropole)
  • (weitgehendes) Alleinstellungsmerkmal (meromiktisch, endemische Fauna oder Flora, etc)
  • So groß, dass man entweder garnicht oder nur als geübter Schwimmer durchschwimmen kann (ca. 1 km, evtl. auch 2 km)
  • tiefer als.. ( Grenzwert bei 50 m bis 100 m)
• nat. Fließgewässer:
  • exponierte Lage oder ungewöhnlicher Verlauf wie z.B. "fliest durch sehr trockenes Gebiet", "durchfließt einen Berg", "Trinkwasserresource für viele Menschen", ungewöhnlich
  • (weitgehendes) Alleinstellungsmerkmal (z.B. die stehende Surferwelle im Münchner Eisbach, ein hoher Wasserfall, bedeutend im Wassersport)
  • Länge mind. 10 km,
  • Wasserführung (hier habe ich keinen Zahlenwert vor Augen, müsste ich recherchieren)
• künstlisches Gewässer:
  • Erfüllt die RK für ein nat. Gewässer; oder
  • ungewöhnliche (Bau-)geschichte (Unfälle, Katastrophen, etc.)
  • (weitgehendes) Alleinstellungsmerkmal (kulturelle Bedeutung)

So in etwa würde ich die Grenze ziehen. ÅñŧóñŜûŝî (Ð) 20:34, 5. Aug. 2019 (CEST)

Danke für die Antwort. Das sieht sich ganz nach überschäumender Regelwut aus. Statt die RK immer weiter zu verkomplizieren sollten sie eher einfacher werden. Das ist aber nur meine bescheidene Meinung zu dem Thema.--SteveK ?! 22:30, 5. Aug. 2019 (CEST)

Das wäre eine massive Verschärfung gegenüber dem Status quo, der eigentlich nicht mehr als einen veröffentlichten Namen fordert. Für mein Gefühl wäre dass zu restriktiv. In D wird ggf. die Gewässereigenschaft nach den im WHG genannten Kriterien festgestellt, wenn es zum Streit kommt. Etwa an diesen Kriterien würde ich größenordnungsmäßig mich hier auch orientieren wollen.--Meloe (Diskussion) 08:11, 6. Aug. 2019 (CEST)

Das wäre nicht nur eine massive Verschärfung, das wäre auch ziemlich unbrauchbar. Der Mummelsee wäre im Zweifelsfall nicht relevant, da kleiner und flacher, Lage wäre wohl strittig, Karsee als Alleinstellungsmerkmal ist auch fraglich, ob endemische Fauna oder Flora vorliegt habe ich nicht geprüft (wird aber auch im Artikel nicht erwähnt). Ähnlich ist das auch bei den Fließgewässern. Der Orlacher_Bach wäre wohl auch irrelevant, zumindest nach Länge und mittlerer Wasserführung. --SteveK ?! 10:22, 6. Aug. 2019 (CEST)

RKs sollen eine Orientierung geben. Einzelfälle kann man gewiss diskutieren. Dazu benötigt man eine portaleigene Seite für Löschkandidaten. Qualität bekommt man im Leben meist nur durch Fleiß und spezifischere RKs samt LDs wären der Arbeitsaufwand für ein besseres Qualitätsniveau bei den Gewässern. ÅñŧóñŜûŝî (Ð) 21:24, 7. Aug. 2019 (CEST)

Selbst wenn wir alle Gewässer bis auf eines löschten, würde dessen Artikel dadurch um kein Gran qualitätsvoller. Irgendwo lauert in Deinem Argument „Qualität durch Löschung“ ein Fehlschluss, vermutlich ist das der modus procrustes.

Zu konzedieren ist allerdings, dass die Arbeit auf Löschdiskussionsseiten so manchem angenehmer dünken mag als die an den Gewässern selbst. Bezogen auf die Artikelqualität ist das Argument wiederum kognitiv verzerrt, nämlich durch Sympathie-und-Antipathie-Heuristik.

Malcolm X schreibt m.E.n. irgendwo autobiographisch, in der Schule habe ihn das Thema Mathematik sehr angesprochen, er habe aber eingesehen, dass sie eben doch nichts für ihn sei, denn “there was no room for argument”.

--Silvicola ^Disk 22:07, 7. Aug. 2019 (CEST)

Ich bin dafür, die RK für Gewässer nicht zu ändern, es besteht einfach kein Grund dazu. Wenn es schlechtre Artikel geben sollte, dann kann man die hier ja zur Diskussion und Verbesserung einstellen. Löschen ist immer der schlechtere Weg. --SteveK ?! 22:27, 7. Aug. 2019 (CEST)

Approbo. Bene dixit Stephanos. --Silvicola ^Disk 22:31, 7. Aug. 2019 (CEST)

Kategorisierung von Rückhaltebecken

Werden auch Rückhaltebecken mit nur periodischem Einstau als See in die jeweilige Flusssystem-Kategorie gestellt? Oder nur solche mit Dauereinstau?

Beispiel Hochwasserrückhaltebecken Wental, sperrt ein Trockental der Schwöbischen Aln. Karte Wer weiß, ob die Grillen auf dem Beckengrund je von überraschendem Zufluss molestiert worden sind.--Silvicola ^Disk 23:08, 27. Aug. 2019 (CEST)

"In dieser Kategorie werden Artikel zu Gewässern (Flüsse, Seen, Kanäle, Moore) erfasst ...". Da es kein Gewässer ist, gehört es m.E. nicht rein.--Meloe (Diskussion) 13:23, 28. Aug. 2019 (CEST)

@Silvicola, Meloe: Es gibt in den Flusssystemkategorien doch den Abschnitt „F“ wie „Feuchtgebiet“! -- Olaf Studt (Diskussion) 22:50, 20. Sep. 2019 (CEST)

Ein "Feuchtgebiet" kann auch ein Gewässer sein, z.B. nach der Ramsar-Konvention: "Feuchtgebiete im Sinne dieses Übereinkommens sind Feuchtwiesen, Moor- und Sumpfgebiete oder Gewässer, die ...". Das hier behandelte Becken ist keines.--Meloe (Diskussion) 08:05, 23. Sep. 2019 (CEST)

Das hier ist eher ein Trockengebiet.

Wie hält man es mit zeitweise wasserstauenden Rückhaltebecken? Oder mit ehemaligen Gewässern? --Silvicola ^Disk 09:02, 23. Sep. 2019 (CEST)

Kategorie:Ehemaliges Gewässer--Meloe (Diskussion) 09:14, 23. Sep. 2019 (CEST)

Danke für den letzten Punkt. --Silvicola ^Disk 20:27, 3. Okt. 2019 (CEST)

Homonyme Zuflüsse.

Längere Fließgewässer haben oft zwei oder mehr Zuflüsse gleichen Namens. Wenn diese in den Zuflusslisten nahe beieiander stehen, sollte man wohl ein (!) oder (sic!) lesbar am Namen anfügen, damit nicht von Lesern Nachlässigkeit beim Aufstellen der Liste unterstellt wird. Es ist ja nicht so, dass uns (pluralis auctoris) solche nie unterliefe.

Wie aber, wenn die Homonyme in längern Listen nun recht weit voneinander entfernt stehen? Ein angefügtes (!) oder (sic!) wäre dann aus dem nahen Kontext heraus jedenfalls nicht selbsterklärend, also vielleicht eher rätselhaft als hilfreich. Soll man überhaupt in solchem Fall auf die Namensgleichheit hinweisen? Wenn ja, mit welcher möglichst selbsterklärenden Markierung oder mit welcher anderen Technik? Die Gefahr im Falle der Nichtmarkierung für den Leser ist wohl, dass er nach dem ersten erfolglosen unpassenden Suchtreffer die Suche unter den Zuflüssen sofort einstellt, weil er unbedacht wähnt, da käme wohl nichts anderes mehr.

Wie sind die Meinungen hierzu? --Silvicola ^Disk 20:39, 3. Okt. 2019 (CEST)

Normalerweise dürften in so einem Fall die Einmündungen in verschiedenen Orten liegen. Einfach die Ortslage der Mündung in Klammern ergänzen, also sowas wie "Dorfbach (Hintertupflingen)" und "Dorfbach (Vordertupflingen)". Damit sind die Einträge unterscheidbar. ÅñŧóñŜûŝî (Ð) 21:25, 3. Okt. 2019 (CEST)

Wer von den Gewässernamen her sucht und nicht die Orte kennt (oft sehr kleine), dem hilft das aber auch nicht. Daneben gibt es auch Fälle, wo man nur schwer oder gar nicht ein verständlich differenzierendes Kriterium findet. (Beispiel Hagenbach, mit hier zugegebenermaßen nahem Zusammenhang, so daß also das sic genügt). Mein Frage ist: Brauchen die Leser einen Nasenstüber, dass es noch einen anderen Zufluss gleichen Namens woanders gibt, oder ist dieser Nasenstüber verzichtbar? --Silvicola ^Disk 11:03, 4. Okt. 2019 (CEST)

Au weia, dass ist schon ein Extremfall. In einer Liste ist m. E. eine Zahl in Klammern besser: "Hagenbach (1)" und "Hagenbach (2)" ÅñŧóñŜûŝî (Ð) 14:42, 4. Okt. 2019 (CEST)

Französische Gewässerdatenbank SANDRE

Hat jemand von Euch eine Ahnung, was mit sandre.fr los ist? Seit Tagen bekomme ich bei allen links aus WP und direkten Suchvorgängen immer nur die Meldung "Cet objet géographique n'a pas été trouvé"... Grüße --Skipper69 (Diskussion) 15:25, 8. Nov. 2019 (CET)

Auch bei mir unbrauchbar, aber anders. Bei Einstieg über die SANDRE-Belege bzw. Klick auf die GKZ bei den Artikeln hier komme ich stets auf eine Seite « Résultats de Recherche », und zwar anscheinend mit immer denselben Ergebnissen, vorne dran steht einheitlich« [S6001490] Barranco de Akaerreza ». Andere Einstiege haben bei mir ohnehin nie so recht funktioniert.

Schlimmstenfalls hat man bei SANDRE die URLs verändert. Das erklärte allerdings noch nicht das Scheitern der direkten Suchvorgänge. Hast Du schon längeren Wartungsintervallen bei SANDRE erlebt? (Ich selbst greife dort nur sehr sporadisch zu.) --Silvicola ^Disk 15:59, 8. Nov. 2019 (CET)

Hallo Silvicola, nein, sowas habe ich auch noch nicht erlebt. Ich erinnere mich zwar an vermutliche Wartungsarbeiten an manchen Wochenenden, aber da kam gar keine Antwort zurück (endloses "Uhr"-Symbol) und es waren auch meist auch nur bestimmte Gewässerbereiche betroffen... --Skipper69 (Diskussion) 16:17, 8. Nov. 2019 (CET)

Hier die Antwort vom sandre-Kundendienst:

..."Nous avons reçu le nouveau référentiel des cours d'eau et nous sommes actuellement en train de reconstituer les fiches cours d'eau. Les fiches sont accessibles au fur et à mesure de cette mise à jour qui sera terminé très prochainement. Nous sommes désolés pour se désagrément..." --Skipper69 (Diskussion) 11:08, 12. Nov. 2019 (CET)

Man sieht wieder einmal: Über mangelnde Höflichkeit von ihrer Seite kann man sich gegenüber Franzosen sicher nicht beschweren. Aber meine Verlagsbuchbestellungen in Frankreich dauern immer um die sechs Wochen. --Silvicola ^Disk 11:52, 12. Nov. 2019 (CET)

Da sind sicher die Gelbwesten dran schuld ... ;-)) - aber bei sandre hat sich auch noch nichts verbessert! --Skipper69 (Diskussion) 11:49, 15. Nov. 2019 (CET)

So, SANDRE funktioniert wieder. Sie haben jetzt die beiden bisher getrennten Bereiche (Daten und Karte) zusammengelegt.--Anarabert (Diskussion) 23:10, 18. Nov. 2019 (CET)