Vorlage Diskussion:Infobox Fluss/Archiv/3

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

Weitere Einzugsgebietsangaben

Infobox Fluss/Archiv/3
Daten
Einzugsgebiet	219,321 km²
EZG2	ca. 848 km²
EZG3	ca. 848 km²

Zur Info:

Es wurde hier vor kurzem diskutiert, ob man in der IB mehrere Werta0ngaben vorsehen kann. Ich habe das heute vor die Einzugsgebiete umgesetzt. Mit der Untervorlage Vorlage:Infobox Fluss/EZG kann man im vorhandenen Parameter EINZUGSGEBIET_SUFFIX weitere Wert darstellen. Für das Beispiel wurde folgender Code verwendet:

{{Infobox Fluss
| EINZUGSGEBIET-PREFIX= 
| EINZUGSGEBIET= 219.321
| NACHWEIS-EINZUGSGEBIET= 
| EINZUGSGEBIET-SUFFIX= {{Vorlage:Infobox Fluss/EZG|NOLINE=JA|BEZ=EZG2|PREFIX=ca.|WERT=848|NACHWEIS=|NOAUTOKAT=Ja}}{{Vorlage:Infobox Fluss/EZG||BEZ=EZG3|PREFIX=ca.|WERT=848|NACHWEIS=|NOAUTOKAT=Ja}}
}}

Die genaue Beschreibung muss ich noch erstellen. Meinungen und Hinweise sind willkommen.--SteveK ?! 11:47, 22. Mär. 2013 (CET)

Kategorien bei NOAUTOKAT= ja

Wurde da jüngstens etwas an der Autokategorisierung geändert? Aus dem Artikel Belaja (Angara) wurden schon am 20. Februar trotz „NOAUTOKAT= Ja“ die hartcodierten Kategorien entfernt, und erst heute wurde er vom MerlBot in die QS eingeliefert. -- Olaf Studt (Diskussion) 12:18, 5. Apr. 2013 (CEST)

Ich habe zwar gestern etwas geändert, das bezog sich aber nicht auf die Anwendung von NOAUTOKAT. Ich kann mir das nicht erklären. Vielleicht hinkt aber auch der MerlBot etwas hinterher.--SteveK ?! 14:48, 5. Apr. 2013 (CEST)

Wartungsliste für veraltete Parameter

Die Vorlage nutzt für die Wartungsliste Spezial:Linkliste/Vorlage:Infobox Fluss/Veraltet (die auf der Wartungsseite übrigens fehlt) ein äußerst kompliziert wirkendes Konstrukt aus zur Zeit insgesamt 7 #ifeq und 14 Untervorlagen. Das kann wie folgt auf 1 #ifeq und 0 Untervorlagen reduziert werden, was entsprechend die Parserlimits reduziert.

{{#ifeq: {{{DGWK|x}}}{{{QUELLE_LAT_MIN|x}}}{{{QUELLE_LAT_SEK|x}}}{{{QUELLE_LONG_MIN|x}}}{{{QUELLE_LONG_SEK|x}}}{{{ABFLUSSMENGE|x}}}{{{BEKANNTE BRÜCKEN|x}}} | xxxxxxx || <span style="display:none">[[Vorlage:Infobox Fluss/Veraltet]]</span>}}

Als einziger funktionaler Unterschied wird dann nicht mehr erkannt, wenn ein Parameter in einem Artikel zufällig mit einem „x“ ausgefüllt ist. Das ist praktisch aber irrelevant. Auch jetzt gibt es einen Sonderfall, der nicht erkannt wird, die Zahl der potentiellen Fehlerkennungen ändert sich also nicht. --TMg 23:59, 18. Apr. 2013 (CEST)

Die Wartungsliste ist entstanden, um zu entfernende Parameter (mit und ohne Inhalt) zu erkennen. Das würde ja auch über die Vorlagenauswertung gehen, nur ist die leider nicht aktuell. Dabei habe ich wohl zu kompliziert gedacht. Ich habe dein Konstrukt eingebaut und auf "ABFLUSSMENGE" und "BEKANNTE BRÜCKEN" beschränkt. Danke für den Hinweis. --SteveK ?! 09:58, 22. Apr. 2013 (CEST)

Danke dir. Es kann manchmal sinnvoll sein, solche Prüfungen zu behalten, wenn bestimmte Parameter hartnäckig immer wieder auftauchen. Aber meist sollte man sie wieder entfernen, wenn der Parameter nirgends mehr vorkommt, um nicht wirkungslosen Code mitzuschleppen. --TMg 00:46, 23. Apr. 2013 (CEST)

ca.

Das hattest du mit wegrevertiert:

{{#if: {{{QUELLHÖHE-PREFIX|}}} | ca. | {{#if: {{{MÜNDUNGSHÖHE-PREFIX|}}} | ca. }} }}
{{#if: {{{QUELLHÖHE-PREFIX|}}}{{{MÜNDUNGSHÖHE-PREFIX|}}} | ca. }}

--TMg 00:55, 23. Apr. 2013 (CEST)

Gemeint war was anderes und eigentlich ist beides nicht korrekt. Habe den Ausdruck beim Höhenunterschied ganz entfernt.--SteveK ?! 22:48, 23. Apr. 2013 (CEST)

Sicher? Jetzt ergibt sich beim Beispiel in der Vorlagendokumentation, dass sowohl bei Quell- als auch bei Mündungshöhe ein „ca.“ steht, beim Höhenunterschied aber eine Zahl ohne Präfix. Täuscht das nicht eine Genauigkeit vor, die nicht gegeben ist? --TMg 22:54, 23. Apr. 2013 (CEST)

Wenn bei einem Prefix steht "Aabach", dann kommt auch das "ca.". Und abfragen ob "ca." drin steht macht auch nicht wirklich Sinn, denn oft genug steht "etwa" anstelle von "ca.". Wer die Höhenangaben mit "ca." sieht, der sollte auch wissen das dann auch die Differenz ungenau ist. Deshalb nach reiflicher Überlegung mein einsamer Entschluss es zu entfernen. Mal schauen ob es Beschwerden hagelt.--SteveK ?! 23:21, 23. Apr. 2013 (CEST)

Oder wenn man als Präfix zweimal „genau“ hinschreibt. ;-) Eine Abfrage auf bestimmte Präfixe wäre gar nicht so schlecht. Dann wird zumindest in den eindeutigen Fällen das Präfix auch vor die Differenz gesetzt. Vor allem bei der Quellhöhe wäre das hilfreich, weil die so weit weg vom Höhenunterschied steht. Bei der Mündungshöhe hast du völlig Recht, die steht ja in der Zeile direkt darüber. --TMg 23:33, 23. Apr. 2013 (CEST)

{{#switch: {{#if: {{{QUELLHÖHE-PREFIX|}}} | {{{QUELLHÖHE-PREFIX}}} | {{{MÜNDUNGSHÖHE-PREFIX|}}} }}
|ca.|etwa|rund = {{#if: {{{QUELLHÖHE-PREFIX|}}} | {{{QUELLHÖHE-PREFIX}}} | {{{MÜNDUNGSHÖHE-PREFIX|}}} }}
}}

Ich formuliere mal die Anforderung:

Wenn der Parameter "QUELLHÖHE-PREFIX" oder "MÜNDUNGSHÖHE-PREFIX" den Wert "ca.", "etwa" oder "rund" annimmt, dann ist der Parameter als Prefix vor der Höhendifferenz einzufügen.

ich käme jetzt auf folgenden Ausdruck:

{{#switch: {{{QUELLHÖHE-PREFIX|}}}
|ca.|etwa|rund = {{{QUELLHÖHE-PREFIX}}}
|#default = {{#switch: {{{MÜNDUNGSHÖHE-PREFIX|}}}
|ca.|etwa|rund = {{{MÜNDUNGSHÖHE-PREFIX}}}
}}
}}

--SteveK ?! 10:40, 24. Apr. 2013 (CEST)

Diese Code-Doppelung wollte ich vermeiden, daher meine obige Vereinfachung. Nur die Quellhöhe beachten (und vielleicht die Liste der Wörter noch etwas erweitern, „zirka“ fehlt). --TMg 12:35, 24. Apr. 2013 (CEST)

Ob die Wortliste ausreicht ist Nebensache, die Realisierung wenn vorrangig. Du hast gemeit es nicht zu entfernen, ich habe nur mal formuliert wir es denn richtig sein könnte. --SteveK ?! 17:10, 24. Apr. 2013 (CEST)

Ich mach nur Vorschläge. Deine Kodierung ist die „korrekteste“. Eine elegantere fällt mir leider nicht ein, außer wie gesagt bewusst auf die Wiederholung des Mündungs-Präfix zu verzichten. --TMg 17:50, 24. Apr. 2013 (CEST)

Der Einbau widerspricht einer Vereinfachung, aber wenn du der Meinung bist wir sollten es einbauen, dann kannst du das gerne machen. --SteveK ?! 09:59, 25. Apr. 2013 (CEST)

Wartungsseite Karte

Der Link in dem Satz "Für den Parameter KARTE existiert eine Wartungsseite." führt zu "Karte fehlt". Gibt es eine Wartungsseite bzw. eine Doku für die Karte oder ist eine Karte nur ein Bild? --Okernick (Diskussion) 07:21, 29. Apr. 2013 (CEST)

Zur Zeit stellt der Parametersatz KARTE eine Bildeinbindung zur Verfügung. Wenn also die "Karte fehlt" gemeldet wird, dann fehlt die Einbindung einer Kartendarstellung. --SteveK ?! 09:50, 29. Apr. 2013 (CEST)

xxxxxx

In vielen Flussartikeln taucht neuerdings die Zeichenkette "xxxxxx" am Beginn des Artikels auf. Hat das irgendetwas mit der Infobox zu tun? Der Verdacht drängt sich auf, da das ausschließlich bei Artikeln mit Fluss-Infobox auftritt, und bei Artikeln mit Nebenboxen, z.B. Aschach (Innbach), entsprechend mehrfach. Viele Grüße, --Luftschiffhafen (Diskussion) 12:58, 29. Apr. 2013 (CEST)

Ist schon behoben.--SteveK ?! 13:18, 29. Apr. 2013 (CEST)

Danke! --Luftschiffhafen (Diskussion) 13:31, 29. Apr. 2013 (CEST)

Hihihi, :-)
ich hatte dies heute Morgen (auch) beim Fluss Ruhr festgestellt und dort gemeldet. Danke für die Korrektur!
--TOMM (Diskussion) 18:49, 29. Apr. 2013 (CEST)

Lagewunsch

Die letzte Änderung ([1]) bitte rückgängig machen oder anpassen. Vorheriges Verhalten wurde besprochen: Vorlage_Diskussion:Infobox_Fluss/Archiv/2#Lagewunsch_für_Mündung. Jetzt erscheinen in vielen Artikeln rechts oben Koordinaten (von Mündung oder Quelle) und zusätzlich ein Lagewunsch, der die Koordinaten überlagert und unleserlich macht. --2A02:810D:10C0:E1:C80A:AF1C:1223:1F02 22:14, 10. Mai 2013 (CEST)

Ich habe das wieder geändert. Bin jedoch der Überzeugung, dass fehlende Mündungskoordinaten zu einem Lagewunsch führen sollten, da die Mündung in der Regen leichter zu finden ist als die korrekte Quellenangabe. Die Umsetzung muss jedoch anders erfolgen. --SteveK ?! 13:12, 12. Mai 2013 (CEST)

Bilderaktualisierung

Kann es sein, dass die Infobox ein aktualisiertes Bild nicht übernimmt? In Thiedebach bleibt das Bild ThiedebachMündung.png auf dem alten Stand, trotz löschen und "rückgängig" bzw. löschen und neu einbinden.--Okernick (Diskussion) 16:00, 30. Apr. 2013 (CEST)

Hallo Okernick, am wahrscheinlichsten ist, dass das Bild noch im Cache deines Browsers ist, versuche mal die F5-Taste. Ansonsten könnte es noch in einem Proxy-Cache gespeichert sein, dann müsste sich das Problem demnächst aber auch von selbst geben. Ich kann bereits die aktualisierte Version sehen. Gruß --HolsteinPommern (Diskussion) 17:03, 30. Apr. 2013 (CEST)

Nein, die Infobox übernimmt die in den Parametern angegeben Werte. HolsteinPommern hat das schon korrekt dargestellt, das wird ein Problem mit einer Zwischenspeicherung sein.--SteveK ?! 22:01, 30. Apr. 2013 (CEST)

Danke, so etwas war das wohl. Dachte nur, dass mit einfachem "Seite aktualisieren" auch der Cache übergebügelt wird, was wohl nicht der Fall ist. --Okernick (Diskussion) 10:47, 26. Mai 2013 (CEST)

Anregung Wasserkörper

Hallo, könnte die Aufnahme der Wasserkörper bzw. Wasserkörpergruppe in die Box hilfreich sein? Man könnte dann Gewässer geringerer Ordnung, für die keine GKZ existiert, die aber durchaus den Relevanzkriterien genügen, systematisch zuordnen.--Okernick (Diskussion) 12:49, 6. Mai 2013 (CEST)

Ich habe keine Vorstellung davon, wie du dir die Umsetzung vorstellst. Meiner Meinung nach haben wir die Box schon kompliziert genug gemacht. Wenn ein Bach keine GKZ hat (und davon gibt es genug in der Welt), dann kann man die ja einfach weglassen. --SteveK ?! 23:06, 9. Mai 2013 (CEST)

Hallo SteveK, Hintergrund ist die Verwendung der Wasserkörpernummern bei der Umsetzung der EG-WRRL sowie die Verwendung von WK-Gruppen. Das NLWKN verwendet die GKZs bei den entsprechenden Dokumenten gar nicht und ordnet die WKs nur noch den entsprechenden Nummern zu. Ich dachte da einfach an einen Eintrag wie den für die GKZ - aber komplizierter ist immer auch schlechter. By the way: wie aktualisere ich "alte" Infoboxen (z. B. hier), ohne den ganzen Schlonz nochmal neu eingeben zu müssen, wahrscheinlich manuell über die Ergänzung der neuen Felder? Gruß --Okernick (Diskussion) 10:41, 26. Mai 2013 (CEST)

Quell- und Mündungshöhen-Prefix sowie Höhenunterschied

Hallo, seit einiger Zeit ergibt ein Ca.-Wert einer Quellhöhe minus einem genauen Wert einer Mündungshöhe seltsamerweise einen genauen Wert beim Höhenunterschied. Früher stand dort in einem solchen Fall – und wenn beide Werte als „ca.“ eingegeben wurden – richtigerweise „ca.“ als Prefix! Das „ca.“ sollte nur wegbleiben, wenn beide Werte eindeutig genau definiert sind, weil derart exakte Werte z. B. in Topo-Karten genannt und belegt sind. Ich bitte um Korrektur!
--TOMM (Diskussion) 17:22, 26. Mai 2013 (CEST)

Ich habe das Konstrukt schon vor einiger Zeit entfernt weil:

1. Jeder Nutzer eigentlich wissen sollte, dass die Angabe "ca." vor einem der Höhenwerte die Differenz genauso ungenau macht.
2. Die originale Implementierung nicht korrekt war (jedes beliebige Prefix führte zu einem "ca."). Das ist zwar nicht aufgefallen, führt aber dazu, dass man das Prefix nicht korrekt verwenden konnte.
3. Im Zuge der Entfernung hatte ich mit TMg eine Diskussion, wie das denn richtig zu implementieren sei. Da er immer wieder auf die Vereinfachung des Quelltextes acht gibt habe ich den Konstrukt nicht eingebaut.

Die Diskussion stand über einem Monat hier und du bist der erste dem das fehlende "ca." auffällt. Ich werde es nur einfügen, wenn hier sich noch weitere Stimmen dafür aussprechen.--SteveK ?! 18:27, 26. Mai 2013 (CEST)

Mir ist das auch schon aufgefallen, aber da zur Zeit ja einiges an der Infobox herumgebastelt wird, wollte ich erst abwarten, bevor ich mich beschwere. Ich fände es schon sehr sinnvoll, wenn bei "ca."-Angaben einer oder beider Höhen der Höhenunterschied ebenfalls als "ca." gekennzeichnet wird. Zur technischen Umsetzung - das war Gegenstand der verlinkten Diskussion - kann ich nichts sagen, wenn das alles zu umständlich ist, kann man das von mir aus auch so machen, dass man das als HÖHENUNTERSCHIED-PRÄFIX oder was auch immer händisch einsetzt. --Luftschiffhafen (Diskussion) 19:21, 26. Mai 2013 (CEST)

Ich schließe mich TOMM an... Wolf170278 (Diskussion) 19:56, 26. Mai 2013 (CEST)

...Ich ebenfalls... --Freak-Line-Community (Diskussion I Beiträge) 20:04, 26. Mai 2013 (CEST)

Nachtrag zu meiner obigen Eingangs-Meldung:
Jahrelang funktionierte die Funktion der Ca.-Mündungshöhe bei in der Infobox eingefügten Ca.-Werten einwandfrei. Mir ist in den letzten Jahren nie ein Fehler aufgefallen; wohl erst seit 2013 klappt es nicht, weil SteveK „das Konstrukt“ leider „vor einiger Zeit entfernt“ hat. Ich würde mich freuen, wenn es wieder eingefügt würde.
Schönen Abend --TOMM (Diskussion) 20:20, 26. Mai 2013 (CEST) und --TOMM (Diskussion) 09:41, 27. Mai 2013 (CEST)

Nachdem hier die Mehrheit für den Einbau ist, habe ich das korrekte Konstrukt eingebaut. Da hier ihr die IB scheinbar auf der Beobachtungsliste habt, bitte ich euch, auch zeitnah Stellung zu beziehen wenn die Richtung nicht stimmt. Ich hatte das entfernt, weil TMg eine Vereinfachung an der Stelle vorgeschlagen hat und ich festgestellt hatte, dass eine PREFIX-Angabe "X-Bach:" auch zu einem "ca." in der Höhendifferenz führt. Ich mache solche Änderungen meist mit bedacht und nicht ohne Grund. --SteveK ?! 22:30, 26. Mai 2013 (CEST)

Vielen Dank, Steve! Gruß Wolf170278 (Diskussion) 22:28, 26. Mai 2013 (CEST)

Du warst zu schnell, deshalb habe ich mich mal davor gequetscht.--SteveK ?! 22:30, 26. Mai 2013 (CEST)

Guten Morgen,
vielen Dank für das Wiedereinfügen des Ca.-Konstrukts!
Künftig werde ich versuchen, mich möglichst zeitnah zu melden, wenn mir Dinge/Fehler auffallen! Es ist doch klar, dass Du solche Änderungen (meist) mit Bedacht und nicht ohne Grund machst, und bisher ist doch eine schöne Infobox entstanden!
--TOMM (Diskussion) 09:37, 27. Mai 2013 (CEST)

Bild gesucht

Die Infobox Berg erzeugt automatisch Bild gesucht, wenn kein Bild/Foto eingespeichert wurde! Könnte man so etwas für die Infobox Fluss auch machen? So wäre die Systematik gewahrt!
--TOMM (Diskussion) 18:32, 28. Mai 2013 (CEST)

Dazu sei erwähnt, daß die Vorlage "Bild gesucht" als höchst umstritten gilt. Darum wurde schon viel geeditwart ... --Elop 18:44, 28. Mai 2013 (CEST)

Ich halte wäre damit auch nicht ganz so glücklich. Zum einen gibt es schon die Wartungsseiten:

• http://de.wikipedia.org/wiki/Spezial:Linkliste/Vorlage:Infobox_Fluss/BILD_fehlt (>6000 Artikel)
• http://de.wikipedia.org/wiki/Spezial:Linkliste/Vorlage:Infobox_Fluss/KARTE_fehlt (>5000 Artikel)

zum anderen ordnet die "Bild gesucht"-Vorlage die Artikel dann in eine Wartungskategorie die dann übervoll wird. Ich halte es für sinnvoller, die Vorlage gezielt zu setzen, da Flussbilder oft genug auch austauschbar sind weil nix Besonderes darauf zu sehen ist.--SteveK ?! 09:25, 29. Mai 2013 (CEST)

Huch,
dass die Automatik Bild gesucht als so negativ betrachtet wird, überrascht und wundert mich, und davon wusste ich zuvor auch nichts! Ich habe meinen obigen Vorschlag gemacht, weil nach kürzlicher Neuanlage des Artikels Brühne (Orke) dort von einem anderen Wiki-Nutzer die Vorlage Bilderwunsch|hier eingefügt wurde; das könnte dann entfallen!
--TOMM (Diskussion) 20:28, 29. Mai 2013 (CEST)

Alle Koordinaten der Infobox Fluss entsprechend "All Coordinates"

In der Regel hat ein Fluss mindestens zwei geographische Punkte (Mündung und Quelle). Kann die Infobox Fluss nicht entsprechend "All Coordinates" diese Koordinaten rechts oben anbieten (anstatt nur die Mündungskoordinaten)?--Slimguy (Diskussion) 11:30, 5. Jan. 2013 (CET)

Mündungspunkte sind zumeist einigermaßen eindeutig, Quellen eher selten. Es ist ja nur eine aus einer immensen Anzahl, im Prinzip willkürlich ausgewählt (auch wenn noch so systematisch) und manchmal mehr kulturell als gewässerkundlich zu verstehen, deswegen nicht selten umstritten. Würde ich von abraten. -- WWasser (Diskussion) 12:39, 5. Jan. 2013 (CET)

Wieso würdest Du davon abraten, einen eh in der Box referenzierten weiteren Punkt darzustellen?

Wenn ich als Unbedarfter bei "Icksbach" auf "Karte" klicke, erwarte ich eigentlich den Bach zu sehen - es ist ja nicht der Artikel "Icksbachmündung". --Elop 14:24, 5. Jan. 2013 (CET)

Etwas off-topic: In der russischen WP gibt es in den Infoboxen jetzt Positionskarten mit der Mündung als Blue pog und Quelle als Cyan pog. Beispiel: ru:Большой Кизил. -- Olaf Studt (Diskussion) 21:42, 6. Jan. 2013 (CET)

Wenn Quelle und Mündung bekannt sind, sollten sie auch gemeinsam auf einer Karte dargestellt werden können, damit man eine Vorstellung vom allgemeinen Verlauf des Flusses bekommt. Ich habe daher "Coordinate article" probeweise durch "All Coordinates" ersetzt. Das funktioniert natürlich, allerdings entgleist die Box, ohne daß ich einen Fehler erkennen könnte. Auslöser dürfte das <br /> sein, das auch in Denkmallisten manchmal Probleme macht; hier sind die Vorlagenspezialisten gefragt. --Telford (Diskussion) 13:01, 7. Jan. 2013 (CET)

Ganz ehrlich, wenn man bei Lenne_(Ruhr) oben rechts auf "Karte" klickt, dann wird der komplette Flusslauf als rote Linie eingeblendet. Das sagt mehr aus als zwei Punkte auf einer Karte. Des weiteren wurde oben schon gesagt, die Mündung lässt sich einfacher finden als die Quelle (gilt weltweit). --SteveK ?! 12:01, 8. Jan. 2013 (CET)

Ah, das mit der Karte wusste ich nicht. Ist allerdings noch längst nicht überall verfügbar; trotzdem auf Dauer wohl der sinnvollere Weg. --Telford (Diskussion) 21:36, 8. Jan. 2013 (CET)

Wußte ich bislang aber auch nicht!

Könntest Du, als OSMler, denn mal easy einrichten, daß meine KMZ-Pfade von Ruhr-Untersystemen, Sieg, Wied, Lahn, Nidda, Kinzig, Fulda, Werra und Saale-Untersystemen in analoger Weise dort eingespeist werden? --Elop 02:57, 9. Jan. 2013 (CET)

Dargestellt wird der Flusslauf, wenn die Objekte in OSM ein Wikipedia-Tag haben. Meist ist das eine Zusammenfassung mehrerer Elemente durch eine Relation. Das Dumme ist nur, das längst nicht alle Flüsse in OSM erfasst sind, da ist auf Seiten von OSM noch einiges zu tun. Wenn ich gezielt nach einzelnen Flüssen schauen soll, dann meldet euch bitte auf meiner Disk. Ich wollte nur zeigen, dass es bessere Methoden zur Darstellung für Gewässer gibt als zwei Punkte auf einer Karte.--SteveK ?! 09:22, 9. Jan. 2013 (CET)

Könnte man nicht u. U. kmz-files direkt integrierbar machen?

Das hier:

• Karte/Luftbild des kompletten Flusssystems der Werra

könnte z. B. doch auch gleich oben einblendbar sein (egal ob Flußsystem oder nur namentlicher Fluß). --Elop 12:55, 9. Jan. 2013 (CET)

Einfache Antwort: Ich wüsste nicht wie. --SteveK ?! 13:29, 9. Jan. 2013 (CET)

Das hieße, man müßte erst alles bei OSM einspeisen ... --Elop 18:41, 9. Jan. 2013 (CET)

ja, so etwa--SteveK ?! 19:45, 9. Jan. 2013 (CET)

Pegel: Lage oberhalb der Mündung

Im Abschnitt Parameter ist bei PEGEL1 zu lesen: „LoM - Lage oberhalb der Mündung (in km/h)“! Das km/h muss km heißen!
--TOMM (Diskussion) 18:19, 27. Jan. 2013 (CET)

Elop hat die Beschreibung korrigiert. Danke für den Hinweis. --SteveK ?! 18:25, 27. Jan. 2013 (CET)

Auch Danke!
--TOMM (Diskussion) 18:48, 27. Jan. 2013 (CET)

Lagewunsch für Mündung

Hallo TMg, der bisherige Zustand war m.E. durchaus Absicht: Lagewunschmöglichkeit für die Mündung auch bei vorhandenen Quellkoordinaten. Der umgekehrte Fall ist wohl wegen der Nebenwirkungen abgeschaltet/auskommentart worden. Hast Du bei Deiner Änderung die Diskussion vom März des vergangenen Jahres berücksichtigt? --Telford (Diskussion) 10:45, 12. Jan. 2013 (CET)

Das bisherige Verhalten war so: Wenn man von den drei Parametern MÜNDUNG_LAT_GRAD, MÜNDUNG_LONG_GRAD und MÜNDUNG_REGION keinen ausgefüllt hatte, wurde auch kein Lagewunsch angezeigt. Füllte man den Parameter MÜNDUNG_REGION aus, erschien plötzlich der Lagewunsch. Das erscheint mir unlogisch. Warum sollte man für Flüsse mit mehreren Mündungen nicht trotzdem die Region eintragen dürfen, wenn die Mündungen alle in der selben liegen? Oder wenn wirklich nur die Koordinate fehlt, warum führt dann das vorsorgliche Ausfüllen der Region zu verschiedenen Anzeigen? Außerdem überlappten sich die Anzeigen der Quelle und des Lagewunsches oben in der Ecke des Artikels, so dass man keines von beidem noch nutzen konnte.

Die Dokumentation sagt klar, dass die Mündung optional ist. An der Wartungsliste Spezial:Linkliste/Vorlage:Infobox Fluss/MÜNDUNGSKOORDINATE fehlt habe ich nichts geändert. --TMg 17:39, 12. Jan. 2013 (CET)

Hinweis meinerseits: die von mir genannte "Diskussion vom März des vergangenen Jahres" findet sich unter Vorlage Diskussion:Infobox Fluss/Archiv/2#Änderung für Lagewunsch. Für mein Gefühl konterkariert die letzte Änderung von TMg das damalige Diskussionsergebnis. --Telford (Diskussion) 20:32, 12. Jan. 2013 (CET)

Ich halte insbesondere die kaputte Anzeige für nicht akzeptabel. Der Lagewunsch müsste mindestens ausgeblendet werden, wenn die Quellen-Koordinate angegeben ist. Genau das passiert aber schon. Die Vorlage hat einen großen Abschnitt für Parameterprüfungen für genau diesen Zweck. Den habe ich gar nicht berührt. Der vorangegangenen Diskussion habe ich inzwischen entnommen, dass der Lage-Parameter sozusagen „missbraucht“ werden sollte, um den Lagewunsch zu aktivieren. Das kommt mir wie schon argumentiert sehr schwer nachvollziehbar vor. Effektiv werden die drei Parameter dadurch zu einer Einheit verschweißt (entweder alle drei ausfüllen oder gar keinen), die erscheinende Fehlermeldung kommuniziert das aber gar nicht. --TMg 22:30, 12. Jan. 2013 (CET)

Die ursprüngliche Implementation sah vor, dass der Lagewunsch durch die Box nur dann generiert werden, wenn weder Quell- noch Mündungskoordinaten angegeben wurden. Wird nur die Quellkoordinate angegeben, dann wird diese zur Artikelkoordinate, wird Quell- und Mündungskoordinate angegeben, dann ist die Mündungskoordinate die Artikelkoordinate. Ist eine Koordinate vorhanden, dann braucht es mMn keinen Lagewunsch mehr zu geben, denn dann findet man das Gewässer ja auf der Karte. --SteveK ?! 01:12, 13. Jan. 2013 (CET)

Nun gut, dann ist das wieder so wie früher. Mir war hauptsächlich wichtig, daß diese Rückänderung nicht ohne Diskussion erfolgte. Ich habe daher die Dokumentation an das aktuelle Verhalten angepasst und sehe den Fall als für mich erledigt an. --Telford (Diskussion) 11:16, 28. Jan. 2013 (CET)

Reihenfolge

Ich hatte Folgendes vor langer Zeit etwa so schon mal angesprochen:
Ich verstehe nicht, warum beim Schreiben eines Fließgewässer-Artikels mit Verwenden der Infobox Fluss im Bearbeitungsfenster die linken Nebenflüsse vor den rechten Zuflüssen auftauchen, sie aber in der Vorschau und nach dem Artikel-Speichern in umgekehrter Reihenfolge gelistet sind“. Das ist verwirrend, zumal wir doch auch von links nach rechts lesen. Bach-/flussabwärts betrachtet würde dies meines Erachtens besser passen: erst links dann rechts (und damit meine ich die Vorschau-Version und die gespeicherte Version)! Als Antwort bekam ich damals wohl nur, dass das an der Vorlagen-Syntax liegt, weil sie dort anders herum gelistet sind. Kann man das ändern? Ich würde mich freuen!
--TOMM (Diskussion) 18:48, 27. Jan. 2013 (CET)

Der Steve kann das sicher. Will ihm da nicht schon wieder bei seiner Ziehtochter zuvorkommen ... --Elop 19:03, 27. Jan. 2013 (CET)

Ja ich kann das, hab es auch gemacht. Die Reihenfolge der Darstellung hängt nicht von der Parameterreihenfolge ab sondern wird durch die Verarbeitung innerhalb der Vorlage bestimmt. --SteveK ?! 14:17, 28. Jan. 2013 (CET)

Hallo,
ich futtere gerade eine Kleinigkeit und schaue gemütlich nach, ob hier was passiert ist. Und endlich: Es ist vollbracht! Danke!

Jetzt müsste es aber auch noch in Vorlage:Infobox Fluss in der Test-Infobox sowie in den Absätzen Parameter und Beispiel herum gedreht werden, damit die Reihenfolge stimmig ist.
--TOMM (Diskussion) 14:31, 28. Jan. 2013 (CET)

Im Abschnitt "Parameter" hab ich das eben umgedreht: [2]. An den anderen Stellen hat es shcon gepasst. --тнояsтеn ⇔ 14:41, 28. Jan. 2013 (CET)

Als ich vorhin nachgeschaut habe, stimmte es noch nicht. Aber ein anderer Wiki-Benutzer hat auch noch Änderungen vorgenommen! Aber jetzt passt es! Danke an alle, die geholfen haben!
--TOMM (Diskussion) 14:53, 28. Jan. 2013 (CET) und --TOMM (Diskussion) 14:57, 28. Jan. 2013 (CET)

Pegel

Könnte man die Box bei gegebenem Wert von | EINZUGSGEBIET= und | ABFLUSS-EZG= einen Prozentsatz errechnen lassen, der dann z.B. als (98%) hinter dem Wert von AEo dargestellt wird? Dies hätte den Vorteil, dass sofort ersichtlich wird, dass auch wenn die Messstation bei manchen Flüssen kilometerweit oberhalb der Mündung liegt, fast der komplette Durchfluss erfasst wird. Gruß --Freak-Line-Community (Diskussion I Beiträge) 16:04, 4. Jan. 2013 (CET)

Das ist keine Frage des Könnens, sondern der Ausnahmen. Oft fehlt halt einer der Parameter und das muss dann alles abgefangen werden. Ferner kann man solche Angaben natürlich auch im Fließtext machen. Ich würde das nur ungern umsetzen wollen. --SteveK ?! 18:48, 9. Feb. 2013 (CET)

Gemeinden

Wo gerade von Städten und Ortschaften die Rede ist: In der Dokumentation zum Parameter GEMEINDEN steht immer noch „Gemeint ist die Ortschaft, nicht die Gemarkung.“ Dabei gibt es gar keine Ortschaft „Seevetal“ oder „Feldberger Seenlandschaft“. -- Olaf Studt (Diskussion) 22:55, 4. Feb. 2013 (CET)

Siehe oben. Ich wäre dafür, die Parameter mal auszublenden und die Reaktionen abzuwarten. Da steht zu viel Müll drin. --SteveK ?! 18:57, 9. Feb. 2013 (CET)

Defaultwert für SORTNAME

Auch bei der Erzeugung des Sortierschlüssels für die Flusssystemkategorien muss der Seitenname als Default verwendet werden. Den derzeitigen Fehler sieht man in der Kategorie:Flusssystem Elbe bei Nebenflusstiefe 1 (wenn die Kategorie nicht bei den meisten Artikeln hartcodiert wäre, wär’ das das reinste Chaos). -- Olaf Studt (Diskussion) 22:24, 8. Feb. 2013 (CET)

Ich habe den Bug gefixed. Eigentlich hatte ich das zwar berücksichtigt, aber nicht bedacht, dass die Defaultwerte nicht zur Anwendung kommen, wenn der Parameter leer angegeben wurde. Danke für die Fehlermeldung.--SteveK ?! 18:41, 9. Feb. 2013 (CET)

Verlinkung und Layout

(„Verlinkung“ war die ursprüngliche Abschnitt-Überschrift)

Noch eine Idee: In der Infobox Fluss dürfte meines Erachtens jeweils nur das Wort Nebenflüsse verlinkt sein (vielleicht reicht sogar nur die Verlinkung der Erstnennung – also hinter Linke), nicht aber die Wörter Linke und Rechte!
--TOMM (Diskussion) 15:06, 28. Jan. 2013 (CET) und --TOMM (Diskussion) 15:13, 28. Jan. 2013 (CET)

Ich habe die Verlinkung aus optischen Gründen komplett gemacht, teils schwarz teils blau sieht mMn blöde aus. Man könnte ja ganz auf die Verlinkung von Nebenfluss verzichten, da dies ein Link für Dummies ist. Der zweite Wunsch ist schwerer umzusetzen, denn wenn bei der nachrangigen Zeile die vorrangige Zeile fehlt, dann muss die Nachrangige doch Verlinkt werden. Das ist es nicht Wert. --SteveK ?! 22:03, 28. Jan. 2013 (CET)

Hmmm,
– Nebenfluss nicht zu verlinken würde ich nicht begrüßen.
– Das mit der nachrangigen und vorrangigen Zeile habe ich übersehen; daher ist mein obiger Vorschlag hinfällig.

Aber eine andere Idee:
Vielleicht gibt es eine Möglichkeit, dies umzusetzen; dafür sind drei (statt zwei) Tabellenzeilen nötig:

• In oberster Nebenfluss-Zeile steht in linker Spalte nur Nebenflüsse (verlinkt), die rechte Spalte bleibt leer.
• In zweiter Zeile steht links (z. B. um drei Stellen nach rechts eingerückt) Linke (unverlinkt); rechts ist Platz zum ausfüllen.
• In dritter Zeile steht links (z. B. um drei Stellen nach rechts eingerückt) Rechte (unverlinkt); rechts ist Platz zum ausfüllen.

Hierbei ist in der rechten Spalte die graue Waagrecht-Trennlinie zwischen erster und dritter Tabellenzeile wegzulassen, und dort könnte in der obersten Zeile generell als Vorgabe „<!---->“ stehen, als Hinweis dafür, das dort nichts einzutragen ist. Anmerkung hierzu: Vielleicht braucht die oberste Zeile, um eben eine solche einzusparen, in der Kopiervorlage der Infobox nicht stehen, sondern nur in der Vorlage!

Ein (weiterer) Vorteil des vorgeschlagenen Layouts: In derzeitiger Gestaltung steht Rechte Nebenflüsse im Gegensatz zu Linke Nebenflüsse (teilweise) in zwei Zeilen, nämlich (u. a.) je nach dem, was im Abfluss-Päckchen bzw. ob dies ausgefüllt ist (dadurch ändern sich innerhalb der Infobox die Spaltenbreiten). Durch die Änderung in Linke und Rechte würde das wegfallen!

Problem des vorgeschlagenen Layouts ist aber: Wie wirkt sich das auf bisher in Artikeln verwendete Infoboxen aus bzw., gibt es einen (Bot-)Weg, der die bisherige Gestaltung und Auflistung automatisch an die vorgeschlagene (neue) Variante anpasst.
--TOMM (Diskussion) 10:34, 29. Jan. 2013 (CET)

Eigentlich macht es gar nicht so viel Sinn, überhaupt die linken von den rechten in der Box zu trennen. Immerhin geht dadurch die exakte Reihenfolge verloren.

Wenn ich lese "Ahre (l), Neckar (r), Main (r), Mosel (l)", weiß ich mehr als durch je 2 Einträge für links und rechts, wo es theoretisch auch sein könnte, daß zuerst die beiden linken und dann die beiden rechten kämen.

Wo eine Trennung Sinn machen könnte, wäre etwa bei den Mittelrhein-Nebenbächen zwischen Nahe und Lahn. Denn die Zwerge aus dem Taunus haben ja mit denen aus dem Hunsrück wenig zu tun (man braucht eine Fähre, um von den einen zu den anderen zu gelangen), und Vater Rhein kratzt es wassertechnisch eher wenig.

Nur kommen solche Bäche ja in keine Box ... --Elop 12:39, 29. Jan. 2013 (CET)

Ich denke, dass die Aufteilung in Linke… und Rechte Nebenflüsse durchaus Sinn macht, auch wenn daraus nicht die „exakte Reihenfolge“ ersichtlich ist. Das trifft übrigens auch nicht auf die in getrennten Zeilen stehende Auflistung Großstädte, Mittelstädte, Kleinstädte und Gemeinden zu, aber das hatte ich vor Jahren schon mal erwähnt, und dann wäre das Päckchen Ortschaften die Lösung; und wenn man es ganz genau nimmt könnte man auch noch Metropolen und Megastädte auflisten, doch die fallen wohl unter Großstädte. Aber wir wollen hier keine Kümmelspalten! Zudem frage ich mich, warum in Infobox Durchflossene Seen und Durchflossene Stauseen steht, aber nicht z. B. Durchflossene Kleinstädte, denn dort steht ja z. B. auch nicht vom Fließgewässer tangierte oder passierte Mittelstädte. Mit anderen Worten: wenn z. B. ein See vom Fließgewässer nicht durchflossen ist, dann wird er nicht aufgelistet; also nur Seen und Stauseen würde reichen!?! Wegen all(er) [wie schreibt man das? :-)] dieser Punkte halte ich nach wie vor meine obige andere Idee für begrüßenswert!
--TOMM (Diskussion) 13:26, 29. Jan. 2013 (CET)

Ich sehe das bei Groß-, Mittel- und Kleinstädten nicht anders. Entweder ich liste nach Größe auf (Kassel, Fulda, Hersfeld, Rotenburg) - damit stelle ich Großes und Bekanntes nach vorne - und helfe bei der Groborientierung, oder aber ich liste flußabwärts.

Ein Ösi, der den Artikel zur Fulda liest, kennt von vornherein vermutlich nur die gleichnamige Stadt, die er eh an jenem Fluß gewähnt hatte (aber Vorsicht Falle! Gera vs. Gera (Fluss)) und KS (erste Info: Aha, Kassel liegt dran). Der Südhesse hingegen sieht schnell auf einen Blick, wie die kleineren Städte zwischen FD und KS - die er z. T. mit Namen kennt, z. T. auch mal dort war - sich aufreihen.

"Mittelstadt" halte ich eh für Humbug. Ist man z. B. in HE ab 20.000, in NW ab 30.000. Viele Leute indes assoziieren damit eher die 50.000er.

Wer bezeichnet sich denn als "Mittelstadt"? So einen Quatsch lese ich nur z. B. in Stadtallendorf im Intro. Niemand im Landkreis käme auf die Idee, von "Mittelstadt" zu reden. Bis auf 1-2 Lokalpatrioten, die unendlich stolz auf die 20.000 sind.

Großstadt hat sich zumindest eingebürgert und jeder kennt die Definition. Auch wenn die früher eher die Metropolen meinte (es gab damals so viele 100.000er wie heute 500.000er - Hessen, BaWü und Niedersachsen nach heutiger Grenzziehung hatten je eine).

Übrinx eine schöne Beschäftigungstherapie, bei Wackelkandidaten wie Kaiserslautern regelmäßig den Text auf "Mittel-" oder "Groß-" abzuändern. Ist also nicht eine Stadt mit rund 100.000 Einwohnern, sondern in manchen Jahren eine Großstadt und in manchwen Jahren eine Mittelstadt.

Die Kriterien, welche Orte schon in der Box geführt werden, ändern sich doch eh von Fluß zu Fluß. Es käme z. B. keiner auf die Idee, beim Rhein Landstädte einzuboxen.

Um zur Fulda zurück zu kommen

Meiner Momentanmeinung nach wäre:

• Größte Städte <hier über 50.000 EW>: Kassel, Fulda
• Städte <ab X.000 Einwohnern)> flussabwärts: Gersfeld, Fulda, Schlitz Bebra, Rotenburg an der Fulda, Kassel, Melsungen, Hann. Münden

für den Infosuchenden praktischer.

Für Dich als Hessen und regelmäßigen Kartenabgraser wäre da eh keine Zusatzinfo drin. Aber, Du wirst lachen, schon für mich wäre es eine Vereinfachung - ich mußte für den Übertrag gerade extra Melsungen anklicken, um zu sehen, ob das vor oder nach Kassel käme (dürfte Dir Nordhessen eher nicht passieren). Und bei Altmühl oder Tauber hätte ich viel zu klicken bzw. müßte dann in den Abschnitt gehen - welcher aber in vielen Artikeln in Prosa verfaßt ist und eben nicht auf "Übersicht" ausgelegt.--Elop 14:43, 29. Jan. 2013 (CET)

Ich halte die Fließgewässerabwärts-Listung für (das Päckchen) Ortschaften für am sinnvollsten; aber bitte KEINE Aufteilung (wie obig vorgeschlagen) in Größte Städte (ab 50.000) und Städte, denn bei einem (verhältnismäßig) kurzen Fließgewässer bzw. einem solchen mit (nur) kleinen Ortschaften könnte man dann nichts mehr auflisten. Daher komme ich immer wieder auf den Begriff Ortschaften, der alles einschließt. !!!

Übrigens, und nicht das dies neue Erkenntnisse sind: Die Begriffe Groß-, Mittel- und Kleinstadt stehen unter anderem auch im/in alten (Brockhaus-)Lexikon/-Lexika (ab 100.000, ab 20.000, …bis 20.000); bei Metropole steht nur „Hauptstadt, Zentrum“ (ohne Einwohnerzahl) und Megastadt gibt es (dort) nicht. Interessant ist auch, was (dazu) hier zu lesen ist!

Obig genannte Beispiele Ösi und Gera vs. Gera (Fluss) [(:-)] sind treffend!

Bzgl. Beschäftigungstherapie bei Wackelkandidaten schreibe ich nur: :-)!

Die Frage ist auch: Ist es überhaupt sinnvoll, das alles umzubauen, denn wie kann das Alte mit dem Neuen vereint werden?
--TOMM (Diskussion) 15:51, 29. Jan. 2013 (CET)

Die in spitze Klammern gesetzten Auswahlgrößen für die Fulda waren doch nicht global gemeint, sondern genau für die Fulda (siehe auch das Wort hier)! Ich erwähnte bereits, daß ich beim Rhein sicher andere Kriterien anlegen würde. Und bei Zwergbächen ebenfalls.

Andererseits könnte da, wo die spitzen Klammern stehen, je eine Fußnote zum (jeweiligen, nicht globalen!) Kriterium stehen. Dann kommt auch nicht ständig jemand, um sein Heimatdorf dazu zu tragen.

Und bei der Fulda spräche rein gar nichts dagegen, daß da "Städte" stünde (es stehen nämlich nur solche drin), während bei kleinen Bächen da per Parameterwahl "Ortschaften" stünde. --Elop 16:41, 29. Jan. 2013 (CET)

Nebenbei bemerkt, zu Begriffsbestimmung unterschiedlicher Stadtgrößen:

Das findet bislang genau eine Studie. Ändert nichts daran, daß "Großstadt" vorerst für Ü100.000 bekannt ist und Mittelstadt deutlich weniger gebräuchlich und auch nicht so eindeutig normiert.

Auf jeden Fall sind z. B. in HE 50.000 und 100.000 die exakten Schwellen für Sonderstatusstadt bzw. kreisfrei. Während die Schwellen in BY im Schnitt (dort ja kein Automatismus) deutlich niedriger und in NW deutlich höher liegen. --Elop 16:48, 29. Jan. 2013 (CET)

Aha, du hast in spitze Klammern gesetzte Auswahlgrößen … nicht global gemeint (das hier habe ich falsch gedeutet).

Das mit der „Fußnote zum (jeweiligen, nicht globalen!) Kriterium“ wäre sinnvoll.

Zur bereits von mir genannter Begriffsbestimmung unterschiedlicher Stadtgrößen fällt mir im Moment nichts ein, und dies ist auch, wie ich oben schon schrieb, nur als Übrigens angemerkt.
--TOMM (Diskussion) 17:15, 29. Jan. 2013 (CET)

Provokante Idee von mir: Gar keine Nebenflüsse mehr in der Box führen. Und dann auch gleich die Ortschaften (Gemeinden, Städte, Gro0städte) mit entsorgen. --SteveK ?! 18:03, 9. Feb. 2013 (CET)

Ich würde sie nicht vermissen. --Freak-Line-Community (Diskussion I Beiträge) 18:07, 9. Feb. 2013 (CET)

Nein, dem kann ich gar nichts abgewinnen! Besonders die Nebenflüsse würden mir sehr abgehen, da gerade bei kleineren Gewässern ein eigenes Kapitel im Text nicht lohnt. Und auch das Hervorheben von größeren Städten in der IB finde ich sehr praktisch und übersichtlich. Ich würde die beiden Punkte gerne behalten! Grüße --Skipper69 (Diskussion) 13:45, 10. Feb. 2013 (CET)

Wartungskategorie

Seit Kurzem werden fehlende Nachweise doppelt ausgewiesen: einmal als automatisch erzeugte normale Kategorie (Rotlink) und einmal als Wartungskategorie. Beispiel: Drôme (Aure)

• Kategorien: Kategorie:Wikipedia:Qualitätssicherung Geographie:NACHWEISE fehlen
• Wartungskategorie: Kategorie:Wikipedia:Qualitätssicherung Geographie:Nachweise fehlen

Ich glaube, da stimmt an der Vorlage was nicht... Grüße --Skipper69 (Diskussion) 09:43, 11. Feb. 2013 (CET)

Fehler behoben, die rote Kat müsste demnächst wieder leer sein. --SteveK ?! 20:43, 11. Feb. 2013 (CET)

Längenangaben

Infobox Fluss/Archiv/3
Daten
Länge	219,3 km
LÄNGE2	ca. 848 km
LÄNGE3	ca. 848 km

Zur Info:

Es wurde hier vor kurzem diskutiert, ob man in der IB mehrere Längenangaben vorsehen kann. Ich habe das heute mal umgesetzt. Mit der Untervorlage Vorlage:Infobox Fluss/LÄNGE kann man im vorhandenen Parameter LÄNGE_SUFFIX weitere Längen eintragen. Für das Beispiel wurde folgender Code verwendet:

Infobox Fluss/Archiv/3
Daten
Länge	219,3 km {{Vorlage:Infobox Fluss/LÄNGE

{{Vorlage:Infobox Fluss/LÄNGE||BEZ=LÄNGE3|PREFIX=ca.|WERT=848|NACHWEIS=|NOAUTOKAT=Ja}}
}}

Die genaue Beschreibung muss ich noch erstellen. Meinungen und Hinweise sind willkommen.--SteveK ?! 18:52, 10. Feb. 2013 (CET)

SORTNAME

Erspart man sich durch Angabe bei "SORTNAME" in der IB den Parameter "SORTIERUNG:" am Ende des Artikels oder hat eins mit dem anderen nichts zu tun? --Skipper69 (Diskussion) 16:54, 24. Mär. 2013 (CET)

Bin mir nicht sicher - Benutzer:SteveK weiß genaueres... Gruß Wolf170278 (Diskussion) 21:08, 1. Apr. 2013 (CEST)

Na, dann warten wir, ob ihn der Osterhase wieder freigibt! --Skipper69 (Diskussion) 13:24, 2. Apr. 2013 (CEST)

Ich habe mir der Vorlage nichts zu tun, und bin nur über Hilfe Diskussion:Kategorien#Das "Verstecken" von Sortierschlüsseln (pro/contra) hierher gekommen. Wenn ich den Vorlagen-Quellcode richtig lese, dann werden mit dieser Vorkage drei Kategorien gesetzt: eine für das Flusssystem, eine für die Quellregion und eine für die Mündungsregion, wobei die zwei letzten auch identisch sein können. Mir scheint, dass SORTNAME nur für diese drei Kategorien einen expliziten Sortierschlüssel schreibt. Weitere Kategorien würden einen anderen Sortierschlüssel verwenden, entweder den Seitennamen, oder den Sortierschlüssel, der mit DEFAULTSORT oder SORTIERUNG vorgeschrieben wird. Ich halte das nicht für sinnvoll, hier einen weiteren expliziten Sortierschlüssel einzuführen. Wie man sieht: das führt zur Verwirrung und zu unnötigen Fehlern. Aber vielleicht habe ich das auch falsch verstanden, und es verhält sich anders. Zumindest sollte es irgendwo beschrieben werden. --Asdert (Diskussion) 15:45, 2. Apr. 2013 (CEST)

Das ist nicht ganz richtig dargestellt. Funktionieren sollte das wie:

• Wird der Parameter SORTNAME angegeben, dann wird dieser über SORTIERUNG als Standardsortierung gesetzt wenn er vom Seitennamen abweicht. Die Sortierung wird nicht gesetzt, wenn sie gleich zum Seitennamen ist.
• Die gesetzte Sortierung wird für alle Kategorien angewendet, bei denen die Sortierung nicht explizit festgelegt wird. Wurde durch die Vorlage eine SORTIERUNG gesetzt, so führt einer weitere SORTIERUNG-Angabe zu einer entsprechenden Meldung.
• Bei den Flusssytemkategorien wird die Sortierung immer explizit angegeben entsprechend der dort üblichen Praxis, also bspw. [[Kategorie:Flusssystem Rhein|1{{{SORTNAME}}}]]
• Gesetzt werden die "Fluss in <Kontinent>"-Kategorien, Regional-Kategorien für die Quell- bzw. Mündungs-Koordinaten und die Flusssystemkategorie.

Soviel ich weiß ist nur eine SORTIERUNG gültig, das habe ich aber jetzt nicht ausprobiert. Gruß --SteveK ?! 16:23, 2. Apr. 2013 (CEST)

Danke für die Auskunft, SteveK! Kannst du mal rüberkommen und dort klarlegen, inwieweit sich SORTNAME und SORTIERUNG in die Quere kommen könnten? Danke. --Asdert (Diskussion) 10:39, 4. Apr. 2013 (CEST)

Parameter FLUSSSYSTEM bei Hauptflüssen ohne Artikel

Im Artikel Arroscia sieht die Zeile „Flusssystem“ etwas seltsam aus (der Hauptfluss des Flusssystems hat keinen Artikel und muss per Klammerzusatz disambiguiert werden) – war das schon immer so, oder wurde da in letzter Zeit etwas geändert? -- Olaf Studt (Diskussion) 13:42, 12. Jul. 2013 (CEST)

Nein, geändert wurde da nichts. Es ist so, dass geprüft wird, ob der Teil vor dem "/" als Artikel existiert. Wenn nicht, dann wird der gesamte Parameter ausgegeben und als Parameterfehler betrachtet. Das ist hier der Fall. Auf die Schnelle habe ich keine Lösung anzubieten außer den fehlenden Artikel als Stub anzulegen. --SteveK ?! 15:28, 12. Jul. 2013 (CEST)

Flüsse, deren Wasser teilweise oder (fast) vollständig abgeleitet werden => mehrere Flusssysteme und Abflusswege

Hallo, wie ist mit Flüssen und Gewässern (See) zu verfahren, deren Wasser teilweise oder (fast) vollständig in weitere Flusssysteme abgeleitet wird? Es gibt dann mehrere Flusssysteme und mehrere Abflusswege. Es lassen sich offenbar mehrere Flusssysteme in der Infobox angeben. Es können weitere Flusssystem-Kategorien manuell angegeben werden. Wie sieht es aber bei mehreren Abflusswegen aus? Diese lassen sich nicht in der Infobox pflegen, oder?--Slimguy (Diskussion) 19:39, 28. Jul. 2013 (CEST)

Ich würde sagen, entscheidend ist, welchen Weg der Fluss dem Namen nach nimmt, auch wenn ein Großteil des Wassers abgeleitet wird. --Luftschiffhafen (Diskussion) 14:22, 29. Jul. 2013 (CEST)

Es lässt sich genau ein Flusssystem in der IB unterbringen. Entscheidend für das Flusssystem ist der Name des Hauptflusses (Rhein und nicht Waal). Die automatische Kategorisierung in Flusssystemkategorien greift da nur bedingt. --SteveK ?! 16:46, 29. Jul. 2013 (CEST)

Hallo, ich rede hier nicht von einer gewöhnlichen Flussbifurkation, sondern von einer künstlichen (menschgemachten) Ableitung von 90 Prozent oder mehr der Wassermenge in ein völlig anderes Flusssystem.--Slimguy (Diskussion) 20:25, 29. Jul. 2013 (CEST)

Hallo, wir reden hier über die Infobox, Sachthemen werden eigentlich im Portal Gewässer oder WP:WPG diskutiert. Nochmal: Die von Menschen gemachten Ableitungen in ein anderes Flusssystem lassen sich in der IB derzeit nicht abbilden, es lässt sich nur ein Flusssystem eintragen. Eine Kategorisierung per IB wird nicht gemacht. --SteveK ?! 22:18, 29. Jul. 2013 (CEST)

Hallo, danke für die Klarstellung.--Slimguy (Diskussion) 07:16, 30. Jul. 2013 (CEST)

Applikation

Hallo, in der App-Version gibt es am rechten Bildrand keinen Zeilenumbruch, so dass z.B. bei Quelle oder Mündung der Text ins "Leere" läuft. --80.187.100.81 09:44, 1. Aug. 2013 (CEST)

Keine Ahnung was du meinst, ich habe das Problem nicht auf meinem Handy.--SteveK ?! 18:17, 1. Aug. 2013 (CEST)

Ich meine nicht die mobilversion in einem Browser, sondern die App, die es im Store zum Download gibt. dort wird in der Infobox Fluss bei längeren Texten einfach über den Bildrand herausgeschrieben und nicht in die nächste Zeile gerutscht wie hier. KA ob das dann an der von hier eingebundenen Box oder am Programm selbst liegt. Ist schade dass es nicht richtig funst. --80.187.100.177 20:15, 1. Aug. 2013 (CEST)

Ich habe keine Idee, woran das liegen könnte. Das müsste ja dann auch bei anderen IBs nicht funktionieren.--SteveK ?! 21:25, 1. Aug. 2013 (CEST)

Hast recht. Ist bei anderen Infoboxen auch. Damit ist das hier erledigtErledigt. --80.187.100.177 21:46, 1. Aug. 2013 (CEST)

Städte und Gemeinden

Wir hatten das schomma, aber ich habe es auf die Schnelle nicht gefunden. Können wir die Box nicht langsam mal auf Orte am Fluß (ohne Berücksichtigung vin Stadtrechten und Einwohnerzahlen) umstellen, sodaß die Reihenfolge ersichtlich bleibt?

Eine zahlenmäßige Beschränkung ist sicher bei größeren Flüssen sinnvoll, aber die könnte man dann in ein neues Boxfeld "Kriterium" reinschreiben (Erschiene dann als Überschrift), sodaß die IP nicht ihr Heimatdorf in die Rheinbox schriebe und auch noch gesichtet würde (Dorf liegt ja dort), da dort stünde "Städte ab X Einwohner" - der Rest gehört dann in den Artikelabschnitt.

Bei Fulda (Fluss) steht schon eine sinnvolle Auswahl, aber die Reihenfolge geht verloren.

Analoges wäre auch bei den Nebenflüssen denkbar. Per Feld mit Überschrift

"Nebenflüsse ab X km / Y km² EZG""

"... Neckar (r), Main (r), Nahe (l), Lahn (r), Mosel (l), ...

weiß ich deutlich mehr als wenn nicht einmal ersichtlich ist, daß die Mosel nach dem Neckar kommt oder warum die Sulz fehlt! --Elop 17:21, 15. Aug. 2013 (CEST)

Ich würde beides ganz aus der IB entfernen, gerade wegen dem was rein und was nicht. Bei größeren Flüssen werden für die Nebenflüsse eh Tabellen gemacht, damit man eine Übersicht hat. Innerhalb der IB sprengt das mMn meistens den Rahmen (außer bei dem 1,5 km langen Ixbach in Ypsilonhausen). --SteveK ?! 11:59, 16. Aug. 2013 (CEST)

Ich dachte so an eine Beschränkung auf 5 oder 10. Die Orte bei der Fulda sind z. B. ziemlich genau die, die für einen Überblick gut sind (nur eben bescheuerterweise nicht der Reihenfolge nach), man könnte natürlich auch auf 2 (über 50.000) oder 3 (Kreisstadt oder kreisfrei) reduzieren. Insbesondere halte ich es nicht für unsinnig, daß man schon in der Box sieht, daß Kassel an der Fulda liegt (wobei man das für Fulda ja schon fast ahnt). Bei den Flüssen sind dort indes willkürlich 3 + 3 - da gehören nur Eder (!) und Haune zwingend rein, vielleicht noch Schlitz und Fliede, aber so richtig bekannt sind die nicht. Und beim Rhein könnte "Aare/Neckar/Main/Mosel/Maas" ausreichen (momentan nur Verweis). Im Zweifel ist sicher weniger mehr. Aber in den Lahn Artikel gehören m. E. unbedingt die Kreisstädte MR, GI, WZ und LM sowie Ohm und Dill.

Es ist sicher nicht immer sinnig, nur die Größe heranzuziehen. Bei der Ruhr z. B. sind Meschede und Arnsberg wichtige Kennorte, während Dortmund, Bochum und Essen da eigentlich falsch sind, auch nach Doku, denn das sind klar Städte am Hellweg, Dortmund sogar jenseits der Emscher. Werden, also nicht nur der heutige Stadtteil, sondern die ehemalige, mit Essen fusionierte Stadt, wäre da treffend. Man könnte es auch "südliches Ruhrgebiet" nennen. Schließlich ist es Willkür, was da zu DO und BO eingemeindet wurde.

Völlig anders ist aber z. B. die Wupper, denn an der liegen genau die wichtigen niederbergischen Orte. Und auch die Lippe reiht Orte auf.

Man kann ja den Autoren je etwas Freiheit lassen. Fest steht doch nur, daß so ein Kriterium wie "Mittelstadt" bescheuert ist - zumal der Begriff nicht eindeutig sind. In Hessen, wo genau die Großstädte (eindeutige Def, jedem bekannt) kreisfrei sind, bezeichnet man üblicherweise die Sonderstatusstädte, genau die 50.000er, so. Während jeder Anrainer sich über das Intro von Stadtallendorf schlapplacht.

Man kann es sich bei einer etwaigen Umstellung auch einfach machen:

Man deaktiviert einfach die derzeitigen Nebenfluß- und Ortssparten - muß man nicht einmal per Bot löschen. Und wenn einer die neu zu installierenden Felder befüllen will, kann er gleichzeitig die unsichtbaren Einträge im Quelltext entfernen. --Elop 13:19, 16. Aug. 2013 (CEST)

Tja, man kann das so oder so sehen. Ich habe keine Lust auf eine Umstellung der Parameterverarbeitung. Zur Zeit werden die Parameter einfach als Text in der IB dargestellt, eine Begrenzung der Anzahl ist derzeit nicht vorgesehen. Das ist eine flexible Lösung die dem Autor die meisten Freiheiten lässt. Regeln werden aber dabei auch oft genug außer acht gelassen

--SteveK ?! 19:46, 16. Aug. 2013 (CEST)

Eine Infobox, die für kleine Bäche genauso wie für große Ströme geeignet ist, muss dem Autor gewisse Freiheiten lassen, und das finde ich auch gut so. Es ist doch klar, dass diese Felder keine vollständige Aufzählung beinhalten, sondern eine mehr oder weniger willkürliche Auswahl. Einschränkungen nach Länge, EZG etc. halte ich für wenig sinnvoll, das verhindert falsche oder unpassende Angaben auch nicht, zumal man dafür erst einmal Länge und EZG sämtlicher Nebenflüsse kennen müsste. Wenn's sein muss, können die Felder von mir aus auch ganz weg, ich gebe aber zu bedenken, dass damit wahrscheinlich viel Information verloren geht. Nicht alles, was in der Infobox steht, steht auch im Fließtext. Viele Grüße, --Luftschiffhafen (Diskussion) 21:24, 16. Aug. 2013 (CEST)

Selbstredend ist bei größeren Flüssen bekannt, wie lang welcher der großen Nebenflüsse ist und wie groß sein EZG. Und, sofern sich die Autoren entschieden, die wichtigsten 3 oder 10 reinzuschreiben, wäre selbstredend ein objektivierbares Kriterium, welches auch in der Box angegeben wäre, sinnvoll.

Beispiel Rhein, wie ich es gerade anführte:

Es sollte dann bereits in der Box stehen, nach welchem Kriterium die Flüsse auch in der Box stünden. Sonst würde bei obiger Fünferauswahl ständig jemand Lahn, Sieg, Ruhr. Lippe oder sogar deutlich kleinere nachtragen - vermutlich je den, an dem er wohnt.

Mein Änderungsvorschlag ist doch primär der, nur je ein Feld für Orte und Nebenflüsse zu lassen und im Zweifel zu sagen, welche aufgeführt sind - statt einer "zufälligen" Auswahl.

>>Nicht alles, was in der Infobox steht, steht auch im Fließtext.<<

Kann bei Abflußwerten schomma vorkommen, aber Orte und Nebenflüsse sollten schon auch im Text stehen. Es ist nicht die Aufgabe einer Infobox, erschöpfend zu listen, sondern sie soll einen Überblick geben.

Deshalb benutzen wir das Feld "bekannte Brücken" auch nicht mehr. Jeder kann sofort 5 Nebenflüsse des Rheins oder 5 Städte an ihm nennen, aber viele nicht einmal eine namentliche Brücke über ihn. Auch wäre bei Brücken die Auswahl schwieriger zu treffen, denn der Rhein ist etappenweise immer konstant breit, was dann auch die Brücken sein müssen. Während es bei Städten und Nebenflüssen herausragende gibt. --Elop 22:56, 16. Aug. 2013 (CEST)

Bei größeren Flüssen ja, aber die Infobox gilt doch nicht nur für den Rhein, sondern auch für kleine Bäche. Gerade wenn, wie du sagst, die Infobox nicht erschöpfend listen, sondern nur einen Überblick geben soll, verstehe ich das Problem mit der derzeitigen Situation nicht. Genau das tut sie ja jetzt. --Luftschiffhafen (Diskussion) 23:24, 16. Aug. 2013 (CEST)

Das muß ja echt schwer sein ...

Siehe mein Grundposting! Schau in die Boxen von Fulda (Fluss) oder von Ruhr - hatte ich beide schon verlinkt!

Bei der Fulda sieht man z. B. die objektivierbarerweise 9 wichtigsten Orte, weiß aber nicht, in welcher Reihenfolge sie durchflossen werden. Du findest dort unter "Großstädte" genau eine. Meine Frage: Wo fließt die Fulda eher durch, durch Gersfeld oder durch Kassel?

Beantwortet die Box nicht einmal! Daß wiederum Kassel eine Großstadt ist und Gersfeld eher nicht, wird sich der Leser auch so denken.

Man weiß nicht einmal, ob Fulda oder Kassel zuerst durchflossen wird, und es ist in der Box bislang sogar vorgesehen, da0 man das nicht ablesen kann!

Gerade fällt mir sogar noch auf, daß irgendein Intelligenzbolzen die "Mittelstädte" auch noch alphabetisch geordnet hat.

Welchen "Überblick" gibt die Box bezüglich der Fulda genau? Einen Überblick über grobe Einwohnerzahlen von Städten?

Dann sind da willkürlich 3 linke und 3 rechte Nebenflüsse, wobei kein Kriterium angegeben ist, warum genau die je 3 (dürfte auch kein sinnvolles für diese Auswahl geben).

Sag' mir bitte noch ohne Spicken (für Grundinformation ist ja die Box da), in welcher Reihenfolge die 6 in der Box aufgeführten Nebenflüsse der Fulda zufließen! --Elop 00:21, 17. Aug. 2013 (CEST)

Erg, steht zwar schon oben, aber nochmal:

Welchen "Überblick" bietet die Info, daß die Ruhr durch die "Großstädte" Dortmund und Bochum fließt, wenn sie gar nicht durch diese fließt, die Box aber dazu einlädt, diese prominent einzutragen, da "einwohnerstärkste Städte, die von der Ruhr periphär tangiert werden"? --Elop 00:28, 17. Aug. 2013 (CEST)

Der Änderungsbedarf scheint sich, gemessen an der Beteiligung an der Diskussion, überschaubar gering zu halten, zumal der Änderungswunsch ohne Eliminierung der vorhandenen Parameter die eh schon komplizierte Box noch unübersichtlicher macht.--SteveK ?! 20:30, 19. Aug. 2013 (CEST)

Ich hatte auch nicht vorgeschlagen, die alten Parameter aktiv beizubehalten. Sondern eben zu deaktivieren und dort, wo sinnvoll, nach neuem System anzulegen. Damit würden auch die über lange Zeit ungeprüften Aufzählungen rausfallen. --Elop 23:46, 19. Aug. 2013 (CEST)

Ich kann mich Elops Argumentation nur anschliessen. Ich wäre allerdings schon froh, wenn bei den Städten die Massgabe „Gemeint ist die Ortschaft, nicht die Gemarkung“ konsequent beachtet würde. Ich finde es einfach unsinnig, dass unter den Orten an der Ruhr auch Iserlohn und Holzwickede genannt werden. An der Ruhr liegt Wickede; aber Holzwickede liegt nördlich des Haarstrangs an der Emscher, auch wenn das Gemeindegebiet sich bis an die Ruhr erstreckt; oder etwa Arnsberg als Stadt an der Möhne – zwischen der Stadt Arnsberg und der Möhne liegt der einige Kilometer breite Arnsberger Wald. Sonst liegt konsequenterweise auch Hamburg (wegen seiner Exklave Neuwerk) an der Nordsee, oder ist Hamburg vielleicht sogar eine Stadt auf einer Insel in der Nordsee? Allerdings müsste in der Beschreibung der Vorlage das Wort „Gemarkung“ durch „Gemeindegebiet“ ersetzt werden. Der Ausdruck „Gemarkung“ wird zwar umgangssprachlich gelegentlich im Sinne von „Gemeindegebiet“ gebraucht; korrekterweise versteht man darunter aber eine Gebietseinheit des Liegenschaftskatasters. Bei den kommunalen Neuordnungen seit Ende der 1960er Jahre und zum Teil auch schon bei früheren Neuordnungen sind die Gemarkungen, anders als die Gemeinden, nicht zusammengelegt worden, sondern bestehen nach wie vor in den alten Grenzen fort. Darüber hinaus müsste die Bezeichnung „Gemeinde“ (neben Gross-, Mittel- und Kleinstädten) ersetzt werden. Denn so ist es unlogisch: Laut den Gemeindeordnungen der Bundesländer ist jede Stadt (nicht im geographischen, sondern im kommunalrechtlichen Sinn) eine Gemeinde. Die leider häufig zu hörende Ausdrucksweise „Städte und Gemeinden“ ist genauso logisch, wie wenn man sagen würde „Frauen und Menschen“. Statt „Gemeinden“ müsste es heissen „Dörfer“. Dann wäre auch von vornherein klar, dass eben die Ortschaft und nicht das Gemeindegebiet gemeint ist.

Wir müssen unterscheiden: Im kommunalpolitischen Sinn gibt es nur Gemeinden (von denen die grösseren in der Regel das Recht haben, sich „Stadt“ zu nennen); jede Gemeinde hat ihr eindeutig begrenztes Gebiet, eben das Gemeindegebiet. Im geographischen Sinn gibt es Städte und Dörfer, also die mehr oder weniger zusammenhängend bebauten Ortschaften, und genau die sollten hier in der Infobox genannt werden, wenn sie an dem jeweiligen Fluss liegen. An der Ruhr liegt also nicht die Stadt Iserlohn, sondern zum Beispiel das Dorf Rheinen (von dem freilich fraglich ist, ob es die für die Nennung in der Infobox der Ruhr erforderliche Relevanz besitzt), und nicht die Stadt Essen, sondern die Städte (im geographischen Sinn) Werden und Kettwig. Und an der Möhne liegt nicht die Stadt Arnsberg, sondern die Stadt (im geographischen Sinn) Neheim oder meinetwegen auch Neheim-Hüsten. Wenn wir schon zu den einzelnen Städten (im geographischen Sinn) und Dörfern eigene Artikel haben, dann ist es doch viel sinnvoller, diese, sofern sie direkt am Fluss liegen, in der Infobox zu nennen und zu verlinken und nicht die Gemeinden, deren Hauptort oftmals weit vom Fluss entfernt liegt. Natürlich wachsen, vor allem in den Ballungsgebieten, Städte (im geographischen Sinn) und Dörfer zusammen. Schwabing gehört seit über hundert Jahren zu München, so wie Charlottenburg zu Berlin. Aber Hohenlimburg würde ich durchaus noch als eigene Stadt (im geographischen Sinn) an der Lenne verstehen, auch wenn es heute zur Stadt (im kommunalpolitischen Sinn) Hagen gehört. Die Abgrenzung ist sicher nicht immer eindeutig; man kann darüber streiten, ob man als Stadt an der Havel Berlin oder Spandau nennen soll. Ich wäre eher für Spandau; denn damit erfährt man sogleich, welcher Teil der Stadt (im kommunalpolitischen Sinn) Berlin nun konkret an der Havel liegt. --BurghardRichter (Diskussion) 19:09, 20. Aug. 2013 (CEST)

Parameterfehler

Diese Wartungsseite ist jetzt leer. Ich werde die betreffenden Parameter in Zukunft in der IB als fehlerhaft markieren, damit die Autoren gleich die richtigen Angaben machen. --SteveK ?! 22:51, 30. Jul. 2013 (CEST)

Liberianische Flüsse in Kategorie:Fluss in Maryland

Konkret der Cavally, der fließt nämlich durchs Maryland County von Liberia (ISO-Code LR-MY). Da muss irgendao ein Programmierfehler stecken. -- Olaf Studt (Diskussion) 23:24, 20. Okt. 2013 (CEST)

Das liegt an den ISO-Vorlagen. Mit diesem Edit habe ich das gefixed.--SteveK ?! 23:31, 20. Okt. 2013 (CEST)

Parameter BILDERWUNSCH

Hallo zusammen, ich habe hier gerade einen optionalen Bilderwunsch eingefügt, wie ich es bereits im Jahr 2011 vorgeschlagen hatte. Damit sollten beide Positionen aus dieser Diskussion ausreichend berücksichtigt sein. Eine Liste aller Flüsse mit Bilderwunsch-Baustein findet ihr hier. Eine erste Umstellung von Vorlage auf Parameter habe ich hier versucht. Die Vorlage:Bilderwunsch/Listeneintrag bietet die Möglichkeit, Koordinaten oder einen Ortsartikel mit Koordinaten anzugeben. Wäre es sinnvoll, diese Möglichkeit auch in der Infobox zu bieten, z.B. über die Parameter BILDERWUNSCH-ORT und/oder BILDERWUNSCH-LÄNGENGRAD, BILDERWUNSCH-BREITENGRAD, BILDERWUNSCH-ISO-REGION? --Flominator 20:04, 5. Okt. 2013 (CEST)

Hi Flominator

Ich habe deine Änderung gerade wieder zurückgesetzt, da ich der Meinung bin, dass das setzen der Vorlage:Bilderwunsch in der Tabelle nicht der richtige Weg ist. In wieweit es überhaupt notwendig ist, daran zweifle ich schon seit einiger Zeit wenn einige die Vorlage in kurzen Flussartikel setzen, die nicht mal durch eine Ortschaft fließen, also ein Allerweltsgewässer sind.

Gruß --SteveK ?! 22:44, 6. Okt. 2013 (CEST)

Das Problem mit den bisherigen Bausteinen kann ich nachvollziehen. Könnten wir den Benutzer vielleicht dazu zwingen, den genauen Ort des Bilderwunsches (z.B. durch Koordinaten) anzugeben? Dann muss er zumindest wissen, was er als Bild haben möchte, da die Vorlage ohne Koordinaten gar nicht angezeigt wird. Wäre das ein gangbarer Weg? --Flominator 19:06, 15. Okt. 2013 (CEST)

Ich würde das mit dem Bilderwunsch ganz aus der IB heraushalten wollen. Wenn jemand meint, das ein Bächlein ein Bild haben sollte, dann kann er diesen Wunsch manuell eintragen. Nicht jedes Bächlein muss bebildert werden. Derzeit wird ja schon eine Wartungsseite gefüllt, wenn kein Bild eingebunden wird, die ja auch abgearbeitet werden kann. Soweit bis hier, muss weiter arbeiten. --SteveK ?! 16:31, 16. Okt. 2013 (CEST)

Nachtrag: Vier zusätzliche Parameter für den Bilderwunsch in der IB einzufügen, das halte ich bei der derzeitigen Anzahl an Parametern für ein fragwürdiges Unterfangen. Was man von mir aus machen kann ist die entsprechende Kategorie zu setzen wenn der Parameter BILD nicht gefüllt ist. Das hätte aber zur Folge, dass die Kategorie mit zusätzlichen >1000 Artikeln gefüllt würde. Zudem wäre der Bilderwunsch nicht abschaltbar. Den Mehrwert kann ich aber nicht erkennen.--SteveK ?! 21:55, 16. Okt. 2013 (CEST)

Ich möchte mich hiermit ausdrücklich für einen automatischen oder zumindest optionalen Bilderwunsch aussprechen. Es gibt durchaus Fotografen, die sich z.B. im Portal:Vorarlberg regelmäßig die Bilderwunschliste anschauen und dann fotografieren gehen. Ein Eintrag dort verschafft die realistische Change, zu einem Bild zu kommen, was nicht in der Bilderwunschliste landet, wird wahrscheinlich auch nicht fotografiert. Abgesehen davon ist das für mich schon eine Frage der Konsistenz - warum soll die Vorlage:Infobox See einen Bilderwunsch erzeugen und die Vorlage:Infobox Fluss nicht? --Reinhard Müller (Diskussion) 00:33, 28. Okt. 2013 (CET)

Der Unterschied von See zu Fluss ist schon etwas, was einen automatischen Bilderwunsch schwer werden lässt. Die längliche Form der Fließgewässer ist das Problem, wo soll da der Wunsch ansetzen (an der Quelle, an der Mündung)? Neue Parameter in der Box selber halte ich für nicht wünschenswert, das verkompliziert die IB unnötig. Zudem werden kurze, wenig signifikante Gewässer dann automatisch mit einem Bilderwunsch versehen, wo gerade dieser dann fraglich erscheint. Eine Wartungsseite der IB listet ja schon heute die Bilderlosen Boxen. --SteveK ?! 22:23, 28. Okt. 2013 (CET)

Die Wartungsseite listet im Moment mehr als 6500 bilderlose Flüsse. Wie würde ich jetzt als motivierter Fotograf aus Vorarlberg alle bilderlosen Flüsse aus der Kategorie:Vorarlberg und ihren Unterkategorien finden? --Reinhard Müller (Diskussion) 22:35, 28. Okt. 2013 (CET)

Danke für die Änderung! Ich hoffe, ich kann mich mit ein paar tollen Fotos von Flüssen revanchieren :-). Ich habe mir erlaubt, eine kleine kosmetische Verbesserung noch vorzunehmen, ich hoffe, das ist so ok! --Reinhard Müller (Diskussion) 22:57, 29. Okt. 2013 (CET)

Die mit den Bilderwünschen zugepflasterten Artikel (wie: [3][4][5][6][7]) sehen alles Andere als gut aus..... --Freak-Line-Community (Diskussion I Beiträge) 05:57, 30. Okt. 2013 (CET)

Ja. Der Bilderwunsch ist jetzt da natürlich doppelt drin, da er vorher explizit war. Zum Glück betrifft das wohl im Moment nur 57 Seiten, wäre also relativ rasch behoben. Welche Lösung würdet ihr besser finden?

a) Möglichkeit in der Infobox, den Bilderwunsch explizit zu unterdrücken mit BILD=fehlt, wie in einigen anderen Infoboxen, und in diesen 57 Seiten den Parameter setzen, oder

b) auf diesen 57 Seiten den alten expliziten Bilderwunsch löschen?

--Reinhard Müller (Diskussion) 08:54, 30. Okt. 2013 (CET)

Natürlich wäre es BILD=none, bieten momentan praktisch alle anderen Bilderwunsch-Automatik-Infoboxen, meine Stimme geht an diese Möglichkeit. --Reinhard Müller (Diskussion) 09:15, 30. Okt. 2013 (CET)

Ich habe das erstmal provisorisch implementiert, wollte sehen was daraus kommt. Mich stört derzeit, dass in der IB grafisch auf den Bilderwunsch aufmerksam gemacht wird. Wie man das bei der Vorlage aber abstellen kann, dass habe ich derzeit noch nicht raus bekommen. Den Parameter zum abschalten muss man natürlich einbauen.--SteveK ?! 11:02, 30. Okt. 2013 (CET)

Das Bapperl in der Infobox finde ich schon gut so, das ist auch bei sämtlichen anderen Infoboxen so, vom Berg angefangen über den See bis zum Kraftwerk. Aber ja, es sollte eine Möglichkeit geben, den Bilderwunsch samt Bapperl auszuschalten. Alle anderen machen das mit BILD=none, daher spreche ich mich hiermit dafür aus, das auch so zu machen. --Reinhard Müller (Diskussion) 11:55, 30. Okt. 2013 (CET)

Das mit den "BILD=none" ist mir zu kompliziert umzusetzen, da damit die Umschaltung zwischen Karte und Bild viel komplexer wird. Ich würde einen eigenen Parameter verwenden. Deine Umsetzung nach oben führt übrigens dazu, dass der Bilderwunsch mit dem Einbinden der Karte erfüllt wird. Das ist glaube ich nicht der Wunsch des Erfinders.--SteveK ?! 22:02, 30. Okt. 2013 (CET)

Für die Umsetzung des BILD=none melde ich mich gerne freiwillig, ich hab mir schon ein paar Gedanken darüber gemacht, wie das einfach und übersichtlich umsetzbar ist. Ich möchte nur nicht meine Zeit hineinstecken, wenn es dann am nächsten Tag revertiert wird. Wenn du also sagst "mach!" dann mache ich Vorlage:Smiley/Wartung/:) . Dass der Bilderwunsch nur kommt, wenn weder Karte noch Bild da ist, war auch beim ersten Anlauf von Merlissimo so, insofern sehe ich das schon als Wunsch des "Erfinders"... Ich dachte auch, es wird dadurch nicht ganz so aufdringlich und vielleicht für die Skeptiker etwas akzeptabler. --Reinhard Müller (Diskussion) 22:51, 30. Okt. 2013 (CET)

Ich habe größere Änderungen immer erst in einer Testimplementation umgesetzt und getestet. Da ich das bisher nicht revertiert habe zeigt doch, dass ich nach einer Lösung suche. Also mach.--SteveK ?! 09:43, 31. Okt. 2013 (CET)

gemacht Vorlage:Smiley/Wartung/:)  --Reinhard Müller (Diskussion) 19:04, 31. Okt. 2013 (CET)

Ich hoffe jetzt sind alle zufrieden. Hast du die Wartungsseite entfernt, ich glaube die brauchen wir nicht mehr.--SteveK ?! 20:40, 31. Okt. 2013 (CET)

Hätte ich noch dringelassen, da der Bilderwunsch ja nur gesetzt wird, wenn Bild und Karte fehlen. --Reinhard Müller (Diskussion) 20:47, 31. Okt. 2013 (CET)

Danke, dass ihr euch einig geworden seid. Analog zu den anderen Infoboxen wäre ich dafür, in diesen Artikeln den manuellen Bilderwunsch zu entfernen. Gruß, --Flominator 12:13, 4. Nov. 2013 (CET)

Ich habe die ganzen Artikel mit doppeltem Bilderwunsch durchgeackert (waren ursprünglich 57 Stück) und habe bei den meisten den manuellen Bilderwunsch entfernt. Nur dort, wo der manuelle Bilderwunsch spezifisch war, habe ich diesen dringelassen und dafür den automatischen per BILD=none ausgeschaltet, damit der spezifische Wunsch nicht verloren geht. Ob ein Wunsch in der Art "Quelle, Mündung und was schönes dazwischen" wirklich spezifisch ist, darüber kann man sicher geteilter Meinung sein. Von mir aus also gerne den manuellen Bilderwunsch heraus, aber dann bitte nicht vergessen das BILD=none wieder wegzumachen, damit der automatische Bilderwunsch kommt. --Reinhard Müller (Diskussion) 12:58, 4. Nov. 2013 (CET)

Habe aufgeräumt und es waren noch fünf. Natürlich habe ich überall das NONE entfernt. --Flominator 15:19, 4. Nov. 2013 (CET)

Einziges Problem bleibt die Lein, die gerade gar keinen Bilderwunsch anzeigt. Ideen? Gruß, --Flominator 20:22, 4. Nov. 2013 (CET)

Siehe Text oben, wenn Karte oder Bild angegeben, dann erfolgt kein automatischer Bilderwunsch. --SteveK ?! 20:27, 4. Nov. 2013 (CET)

Wäre es sinnvoll, ohne Bild aber mit Karte wenigstens einen versteckten Bilderwunsch zu erfassen? --Flominator 17:21, 9. Nov. 2013 (CET)

Ich denke, dass es überflüssig ist. Die meisten größeren Gewässer haben Bilder, die kleineren sehen sich meist zum verwechseln ähnlich. Deswegen mag ich den ganzen Bilderwunschkram nicht wirklich unterstützen.--SteveK ?! 17:41, 9. Nov. 2013 (CET)

Gewässersystem bei Küstenflüssen

Hallo, könnte man nicht bei den Küstenflüssen die "Kategorie:Gewässersystem xxx" aus dem Abfluss-Parameter übernehmen und in die Auto-Kat-Funktion integrieren?? Grüße --Skipper69 (Diskussion) 16:36, 14. Nov. 2013 (CET)

Ich würde das gerne in ein Modul überführen, da brauche ich aber Hilfe. Dann könnte man auch eine Liste implementieren, bei denen die Alternativ Darstellung nicht für die Kategorisierung verwendet wird. Beispiel: Bode - Bode (Wipper). Damit wäre die Autokat-Funktion einfacher zu handeln --SteveK ?! 12:04, 15. Nov. 2013 (CET)

Parameter "Pegel"

Ist es korrekt, dass man beim Parameter "Pegel" die Pegelbezeichnung nicht mehr verlinken kann? Ich hab das beim Fluss Loisance versucht mit dem Ergebnis, dass der gesamte Pegel-Parameter gar nicht mehr angezeigt wurde... --Skipper69 (Diskussion) 12:37, 23. Nov. 2013 (CET)

Ich habe das Problem gerade mal angeschaut. Die Vorlage:ParmPart extrahiert nicht mehr, wenn ein verlinkter Text angegeben wird. In der Beschreibung steht, dass die "[" zu den verbotenen Zeichen gehören. SteveK ?! 15:46, 23. Nov. 2013 (CET)

Ich kann zwar die Sinnhaftigkeit dieser Einschränkung nicht nachvollziehen, aber wenn es im Sinne des Erfinders ist, kann ich auch damit leben. --Skipper69 (Diskussion) 17:46, 23. Nov. 2013 (CET)

An für sich müsste sich die Parser-Funktion auch mit einem Modul erschlagen lassen, die die Einschränkungen dann nur auf den "/" macht. Aber dafür bin ich derzeit nicht der richtige Ansprechpartner.--SteveK ?! 18:34, 24. Nov. 2013 (CET)

Eingabe und Darstellung des Abflussweges

Dass die Pfeile durch Eingabe von "//" erzeugt werden, ist hilfreich.

Lästig ist dagegen, dass das Programm automatisch Link-Klammern um die eingegebenen Flussnamen setzt und das Lemma unverarbeitet in der Box erscheinen lässt. Da der Abflussweg nur aus Gewässern besteht und zu jedem Fluss sowieso nach dem nächsten Pfeil das Zielgewässer steht, ist es unschön, wenn in der Box trotzdem Afluss (Bfluss) → Bfluss (Fluss) angezeigt wird.

Müsste der eintragende Autor die Link-Klammern selber setzen, ließe sich dieser Unsinn vermeiden. Um aus der gegenwärtigen Situation das Beste zu machen, wird ein zweites Eingabefeld für den Abflussweg gebraucht, das nicht automatisch verlinkt.--Ulamm (Diskussion) 00:50, 28. Nov. 2013 (CET)

So ganz verstehe ich deinen Einwand nicht. Die Angabe "Afluss (Bfluss)//Bfluss (Fluss)" erzeugt "Afluss (Bfluss) → Bfluss (Fluss)", "Afluss (Bfluss)/Afluss/Bfluss (Fluss)/Bfluss" erzeugt "Afluss → Bfluss", jeweils verlinkt auf den Artikel. --SteveK ?! 12:05, 28. Nov. 2013 (CET)

Zur Unterscheidung von anderen Objekten gleichen Namens tragen viele Flusslemmata die Zusatzbezeichnung (Fluss). Oder sie tragen zur Unterscheidung von anderen Flüssen gleichen Namens in Klammern den Namen ihres Zielgewässers.

In der Darstellung des Abflussweges ist der Zusatz (Fluss) unnötiger Ballast, weil der Abflussweg nur aus Flüssen, Seen und Kanälen bestehen kann. Und das Zielgewässer als Zusatzbezeichnung ist unnötiger Ballast, weil das Zielgewässer sowieso als nächstes Gewässer des Abflussweges aufgezählt wird.

Indem die Gewässerlemmata des Abflussweges ohne eckige Klammern eingegeben und dann durch Anweisungen im Quelltext zwangsweise mit eckigen Klammern versehen werden, erscheint der Ballast an Zusatzbezeichnungen auch in der angezeigten Infobox. Ich habe versucht, durch Eingaben in der Art von „Afluss (Bfluss)|Afluss“ Flussnamen ohne die im Lemma enthaltene Zusatzbezeichnung anzeigen zu lassen, aber bei derartige Eingaben entfällt die Anzeige des Abflussweges ganz. Ebenso entfällt sie ganz, wenn man die Abflussgewässer als vollständige Links eingibt, also mit eckigen Klammern und mit „|“ zwischen Lemma und anzuzeigendem Text.

Erforderlich ist eine alternative Eingabemöglichkeit wie bei den geografischen Daten, die man die wahlweise mit Minuten und Sekunden oder mit Dezimalkomma eingeben kann (Da benutze ich die Infobox mittlerweile als Umrechnungsmaschine :).--Ulamm (Diskussion) 01:06, 30. Nov. 2013 (CET)

Hallo Ulamm, ich verstehe Dein Problem mit den Abflusswegen noch immer nicht. Schau Dir doch bitte einmal den Artikel Argos (Verzée) an. Da hast Du einen ziemlich komplexen Abflussweg über Flüsse mit den unterschiedlichsten Klammerergänzungen in den Lemmata. Und das Ergebnis ist ganz korrekt ich ich habe bei der Erstellung auch keine Kopfstände machen müssen. Ich sehe hier keinen Handlungsbedarf! Grüße --Skipper69 (Diskussion) 13:46, 30. Nov. 2013 (CET)

Inzwischen hat User:Ben Ben es mir erklärt, indem er eine meiner Infoboxen korrigiert hat: Werden die Abflussgewässer durch Doppel-Slash getrennt, erscheinen zwar die Lemmata in der Infobox, aber zwischen den slashes kann man die Namensdarstellung eingeben.--Ulamm (Diskussion) 14:27, 30. Nov. 2013 (CET)

Auf die Erkenntnis hättest du auch durch mein Posting kommen können. --SteveK ?! 15:47, 30. Nov. 2013 (CET)

Peinlich für mich :)( --Ulamm (Diskussion) 16:10, 30. Nov. 2013 (CET)

Breiten und Bildposition

• Im Artikel Welse (Oder) füllt das als Titelbild benutzte Foto das zur Verfügung stehende Feld nicht ganz, sitzt dort aber auch nicht mittig.
• Grundsätzlich werden kurze Artikel nicht selten von ihrer riesigen Infobox förmlich erschlagen. Da sollte es möglich sein, alle Abbildungen außerhalb der Box zu platzieren, ohne dass zwischen Flussname und der zweiten Überschrift („Daten“) der QS-Hinweis „Foto fehlt“ erscheint. Damit nette kleine abbildungsfreie Infoboxen besser aussehen, sollte bei ihnen die zweiten Überschrift („Daten“) entfallen.--Ulamm (Diskussion) 11:07, 3. Dez. 2013 (CET)

Doch, das Foto sitzt mittig. Es hat allerdings am linken Rand einen weißen Streifen; ich vermute, dass es sich um einen etwas verunglückten Scan handelt (man beachte die Exif-Daten!). Korrektur ist kein Problem, ich mache das. --Telford (Diskussion) 12:47, 3. Dez. 2013 (CET)

Und der Rest geht auch: einfach als Bildname none eintragen! --Telford (Diskussion) 17:10, 3. Dez. 2013 (CET)

a) Mehrere Gewässerkennzahlen; b) Wasserkörper-Nummern

Mehrere Gewässerkennzahlen

• Durch unterschiedliche Gewässerabgrenzungen durch Namensdefinition einerseits und Gewässerkennzahlen andererseits können namentlich bekannte Gewässer mehrere Gewässerkennzahlen tragen, ohne dass gegenläufige Fließrichtungen (Gewässer mit Pseudobifurkation) die Anlage einer Zweitbox sinnvoll machen würden. Bisher ist das weder direkt möglich noch mit Trick (Zweckentfremdung eines Präfix oder Suffix).

Dieses ist mit der Box ganz ohne Tricks möglich und auch in der Dokumentation beschrieben:

GKZ= DE/2222/DE/22223 ergibt DE: 2222, DE: 22223

Das funktioniert mit bis zu 10 GKZ. --SteveK ?! 10:00, 17. Jan. 2014 (CET)

Funktioniert schon jahrelang - siehe zB französischen Fluss Somme! --Skipper69 (Diskussion) 10:06, 17. Jan. 2014 (CET)

Aha dann kann man also zwei Nummer mit demselben Staatskürzel eingeben.

Eine Möglichkeit, mittels Suffices zu erklären, welche Nummer für welchen Abschnitt gilt wäre sinnvoll.--Ulamm (Diskussion) 17:48, 17. Jan. 2014 (CET)

Es macht keinen Sinn, alles in die IB zu pressen. Die Beschreibung welcher Abschnitt mit welcher GKZ versehen ist gehört eindeutig in den Artikeltext. --SteveK ?! 20:30, 17. Jan. 2014 (CET)

Wasserkörper-Nummern

• Neben den Gewässerkennziffern, die die Systematik eines Flusssystems verdeutlichen gibt es ja auch noch die Wasserkörper-Nummern, die im Zusammenhang mit der EU-Wasserrahmenrichtlinie ökologisch definierte Gewässer(abschnitte) bezeichnen. auch deren kann sowohl ein namentlich definiertes Gewässer als auch ein durch Gewässerkennzahl definiertes Gewässer mehrere tragen. Bisher sind sie in der Infobox anscheinend noch gar nicht vorgesehen.--Ulamm (Diskussion) 21:40, 16. Jan. 2014 (CET)

Ist derzeit tatsächlich nicht vorgesehen. Ich habe die Information bisher nicht vermisst. Wenn die Umsetzung mehrheitlich gewünscht wird, dann kann man das sicher machen. Andere Meinungen?--SteveK ?! 10:00, 17. Jan. 2014 (CET)

Die Möglichkeit, mehrere GKZ anzugeben ist m.E. unumgänglich. Wo ich bisher auf das Problem gestoßen bin habe ich es umgangen, indem ich mir selber eine Infobox gestrickt habe, die äußerlich wie deine aussieht.

Eine Möglichkeit Wasserköpernummern nach EU-WRRL einzugeben, tut niemendem weh. Es gibt ja auch andere Eingabeoptionen, die bei einem großen Teil der Gewässer nicht wahrgenommen werden.--Ulamm (Diskussion) 13:29, 17. Jan. 2014 (CET)

Die Frage ist aber, ob wir das in der Box brauchen. Wer braucht das sofort auf den ersten Block abrufbereit?

Daß die Lahn "258" ist, ist immerhin etwas, was man sich merken kann und was außerdem bereits vermuten läßt, daß der Main "24" und die Mosel "26" ist. Außerdem weiß man damit, daß "258214" zum System gehört.

Vor allem aber ist das Lemma der Icksbach und nicht Ökologische Gewässerabschnitte des Icksbaches. --Elop 13:53, 17. Jan. 2014 (CET)

Die GKZ ist vor allem gut für die Unterscheidung gleichnamiger Gewässer, weshalb sie auch in der IB steht. --SteveK ?! 14:10, 17. Jan. 2014 (CET)

Änderung beim Parameter FLUSSSYSTEM

Ich habe heute eine Erweiterung des Parameters vorgenommen. Es lassen sich jetzt zwei Flusssystem nennen. Funktionieren tut das so wie beim Abflussweg. Die Beschreibung des Parameters werde ich noch aktualisieren. --SteveK ?! 15:56, 5. Mai 2014 (CEST)

Falsche automatische Kategorievergabe

Der Dreibaach in der belgischen Provinz Luxemburg wird fälschlicherweise in die Kategorie:Fluss in Luxemburg einsortiert.--Anarabert (Diskussion) 13:02, 8. Jul. 2014 (CEST)

Das ist seltsam, die Kategorien werden meines Wissens nach den ISO-Codes für Quell- und Mündungsregion vergeben, und die sind ja beide korrekt mit BE-WLX angegeben. Da scheint wohl wirklich etwas falsch zu laufen. --Luftschiffhafen (Diskussion) 14:30, 8. Jul. 2014 (CEST)

Alle belgische Zuflüsse der Attert werden falsch als luxemburgisch einsortiert und auch sie selbst zwar richtig als luxemburgisch, jedoch nicht als belgisch.--Anarabert (Diskussion) 14:53, 8. Jul. 2014 (CEST)

Offenbar wird BE-WLX fälschlich als (Staat) Luxemburg ausgewertet. Vielleicht kann SteveK oder ein anderer Experte hier Abhilfe schaffen. --Luftschiffhafen (Diskussion) 14:56, 8. Jul. 2014 (CEST)

Nachtrag: Flüsse in Belgien werden offenbar nicht weiter nach Region kategorisiert, sodass natürlich eine Lösung wäre, nur BE als Regionscode anzugeben. --Luftschiffhafen (Diskussion) 15:00, 8. Jul. 2014 (CEST)

Du hast recht, andere belgische Kürzel werden nicht falsch eingeordnet. Aber weil z.Z die belgischen Fließgewässer nicht nach der Region eingeordnet werden, sie deshalb nur mit BE zu kennzeichnen, kann nicht die Lösung sein, da ab einer gewissen Anzahl der Gewässer eine Aufteilung nach Regionen sinnvoll ist.--Anarabert (Diskussion) 15:08, 8. Jul. 2014 (CEST)

Aber notfalls gibt es ja den Parameter NOAUTOKAT mit dessen Hilfe man eine falsche automatische Kategorievergabe ausschalten kann.--Anarabert (Diskussion) 15:13, 8. Jul. 2014 (CEST)

Hier oder in einer der Untervorlagen läuft wohl irgend eine Stringüberprüfung schief.--Anarabert (Diskussion) 15:41, 8. Jul. 2014 (CEST)

Hier ist wohl der Übeltäter.--Anarabert (Diskussion) 18:16, 8. Jul. 2014 (CEST)

Ich habe den Fehler in der Vorlage:Info ISO-3166-2:BE-WLX behoben. Mit der Angabe des "in"-Parameters dort wird der Defaultwert überschrieben, der bei der Provinz Luxemburg natürlich auf "in Luxemburg" gesetzt wird. Eigentlich müsste dass aber statt "in Belgien" passen gemacht werden für die belgische Provinz. --SteveK ?! 11:19, 9. Jul. 2014 (CEST)

Mittelstädte et al

Ich wollte nochmal die hier bereits angeklungene Diskussion wiedererwecken! Ich kam darauf, weil gerade jemand beim Main eine fehlende "Mittelstadt" nachgetragen hat.

Welche "Mittelstadt" kommt vor und welche nach Würzburg? Ich favorisiere da immer noch eine Auflistung "Orte flußabwärts" (hier: Städte ab 20.000) mit je individuell angemessenem, referenziertem Kriterium. Wobei man hier durchaus auch die Infobox diesbezüglich kürzen sollte und nur 50.000er drinlassen. Wenn man sich auf global "max. um 10 Orte" einigen könnte (wir reden ja von der Infobox und nicht vom Abschnitt im Artikel)), bräuchte man auch keine Hinweise auf die Größen, da Frankfurt nicht zwischen Ministädten verloren ginge:

• Bayreuth, Bamberg, Schweinfurt, Würzburg, Aschaffenburg, Hanau, Offenbach, Frankfurt, Rüsselsheim, Mainz - Wiesbaden, welches jetzt drinsteht, liegt ja nur per Mainz-Kostheim am Main und gehört eh nicht in die Box.

Bei den Nebenflüssen steht beim Main eine in meinen Augen sinnvolle Auswahl. Hier ist auch die Trennung von linken und rechten sinnvoll. Bei kleineren fände ich u. U. die Aufzählung der Reihe nach sinnvoller. Ganz einfach, weil die oft keine Artikel haben. Und man bedenke, daß vielleicht eine IP freundlicherweise Nebenbäche eines kleineren Flüßchens in die Box einträgt und keinen Bock hat, gleich einen Abschnitt zu erstellen. Dann haben wir in der Box u. U. sowas, und die Reihenfolge darf gerne geraten werden. --Elop 12:48, 18. Aug. 2014 (CEST)

Alle Listenfelder der Box sollte nicht überfüllt werden. Weil dem gewöhnlichen Leser Flüsse deutlich weniger bekannt sind als Städte, gilt das verstärkt für die Nebenflusslisten, die sollten also noch knapper als die Städtelisten gehalten werden, Faustregel: höchstens ein halbes Dutzend. Genaueres dann jeweils in eigenem Abschnitt, und darin bitte bei den Flüsse die beider Seiten zusammen in Fließreihenfolge.

Für größere Flüssen könnte ich mir auch vorstellen, dass man beispielsweise eine selbständige Liste der Städte an der Donau oder eine Liste der Orte an der bayerischen Donau anlegt (zumindest im zweiten Fall dann aber hierarchisch, Regbez → Lkr → Komm → Ort). Erstens, um den Gewässerartikel nicht platzen zu lassen. Zweitens, inhaltlich gesehen: Hand aufs Herz, wer (außer Benutzer:Zollernalb) wüsste schon auf Anhieb, in welcher Folge Immendingen, Tuttlingen und Sigmaringen an der Donau liegen, oder Dillingen, Donauwörth, Neuburg, Ingolstadt und Kelheim, oder Straubing und Deggendorf? Und beim oberen Neckar: in welcher Reihenfolge kommen Reutlingen, Tübingen, Rottenburg, Horb? Links oder rechts oder beides? Siedlungs- oder nur Gebietsanrainer? Größenordnungen? So eine Liste wäre sicherlich eine sinnvolle Informationsaufarbeitung.

Sowas wird in diesem Leben wohl schon noch mal drankommen.

Beim Main finde ich die Mittelstädte-Liste schon ein Tüttelchen zu voll. Lichtenfels, Seligenstadt, Maintal, Mühlheim – sind halt wohl teilweise so vollgefressene Reformstädte der 70er Jahre, die es noch nicht in ältere Hirne geschafft haben, oder?

--Silvicola ^Disk 14:05, 18. Aug. 2014 (CEST)

Seligenstadt kennt man wohl eher von seinem Wahrzeichen her, dem Dreieck (während z. B. Worms mehrere bekannte Wahrzeichen hat, sodaß der Besucher, wenn denn das bekannte Konkordat wegen Renovierungsarbeiten geschlossen sein sollte, halt ersatzweise den Dom besichtigen kann) ... Von den Kleineren dürfte nur Kronach etwas bekannter sein. Wobei Rüsselsheim auch nur durch die vierrädrigen Rüsselspringer bekannt ist, aber durchaus weithin (wobei ja selbst Zuffenhausen, nicht am Main, ein weithin bekannter Orts(teil)name ist). --Elop 15:30, 18. Aug. 2014 (CEST)

Den Rüösselspringer hat schon ein anderer ausgiebig abgehandelt: La vie – Mode d'emploi (Der deutsche Artikel ist furchtbar rudimentär.) Selbiger hatte übrigens hinreichend Geschmack, um sich nicht pedantisch an die Regeln zu halten; wenn die auferlegten formalen Zwänge zu störend für den Zweck des Werks geworden wären, hat er sie halt eben auch mal souverän ignoriert. --Silvicola ^Disk 18:34, 18. Aug. 2014 (CEST)

Den Sinn der Unterteilung in Großstädte, Mittelstädte, Kleinstädte und Gemeinden habe ich nie verstanden. Bei großen Flüssen wie der Donau sind vermutlich allein die Großstädte viel zu viele, bei den meisten Gebirgsbächen ist nicht einmal ein Dorf weit und breit. Ein Kriterium wie "die max. 10 größten/bedeutendsten Orte" fände ich da schon sinnvoller. Zumindest in Österreich sind die Begriffe auch nicht sehr etabliert, gerade hat jemand bei der Enknach Braunau am Inn vom Feld "Kleinstädte" ins Feld "Mittelstädte" verschoben, was vermutlich der offiziellen Definition widerspricht, ich ihm aber nicht verübeln kann. Braunau (16.000 Einwohner, Bezirkshauptstadt) ist für österreichische Verhältnisse wirklich keine "Kleinstadt". --Luftschiffhafen (Diskussion) 14:50, 18. Aug. 2014 (CEST)

Ich sagte es schon in der früheren Diskus:

Landläufig werden oft nur die 50.000er als "Mittelstädte" angesehen.

Ich wäre, wie gesagt, für "maximal um 10", sodaß im Einzelfall mal 12 möglich wären, aber eben auch 5 gängig sein könnte. Und eben referenziertes Kriterium, damit nicht noch jeder schnell sein eigenes Städtchen einträgt und der Leser auch weiß, ab welcher Schwelle weggelassen wird. --Elop 15:30, 18. Aug. 2014 (CEST)

Ich bin fast immer für um. --Silvicola ^Disk 18:10, 18. Aug. 2014 (CEST)

Eine Auswahl sollte nach konkreten Kriterien erfolgen. Das funktioniert aber bei "bedeutenden Städten" nicht ohne POV. Das mit der Unterteilung der Kommunen ist schon sehr lange in der Box. Sinnvoll sind die Angaben nur dann, wenn sie nicht mehr als zwei, max. drei Zeilen ausmachen. Ich lasse die Nebenflüsse und Orte meist leer und schreibe das in den Text, weil es dort einfach übersichtlicher zu formatieren ist. In der IB könnte ich auf die Parameter verzichten.--SteveK ?! 15:34, 18. Aug. 2014 (CEST)

Gerade für den Österreicher oder Norddeutschen sind aber die genannten 10 Städte (ausgewählt nach objektivierbarem Kriterium) sowie die 5 Zuflüsse, die jetzt im Main-Artikel stehen, eine gute Grundinfo zur Orientierung. --Elop 15:42, 18. Aug. 2014 (CEST)

@Luftschiffhafen: Ich teile Dein Unverständnis ganz und gar; andererseits ist die Rubrizierung, pragmatisch gesehen, auch nicht so furchtbar schlimm. Bei den häufigsten Kleinkalibern von Gewässern sind die Rubriken Großstädte und Mittelstädte allermeist leer und tauchen dann in der dargestellten Box gar nicht auf. Oft gibt es sogar nur Gemeinden, dann hat man auch nur eine Liste – mit dann eben dem Unterbegriff „Gemeinde“ von „Kommune“ als Titel. Ist ja gar nicht so schlecht, da im Deutschen ein wirklich gängiger Überbegriff zum behelfsweise aufzählenden „Städte und Gemeinden“ fehlt. (Dazu gibt es dann noch so Sonderfälle wie gemeindefreie Forstgebiete … die man begrifflich schon gar nirgends klar unterstellen könnte.)

Im Grunde ist zumindest in DE die Einteilung von Kommunen in Gemeinden einesteils und Städte andererseits reine historisch gewordene Willkür; es gibt Städte mit 2-3.000 Einwohnern und Gemeinden mit 10-20.000 Einwohnern. Die gegenwärtige Bedeutsamkeit von Kommunen drückt sich eher (!) in diesen bürokratisch klingenden Raumordnungsbegriffen Unterzentrum, Mittelzentrum, Oberzentrum und was weiß ich noch für welchen Abwandlungen aus, von denen hier aber gar kein großen Aufhebens gemacht wird, in der Flussbox schon gar nicht. So etwas findet man dann allenfalls in den Ge-Ks-Ms-Gs-Artikeln selbst. Ist vermutlich auch gut so; ich kenne da Reformkonstrukte au den 70ern, bei denen, nachdem die Behörden vom Gießen-Marburg-Virus angesteckt waren, man ein „zentrales“ Rathaus oder eine solche Schule frisch in die grüne Wiese zwischen die weitab liegenden althergebrachten Ortschaften gestellt hat. Holla, es geht voran, wenn Aldi noch einen Laden daneben stellt, dann sind wir bald auch noch Stadt!

--Silvicola ^Disk 18:08, 18. Aug. 2014 (CEST)

Eine sehr interessante Stadt ist auch Arnstein (Sachsen-Anhalt) - einfach mal die Koordinaten des Artikels klicken ... Stadtrechte vermutlich vom randständigen Sandersleben im Osten geerbt ...

Gießen-Marburg-Virus? Oder meinst Du Lahn (Stadt)? Das waren Gießen und Wetzlar und die Dörfer dazwischen ... Einst die viertgrößte Stadt Hessens nach F, WI und KS - und noch vor DA. --Elop 19:28, 18. Aug. 2014 (CEST)

Irgendwann gibt's bestimmt eine Stadt Mecklenburg ohne Stralsund und Rostock. Wäre halt eine gewaltige Verwaltungsvereinfachung … triadische Organisation, nur eine Hierarchiebene … Aber wir hier unten können's noch besser und gründen dann bald die Stadt Südwestdeutsches Schichtstufenland, am besten gleich aküfi-gerecht und in der zukunftsicheren Sprache: SWGCS. Freu mich schon drauf, ein richtiger Switch-Seizer zu werden.

@Wetzen und Gießlar: Was soll ich Armer denn machen, wenn die Assoziation stimmt, die Tatsachen aber noch nicht so ganz auf ihrer Höhe sind?! --Silvicola ^Disk 22:37, 18. Aug. 2014 (CEST)

Das hätten die Gießener wohl gerne - sich in unserem Virus mit zu sonnen! --Elop 01:01, 19. Aug. 2014 (CEST)

@Silvicola: Schlimm find ich's auch nicht, aber halt auch nicht wirklich nachvollziehbar, schon weil, wie erwähnt, die Begriffe nicht einheitlich definiert und etabliert sind. Städte sind in Deutschland keine Gemeinden? Echt nicht? Was denn dann? Aber das würde natürlich die Unterteilung in "...städte" und "Gemeinden" erklären. In Österreich sind Stadtgemeinden (und Marktgemeinden) Gemeinden wie alle anderen auch. (Was anderes sind Statutarstädte, vergleichbar den kreisfreien Städten in D.) Dementsprechend hat z.B. jemand völlig logisch beim Glanbach Salzburg sowohl als Großstadt als auch als Gemeinde eingetragen. --Luftschiffhafen (Diskussion) 18:37, 19. Aug. 2014 (CEST)

Über die rechtliche Lage wollte ich nichts gesagt haben, ich kenne mich darin nicht aus. Ich bemerke nur, dass deutsche Sprecher gerne, wenn sie beides zusammen meinen, den Sammelbegriff Städte und Gemeinden benutzen, wohl weil es nach ihrem Sprachgefühl (!) diese Aufzählung braucht. Gemeinden werden eben in der allgemeinen Rede eher exklusiv gebraucht, der wohl auch fast jedem zumindest passiv bekannte Begriff Kommune, der dem Problem abhelfen könnte, lebt nicht in der Umgangssprache. Und hier muss man natürlich gerade auch mit naiver Auffassung der verwendeten Begriffe rechnen. – Wie war das noch in der Botanik? Die Erdbeere hat genau genommen Nüsse als Früchte …

M.E.n. gibt es rechtlich etwa in DE-BW gar keinen Stadtrat, sondern einen Gemeinderat der jeweiligen Stadt. Trotzdem redet alle Welt ganz selbstverständlich vom Stadtrat.

Noch ein schönes Beispiel einer „Stadt“ gefällig? — Langenburg, 1,7 kE auf 31 km², inklusive zweier Dörfer, fünf Weiler, eines Gehöftes und eines Wohnplatzes. Dazu eine Große Basilika in einem Teilort (Krypta ist erhalten) und zwei noch recht ordentlich aufrecht stehende Schlösser. Dem Vernehmen nach ist vor ein paar Jahren der letzte Arzt wegen Patientenmangels weggezogen, in die benachbarte „Stadt“ Gerabronn, 4,2 kE (1 × Stadt, 4 × Dorf, 12 × Weiler, 1 × Wohnplatz, 40 km²), wo die Nachbarstädter inzwischen auch das Tägliche einkaufen, ausgenommen vielleicht die Wibele und die Ansichtskarten, die's in einem der örtlichen Tortentouristinnencafés gibt.

--Silvicola ^Disk 22:10, 19. Aug. 2014 (CEST)

Abbildung von um- bzw. abgeleiteten natürlichen Gewässern

Hallo, es gibt Probleme mit der Abbildung von um- bzw. abgeleiteten natürlichen Gewässern in der "Infobox Fluss" bzw. in der "Kategorie Flusssystem". Es gibt zig Beispiele, wo durch Menschenhand, Flüsse größtenteils in andere Einzugsgebiete umgeleitet werden, oder aufgrund von Bewässerung ihr ursprüngliches Ziel nicht mehr erreichen. Da macht es für mich wenig Sinn, am ursprünglichen Flusslauf festzuhalten. Hier sollte die Infobox eine gewisse Flexibilität anbieten.--Slimguy (Diskussion) 19:30, 13. Okt. 2014 (CEST)

Ich verstehe irgendwie die Frage nicht, denn Bilder wirst du nicht meinen. Kannst du bitte ein konkretes Beispiel benennen damit es etwas klarer wird. --SteveK ?! 20:16, 13. Okt. 2014 (CEST)

Reihenfolge in der Infobox: Bild - Karte - Bild1 anstatt wie bisher Karte - Bild - Bild1

Hallo, ich würde mir wünschen, dass das BILD oben in der Infobox steht und die KARTE sowie die weiteren Bilder BILD1, etc. unter den Fluss-Angaben. Ich schätze es, einen ersten (optischen) Eindruck von dem Objekt (=Fluss) zu bekommen, auch wenn dieser nur einen Ausschnitt (bestimmter Flussabschnitt, Jahreszeit, etc.) hergibt. Die Karte ist natürlich wichtig, aber in vielen (>95 Prozent der) Fälle, ist die Karte nicht speziell für den bestimmten Fluss, sondern eine Karte mit zig Flüssen (evtl. in einer anderen Sprache oder Schreibweise), in welcher man erst mal den "richtigen" Fluss herausfinden muss.--Slimguy (Diskussion) 19:25, 13. Okt. 2014 (CEST)

Das hieße aber stets, einen festen Ort auszuzeichnen. Bei Fulda (Fluss) müßten sich dann die Städte Fulda und Kassel streiten, der Rhein würde u. U. Kölle-Alaaf "gehören" (oder es würden sich 10 oder mehr Städte streiten), usw. Alternativ würden sich Oberer Mittelrhein und Ober/Niederrhein darum streiten, wer darstellt, wie "der Rhein" aussieht.

Dabei ist genau eine Karte des Einzugs- und Flußgebieteas das, was "neutral" seine globale Bedeutung darstellt. --Elop 03:00, 14. Okt. 2014 (CEST)

Hugh!. --Silvicola ^Disk 07:34, 14. Okt. 2014 (CEST)

Ich hatte in der Projekt-Disk darauf abgehoben, dass die Bilder großenteils ziemlich beliebig sind. Das Argument von Elop kommt noch hinzu. Das eine gute Karte den besseren Überblick über den Flusslauf bietet, ist meiner Meinung nach einleuchtend. Ich hatte das Thema auf der Projektseite angesprochen, weil ich gesehen habe, dass Slimguy die vorhandenen Karten in die Zusatzbilder eingebunden hat statt in den Parameter KARTE. Das führt dann zu erhöhtem Wartungsaufwand, wenn man gezielt die Wartungsseiten abarbeitet. --SteveK ?! 09:22, 14. Okt. 2014 (CEST)

Fehler BUG in Flussartikel Hryuda

Hallo, im Artikel Hryuda

ist das Abflusssystem wie folgt angebeben:
| ABFLUSSWEG= Schtschara/Memel/Ostsee
Dennoch wird der Artikel in der Kategorie:Flusssystem Memel unter 1 angezeigt und nicht unter 2
in der Infobox traucht Schtschara nicht auf. --Francis McLloyd (Diskussion) 17:06, 15. Okt. 2014 (CEST)

Die Flüsse im Abflussweg müssen durch zwei // getrennt werden, ich hab's korrigiert. --Luftschiffhafen (Diskussion) 17:23, 15. Okt. 2014 (CEST)

Bei der von dir genannten Angabe wird der Artikel Schtschara so verlinkt: [[Schtschara|Memel]]. Die Ostsee wird dann wieder korrekt verlinkt.--SteveK ?! 22:45, 15. Okt. 2014 (CEST)

Fehler in der InfoboxFluss

Bei einigen Fließgewässern funktioniert die Infobox (bei mir???) nicht mehr richtig:

Beispiele: Kirchbach_(Gräbenackers_Bach), Marbach (Mümling), Wörsbach (Emsbach)

--Anarabert (Diskussion) 15:34, 27. Okt. 2014 (CET)

Nachtrag: Der Fehler entsteht bei den Parametern QUELLE_LAT_GRAD und QUELLE_LONG_GRAD, sowie MÜNDUNG_LAT_GRAD und MÜNDUNG_LONG_GRAD. --Anarabert (Diskussion) 15:48, 27. Okt. 2014 (CET)

Scheint ein generelles Problem mit den Koordinaten zu sein: Wikipedia:Fragen zur Wikipedia#Vorlage:Coordinate. --Luftschiffhafen (Diskussion) 15:50, 27. Okt. 2014 (CET)

SORTNAME und SORTIERUNG

herüberkopiert aus Benutzer Diskussion:Udo T.#Bühler (Fluss) --Silvicola ^Disk 17:39, 27. Okt. 2014 (CET)

 **** ZITAT ANFANG ****

die Aktion wäre nicht nötig gewesen, weil in der Einbindung der Vorlage:Infobox Fluss schon ein passender SORTNAME-Parameter definiert war. (Zumindest verlasse ich mich darauf, dass das so klappt und der passende Sortierungszusatz daraus generiert wird.)

Siehe auch Hilfe:Kategorien#Regel: Sonderzeichen: die Klammersymbole sollten als Sonderzeichen also ebenfalls raus. Gruß --Silvicola ^Disk 15:21, 26. Okt. 2014 (CET)

Hallo Silvicola,

danke für den Hinweis. Allerdings können die Auswertungen von WP:WPSK das wohl nicht erkennen, was in evtl. eingebundenen Vorlagen so alles drinsteckt. Deswegen ist der Beitrag auch in der entsprechenden Fehlerliste aufgetaucht. Es schadet aber auch nichts, denke ich. Mit dem Klammerzusatz hast Du recht, der sollte eigentlich ganz weg, das habe in dem Fall wohl übersehen, aber soeben korrigiert.

Gruß --Udo T. (Diskussion) 15:30, 26. Okt. 2014 (CET)

Nachtrag: Ich habe mir mal die Mühe gemacht und die Vorlage "Infobox Fluss" aus dem Beitrag Bühler (Fluss) auf Spezial:Vorlagen expandieren aufgedröselt. Der Sortierbegriff "Buhler Fluss" wird dort nur in die Kategorie "Flusssystem Bühler" mit übergeben. Da es aber noch weitere Kategorien ohne Sortierschlüssel gibt, kam der Beitrag wohl berechtigterweise auf die Fehlerliste. Gruß --Udo T. (Diskussion) 15:57, 26. Okt. 2014 (CET)

Das heißt, man tut gut daran, bei allen einschlägigen SORTNAME-befüllten Gewässer doch das DEFAULTSORT-Konstrukt doch noch unabhängig davon zu setzen? Denn in der Regel kommt ein Gewässer ja auch in die Kategorie durchflossener Gemeinden oder Landkreise. Gut zu wissen.

Übrigens vielen Dank für manchen Artikel-Nachputz, durch den Du mir schon über die Beobachtungsliste gelaufen bist. Ich werde wohl nicht bei jeder Rechtschreibkorrektur den Dankeknopf betätigt haben. --Silvicola ^Disk 16:43, 26. Okt. 2014 (CET)

Wäre wohl besser, da man ja auch nie weiß, ob nicht jemand später eine weitere Kategorie hinzufügt. Dann sollte man allerdings ganz offensichtlich den gleichen Sortierbegriff wie in der Vorlage verwenden, wie ich vorhin (auch in anderen Fluss-Beiträgen und dank Deines Hinweises) bemerkt, dann aber nachträglich sofort korrigiert habe.

Wegen der Korrekturen, nichts zu danken, jeder hilft, wo er eben am besten kann. WP:WPSK hat übrigens nichts mit Rechtschreibfehlern zu tun (die ich aber bei Bedarf auch beseitige ;o), sondern mit Syntaxkorrekturen im Quellcode.

Gruß --Udo T. (Diskussion) 16:52, 26. Okt. 2014 (CET)

Der Paramter SORTNAME regelt nicht nur die Reihenfolge bei den Flusssystemkategorien, sondern auch in den anderen (beispielsweise Gewässer im Landkreis Würzburg): Siehe dazu meinen Test beim Göckersgraben.--Anarabert (Diskussion) 17:15, 26. Okt. 2014 (CET)

Hallo Anarabert,

danke auch Dir für den Hinweis. Offensichtlich gibt es Kategorien, die das auswerten, andere aber hingegen nicht. Ich habe mich mittlerweile darauf eingestellt, bei der Bearbeitung einer fehlenden Sortierung darauf zu achten, ob es einen SORTNAME o.ä. in einer Vorlage gibt. Falls ja, dann verwende ich diesen Wert ebenfalls für meine Korrektur.

Gruß --Udo T. (Diskussion) 17:25, 26. Okt. 2014 (CET)

Meine Stellungnahme: Die Vorlage:Infobox Fluss setzt den Sortierschlüssen auf den Wert in SORTNAME, wenn die automatische Kategorisierung nicht abgeschaltet ist. Das erfolgt etwas versteckt in Vorlage:Infobox Fluss/KAT. Weicht die Angabe von SORTNAME von einer Angabe SORTIERUNG im Artikel ab, so wird ja eine rote Fehlermeldung ausgegeben. Gleiche Angabe doppelt schadet aber auch nicht.--SteveK ?! 19:15, 26. Okt. 2014 (CET)

Hallo SteveK,

also so wie ich das sehe, können die Auswertungs-Skripte von WP:WPSK das für diese Fehler-ID schlicht und einfach nicht erfassen. Hier wird ja sogar eine Vorlage durch eine Vorlage eingebunden. Ich glaube kaum, dass diese Auswertungs-Skripte bei jeder Seite auch noch die ganzen Vorlagen parsen. Aber es betrifft ja nur Lemmas mit Sonderzeichen und ich weiß ja nun Bescheid. Vielleicht werde ich im Beschreibungstext zu dieser Fehler-ID einen Hinweis auf die Infobox Fluss eintragen und dass bei der Bearbeitung der Wert von SORTNAME übernommen werden muss. Gibt es eigentlich noch mehr Vorlagen (Infoboxen), bei denen es einen Parameter SORTNAME gibt?

Gruß --Udo T. (Diskussion) 20:28, 26. Okt. 2014 (CET)

Sollte der Parameter SORTNAME in der Vorlage:Infobox Fluss für die richtige Sortierung in allen Kategorien sorgen, bedarf es keiner zusätzlichen Sortierungklausel außerhalb der Box. Ist dies nicht der Fall, dann ist er selbst völlig überflüssig.--Anarabert (Diskussion) 23:09, 26. Okt. 2014 (CET)

Sehe ich auch so. Kann man sich für wirklich alle Kategorien auf das Einsetzen der rechten Sortierung verlassen – dann verlässt man sich auch drauf. Wenn aber nicht, dann nicht. --Silvicola ^Disk 00:50, 27. Okt. 2014 (CET)

Nunja, vielleicht war es aber auch einfach keine so gute Idee, die Sortierung irgendwo (vorbei am Standard) in einer Vorlage zu verstecken. Mir persönlich ist es ja egal, wo sie nun steht und ich selber weiß es nun. Wenn ihr also die von mir vorgenommenen Änderungen wieder rückgängig machen wollt, habe ich überhaupt kein Problem damit. Die betroffenen Beiträge werden dann aber immer wieder in diesen Fehlerlisten auftauchen und es gibt auch noch andere, die im Projekt WP:WPSK mitmachen, sogar völlig neue Benutzer wagen sich da hin und wieder ran. Es besteht somit die Gefahr, dass andere euch da später immer wieder was reinsetzen werden.

Gruß --Udo T. (Diskussion) 01:14, 27. Okt. 2014 (CET)

Die Implementierung mit der Möglichkeit des Abschaltens der Kategorisierung durch die IB wurde so vorgenommen, um bei Nebenboxen nicht die schon in der Hauptbox gesetzte Sortierung überschreiben wird. Ob man beim Abschalten sich nur auf den Parameter NEBENBOX für das Abschalten der Sortierungsangabe stützt, ist hier zu überlegen. Der Parameter NOAUTOKAT soll ja eigentlich nur die falsche Einordnung in die Flusssystemkategorien verhindern.

Folgendes ist zu überlegen: 1. SORTNAME nur noch durch die Angabe von NEBENBOX ausschalten. 2. Verlagerung des Setzens der Sortierung in die oberste Ebene und unabhängig vom Parameter NOAUTOKAT gestalten.

Beides ist kein großer Aufwand. Wenn möglich vielleicht auch den Parameter umbenennen in SORTIERUNG, dann ist es eindeutig was das macht.

Gruß --SteveK ?! 09:54, 27. Okt. 2014 (CET)

 **** ZITAT ENDE ****

Was läuft hier schief

und wieso? Siehe Sur (Fluss). --Silvicola ^Disk 15:34, 27. Okt. 2014 (CET)

Und auch hier: Elisabethszeller Bach. --Silvicola ^Disk 15:47, 27. Okt. 2014 (CET)

Und auch hier: Lobbach (Elsenz).

Irgend eine Änderungen im Box-Code mit unerwarteten Nebenwirkungen? --Silvicola ^Disk 15:49, 27. Okt. 2014 (CET)

Der gleiche Fehler, wie bei mir, aber nur beim Lobbach (Elsenz), die beiden anderen Beispiele von Dir sind bei mir OK.--Anarabert (Diskussion) 15:52, 27. Okt. 2014 (CET)

Siehe einen Abschnitt höher und Wikipedia:Fragen zur Wikipedia#Vorlage:Coordinate. NNW 15:54, 27. Okt. 2014 (CET)

Und mit jedem Purge auf einen guten ein fauler mehr. --Silvicola ^Disk 15:56, 27. Okt. 2014 (CET)

Elisa und Sur sind bei mir immer noch böse zugerichtet. --Silvicola ^Disk 15:58, 27. Okt. 2014 (CET)

Alles recht merkwürdig: Jetzt sind bei mir alle Deine Beispiele auch faul. Kurzzeitig abgemeldet waren dagegen einige welche vorher fehlerhaft waren OK, dafür aber andere nicht korrekt.--Anarabert (Diskussion) 16:06, 27. Okt. 2014 (CET)

Horgner bringt es ganz gut auf den Punkt:

>>Das zerschiesst ja nur das Layout von ein paar tausend Artikeln. Wem gehört der Orden dafür? <<

--Elop 16:14, 27. Okt. 2014 (CET)

Beim Lobbach (Elsenz) habe ich einen Umpruch </br /> gegen <br /> getauscht, dann war das Problem behoben.--SteveK ?! 16:36, 27. Okt. 2014 (CET)

Das ist dann aber schon eher merkwürdich, wenn es ja ein Problem der Koordinatenvorlage iss ... --Elop 16:42, 27. Okt. 2014 (CET)

I beg to doubt on that, too.

Siehe Vorlage Diskussion:Coordinate#Merkwürdige Anzeige??. --Silvicola ^Disk 16:44, 27. Okt. 2014 (CET)

Lag wahrscheinlich am Autopurge. So nach und nach scheinen die jetzt alle wieder zu funzen ... --Elop 16:45, 27. Okt. 2014 (CET)

ita erat oder so ... --Elop 16:47, 27. Okt. 2014 (CET)

Hauptsache ist: nicht Iterat. --Silvicola ^Disk 11:37, 28. Okt. 2014 (CET)

Kategorie für endorheische Gewässer

Hallo, gibt es für endorheische Gewässer, die zuwenig Artikel für eine eigene Flusssystem- bzw. Gewässersystemkategorie aufweisen, eine Sammelkategorie (evtl. Kategorie: endorheische Gewässer oder endorheische Flüsse/abflusslose Seen)? Falls nicht, würde es nicht Sinn machen, so eine Kategorie bzw. solche Kategorien anzulegen? Dann würden diese Artikel nicht als "Fluss ohne Flusssystemkategorie" in der Wartungsliste auftauchen.--Slimguy (Diskussion) 19:34, 13. Okt. 2014 (CEST)

Diese Frage hat meiner Meinung nach erstmal nicht viel mit der Infobox und ihrer Programmierung zu tun, vielmehr mit der Kategorisierung an sich. Die automatischen Kategorisierung nach Flusssystemen ordnet derzeit lediglich dann den Artikel in eine solche ein, wenn ein Artikel des Abflusswegs in eine [[:Kategorie:Flusssystem <Artikel>]] hat, wobei <Artikel> sowohl das Lemma incl Namenszusatz als auch die Darstellung sein kann.--SteveK ?! 20:22, 13. Okt. 2014 (CEST)

Es gibt Kategorie:Endorheisches Flusssystem und auch Kategorie:Endorheisches Gewässersystem. Wobei Flusssysteme, die endorheischh sind, in die erste Kategorie gehören, in die zweite nur solche, die selbst das "Ziel" der endorheischen Systeme sind, also das Binnenmeer und dergleichen. -Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 00:16, 1. Nov. 2014 (CET)

TOPO-KARTE

Die Vorlage:Infobox Berg hat – seit wann auch immer, jedenfalls ist es mir erst kürzlich aufgefallen – einen Parameter TOPO-KARTE, über den man eine Online-Karte verlinken kann. Da inzwischen mehrere Kartenserver deutscher Bundesländer und Gebietskörperschaften

Geoportal Baden-Württemberg (Hinweise)

BayernAtlas der Bayerischen Staatsregierung (Hinweise)

Kartendienst des Landschaftsinformationssystems der Naturschutzverwaltung Rheinland-Pfalz (LANIS-Karte) (Hinweise)

www.lagis-hessen.de

Navigator Göttinger Land

… mehr ? …

ganz oder leidlich selbstgewählte Kartenausschnitte zu verlinken erlauben, wäre zu überlegen, ob man in dieser Vorlage hier Ähnliches vorsehen sollte.

Nach Möglichkeit bindet man Onlinekarten der Flussläufe derzeit ja schon unter den Weblinks ein. Die Frage ist also nur, ob man den Schnellklickenden unter den Lesern das Scrollen ersparen soll.

GGf. sollte dort natürlich nicht alles, was sich gerade eben auch noch Karte schimpft, vertreten sein können, sondern nur solide Topographisches.

Wie sind die Meinungen dazu? --Silvicola ^Disk 07:22, 14. Okt. 2014 (CEST)

Ich nehme an, das Einfügen in die Bergbox fiel in Herzis (noch andauernde) Ägide als Boxenbergziege. Wäre gegebenenfalls am einfachsten, wenn der es einpflegte - dann muß sich das Boxenflußpferd nicht eindenken ... --Elop 19:19, 15. Okt. 2014 (CEST)

Ist das eine Darstellung oder lediglich ein Link der dann erscheint?--SteveK ?! 22:41, 15. Okt. 2014 (CEST)

Nur ein Link, den man als Artikelschreiber auch noch selbst in Wikisyntax zusammenbastelt, anscheinend – anderes liegt auch nicht nahe – mit einer Serverbezeichnung als Linktext. Vorlagentechnisch also höchst simpel; ein Dreizeiler in der Berginfobox. --Silvicola ^Disk 01:18, 16. Okt. 2014 (CEST)

Habe ich auch gesehen. Wäre noch zu klären, wo das Plaziert werden soll.--SteveK ?! 11:21, 16. Okt. 2014 (CEST)

Schwierig zu entscheiden. Dass das Angebot nur indirekt zu haben ist, spricht einerseits eher gegen den Platz gleich nach dem Kartenbild. Andererseits, wenn das fehlt, ist der Link vielleicht ersatzweise begehrt und deshalb doch recht prominent oben zu platzieren. Ansonsten gäbe es thematisch hinter dem EZG und vor den mehr technischen Abflussdaten, die wohl für die meisten Leser nicht dermaßen interessant sind, eine nutzbare Zäsur. Oder doch erst hinter die zweite Runde der Milieu-Geodaten Stadt-Gemeinde-Nebenfluss-See, also ganz am Ende?

Am besten wäre vielleicht vorab eine kleine Umfrage unter den Interessierten hier. Nach dem Einbau sieht man erst, ob und welche Forderungen und Proteste kommen, das ist dann der wirkliche Test. Da die Reihenfolge der Parameter in der Formatvorlage ohnehin schon abweicht von ihrer Darstellungsreihenfolge, kann man ja auch nachträglich schadlos den Erscheinungsort dieses Parameters in der programmierten Vorlage noch ändern.

--Silvicola ^Disk 15:32, 16. Okt. 2014 (CEST)

@Elop: Was haben wir gelacht! Boxenbergziege.

Zu TOPO-KARTE in der Infobox Berg: Ist ein Relikt, dass nicht von mir stammt und dem ich eher skeptisch gegenüberstehe (WP:WEB, link auf Kartendienste). Verwendet wurde der Parameter ursprünglich nicht zur Verlinkung einer Online-Karte, sondern zur Anführung einer Topologischen Karte in Papierform: Augstenberg (Silvretta), Mount Hayes, Piz Medel, aber inzwischen auch als Weblink z.B. Krähberg.

Es kommt gerade mal bei 83 Bergen (< 1% vor); davon bei 16 als Weblink im Sinne des hier diskutierten. Daher ist der Parameter aus der Bergbox vielleicht keine Referenz für hier.

Inhaltlich halte ich den Verweis auf eine Karte in Papierform für entbehrlich, da jederzeit über die Webseiten der Verlage herausfindbar. Und auch, weil sich die Kartenschnitte (aus kommerziellen Überlegungen) auch mal ändern können (so z.B. neulich bei der 1:50000 des BEV in AT). Vielleicht gibt es in Zeiten zunehmender Entstaatlichung auch keine offiziellen Karten mehr. Und weil Karten weitgehend Online verfügbar sind (über Coordinate und Geohack auffindbar). Den Weblink eher nicht wegen WP:WEB, link auf Kartendienste. Was doch wirklich gebraucht wird, ist eine Karte des Flusssystems, egal ob aus der Kartenwerkstatt oder von extern (z.B. über die Gewässerkennzahl). Bei kleinen Flüssen helfen die Koordinaten, bei großen hilft die Karte auch nix (Donau, Rhein, etc.).

In meiner Funktion als Boxentunnelbohrwurm (© Elop, derived work) habe ich in der {{Infobox Tunnel}} gerade {{All Coordinates}} eingebaut, was dazu führt, dass die beiden Tunnelportale auf der Karte angezeigt werden und damit der ganze Tunnelverlauf. Bei Flüssen wird die Mündungskoordinate hergenommen, falls definiert, sonst die Quellkoordinate. Es wäre durchaus überlegenswert, hier auch {{All Coordinates}} über die Box zu erzeugen, statt einer endlagigen Koordinate. Dazu kommt, dass in vielen Flussartikeln weitere Koordinaten vorkommen können (Mündungen von Nebenflüssen, etc.) lg --Herzi Pinki (Diskussion) 10:05, 1. Nov. 2014 (CET)

Vorausgeschickt: Ich erwog nur und ausschließlich, einen für den Fluss genau passenden Kartenausschnitt zu verlinken. Wenn ich mir die einschlägige Partie von WP:WEB durchlese

Keine Links auf Websites zur Darstellung koordinatenbasierter Landkarten, Satellitenfotos oder Luftaufnahmen, sofern vergleichbare Inhalte in den vom WikiProjekt Georeferenzierung vermittelten Kartenressourcen enthalten sind. Darstellungen und Anwendungen, die auf geographischen Koordinaten basieren, werden primär durch die Verwendung der Vorlagen für Artikel- und Textkoordinaten nutzbar gemacht. Näheres zu deren Benutzung findet sich im Wikiprojekt Georeferenzierung.

dann habe ich den Eindruck, es solle da die Punktkoordinatendarstellung tunlichst über WP-Hausmachermethoden kanalisiert werden. Hier geht es aber um Ausschnittsdarstellung (Flusssystem, Einzugsgebiet).

Wenn man alternativ durch Aufbohren der Geohack-Koordinatenpunktdarstellung Flächendarstellung realisieren will, geht das natürlich auch, indem man wohl Parameter für den Zentralpunkt, Breit und Länge liefert. Ich zweifle etwas, ob die Semantik da jedem möglichen Beiträger so klar wäre und ob er das reverse Parameterermitteln so hinbekäme wie die schlichte Übernahme eines Weblinks, der überdies ziemlich übel kodiert sein kann. Wozu sollen dann Vorlagenprogrammierer hier erst mal für jeden Service Reverse Engineering betreiben, auf dass man die Beiträger dazu verpflichten kann, ihrerseits die Parameter für die Einbindung selbst hinpfriemeln zu müssen. Wieso diesen Umweg gehen? Ist das nicht ein Befall durch das Not-invented-here-Syndrom?

--Silvicola ^Disk 16:44, 1. Nov. 2014 (CET)

Hallo Silvicola, ich habe die Situation bei den Bergen beleuchtet. Ich stimme dir zu, dass die WP Kartendienste keine flächigen Objekte direkt unterstützen. Aber ein rechteckiger Kartenausschnitt ist ja auch noch kein flächiges Objekt. Es braucht eine Shape, die den Fluss + sein Einzugsgebiet auf den Kartendiensten entsprechend visualisiert. Was ist dein Vorschlag dazu? Einen Weblink auf eine Karte kannst du unten unter Weblinks immer einbauen (dort genauso WP:WEB), die Semantik von TOPO-KARTE ist eine andere (wie ich oben erläutert habe, d.h. für Links auf externe Kartendienste sollte man einen anderen Parameternamen erfinden), es geht hier ja um einen zusätzlichen Parameter in der Box. Es wäre insgesamt von Vorteil, wenn alle diese Kartendienste im Geohack eingebaut wären, dann sind sie für alle Koordinaten nutzbar, nicht nur für die Flüsse. Wie würde deine Lösung bei grenzüberschreitenden Flüssen aussehen? Welche Topo-Karte nimmst du da? {{All Coordinates}} würde für alle Flüsse sofort eine Verbesserung bringen, insbesondere für kleine. Aber dazu fehlt deine Meinung noch. Rechts ein Beispiel für die Elbe und Singold

 Karte mit allen Koordinaten der Elbe: OSM | WikiMap

 Karte mit allen Koordinaten des Singolds: OSM | WikiMap

lg --Herzi Pinki (Diskussion) 20:38, 1. Nov. 2014 (CET)

Man könnte auch sowas einbinden, am besten direkt. Dann weiß man jedenfalls gleich, wo das Gewässer fließt.SteveK ?! 22:22, 1. Nov. 2014 (CET)

Die Darstellung des Verlaufs ist besser, aber die der Umgebung halt nicht berauschend, wie meist bei OSM. Für Flüsse sind umgebenden Höhenlinien sehr wichtig, die wohl nie zu haben sind. Ich vermute, der Verlaufs-Polygonzug kommt aus so einem koordinatenausspuckendem Gerät. Wird man damit nun gerade viele Flussverläufe exakt angeliefert bekommen? --~~

Hallo HP,

1. eine Karte des Einzugsgebietes oder des Flusssystems bieten zu können, wäre ja schon ein atemberaubender Luxus, den ich mangels entsprechender Dienste im Allgemeinen zunächst gar nicht erhoffen würde. Was die Zukunft da bietet, muss man sehen.

2. Aber eine gute topographische Karte, die den Fluss in seinem Milieu zeigt, ist schon sehr viel wert. Es braucht da gar keinen zusätzlichen Einzugsgebiets-Shape, um hier eine Verbesserung gegenüber den wohl gängigerweise via Geohack von OSM/Google Maps/Bing gezeigten Luftbildkarten oder sehr auf den Straßenverlauf fokussierten Karten zu schaffen. Topographische Karten sind seit Jahrhunderten auf gute Darstellung von Flüssen getrimmt, die Luftaufnahmen dagegen sind nur ein Behelf. Ein heftiger Geobeiträger hier hat mir gegenüber mal geäußert, den Lauf der Rems auf einer solchen Luftbildkarte völlig falsch gesehen zu haben, er nahm anscheinend die verbundenen Rodungsinseln auf dem rechts begleitenden Welzheimer Wald für Tallichtungen. Wie wird es da erst nur gelegentlich eine Karte nutzenden Lesern gehen?

3. Der Bearbeiter und ggf. Verlinker weiß besser als der Leser, welche der lokal verfügbaren Karten für die Flussdarstellung am tauglichsten ist. Der Leser müsste erst alle durchprobieren (und wenn er auch noch ein Gebremster-Schaum-Internet-Segler ist wie ich, dazu auch noch erst ein paar Sites pro Service für JavaScript freischalten …). Freiheit der Wahl mit Geohack, ja, aber auch der Qual.

4. Bei der All-Coordinates-Elbe erkennt man wenig vom tatsächlichen Verlauf, weil der Farbtropfen zu wenige gesetzt sind. Wären es mehr, verlöre man leicht den Überblick über die rechten Zuflüsse, bei gewundenerer Flüssen auch über einen Teil des eigenen Verlaufs. Diese Achtung-Hier-Aufwärtskullerträne mag sinnvoll sein, um auf wenige Einzelpunkte hinzuweisen, wenn sie sich aber dicht an dicht reihen, wird es zu aufdringlich. Kommt mir vor wie die fetten Weinglas-und-Suppenteller-Hinweis-Icons auf manchen neueren Tourismus- und sogar Wanderkarten, die dann das wesentlichere Topographische oft verdecken.

5. All-Coordinates am Beispiel der Singold: Auf keiner der derzeit gebotenen Karten erkennt man etwa die enge Begrenzung des Einzugsgebietes zwischen Wertach und Lech. Dagegen hier auf einen Blick.

6. Wenn man die für Flussdarstellung tauglichen (typischerweise) TKs unter die Dienste von Geohack bringen kann, schön und gut. Wenn man dort von Seiten des Bearbeiters auf die (oder den) allein tauglichen einschränken könnte, noch besser. Vorher lieber die Taube in der Hand als die ganze bunte Vogelschar auf dem Dach. (Bunt ist übrigens gerade so ein Punkt … Die Farbcodierung für verschiedene Kategorien topographischer Objekte ist zwar zwischen TKs auch nicht gerade einheitlich, aber im Vergleich zu den Komm-in-meinen-Diner-und-hol-Dir-den-Coffee-to-go-Diensten ist das alles noch Gold.)

7. Es ist nicht garantiert, dass man auch nur oft eine so gute (topographische) Karte finden wird, dass man ihr eine Verlinkung in der Box gewähren wollte. Das ist aber kein Grund, deshalb nie dort zu verlinken.

8. Es geht hier nur und allein darum, ob man der in der Regel vom Bearbeiter ohnehin schon unten bei den Weblinks verlinkten tauglichsten Online-Karte einen prominenteren Platz weiter oben in der Flussbox verschaffen soll. Ob das sinnvoll ist, hängt vom Nutzungsprofil ab. Ich selbst will immer möglichst bald auf eine brauchbare Karte kommen, mir würde das also Zeit ersparen. (Soweit mein Eigeninteresse, ansonsten mache ich mit diesem nur den advocatus angeli der Aufnahme in den Boxenhimmel.) Wie sieht es bei der gesamten Leserschaft aus? — Vermuten würde ich, dass ein Kartenblick aufs Gewässer für den typischen Leser wichtiger ist als etwa die Lektüre der dort genannten Abflussdaten. Zumindest wenn die Ladezeiten, ein schwachbrüstiger Rechner usw. ihn nicht hiervon pragmatisch abhalten.

Gruß --Silvicola ^Disk 22:43, 1. Nov. 2014 (CET)

Hallo SC,

1. du kannst :::# zum Durchnummerieren verwenden.
2. ad 5, Singold. Mit Verlaub, ich sehe dort gar nichts auf den ersten Blick. Nicht so übertreiben. Ich muss hineinscrollen, damit der Flussname überhaupt angezeigt wird. Und dann, wie kann man den Link auf den Bayernviewer gestalten, dass der back-Button funktioniert?
3. Ich habe gemeint, dass {{All Coordinates}} eine unmittelbare Verbesserung gegenüber der jetzigen einen Mündungskoordinate ist. Und dass sie zentral über die Box in 3 Minuten eingeführt werden kann. Das ist jetzt noch kein Widerspruch zu deinem Wunsch, aber wie lange brauchst du, bis du bei einer nennenswerten Anzahl an Füssen den TOPO-link gesetzt hast? Es ist keine Alternative zu deinem Link, dafür einfach und weltweit machbar.
4. Was machst du bei grenzüberschreitenden Flüssen? In wie vielen Ländern gibt es diese Dienste? Man kann also maximal einen solchen Parameter als Option anbieten.

lg --Herzi Pinki (Diskussion) 00:45, 2. Nov. 2014 (CET)

@1.: Weiß ich selbstredend, aber benutze ich in Diskussionen nie, weil man mit expliziter Nummerierung im Bearbeitungfenster als Replikant sich einfacher auf einen bestimmten Punkt beziehen kann, ohne jedesmal die Gartenzäune abzählen zu müssen. Mehrfaches „Tiefen-Einweben“ macht ja alles recht bald unübersichtlich, also besser den eigenen Beitrag en bloc nachstellen. Im Grunde geht es bei Diskussionen auch nie um die exakte Anzahl und Position der Punkte in der Folge, sondern um einen distinktive Markierung. Das sehe ich sogar als Service für andere, auch um den Preis, dass die dann vielleicht wähnen, ich kennte die Listensyntax nicht.

@2. Ich muss gestehen, ich benutze bei Karten nie den Back-Button, sondern mache stets für den Link eine neue Browserkachel auf. Auch sonst selten. --Silvicola ^Disk 01:47, 2. Nov. 2014 (CET)

@3. Verbesserungen gibt es hier ohnehin immer nur inkrementell. Zumindest ich selbst arbeite fast immer an einem Artikel und gehe zum nächsten, einen Aspekt in Hunderten von Artikeln zu erledigen, peinigte mich so wie die massenhaften Linkanpassungen nach Lemmaverschiebung, an denen ich im Hinblick auf tüttelige Querschnittsarbeit genug habe. Wenn ich inhaltlich Mangelhaftes sehe, verbessere ich gleich mehr oder aber gar nichts. Wie Du selbst andeutest, schließt TOPO All-Coordinates nicht aus.

@4. Man kann nicht alles haben, das Feld müsste ja auch nicht immer gefüllt sein. Wenn es aber gefüllt ist, sollte man Brauchbares erwarten können. Dass es weniger transnationale Karten gibt als wünschenswert, ist kein Problem, das in der Wikipedia zu lösen wäre. Dienste werden wohl weiterhin noch kräftig zuwachsen, schau nur mal. wie sich die Quellensammlung in letzter Zeit bläht!  :::::--Silvicola ^Disk 01:47, 2. Nov. 2014 (CET)

Manchmal gibt es doch schon Projekte mit grenzüberschreitenden Karten (bzw. deren Zusammenführung):

Geoportal Großregion GIS-GR

--Anarabert (Diskussion) 06:48, 2. Nov. 2014 (CET)

Einwände gegen mehrzeilige Parameterwerte?

Mrhein
Lage	Nordrhein-Bayern Querfranken Landkreis Nürnberg-Xanten

Ich wollte die Gebietskörperschaftshierarchie unter LAGE klarer darstellen. Anscheinend – Aufklärung darüber habe ich hier erfahren – kann man in den Parameterwerten auch Umbrüche einbauen und dann mit „:“ und „*“ wie in gewöhnlichem Wikitext gliedern. Spricht denn etwas gegen mehrzeilige Syntax wie nebenan im LAGE-Parameterwert? --Silvicola ^Disk 18:09, 24. Sep. 2014 (CEST)

Ich hatte hier im August eine Diskussion über Reihenfolge und deine Formatierung mit einem anderen Mitarbeiter. Letztlich nicht eine Frage des Könnens so wie du es ja schon zeigst, sondern der Akzeptanz. Ich würde die Formatierung akzeptieren, wenn nicht in der Lagezeile ellenlange Listen entstehen. Bei ca. fünf Zeilen würde ich die Grenze ziehen wollen. --SteveK ?! 19:49, 24. Sep. 2014 (CEST)

Ca. fünf klingt auch für mich vernünftig. Wenn mehr käme, sollte man sich ohnehin auf die höheren Einheiten beschränken, so wie man bei den Kategorien ja auch nicht ein Dutzend Gemeinden einstellt. „Too much of a good thing good for nothing.“

Was mir beim derzeitigen Textaufzählungs-System aufstieß, waren etwa Landeswechsler, bei denen dann die Zuordnung der Kreise zum Land vage wird (schlimmstenfalls noch etwa wie bei HE→Odenwaldkreis und BW→Neckar-Odenwald-Kreis) und manchem vielleicht Falsches insinuiert, denn die schwachen Trenner Komma und Strichpunkt können so oder so aufgefasst werden, während Einrückung top-down klar und selbsterklärend ist. Und dann will ichs bei den selbstverfassten Artikeln eben auch konsistent nach nur einem System halten.

--Silvicola ^Disk 21:13, 24. Sep. 2014 (CEST)

Bei der von mir angesprochenen Diskussion mit TOMM ging es auch darum, ob in der Lage das Gebirge auftauchen darf/soll/kann. Ich vertrete da den Standpunkt, dass man nicht die politische Zuordnung mit geographischen Zuordnungen mischen sollte (Beispiel). Alleine können wir das eh nicht entscheiden.--SteveK ?! 12:47, 25. Sep. 2014 (CEST)

Ich finde mehrzeilige hierarchische Angaben nicht sonderlich schön, und ich finde auch, dass in der Infobox eine grobe Angabe wie das Bundesland und ggf. eine entsprechend kleinere Region ausreicht. Aber das ist alles Geschmackssache, und wenn's nach mir geht, soll das jeder so machen, wie er's für richtig hält. Warum sollte man politische und geographische Zuordnungen nicht mischen? Eine Angabe wie, sagen wir, "Ötztaler Alpen, Tirol" erscheint mir für einen entsprechenden Gebirgsbach treffender als "Bezirk Imst, Tirol" oder aber "Ötztaler Alpen, Ostalpen". --Luftschiffhafen (Diskussion) 13:09, 25. Sep. 2014 (CEST)

(Nach Bearbeitungskonflikt.) Mir hat es bisher auch immer eher widerstrebt, in der LAGE die politisch-administrative Zuordnung noch mit einer landschaftlichen zu vermengen, weil die quer liegt und meist auch noch vage ist. Ich könnte mir aber vorstellen, aus Pragmatismus davon abzugehen und mich „unten“ ganz auf die landschaftliche zu beschränken, wenn es beispielsweise um einen ganz siedlungsfernen Hochgebirgsbach geht. Dort sind Gemeinde- und Kreisgrenzen kaum jemandem präsent, die der Ebenen drüber schon, vermutlich weil das oft alte Schmuggelgrenzen sind und diese auch konsequenter auf den Graten laufen. Es gibt in BY etwa landesunmittelbare Forstgebiete, die so abgelegen sind, dass kein Leser, der nicht Alpinist ist und dann ohnehin eher nach Morphologie zuordnet, je in die Gegend kommt. Dann helfen die gewöhnlichen administrativen Gebietshierarchien keinem zur anschaulichen Verortung. Dank noch vieler Mittelgebirgsbäche werde ich aber wohl eher nicht in Versuchung kommen, selber so einen Wechselbalg zu zeugen. --Silvicola ^Disk 13:33, 25. Sep. 2014 (CEST)

Mrhein
Lage	Nordrhein-Bayern, Querfranken, Landkreis Nürnberg-Xanten

Die Angaben aus dem obigen Beispiel werden schon jetzt mehrzeilig, auch wenn man keine Umbrüche verwendet. So gesehen sind einzeilige Lageangaben wohl eher selten. Das mit den Gebirgen in abgelegenen Regionen kann ich nachvollziehen. Das kommt aber auf die Gegend an. Bei meinem Beispiel Jückenhohl ist wohl das Rothaargebirge als Lage schlechter als die Angabe der Kommune Brilon. Die Ausgangsfrage war aber, ob man die Lage wie gezeigt strukturieren darf. --SteveK ?! 16:11, 25. Sep. 2014 (CEST)

Die Benutzung der gewöhnlichen Wikisyntax in den Wertfeldern der Infobox hat die folgenden Nachteile:

1. Recht tiefe Einzüge, das führt bei tiefer Schachtelung vermehrt zu unschönen Umfaltungen bei langen Namen von Gebietskörperschaften („Landkreis Neustadt an der Aisch-Windheim“ und ähnliche Kaliber).

2. Zeilenabstand ist für die Box zu groß, der unter der letzten Zeile stört ebenfalls

Als Beispiel siehe etwa Zellergraben oder Gertraudengraben. Deshalb würde ich doch gerne eine eigene Vorlage benutzen. Interesse dafür besteht zumindest auch von Benutzer:Anarabert. Siehe Benutzer:Silvicola/Vorlage:Einrückung für die geplante Vorlage und Benutzer:Silvicola/Einrückung-Test für ein Verwendungsbeispiel. Einwände?

Ich dachte an eine Benennung als Vorlage:Ab-Spalte oder Vorlage:Box-ab-Spalte oder ähnlich. Einwände? Andere Namensvorschläge? (Die Vorlage ist auch für andere Infoboxen benutzbar, deshalb scheint eine Subsumtion unter Vorlage:Infobox Fluss nicht sinnvoll.)

Bitte um Stellungnahme. --Silvicola ^Disk 15:55, 30. Sep. 2014 (CEST)

Mrhein
Lage	Landkreis Neustadt an der Aisch-Windheim
Durchflossene Seen	X-See

Wie man die Einrückung macht, dass ist wohl fast egal. Irgendeinen Tod wird man dabei immer sterben, weil die 1. Spalte eben nicht immer so schmal ist wie hier auf der Seite gezeigt. Da wird dein LK auch ohne Einrückung umgebrochen. --SteveK ?! 13:07, 1. Okt. 2014 (CEST)

Vergleich

1. Variante, mit Standard-Wikisyntax.

2. Variante mit vorgeschlagener Vorlage.

Vorbemerkung: Ich persönlich notiere die Hierarchieebene DACH in eigenen Artikeln nie. Wer die deutschsprachige Wikipedia sinnvoll benutzen kann, der weiß meines Erachtens zumindest passiv, dass Bayern in Deutschland liegt und die Steiermark in Österreich und der Kanton Zug in der Schweiz. Aus meiner Sicht ist das deshalb pragmatisch gesehen redundant. Ich würde auch in BY die Regierungspräsidien nur alternativ zu Landkreisen setzen wollen, wenn der Fluss lang ist, sonst wird mir das zu tüttelig. Aber es gibt nun mal welche, die hier immer auch diese beiden Ebenen zeigen wollen.

Analyse:

1. Wegen geringerer Einrückungstiefe mit der Vorlage weniger Zeilen. (Dazu auch die absichtlich nur 12px Linksrand pro Stufe in der Vorlage.) Vgl. den Dreizeiler für den „bösen“ Landkreis. Ist so sicher nicht immer besser, aber eben öfter.

2. Der Vertikalabstand der Zeilen ist mit der Vorlage ganz wie in den anderen Boxfeldern – vgl. Abfluss – und zwischen allen Zeilen gleich. Bei Wikisyntax dagegen liegt zwischen manchen aufeinanderfolgenden Zeilen – offenbar beim Hierarchiestufenwechsel sowie am Ende des gesamten Boxfeldes – mehr Weißraum als zwischen den anderen. Ist vielleicht für freien Artikeltext typographisch sinnvoll, für raumbegrenzte Boxfeldern eher unpassend.

--Silvicola ^Disk 22:20, 1. Okt. 2014 (CEST)

Wer nicht widerspricht, billigt wohl. In den Vorlagennamensraum gestellt als Vorlage:Ab-Spalte. Gruß --Silvicola ^Disk 01:47, 5. Okt. 2014 (CEST)

Hallo Silvicola, nachdem du zum Abschluss deiner Anfrage in der Vorlagenwerkstatt nach Anregung von Benutzer:PerfektesChaos zu der Meinung „keine Extrawurst nötig, sondern Standardwiki-Syntax“ gekommen warst, war ich davon ausgegangen, dass du auf die Einführung einer eigenen Formatierungsvorlage verzichten willst. Deshalb habe ich mich dort nicht mehr dazu geäußert und bin jetzt überrascht darüber, dass sie doch angelegt wurde und schon zahlreich zum Einsatz kommt.

Aus mehreren Gründen bin ich gegen dieses Vorgehen. Der mir wichtigste hat mit Semantik zu tun. Wir gehen beim Formatieren erstmal nicht nach Aussehen, sondern nach Bedeutung. Eine mehrstufige Liste, wie hier bei der Belegung des Parameters „Lage“ ist auch als solche umzusetzen. Es reicht nicht, dass sie so ähnlich aussieht wie eine solche. Durch Ersetzen einer mit Doppelpunkten erzeugten Liste durch eine Aneinanderreihung von Vorlagenaufrufen geht die ursprüngliche Mehrstufigkeit verloren. Das betrifft nicht nur den Leser, der möglicherweise Hilfsmittel einsetzt, um sie besser sichtbar zu machen, sondern auch die maschinelle Auswertung und diejenigen Konsumenten, die darauf angewiesen sind, sich den Inhalt von Screenreadern vorlesen zu lassen. Andere Gründe für meine Haltung sind das abweichende Aussehen im Vergleich zu vielen anderen Infoboxen und der weniger intuitive und schwerer zu pflegende Quelltext beim Einsatz dieser Vorlage.

Um einige Zeilen der Infoboxdarstellungen in Artikeln einzusparen, gibt es die Möglichkeit, die Breite der rechten Spalte der Infobox zu erhöhen oder die Schriftgröße der Lage-Angaben zu verringern. Wem das nicht reicht, kann durch individuelle Benutzereinstellungen auch die Einrücktiefe und Außenabstände bei Listen innerhalb von Infoboxen verringern. Hierbei bin ich auf Wunsch gern behilflich.

Was meinst du (oder auch andere Mitlesende) dazu? --Wiegels „…“ 01:50, 28. Okt. 2014 (CET)

Hallo Wiegels,

Mein Ausgangspunkt für die ganze Aktion war ja auch, dass die üblichen Komma/Strichpunkt-Listen in der LAGE semantisch zu intransparent sind, vor allem wenn höhere Hierarchiebenen wechseln. Wenn es durch tiefe, für Fließtext wohl gut, hier aber eher nicht passende Einrückungsbreite dann zu vermehrten Zwangsumbrüchen kommt, verhindert dies allerdings auch die Lesbarkeit; ich vermute bei verkleinerter Schrifthöhe wäre dies genauso und dazu noch eine Barriere für schlecht Lesende.

Könnte man denn wenigstens die für die Doppelpunkteinrückung benutzte Einrückungsbreite mit einem div-Konstrukt manipulieren? Das fände ich übrigens auch für andere Boxen sinnvoll, vgl. etwa diese Vorlage:Infobox Sprache etwa in Buginesische Sprache oder Hazaragi, mit weniger käme man da weniger schnell an den Rand des leidlich Zumutbaren.

Die störende vertikale Metrik, sobald dort zeilengefalteter Wiki-Text auftritt, ist wohl ein Problem aller Infobox-Felder. Im Grund ist das alles ein Problem unangemessener Formatierungsparameter für Wikitext im Kontext der Infoboxen. Kann man das nicht irgendwo an der Wurzel bekämpfen?

Aber warten wir erst mal ab, was Vorlagen-Benutzer:Anarabert meint.

--Silvicola ^Disk 10:07, 28. Okt. 2014 (CET)

Der Einwand mit den Blinden zieht meiner Ansicht nach nicht wirklich, da gegen die bisherigen Darstellungen, welche überhaupt nicht gegliedet sind, noch keinerlei Protest kam. Auch kann keine größere Verständlichkeit erzeugt werden, wenn statt "Deutschland, Bayern, Mittelfranken" dann "Deutschland, eine Stufe tiefer Bayern, eine Stufe tiefer Mittelfranken" vorgelesen wird.

Und für die automatischen "Einscannerer", welche oftmals mit Wikipedia-Wissen ihren "großen Reibach machen" schreibe ich nicht.

Wer trotzdem auf Semantik besteht, soll dann auch die dafür entsprechenden Werkzeuge bereitstellen, daß das Ergebnis auch ohne individuelle Klimmzüge optisch ansprechbar gestaltet werden kann.--Anarabert (Diskussion) 10:18, 28. Okt. 2014 (CET)

Vergleiche Aisch-Var1 (greulich) mit Aisch-Var2 (gediegen)--Anarabert (Diskussion) 11:27, 28. Okt. 2014 (CET)

Hallo zusammen, wenn ich es richtig sehe, wurde die Vorlage:Ab-Spalte für rein kosmetische Korrekturen erstellt, nämlich zur Einsparung einzelner Umbrüche und Verringerung der vertikalen Ausdehnung einer Liste um einige Pixel. Wenn man diesem Nutzen die oben und unten aufgezählten Nachteile gegenüberstellt, hat die Vorlage meiner Meinung nach keine Daseinsberechtigung, und ich glaube auf Grund meiner Erfahrung behaupten zu können, dass die meisten anderen potenziellen Nutzer das genauso sehen. Die einzig sinnvolle Möglichkeit, eine Veränderung der Formatierung in eurem Sinne herbeizuführen, sehe ich darin, Einrückungen und Außenabstände von Listen innerhalb von Infoboxen global kleiner einstellen zu lassen, wobei zu prüfen wäre, ob die gewünschten Änderungen auf einzelne Betriebssysteme, Browser, Skins und/oder Ausgabegeräte einzuschränken sind. Eine Anlaufstelle für einen solchen Wunsch wäre vielleicht MediaWiki Diskussion:Common.css (oder Feature-Requests). Solltet ihr euch zum Rückbau entschließen und Hilfe brauchen, sagt einfach Bescheid. :-) --Wiegels „…“ 23:21, 31. Okt. 2014 (CET)

Nicht nur für Kosmetik, sondern um die politische Gliederung unverkennbar anzuzeigen. Das gängige Komma-Strichpunkt-System ist nämlich gerade semantisch unzureichend, besonders, wenn wieder auf die höhere Ebene gesprungen werden müsste, wird das konfus.

Ich sehe auch, dass das Problem besser an anderer Stelle angegangen werden sollte, nämlich bei der Layoutmetrik (Einrückungen und Zeilenabstände) der Infoboxen. Ich verstehe eigentlich auch nicht, wieso das noch nicht stattgefunden hat, da wohl seit je in Parameterfelder von Infoboxen beliebiger Wikitext hinein darf. Infoboxen sind aber nun mal typischerweise schmal, also muss man die Einrückungstiefe darin heruntersetzen, es sei denn, man wollte Features anbieten, die dann aber gefälligst nicht zu benutzen sind. Ich ermpfehle einen Blick besonders auf die taxonomisch tiefgestaffelten Sprachen mit einer Vorlage:Infobox Sprache, da wird oft von den Artikelanlegern schon gar nicht weiter in die Tiefe geschachtelt, weil der Weißraumkeil von links oben her zu wenig Gefälle hat. Und bei den Sprachen mit mehrfach zwangsweise gefalteten „Familiennamen“ erkennt man auch, dass diese flattrige vertikale Abstandsmetrik eben auch die semantisch korrekte Auffassung behindern kann.

Für einen offnungsfrohen Gang nach Meta, um dort Änderungen anzuregen, bin ich zu wenig Optimist. Außerdem habe ich gar keine Lust, mit Das-war-schon-immer-so-da-könnte-ja-jeder-kommen-Trompetern zu diskutieren; die bleiben auf Meta selten aus und dann nie sehr einsam. Exegese heiliger Prinzipien verschafft das Bewusstsein, im Besitz höherwertiger Normen zu sein, verhilft aber außer zum Rechthaben zu gar nichts.

Zu den mobilen Ausgabegeräten kann ich nichts sagen, da fehlt mir jede Anschauung und das wird so bleiben.

Und Skins können von mir aus ganz im Orkus verschwinden; ich verstehe nicht, wieso man partout alles dekorativ konfigurieren können soll und dann bald muss, weil das eine Feature nur damit und das andere nur damit funktioniert. Ich will möglichst brauchbare und einheitliche Werkzeuge und keine bunten Schleifchen.

Der Rückbau wäre selbtredend technisch gar kein Problem; mir fehlt nur das Motiv dazu.

MfG --Silvicola ^Disk 23:57, 1. Nov. 2014 (CET)

Hallo zusammen, ich habe jetzt einen Löschantrag auf die Vorlage:Ab-Spalte gestellt. --Wiegels „…“ 23:29, 5. Nov. 2014 (CET)

Aisch-Var1
Daten
Gewässerkennzahl	DE: 2428
Lage	Deutschland Bayern Mittelfranken Landkreis Neustadt a.d.Aisch-Bad Windsheim Landkreis Erlangen-Höchstadt Unterfranken Landkreis Forchheim
Flusssystem	Rhein
Abfluss über	Regnitz → Main → Rhein → Nordsee
Länge	83 km
Einzugsgebiet	1.006,8 km²

Aisch-Var2
Daten
Gewässerkennzahl	DE: 2428
Lage	Benutzer:Silvicola/Vorlage:EinrückungBenutzer:Silvicola/Vorlage:EinrückungBenutzer:Silvicola/Vorlage:EinrückungBenutzer:Silvicola/Vorlage:EinrückungBenutzer:Silvicola/Vorlage:EinrückungBenutzer:Silvicola/Vorlage:EinrückungBenutzer:Silvicola/Vorlage:Einrückung
Flusssystem	Rhein
Abfluss über	Regnitz → Main → Rhein → Nordsee
Länge	83 km
Einzugsgebiet	1.006,8 km²

Vorlage:Ab-Spalte

• Würdet ihr euch bitte intern und leise darauf einigen, dieses Dingens unauffällig wieder aus euren Infoboxen verschwinden zu lassen?
• Es ist der helle Wahnsinn, eine solch komplizierte und langwierige Konstruktion statt eines simplen Doppelpunktes einzubauen, der auch allen Autoren vertraut wäre.
• Nebenbei ist mir fachlich die Auswirkung unklar.
  • Wie sähen bei überregionalen Gebilden die geografischen Angaben aus?
  • Was passiert bei Donau, Inn, Elbe? Wann so, wann anders?
  • Was passiert mit dem Gebirgsbach in der Gemeinde Hinterdupfingen im Landkreis Niederflach, der sich einige Kilometer durch Oberottingen im Nachbarlandkreis Mittelerde schlängelt, um dann wieder nach Niederflach zurückzukehren?
  • Allgemein fehlt hier ein Sortiment an Anwendungsbeispielen für das neue zeilenweise Prinzip der geografischen Angaben, mal völlig unabhängig von der Vorlage.
  • Das betrifft auch generell die umseitige Vorlagendoku, die zu mager ist verglichen mit der Häufigkeit der Anwendung und Komplexität der Gebilde.
• Ich stelle fest, dass hier eine wesentliche Veränderung in Artikeln realisiert wurde, ohne dass im Fachgebiet Konsens bestand, bzw. obwohl bekannt war, dass noch erheblicher Klärungsbedarf bestand.
• Eigentlich schade; nach der Beratung in der Vorlagenwerkstatt hätte ich angenommen, dass das Thema soweit vom Tisch wäre. Dabei wurde doch völlig richtig vor einer Handlung erstmal gefragt, was den Hütern des Vorlagen-Namensraums dazu einfällt.
• Ein derart kompliziertes Gefrickel hatten einige Enthusiasten vor zehn Jahren mal zu unterschiedlichsten Wünschen angefangen. Das hatte sich aber nicht bewährt und es hatte dann viele Jahre gedauert, den Murks nach und nach wieder aus den Artikeln herauszuarbeiten.
  • Es handelt sich bei solchem Aktionismus von Einzelpersonen erfahrungsgemäß nie um dauerhafte Lösungen, die dann spätestens mit Ende der Aktivitätsperiode wieder mühsam zurückgebaut werden müssen.
  • Fachlich ist es ohnehin mangelhaft gelöst; es führt eine aufwändige Berechnung durch und schreibt Pixel fest, während wir zur Skalierung auch auf Mobilgeräten unsere Layout-Informationen dynamisch festlegen. Die Optik ist auch Browser-, Betriebsart- und Skinabhängig.
• Wohlgemerkt geht es mir nur um die Frage „Doppelpunkt statt langwierigem Vorlagengehabe“.
  • Die Quelltextverkomplizierung und Quelltextlesbarkeitsverschlechterung und Zwang zum Festlegen der Zahlenwerte für die Ebenen stehen in keinerlei sinnvollem Verhältnis zum minimalen Nutzen, der dort angestrebt wird (welcher soll das überhaupt sein?).
  • Ob nun zeilenweise oder mit Komma gegliedert mögen die Flussnymphen entscheiden.
• Ich werde in näherer Zukunft Löschantrag gegen die Vorlage stellen.
• Übrigens könntet ihr euch mal nützlich machen. In diversen Einbindungen der umseitigen Vorlage wurden Parameter doppelt angegeben, was neuerdings in der Kategorie:Wikipedia:Doppelter Parameter in Vorlageneinbindung aufschlägt. Wohl bei einem Dutzend Flüsse hatte ich das in den letzten Tagen bereinigt; würdet ihr bitte die bisher gelisteten Artikel (von denen täglich mehr gefunden werden) durchgehen und eure (Fluss, River) korrigieren? Danke.

VG --PerfektesChaos 11:24, 29. Okt. 2014 (CET)

Deine Tonart gefällt mir nicht.--Anarabert (Diskussion) 14:54, 29. Okt. 2014 (CET)

Gut und knapp gesagt. --Silvicola ^Disk 16:59, 29. Okt. 2014 (CET)

Unabhängig von der Tonart hat PerfektesChaos natürlich Recht. --Herzi Pinki (Diskussion) 10:21, 1. Nov. 2014 (CET)

Hier gibt's noch komplett lagelose Flüsse. Lage nach meinem Verständnis sollte eine grobe Orientierung sein (Thüringen, Deutschland), und kein kleinklein (Ostrand der Ortslage Tote Hose). Über die Koordinaten kommt man eh dorthin. Und da kann jeder/jede das herauslesen, was wir hier proaktiv gar nicht anbieten können. Bei punktförmigen Objekten (was Flüsse nicht sind), lässt sich die Lage sogar aus der ISO Region automatisch erzeugen. lg --Herzi Pinki (Diskussion) 10:21, 1. Nov. 2014 (CET)

Die Lage sollte mE den vollen Geozoom bis so etwa aufs EZG herunter enthalten, so dass der typische Nutzer das gedanklich lokalisieren kann. Groborientierung ja, aber verschiedene Leser haben verschieden ausgeprägte geographische Kenntnisse und für verschiedene Größenklassen von Gewässern ist grob mehr oder weniger fein. (Beim Rhein etwa reichen wohl die durchflossenen Länder.) Ausufern sollte der LAGE-Parameter selbstredend nicht, aber einen – sagen wir mal – Rotenbach in Mittelfranken in Bayern in Deutschland festzulegen ist nicht wirklich hilfreich, da muss schon noch der Landkreis dazu und die Gemeinde(n), in LAGE (nur wenn's dort nicht zu viel wird) oder im entsprechenden GEMEINDEN/KLEINSTÄDTE/…-Feld.

Die Erwähnung von Deutschland/Österreich/Schweiz oberhalb des Bundeslandes/Kantons halte ich übrigens im allgemeinen für überflüssig. Wer soviel Deutsch kann, dass er die WP lesen kann, weiß auch, dass etwa Zug ein Schweizer Kanton ist, zumindest wenn man Kanton davorstellt.

Bitte auch zu berücksichtigen, dass nicht jeder immer nur fremde Lücken füllen will. Mancher arbeitet lieber breit, ein anderer bohrt lieber am Detail. Mit dem Mangel an einer Stelle sollte man nicht gegen die Arbeit an einer anderen argumentieren. --Silvicola ^Disk 23:17, 1. Nov. 2014 (CET)

Hallo SC, hier geht es um die Infobox. Das ist per se breit und betrifft alle Artikel (alle Flüsse). Wer lieber in die Tiefe bohrt, möge solche Sachen bei den einzelnen Artikeln diskutieren. lg --Herzi Pinki (Diskussion) 09:39, 2. Nov. 2014 (CET)

@Breit und bohren: Das ging nur gegen das Argument „Mach doch stattdessen mal lieber das da, was ich viel wichtiger finde“, das in WP-Sachen nie pertinent ist. Jeder arbeitet hier nur an der Baustelle, die ihm behagt, verweist man ihn von der, macht er in der Regel gar nichts und jedenfalls nicht das ihm Aufgetragene. --Silvicola ^Disk 10:52, 2. Nov. 2014 (CET)

Ganz einfach: Gestaltet das Wirken des Doppelpunktes innerhalb der Infobox so, daß er ästhetisch genauso wie die Vorlage arbeitet, dann bedarf es dieser Vorlage nicht mehr und alle sind zufrieden gestellt.--Anarabert (Diskussion) 12:50, 2. Nov. 2014 (CET)

@Silvicola: Mir genügt es völlig, zu wissen (zumindest auf den ersten Blick), dass besagter Rotenbach in Mittelfranken liegt. Alles Genauere kann (und soll) doch im Artikeltext erwähnt werden. Und wer's ganz genau wissen will, klickt auf die Koordinaten. --Luftschiffhafen (Diskussion) 00:39, 3. Nov. 2014 (CET)

@Luftschiffhafen: Du denkst an jene, die – wie vermutlich Du selbst und meine Person auch – gerne einen weiteren Rotenbach mit den Augen verspeisen. Es gibt aber andere, die schnell unerwünschte von mehreren Kandidaten aussondern, sich also nicht en passant am Beifang delektieren wollen. „Was du willst, dass man dir tu, das füge keinem andern zu – denn die Geschmäcker sind verschieden.“ (Oscar Wilde, zumindest so ähnlich.) Ein prominenten Platz für die Aussonderungsdaten ist für diese Absicht hilfreich.

Mir geht es übrigens ähnlich – vielleicht deshalb soviel Verständnis – wenn ich einen neuen Rotenbach einstelle und dann etwa bemerke, dass die Definitionen in der BKL nicht genau/distinktiv genug sind, so dass ich sie passend ergänzen will – und dazu dann erst in den bestehenden Artikeln das Einschlägige zusammensuchen muss.

Gruß von --Silvicola ^Disk 03:44, 3. Nov. 2014 (CET)

Abgesehen davon, dass das Aussondern Aufgabe der BKS ist, wäre dafür eine Angabe unterhalb der Region nur notwendig, wenn es in Mittelfranken mehr als einen Rotenbach gibt. Jemand, der die Gegend kennt, weiß ohnehin Bescheid, jemandem, der sie nicht kennt, nützt die Angabe des Landkreises auch nichts. (Außerdem finde ich wie schon gesagt bei Flüssen eine naturräumliche Untergliederung oft sinnvoller als eine politische.) Viele Grüße, --Luftschiffhafen (Diskussion) 23:09, 3. Nov. 2014 (CET)

wenn es in Mittelfranken mehr als einen Rotenbach – Deshalb hatte ich beispielhaft den sehr gängigen Namen Rotenbach gewählt. Die Verteilung des Bachnamen ist vermutlich irgendwie zipfisch.

Die Leser haben in verschiedenen Gegenden sehr verschiedene „Auflösung“ in ihren Geographiekenntnissen, also jeweils überall ein Teil nur bis auf Kontinent-, Länder-, Distrikt-, Gemeindeniveau. Wo man gut auflöst, will man dann auch genau verortet sehen bzw. schnell auscheiden können. Auch ein „Also da jedenfalls nicht“ kann helfen.

@NR statt politisch-administrativ: Das stimmt unbedingt etwa fürs Hochgebirge, wo sich kaum einer etwa um Gemeindegrenzen schert und die naturräumliche Gliederung evident und unausweichlich vor einem steht. (Talzüge mit nur Längsdurchgängigkeit usw.) In der dichter bevölkerten Kulturlandschaft dagegen beißen sich die naturräumlichen Gliederungsnamen sehr mit den traditionell-historischen Landschaftsnamen und sind den Meisten sehr unbekannt. So verdienstvoll unsere Naturräumler hier wirken – bis diese Gliederungsauffassung zum Mann auf der Straße vorgedrungen sein wird, wird wohl noch einiges an Wasser den Rhein heruntergeflossen sein, wenn denn das je Erfolg haben wird. Also sollte man so lange als Dienstleister Rücksicht auf das verbreitete Ordnungsschema nehmen. --Silvicola ^Disk 00:29, 4. Nov. 2014 (CET)

@

Ich sehe das eigentlich genau umgekehrt: naturräumliche Bezeichnungen sind m.E. - auch außerhalb der Hochgebirge - in der Regel bekannter als Verwaltungseinheiten (unterhalb der Bundesländer). Ein Ortsfremder kann sicher den Schwarzwald eher verorten als den Ortenaukreis. Viele Grüße, --Luftschiffhafen (Diskussion) 00:13, 5. Nov. 2014 (CET)

Einheit der Abflussspende

Die korrekte Einheit der Abflussspende Mq ist l/(s·km²). In den Infoboxen Fluss wird jedoch l/s km² angezeigt, was (l/s)*km² = (l*km²)/s bedeutet.
Ich denke, dass jemand der sich auskennt (ich leider nicht), sollte die Darstellung der Einheit zentral korrigieren. --Atc (Diskussion)

Sehr guter Einwand. Selbst in der Literatur (z.B. im Hydrographischen Jahrbuch von Österreich) wird oft l/s km² angegeben, aber das kann nicht stimmen, es muss in der Tat l/(s km²) heißen. --Luftschiffhafen (Diskussion) 16:41, 10. Nov. 2014 (CET)

Korrigiert --SteveK ?! 18:21, 10. Nov. 2014 (CET)

Das war ja eine schnelle Antwort und Änderung. Danke! --Atc (Diskussion)

Ich kann hierzu nur beitragen, dass die Dimension für Abflussspenden in l/s·km² in der gesamten Fachliteratur für Wasserbau, Wasserwirtschaft und Hydrologie üblich ist und praktiziert wird, wohlwissend, dass es eigentlich physikalisch die falsche Schreibweise ist. Beispiele finden sich (neben dem oben genannten) im Wendehorst, im Taschenbuch der Wasserwirtschaft, selbst in der DDR-Literatur (Kittner, Starke, Wissel: Wasserversorgung, 5. Auflage) sowie in der aktuellen DIN 19700 (Talsperren). Hier wird ausnahmslos und bewusst die Dimension l/s·km² oder auch l/s km² angegeben. Man legt an dieser Stelle einfach mehr Wert auf ein flüssiges Schriftbild. Insofern sollte man es sich genau überlegen, ob man hier jetzt neue Maßstäbe setzen will. Gruß, --JuTe CLZ (Diskussion) 20:47, 11. Nov. 2014 (CET)

Mir ist es egal, wie es dargestellt wird. Richtig wäre wohl

${\frac {l}{s\cdot km^{2}}}$

wobei sich das nicht in einer normalen Textzeile darstellen kann. Sagt mir Bescheid, wenn ihr eine einvernehmliche Lösung gefunden habt. Meiner Meinung geht beides, da es in der Fachliteratur auch verwendet wird.--SteveK ?! 21:23, 11. Nov. 2014 (CET)

Genau so wie von SteveK als Bruch dargestellt ist es zu verstehen. Bei der Schreibweise in einer Zeile muss dann der Nenner geklammert werden, damit er als solcher ersichtlich ist. Ein "flüssiges Schriftbild" kann kein Argument dafür sein, es falsch darzustellen. (Wenn es wirklich "flüssig" sein sollte, müsste man den Bruch kürzen und als Einheit m/s verwenden.) Wikipedia ist auch für Nicht-Hydrologen, die mit dieser eigenartigen Konvention nicht vertraut sind. --Luftschiffhafen (Diskussion) 23:31, 11. Nov. 2014 (CET)

Wie Lsh: noo khoi Gschlamp! Ärgerlich genug, dass man von Nachrichtensprechern notorisch die Einheit „Stundenkilometer“ für Geschwindigkeiten hört. --Silvicola ^Disk 02:43, 12. Nov. 2014 (CET)

BKL-Links fixen

Hallo, wahrscheinlich eine Standardfrage ... Ich möchte in der Infobox Rickenbach (Schwarzach) den enthaltenen BKL-Link nach Schwarzach (Dornbirner Ach) fixen. Wenn ich es analog dem Parameter Mündung mache (ganz normaler Link, als wäre es Text), verschwindet der ganze Abflussweg. Wie geht es richtig und könnte man das auffindbar dokumentieren? Danke, eryakaas | D 00:28, 17. Nov. 2014 (CET)

Ich hab's gerichtet. Das Problem war vermutlich, dass Du einen weiteren Querstrich als Trenner von Lemmalink Schwarzach (Dornbirner Ach) und Lemmatext Schwarzach eingefügt hast, ohne jedoch hinten ergänzend dazu den einen des Doppelschrägstrichs wegzunehmen. Im Abflussweg ist hinter einem Eintrag nur dann // zu schreiben, wenn der davor stehende Lemmaname zugleich der gewünschte Darstellungsnamen sein soll. Im anderen Fall, wenn ein Darstellungsname genannt wird, nur einfaches /. Der Abflussweg muss im Quelltext also immer eine gerade Zahl von Schrägstrichen aufweisen, damit er zumindest formal korrekt ist. Gruß --Silvicola ^Disk 01:32, 17. Nov. 2014 (CET)

Nachtrag: Beschreibung hier, auch für andere Parameter: Vorlage:Infobox Fluss#Parameter --Silvicola ^Disk 01:35, 17. Nov. 2014 (CET)

Oh danke. Zwischen die Schrägstriche schreiben, darauf wäre ich nie gekommen. Die Doku hatte ich direkt in der Vorlage Abflussweg gesucht. Zu kompliziert gedacht ;-) Grüße, eryakaas | D 10:00, 17. Nov. 2014 (CET)

Veraltete Parameter gemäß Wartungsseite

Mal eine Erfolgsmeldung: Die Wartungsseite hat nach aktuellem Stand 0 Einträge. --SteveK ?! 21:48, 9. Nov. 2014 (CET)

Problem mit automatischer Kategorisierung nach Verschiebung

Ich habe den Artikel Chao Phraya auf Mae Nam Chao Phraya verschoben (so ist der Fluss in den meisten von mir konsultierten Atlanten verzeichnet). Jetzt gibt es aber ein Problem mit der automatischen Kategorisierung: Der Artikel über den Strom und die über seine Nebenflüsse, die bislang automatisch in der Kategorie:Flusssystem Chao Phraya waren (ich vermute, durch einen Mechanismus dieser Vorlage, denn die Kategorie war nicht extra im Artikel eingetragen), sind jetzt nicht mehr dort aufgeführt. Dort finden sich jetzt nur noch die manuell kategorisierten Artikel. Was muss man tun, damit das wieder funktioniert? --Bujo (Diskussion) 13:32, 1. Mär. 2015 (CET)

Wenn ich das richtig sehe wurde der Kategorie wurde durch die Verschiebung ihr "Leitfluss" genommen. Darum kann keine Kategorierung erfolgen. Nun stellt sich die Frage ob die Umbennenung haltbar ist. Dann müßte auch die Kategorie umbenannt werden, damit es wieder funktioniert. Ich habe eine entsprechende Frage in die Diskussion der Kategorie gestellt. --Drgkl (Diskussion) 02:09, 9. Apr. 2015 (CEST)

Probleme mit Mündungstextanzeige unter All_Coordinates

Ich sehe da nur den Schriftzug #2, während bei der Quelle durchaus sauber Quelle SOUNDSOBACH steht. B ei OSM wie bei Bing gleichermaßen. Diese „Mündungsbezeichnung“ ist natürlich unschön und vor allem wenig hilfreich. Wenn man sich den generierten HTML-Text ansieht, hat der Anker für die Quelle ein Attribut text=Quelle Soundsobach, während das bei dem der Mündung zu fehlen scheint. (Hoffentlich nichts übersehen in der Browser-Quelltextdarstellung mit überlangen Zeilen.)

Womöglich ein schon bekanntes Problem, aber ich wollte es mal angesprochen haben. Das #2 sieht natürlich gerade so aus, als würde irgendeine Namenskollision in irgendeiner Komponente auf die brachiale Art aufgelöst.--Silvicola ^Disk 00:07, 14. Mai 2015 (CEST)

Wunsch nach weiteren Parameter

Ich fände es gut, wenn in der Box noch die Parameter

• Hydrologischer Hauptstrang und
• Hydrologische Länge aufgenommen würden.

Beispiel für den Main:

Hydrologischer Hauptstrang: Rednitz->Regnitz->Main

Hydrologische Länge: 553 km

--Anarabert (Diskussion) 17:57, 23. Jun. 2015 (CEST)

Das würde mir so manche leidige Bastelei und insbesondere Umbruch- und Weißraum-Formatiererei mit der Vorlage:Infobox Fluss/LÄNGE ersparen … Der Vorschlag gefällt mir also.

Im Grunde gefiele mir alles, was die vielen Lesern nicht verständliche begriffliche Trennung zwischen den Entitäten Hauptstrang und konventioneller maximaler Namensabschnitt ihnen deutlich machte. Leider treffen ja noch nicht einmal die meisten Gewässerverzeichnisse/-serber diese begriffliche Unterscheidung explizit.

Doch ist einiges vorher noch zu bedenken:

1. Es gibt nicht nur obere, sondern zuweilen auch untere hydrologische „Verlängerungen“ (Mündungsarme, vgl. Rhein/Merwede) oder irgendwelche durchaus mit ordentlichem Namen ausgerüsteten Bäche, die dann auf dem letzten Kilometer vor der Mündung plötzlich als banaler Mühlbach oder mit ähnlich generischem Namen bis zu einer Mühle an der Mündung laufen. Die Frage stellt sich also zuweilen: wieviel an Abschnittsnamen „absorbiert“ man (in der Infobox!) auch bei den hydrologischen Strängen stillschweigend und erwähnt man dann nur allein im Artikeltext.

2. Ferner sollte man sich überlegen, wie zu verfahren ist, wenn der amtlich festgestellte Strang sich offensichtlich „regelwidrig“ an den unbedeutenderen Oberlauf hält – das kommt vor, sei es wegen der nun einmal etablierten Namensgebung, sei es wegen der größeren Richtungskonstanz. Häufig ist auch, dass unter mehreren auf der TK unbenannten Oberläufen dann der längere statt des einzugsgebietsreichere offenbar arbiträr zum amtlichen Hauptstrangteilnehmer erwählt wurde. (Und zugleich oft mutmaßlich „urgetauft“.) Darf oder muss man dann (nach Regel: das größere Teileinzugsgebiet geht vor) verbessern? Und wie macht man etwa im ersten der Fälle deutlich, dass im hydrologischen Hauptstrang mit dem Namen dann nicht der gesamte konventionelle Namensabschnitt gemeint ist, sondern nur von hier bis da ? In der Box gar nicht, sondern nur im Fließtext des Artikels, weil sonst zu kompliziert?

3. Es bräuchte zu beiden neuen Parametern auch jeweils einen zugehörigen NACHWEIS-XX-Parameter.

Notabene: Ich will keineswegs mit irgendwelchen Sonderfällen eine grundsätzliche Verbesserung hemmen; denn dass hydrologischer Strang und konventioneller Namensstrang auseinanderfallen, ist wirklich sehr häufig und verdient eine vernünftige und vor allem auch für Neulinge in Gewässerdingen nicht zu komplizierte Darstellungsmöglichkeit. Nur sollte man eine die häufigen Fälle bedenkende Erläuterung im Vorhinein erwägen und dann in die Parameterbeschreibung schreiben. Dass das nur eine Leitlinie, aber keine blind bindende Regel rein kann, scheint mir evident; man wird auch zuweilen von ihr wieder absehen müssen.

--Silvicola ^Disk 19:59, 23. Jun. 2015 (CEST)

Sowas geht nur, wenn es in der Box mit entsprechenden Artikeln verlinkt werden kann. Wie etwa Schartenhöhe in der Infobox Berg. Stünde das da nicht, würde mancher Leser irgendeine Scharte in der Nähe des Bergs vermuten. --Elop 12:16, 27. Jun. 2015 (CEST)

Eintrag zum Parameter FLUSSSYSTEM

Derzeit:

Es wird nur der Fluss angegeben, der für das Gesamtflusssystem namensgebend ist. Die Eingabe erfolgt nach EBNF-Syntax:

FLUSSSYSTEM = Lemma [ "/" Darstellung ]

Beispiel: Der Chamb gehört zum Flusssystem der Donau, also wird nur Donau eingetragen.

Die Bedeutung von Gesamt- bleibt zu vage. Man könnte es auf den im Artikel behandelten Fluss beziehen und dann darin nur eine Warnung davor erkennen, keinesfalls ein Flusssystem eines Zulaufes von ihm aus Versehen einzutragen. In Wirklichkeit meint das Gesamt aber bei den Binnenlandflüssen: über das eigene Flusssystem des behandelten Flusses ggf. hinaus bis hinunter an die See.

Deshalb Vorschlag (mit komplexerem Beispiel):

Verlangt ist das größte der Flusssysteme, denen der behandelte Fluss angehört, das nämlich bis ans Meer reicht. Einzutragen ist derjenige Fluss, nach dem es benannt wird, und zwar (in EBNF-Syntax):

FLUSSSYSTEM = Lemma [ "/" Darstellung ]

Beispiel: Die Regnitz gehört zu den fortschreitend größeren Flusssystemen der Regnitz selbst, dann des Mains und schließlich des Rheins. Dieser mündet über u. a. seinen Unterlauf Nieuwe Merwede in die Nordsee. Eingetragen wird „Rhein“, weil er das gesamte Flusssystem bis zu den Nordseemündungen bezeichnet und der Rhein das Lemma „Rhein“ ohne Klammerergänzung hat.

--Silvicola ^Disk 01:36, 11. Jun. 2015 (CEST)

Rundung

Momentan zeigt die Box in der Länge nur eine Nachkommastelle an, im EZG aber zwei. Dabei ist die Meßgenauigkeit eher umgekehrt. Dort, wo es offizielle "Kilometersteine" gibt, lassen sich Längen durchaus auf 10 m genau angeben, während das EZG so genau gar nicht ermittelbar ist und sich Angaben mit mehreren Nachkommastellen auf willkürliche, vermutete Einzeichnungen beziehen. Bei der Fränkischen Saale weichen zwei "offizielle" Angaben sogar um 1,63 ab, obwohl das EZG ja, anders als die Länge (welche Quelle und welcher verzweigungsarm wird genommen), kaum interpretierbar ist.

In der Folge gibt es bei kleinen, aber genau bestimmbaren Bächen Längen mit zwei und EZGe mit vier signifikanten Stellen in der Box.

Ich wäre da dringend für 2 Nachkommastellen bei der Länge - die wir natürlich nur bei "offiziellen" Angaben nutzen. Eigenmessungen mit jener vorgegaukelten Genauigkeit wären ab einigen 100 m da zu willkürlich. --Elop 14:47, 29. Jun. 2015 (CEST)

Das ist leider nicht so einfach wie du dir das vorstellst. Die Vorlage mit der die Formatierung gemacht wird lässt genau zwei Bereiche zu. Bei der Länge werden alle Angabe <1000m in ganzen Metern, bei >=1000m in 0,1km Schritten formatiert. Ab 10 km Länge halte ich die Angabe von drei Nachkommastellen auch für falsch, da das eine Genauigkeit vortäuscht, die die Erfassung nicht hat. Zudem ändern sich die Flusslängen ja auch laufend durch natürliche Effekte. Ob man da etwas ändern sollte, dass wage ich zu bezweifeln.--SteveK ?! 14:35, 23. Jul. 2015 (CEST)

Bäche unter 1 km haben ja eher seltener einen Artikel. Wobei ich 3 Nachkommastellen eigentlich immer für falsch halte - ein Bach ist ja keine Dachrinne! Ich sprach von zweien.

Und ein "nominell" 857,341 m langer Bach kann ja als 0,86 km oder 860 m angegeben werden. --Elop 14:49, 23. Jul. 2015 (CEST)

… unter 1 km haben ja eher selten … — Da muss ich Dir aber Pfeffer geben, da musst Du aber glatt beten gehen. Und wenn ich nur noch weitere 10.003 Jahre lebe, ohne dieses A…zei…hei oder wie dieses Dings noch mal heißt, werden es bestimmt noch viel mehr!

Mal eine ernstere Sache: Könnte man nicht die Rundung bei den EZGs wenigstens mal so wie bei den Längen haben, d.h. zumindest die mit ≥ 1 km² werden pauschal auf eine NKS gerundet? Über so etwas kann man doch nur hüsteln. Man sollte aber tunlichst belegte Zahlen wie sie sind in die Box eintragen können, ergo muss es halt die Rundung richten. Bei LUBW bekommt man übrigens sogar 3 NKS fürs EZG geboten, das wird dann noch lustiger. --Silvicola ^Disk 22:58, 23. Jul. 2015 (CEST)

Die Pfeffer-beten-Bäche haben aber eben keine Längengenauigkeit von 3, sondern nur eine von 2 Nachkommastellen.

Dessen ungeachtet ist mir ja A-Berts Gründlichkeit bekannt - da kenne ich längst schon welche unter 1 km.

Aber m. W. keinen, wo "457 m" pder "457,7 m" stünde. --Elop 00:05, 24. Jul. 2015 (CEST)

Dessen ungeachtet:

Ich gebe Dir keine 10.003 Wochen mehr - auch wenn das "hart" klingen mag. --Elop 00:05, 24. Jul. 2015 (CEST)

Es liegt halt an der Quelle: die PDF-Gewässerverzeichnisse GVxy der Bayern weisen 2 NKS aus; wenn man aber diese umfassende Excel-Tabelle als Quelle nutzte und die wirklich zerpflückte, also dort die Rundung in den Feldern abschaltete, dann hätte man auch hier mehr Stellen. LUBW hat wie gesagt 3, und meistens finde ich 1 NKS schon genug. (Bei den NAmensabschnitten auf LUBW geht's sogar bis auf Dezimeter herunter.) Bei sehr kleinen Werten wird dann halt der relative Fehler durch die Rundung sehr groß – umsonst ist nur der Tod.

Angesichts der Abflussrichtung war wohl Ana eher nicht am Werk, Ana hat bekanntlich sehr unverhohlen antimauro- und proboreothalassische Präferenzen. Zudem sind beidesmal am Ursprung Karstquellen, da hat denn wohl eher unser Freak Hand angelegt. --Silvicola ^Disk 03:00, 24. Jul. 2015 (CEST)

Hast Du WikiHistory noch immer nicht installiert?

• Pfeffer: von Freak-Line-Community (92 %), Silvicola (7 %), Fomafix (1 %), MystBot (1 %), 5 weiteren Autoren (0 %)
• beten gehen: von Freak-Line-Community (87 %), WaldiWuff (7 %), SteveK (3 %), Hydro (1 %), Silvicola (1 %), 2 weiteren Autoren (0 %)

A-Bert ist unter 0,8 auch zuweilen faul, siehe das US-amerikanische Fließgewässer (*?, †?). Der 1-er gehört übrinx mir! --Elop 11:16, 24. Jul. 2015 (CEST)

Eine Rundung des Einzugsgebietes auf eine Nachkommastelle würde ich befürworten. --Luftschiffhafen (Diskussion) 00:12, 24. Jul. 2015 (CEST)

Warum nicht drei signifikante Stellen, also 0,876; 1,57; 46,3; 177? -- Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 01:03, 25. Jul. 2015 (CEST)

Ich hätte auch nichts gegen drei NKS, aber unter einer Bedingung: Dass an der Box irgend etwas angebracht wird, was auf die Fragwürdigkeit solcher Genauigkeit pauschal, nicht allzu aufdringlich, aber auffindbar hinweist. (Vielleicht in Gestalt einer Fußnote zum Eintragtitel Einzugsgebiet oder so ähnlich. Am besten so, dass einmal zu lesen jedem Nutzer genügt und er dann nicht immer mit der Nase draufgedrückt wird.) Dann wird deutlich, dass der eingestellte Wert nur nach Prinzip best effort zu verstehen ist und keine Genauigkeit nach der angegebenen Nachkommastellenzahl insinuieren soll – ein Anspruch, der meistens recht kühn wäre. --Silvicola ^Disk 01:30, 25. Jul. 2015 (CEST)

Matthias sprach von Signifikanten Stellen, nicht von NKS. --Elop 01:37, 25. Jul. 2015 (CEST)

Ich hatte zu schnell und oberflächlich gelesen. Der Vorschlag ist gut. --Silvicola ^Disk 02:01, 25. Jul. 2015 (CEST)

Abflussparameter

Gibt es einen Unterschied bei der Auflistung der Pegel-Werte als "PEGEL1" etc. in EBNF-Syntax und der Auflistung als "ABFLUSS...". Ersteres scheint mir besser (als einziges?) geeignet zu sein, um mehrere Pegel aufzunehmen. Ist letzteres deshalb "nicht empfohlen/veraltet" oder warum gibt es beides? Glückauf! --HsBerlin01 (Diskussion) 21:10, 14. Okt. 2015 (CEST)

Ursprünglich gab es nur die "alten" Parameter für den Abfluss. Da Abflusswerte aber immer an Pegel gebunden sind, wurden später die Pegel-Parameter eingefügt. Nach der alten Form hätte das zu einer Flut von Parametern geführt, deshalb die Umstellung. Der veraltete Parameter ist noch aktiv, weil noch in Benutzung. --SteveK ?! 21:36, 14. Okt. 2015 (CEST)

Aber prinzipiell gilt, dass bei Neuanlage und Wohlgefallen an der EBNF-Syntax die alten Abfluss-Werte (der Übersichtlichkeit wegen) durchaus weggelassen werden können? --HsBerlin01 (Diskussion) 21:42, 14. Okt. 2015 (CEST)

Ja, man braucht eigentlich keine leeren Parameter angeben. Wer den Vorlagenmeister verwendet, der wird die leeren Abflussparaameter auch nicht im Artikel stehen haben. --SteveK ?! 21:55, 14. Okt. 2015 (CEST)

Ich vermute, dass es deshalb auch erwünscht ist, in den Altartikeln auf das neue System umzustellen und dabei tunlichst genau auf die Positionen im schrägstrichgetrennten, meist nur dünn besetzten PEGEL-Eintrag zu achten …, damit hoffentlich irgendwann der alte Parameterkrempel ganz raus kann?

Ich würde dann auch dazu raten, diese Absicht in den Parameter-Erläuterungen zu nennen, damit nicht noch neue veraltete Verwendungen dazukommen. So ungefähr à la „Veraltet. Sollte nicht mehr benutzt werden, stattdessen soll der ganze Satz an ABFLUSS-Parameterwerten jetzt in einen (den ersten?) der PEGEL<x>-Parameter verpackt werden und der zugehörige Nachweis – vormals in NACHWEIS-ABFLUSS – nunmehr im entsprechenden NACHWEIS-PEGEL<x>.“ --Silvicola ^Disk 01:05, 15. Okt. 2015 (CEST)

Nun ich wollte nicht gleich mit der Tür ins Haus fallen aber auf so etwas wollte ich hinaus :-) Da die Tür aber nun mal offen steht könnte "man" sich folgende Maßnahmen vorstellen (geordnet aufsteigend nach Aufwand):

1. Kopiervorlage anpassen, d.h. alte Parameter raus
2. Beschreibung in der o.g. Form anpassen und die veralteten irgendwie kennzeichnen
3. Wartungsliste einrichten
4. per Bot umstellen (in einer einfachen Version vielleicht nur die unbelegten raus. In einer komplexeren Migration.)

Aus meiner Sicht gibt es zwei Punkte zu berücksichtigen:

1. Die alte Version ist etwas intuitiver zu bedienen. Aber ich denke, dass die Pegelwerte generell nur von Benutzern erfasst werden, die das System verstehen. Überdies gibt es ausreichend Nutzer die über jeden Flussartikel schauen.
2. Die alte Version ist (meine Vermutung) leichter erweiterbar. Beispiel: Ich wünschte mir beispielsweise eine Erweiterung um das Jahrhunderthochwasser (Q100). Ließe sich so etwas auch mit der Pegelx-Syntax machen? Glückauf! --HsBerlin01 (Diskussion) 10:44, 15. Okt. 2015 (CEST)

@"alte Parameter raus": Dann sollte man aber sicherheitshalber im Vorspann vor der dargebotenen Kopiervorlage dazu schreiben, dass es noch andere Parameter gibt, welche gewissermaßen auf Ausding sind und in bestehenden Artikel nicht einfach samt Wert beerdigt werden dürfen. Detailliert aufgeführt und erläutert könnten sie dann gerne erst weiter unten werden, vielleicht sogar in einer separaten Tabelle. (Ein Parameter auf Abruf hat ja ohnehin keinen „richtigen“ Platz mehr in der vorsortierten Reihenfolge der Parameter.)

@"Die alte Version ist etwas intuitiver zu bedienen": Zweifellos. Vor allem wenn man wie ich meist nur mit Bächen umgeht, ist das nötige Handhabungswissen beim nächsten Male, wenn dann doch ein Fluss in Pegelklasse ins Schussfeld tritt, schon wieder verschollen. Aber endlos doppelgleisig zu fahren macht den dauerhaften Lerneffekt noch geringer.

Ich hätte es übrigens für besser gehalten, für PEGEL eine Untervorlage einzurichten mit nur benannten Parametern; so etwas erläutert sich von alleine, im Gegensatz zur Parameterbindung per Position zwischen dem guten halben Dutzend Schrägstrichen. Aber ich will hier mal lieber nicht die nächste Wartungslawine lostreten … und wenn denn die Berechnung der Abflussspende manchmal auch auf EINZUGSGEBIET Zugriff nähme (heikel!), käme dazu noch ein wikitechnisches Veto.

--Silvicola ^Disk 12:34, 15. Okt. 2015 (CEST)

(nach BK)Ich antworte mal so:

zu 1. und 2. Das ist einfach durchzuführen und kann eigentlich jeder hier machen.

zu 3. das nehme ich mal auf, wann ich dazu komme muß ich mal sehen

zu 4. Wir hatten da mal eine Anfrage bei den Bots, die wurde dann wegen der Richtlinien nicht ausgeführt. Sollte man vielleicht drauf verzichten. Wenn man die Wartungsseite eingerichtet hat, dann weiß man auch ob sich das überhaupt lohnt.

zur Erweiterung eignet sich auch die Form mit den Schrägstrichen, weshalb ich das so ja mal implementiert habe. Das ist wenn ich es mir recht überlege sogar einfacher als bei der "alten" Form.

so, jetzt gehe ich wieder an die Arbeit. Gruß --SteveK ?! 12:44, 15. Okt. 2015 (CEST)

@Silvicola: Die Untervorlage gibt es schon ;-) Vorlage:Infobox_Fluss/PEGEL --SteveK ?! 12:48, 15. Okt. 2015 (CEST)

Gut dann mache ich für 1. und 2. heute abend mal eine Änderung. Und bei der Wartung beteilige ich mich natürlich. Bloß das einrichten müsstest du halt übernehmen. Glückauf! --HsBerlin01 (Diskussion) 12:59, 15. Okt. 2015 (CEST)

Die Wartungsseite ist eingerichtet. --SteveK ?! 14:05, 15. Okt. 2015 (CEST)

Schön und schön. --Silvicola ^Disk 14:11, 15. Okt. 2015 (CEST)

Nur zwischen 6000 und 8000. Ein Klacks! --Silvicola ^Disk 14:13, 15. Okt. 2015 (CEST)

Kopiervorlage um die ABFLUSS-Parameter gekürzt, Warnhinweis für zu unternehmungslustige Altbestand-Bereiniger vorgestellt, in den Parameterbeschreibungen ABFLUSS per Lehrer-Lämpel-Zeigefinger auf PEGEL umgeleitet. Im Abschnitt Beispiel dagegen die ABFLUSS-Parameter stehen lassen – denn genau in der Gemengelage kann man das ja antreffen. Sollte nach Bereinigung des Altbestandes … dereinst … auch dort raus. --Silvicola ^Disk 14:48, 15. Okt. 2015 (CEST)

Das war auch der Grund dafür, das wir es bisher nicht als veraltet gekennzeichnet haben. Der Parameter "Bekannten Brücken" wird immer noch hin und wieder eingebunden, obwohl keine Vorlage mehr mit dem Parameter vorhanden ist. Bei der Menge kann man schön Edits sammeln. --SteveK ?! 15:17, 15. Okt. 2015 (CEST)

Ich habe jetzt 7704 gezählt, um deine Angabe zu präzisieren. --SteveK ?! 15:21, 15. Okt. 2015 (CEST)

Danke fürs schnelle Umsetzen. Nun hatte ich nicht mal Gelegenheit, meinen Part (1. und 2.) einzulösen. Ich habe mal probehalber ein paar Artikel umgestellt und musste hierbei feststellen, dass sich das doch etwas aufwändiger gestaltet. Das liegt daran, weil praktisch jeder Artikel eine andere Anforderung darstellt. Es war natürlich von vornherein klar, dass, wenn die Werte zu migrieren sind, ein höhere Aufwand entsteht. Selbst wenn nur die unbelegten ABFLUSS-Angaben zu löschen sind ist es immer noch ein Unterschied, ob die PEGELx-Platzhalter da sind oder nicht. Nur rauslöschen finde ich nicht gut, also holen und C&P. Und wenn die PEGELx-Platzhalter da sind fehlt oft das "/////////". Dann muss man noch all die Kleinigkeiten machen wie Zusammenfassung angeben, nur Kleinigkeiten anklicken und Seite nicht beobachten (ist bei mir Standard will ich hier aber nicht haben). Lässt sich das nicht noch komfortabler gestalten? Ich denke da an eine Vorbelegung der Werte (bei den Klammerfehlern von Aka ist das immer schon belegt) und kann man nicht einen Typus nach dem anderen abarbeiten?

Ich habe mit jetzt erst mal mit der insource-Suche geholfen. Allerdings kann ich scheinbar nicht richtig lesen, denn ich finde keine Aussage, welche Regulären Ausdrücke denn zu verwenden sind. Darum erst mal nur alle Werte mit PEGEL ohne Angaben und die ersten Werte leer (177 Stück). Danach kommt PEGEL egal, alle Werte leer (1324 - 177 Stück). So werde ich mich vom einfachen zum schwierigen hangeln und immer mal was abarbeiten. 10 Stück pro Tag. Wer macht mit? Wenn du/ihr dich/euch mit den regulären Ausdrücken auskennt könnte man das natürlich noch besser gestalten. Glückauf! --HsBerlin01 (Diskussion) 21:50, 15. Okt. 2015 (CEST)

P.S. Ich komme gerade ins Zweifeln, ob die Aussagen wirklich identisch sind. Könnt ihr euch mal Main anschauen. Die PEGELx-Angaben performen wie gehabt, aber der ABFLUSS zeigt an "Abfluss an der Mündung". Mit den Pegeln kann ich das scheinbar nicht ausdrücken!? Glückauf! --HsBerlin01 (Diskussion) 23:04, 15. Okt. 2015 (CEST)

Ich fasse nur solche an, die mir sowieso über den Weg laufen. Ich habe nämlich jüngst bei einer Lemmaverschiebung mit händischem Linkfixen gegen 4000 Seiten mikroeditiert und dann nach gemessener Zeit etwa einen Monat rigorosen Ausmerzens gebraucht, um die Beobachtungsliste wieder so weit zurückzuschneiden, dass ich nun in den täglich mir vorgelegten fremden Bearbeitungen nicht mehr ersticke. Von der verblödend monotonen Ersetzungsmechanik vorher will ich dabei noch gar nicht reden. Gut Ding will Weile.

@"/////////": Man kann doch hoffentlich stattdessen auch ins entsprechende PEGEL-Feld gleich eine Einbindung der Untervorlage /PEGEL mit verständlicherem benanntem Parametersatz benutzen, oder? Also so etwas:

PEGEL1={{Vorlage:Infobox Fluss/PEGEL|BEZ=|NACHWEIS=|NACHWEISE=|EZG|LoM=|NNQ=|NNQ-Datum=|MNQ=|MQ=|MHQ=|HHQ=|HHQ-Datum=|REIHE=}}

Was muss dabei in NACHWEISE rein, damit der in den anderen Flussboxparametern (PEGEL1-REIHE und) NACHWEIS-PEGEL1 fehlende Eintrag nicht reklamiert wird? – Die Untervorlage ist nämlich etwas schweigsam. Dass der Intervallgrenzentrenner im Parameter REIHE (und entsprechend in der positionsgebundenen "/////////"-Parametrisierung) nun denselben inneren Intervalltrenner "/" hat wie der Parametersatz, worin er mit eingebaut ist, wundert mich etwas. Ist denn überhaupt sicher, dass die REIHE immer über konsekutive Jahre gehen muss? Es könnte doch auch ein Meßgerät im Amazonasschungel mal zwei Jahre ausfallen, bis eben der Hydrologe wieder vorbeischaut und das tückische fühlende Objekt mit dem Hammer bedroht und zur Raison bringt …

--Silvicola ^Disk 02:28, 16. Okt. 2015 (CEST)

So ganz einfach zu verstehen ist deine Frage nicht. Die Angabe "REIHE" ist eine einfache Textangabe, die entsprechend gemacht oder eben auch nicht gemacht wird. Für uns macht nur die Jahresangabe wirklich Sinn, wobei es im "Gewässerkundlichen Jahrbuch" sowohl Abflussjahrwerte als auch Kalenderjahrwerte gibt. Weierführende Info HIER. Der "/" ist bei dem Beispiel also einfach ein Zeichen und kein Trenner, mit dem die Jahreszahlen auseinandergenommen werden. Deswegen gibt es ja für die Reihe auch einen eigenen Parameter.

Nachweis wird immer dann fehlend markiert, wenn nix angegeben ist und NACHWEISE auch nicht angegeben ist. Der Inhalt wird nicht geprüft.

Fragen beantwortet?--SteveK ?! 09:02, 16. Okt. 2015 (CEST)

Sollte eigentlich bei beiden gleich funktionieren, ist aber leider nicht so. Somit hast du einen Fehler aufgedeckt. Ich werde da mal nachschauen das es gleich funktioniert. Gruß --SteveK ?! 23:34, 15. Okt. 2015 (CEST)

Nachtrag: Da wurde ein Trick angewendet, der Test wird über den Nachweis eingefügt. Das sollte in beiden Fällen gleich funktionieren. SteveK ?! 23:40, 15. Okt. 2015 (CEST)

Ja du hast recht. Andersherum funktioniert das auch. Nicht unclever. Glückauf! --HsBerlin01 (Diskussion) 23:49, 15. Okt. 2015 (CEST)

Pegelreihenfolge

Soll man, im Falle es mehrere Pegel gibt, diese nach steigendem LoM/flussaufwärts oder nach fallendem LoM/flussabwärts sortieren? --Silvicola ^Disk 22:26, 5. Nov. 2015 (CET)

Das ist nicht definiert, und ich würde das auch nicht wirklich vorschreiben wollen. Ich würde die Fließrichtung nehmen, denn ein Fluss fließt von der Quelle zur Mündung und wird dabei größer. --SteveK ?! 22:29, 5. Nov. 2015 (CET)

Danke. --Silvicola ^Disk 22:59, 5. Nov. 2015 (CET)

Flussabwärts erscheint mir auch logisch (so auch etwa im Hydrographischen Jahrbuch von Österreich). --Luftschiffhafen (Diskussion) 23:02, 5. Nov. 2015 (CET)

Und es geht auch gut, wenn etwa PEGEL1 zu wenig Daten hat, um selbst dargestellt zu werden, siehe Lauterach (Fluss). --Silvicola ^Disk 23:08, 5. Nov. 2015 (CET)

Störender „Pegel“ bei kalkulatorischem Gesamtabfluss

Siehe bei Fränkische Saale. Wenn man die veraltenden ABFLUSS*-Parameterwerte in PEGEL2* umverpacken will, bekommt der hier nur kalkulierte Mündungsabfluss, wie auch immer man den nennen wollte, automatisch ein Abfluss am Pegel vorgestellt, was mindestens eine falsche Insinuation ist – ein kalkulatorischer Abflusswert ist nun einmal, bei allen Heiligen der empirischen Wissenschaft seit Galilei, kein Messwert. Vermutlich gibt es im Bestand noch mehr solcher nicht an einem vorhandenen Pegel gemessener, sondern sonstwie ermittelter Gesamtabflusswerte. Irgendwie sollte man die Vorstellung zumindest des Wortes Pegel bei den PEGELnn-Erzeugnissen deshalb verhindern können. --Silvicola ^Disk 05:01, 24. Dez. 2015 (CET)

Im Hessen werden die größeren Flüsse alle von HLUG durchgerechnet. Davon ab ist Kollege Wwasser ja ein Experte für Abflussspendenberechnung und -auswertung.

Bei der Lahn haben wir eine Pegelsumme als Abschätzung nach oben, die immerhin fast 10 % EZG mehr zählt als der unterste Lahnpegel. Wenn man jetzt die abflusstechnische Rivalität zur Sieg bedenkt, die einen Pegel kurz vorm Versiegen im Rhein hat ...

Habe übrinx bei ebender gerade umgerüstet und mich gefragt, welchen Vorteil denn die Schrägstriche haben sollen. Beim Ersteinfüllen kann man ja aus der Vorlagendoku übernehmen und überschreiben (wobei ich den Sinn der eckigen Klammern und Anführungszeichen nicht sehe - je spitze Klammern sollten reichen), aber danach überschreibt man beim Aktualisieren Zahlen mit Zahlen. Da kann man deutlich weniger Mist machen, wenn da "MQ" steht, wo MQ rein soll.

Das führt auf lange Sicht dahin, daß entweder die Boxen nur noch von Nerds befüllt werden oder aber immer wieder mal falsch befüllt werden.--Elop 12:32, 24. Dez. 2015 (CET)

Völlig korrekte Diagnose. Drum hatte ich bei einer älteren Diskussion hier ja schon einmal angeregt, nicht de facto positionelle Parameter (über den Index der jeweiligen Schrägstrich-Teilschachtel) zu benutzen, sondern benannte Parameter, bei deren Benutzung man weniger leicht das Fach vertauscht. Man hat mich damals auf

Vorlage:Infobox Fluss/PEGEL

verwiesen, aber diese Untervorlage hat statt 10 sogar 13 Parameter (10 + je einen entsprechend PEGELnn-REIHE und PEGELnn-Nachweis + 1 Flag zu Wartungszwecken?) und vertrüge durchaus eine bessere Dokumentation als derzeit. Auch wäre ich gar nicht sicher, ob man die nun auch direkt (im jeweils ersten Parameter PEGELnn des PEGELnn-Parametertripels?) einfüllen soll; deshalb habe ich bisher weiterhin brav abgezählt.

Zumindest ein Kopiermuster

{{Vorlage:Infobox Fluss/PEGEL|BEZ=|NACHWEIS=|NACHWEISE=|EZG=|LoM=|NNQ=|NNQ-Datum=|MNQ=|MQ=|MHQ=|HHQ=|HHQ-Datum=|REIHE=}}

sollte schon bei der Untervorlagenbeschreibung zu finden sein. Und, mit Verlaub gesagt, die Wahl der zwei Parameternamen NACHWEIS/NACHWEISE ist von ähnlicher Bedachtsamkeit eingeflößt wie die Wahl der Tags <onlyinclude>/<includeonly> bei der Vorlagensyntax. Der Name des Steuerflags sollte, da es ein Boolescher Wert ist, schon syntaktisch auch ein Boolesches Attribut signalisieren, etwa ISTNACHGEWIESEN oder NACHWEISFEHLT. Nach derzeitiger Bezeichnung, und mehr hat man nicht, wird nämlich nicht einmal klar, ob mit zu true evaluierendem Wert Bestand oder Fehlen des Nachweises gemeint ist.

So wie mir das am plausibelsten verwendbar schien, geht es jedenfalls nicht, vergleiche vorher und nachher hier.

--Silvicola ^Disk 13:49, 24. Dez. 2015 (CET)

Vielleicht sollte man die jetzt als veraltet gehandhabten benannten Parameter für den Mündungsabfluss nehmen, auch wenn der seltener vorliegt als ein unterster Pegelwert, und danach die Pegelwerte. Wenn genau die gleiche Reihenfolge einzuhalten ist, dürfte das analoge Ausfüllen der Schrägstrichfolge der Pegel auch mäßig nerdoiden Normalos möglich sein. Das wäre zwar nicht das Eleganteste, aber wenigstens ohne Klimmzüge machbar. Statt am Pegel müsste es nur heißen an der Mündung (bei versiegenden Flüssen dürfte natürlich nichts eingetragen sein). Ich habe mich bei Mündungswerten bisher immer beholfen, dass ich den Pegel offen gelassen habe und – quick and dirty – vor dem hier allfälligen Einzelnachweis ein geschütztes Leerzeichen gesetzt und an der Mündung geschrieben habe. -- WWasser (Diskussion) 14:21, 24. Dez. 2015 (CET)

Wegen des Gewöhnungseffektes sollte man, ob man es nun bei positionellen Parametern belässt wie derzeit (da besonders, weil hierbei die Verschiebung der Positionen besonders verwirrt!) oder zu einer Untervorlage mit benannten Parameter wechselte (ob das dort technisch geht ohne weiteren Schalter-Parameter für die Art des Pegels, weiß ich nicht), bei Quell-, Lauf- und Abflusspegeln immer denselben Satz von Parametern anbieten, also derzeit zehn. Es muss nur eben allenfalls beim Quellpegel die Darstellung von NAME/LoM/EZG unterdrückt werden und beim Abflusspegel der von LoM. Beim Quellpegel könnte aber sogar NAME (eine benannte Quelle unter mehreren) und EZG (Karstquellen mit großen oberflächlich trockenen Einzugsgebieten!) angeben zu können zuweilen durchaus sinnvoll sein, LoM ist natürlich angesichts der Längenangabe in der Flussbox (meist) redundant. Und selbst die „Abflusspegel“ stehen bei flachen Gewässern oft weit vor der Mündung also >>0 km, schon allein aus technischen Gründen – man will ja nicht gerade nur den Rückstau eines Hochwassers im Vorfluter messen, sondern etwas hydrologisch Eigenes. --Silvicola ^Disk 14:46, 24. Dez. 2015 (CET)