Vorlage Diskussion:Abflusstabelle

Kleine Schriftgröße im Tabellenkopf

Hallo zusammen, sicher wurde sich was dabei gedacht, aber dennoch rate ich von der kleineren Schrift einiger Teile des Tabellenkopfs ab. Die geänderte Darstellung bringt kaum Platzvorteil, macht aber den Tabellenkopf optisch unruhig und sorgt dafür dass diese Teile auf Anzeigegeräten mit eh schon kleiner Schrift unlesbar werden. --Cepheiden (Diskussion) 14:49, 31. Okt. 2012 (CET)

Tachauch Cepheiden!

Ich sehe nicht nur einen Platzvorteil, sondern auch eine Hervorhebung des Wichtigen (Spaltenkennzeichnung) gegenüber dem Unwichtigen (Einheit).

De facto liest man doch nur keinmal oder einmal die Einheit nach, während man als Betrachter und Interpretierender der Tabelle immer wieder schaut, wo denn die MQ-Spalte (oder eine andere) sei.

Zum Thema eckige Klammern:

Bislang ist es in so gut wie allen geographischen Tabellen und Listen üblich, die Einheit in eckige Klammern zu setzen. Sicher könnte man beschließen, das nicht mehr zu tun bzw. rückwirkend je alles umzubauen, das hätte aber im konsens mit dem WikiProjekt Geographie zu geschehen.

Und wenn man denn unbedingt mit "in" deklarieren sollen wollte, gäbe es genau zwei Möglichkeiten, dieses zu tun, ohne das Layout zu zerschießen:

1. Man setzte nach dem "in" ein geschütztes Leerzeichen. Hierdurch würden die Spalten indes noch breiter werden, als sie schon sind.
2. Man setzte nach dem "in" je einen Umbruch und fügte einen solchen auch in die "in"-freien Spalten ein. Damit verschmälerte man u. U. sogar einige Spalten, aber dafür hätte der Kopf eine Zeile mehr.

Macht man es indes in Deiner Variante, hüpfen die eigentlichen Deklarationen in einer befüllten Tabelle wild auf und ab, da mal ein Umbruch erfolgt, mal nicht. --Elop 19:05, 31. Okt. 2012 (CET)

bitte History beachten! --darkking3 ^Թ 19:14, 31. Okt. 2012 (CET)

Stimmt, der Steve war der Fiesling ... --Elop 19:34, 31. Okt. 2012 (CET)

Die Tatsache, dass Einheiten in eckige Klammern sind laut DIN (u.a. DIN 1331) falsch sind, scheint niemand Bezug nehmen zu wollen. Es ist also keine Frage des Geschmacks oder des Layouts, das mit der unruhigen kleineren Schrift und zusätzlichen Klammern nicht ansprechender oder übersichtlicher wird, sondern in meinen Augen bereits "zerschossen" ist. Dazu tragen auch Fußnoten vor oder mitten in Wörtern. Dennoch ein Hinweis, die Spaltenbreite wird in einem realen Beispiel wie dem auf der Dokumentationsseite nur wenig breiter, wenn man keine Schriftverkleinerung und korrekte Tabellenbeschriftung einsetzt. Mehr Breite würde man sparen, wenn man die Sortierfunktion abschaltet, die durch die Gruppierung der Einträge eh wenig Sinn hat. Aber wenn hier alle der Meinung sind es sei korrekt und hübsch, dann will ich mich in einen Bereich dem ich mich sonst nicht bewege nicht weiter damit aufhalten. Tschüss --Cepheiden (Diskussion) 15:43, 1. Nov. 2012 (CET)

LieberCepheiden,

ich bin doch darauf eingegangen. Die Din 1313 ist eine deutsche Norm zur Schreibweise physikalischer Gleichungen.

Sie kann aber schwerlich außerhalb ihres Anwendungsgebietes eckige Klammern verbieten. Aber, wie gesagt, Du könntest versuchen, per MB ein verbot durchzusetzen.

Bislang sieht die Konvention, zumindest für Listen und Tabellen im Geographie-Bereich, anders aus.

>>die Spaltenbreite wird in einem realen Beispiel wie dem auf der Dokumentationsseite nur wenig breiter

Testen wir das mal für die 4 q-Soalten:

[l/(s·km²)] | [l/(s·km²)] | [l/(s·km²)] | [l/(s·km²)] |

in l/(s·km²) | in l/(s·km²) | in l/(s·km²) | in l/(s·km²) |

Was die Sortierbarkeit anbelangt:

In einigen Spalten wird sie nicht zwingend gebraucht, aber gerade bei den q-Spalten ist sie sehr wichtig. Bei der Reihe könnte man sie abschalten, aber damit gewönne man nichts.

Der Rest steht in den ersten beiden Sätzen meiner ersten Antwort an Dich!

Letztlich würde die Tabelle sogar den gleichen Zweck verrichten, wenn überhaupt keine Einheiten angegeben wären. Wer nämlich eine solche Tabelle lesen und interpretieren kann, ist eh ein Flußpferd und weiß, um welche Einheiten es geht. Und wer sie als laie nur vage anhand des jeweiligen Begleittextes verstehen will, dem bringen nur die Relationen zwischen den Zahlen gleicher Einheit etwas.

Es gibt auch keine alternativen Einheiten aus konträren Systemen wie bei PS und kW oder Kalorien und Joule. --Elop 17:26, 1. Nov. 2012 (CET)

Ich fühle mich unschuldig. Die Änderung zielte auf eine bessere Lesbarkeit des Quelltextes ab. Die Ausrichtung per BR-Tag hielt ich für einen Hilfkonstrukt zur mittigen Ausrichtung. --SteveK ?! 09:30, 2. Nov. 2012 (CET)

Hallo Elop, ja, die DIN 1313 ist eine deutsche Norm. Nein, nicht zur Schreibweise physikalischer Gleichungen. Sie trägt den Titel Größen und beschäftigt sich mit grundlegende Festlegungen für Größen und damit zusammenhängende Begriffe. Diese sind für den allgemeinen Gebrauch bei der qualitativen und quantitativen Beschreibung naturgesetzlicher Erscheinungen in den verschiedenen Gebieten von Naturwissenschaft und Technik vorgesehen. Sei bezieht sich auf alle Bereiche von Größenangaben in Naturwissenschaft und Technik. Wo siehst du hier eine Anwendung außerhalb des Anwendungsgebietes? Ist Geografie und vor allem der Bereich in dem die Tabelle verwendet wird nun doch nicht als Naturwissenschaft sondern als reine Sozialwissenschaft anzusehen?

Des Weiteren ist die Schreibweise in mathematisch/physikalischer Sicht als falsch anzusehen (vgl. u.a. die Schreibweise von zugeschnittenen Größengleichungen oder Formatierungen von grafischen Darstellungen wie Diagrammen, vgl. auch DIN 461). Aber das wird dir sicher egal sein, denn es ist ja "üblich". Leider ist vieles üblich was eigentlich nicht korrekt ist. Nichtsdestotrotz würde ich ich diesem Punkt gern einen Beleg sehen, der diese Schreibweise explizit erlaubt oder gar empfiehlt und damit eine Gegenquelle zu der Anmerkung in der DIN 1313 darstellt. Wo findet man eigentlich die "Konvention, [..] für Listen und Tabellen im Geographie-Bereich"?

Was dein Beispiel angeht, hier verstehst du unter einem realen Beispiel offenbar nur den Tabellenkopf ohne weitere Spalten, sehr interessant. Aber für eine Abschätzung ist dies im Vergleich mit einem abgespeckten Beispiel natürlich ausreichend. Den Nachteil einer ca. 20 % breiteren Tabelle, halte ich, wie gesagt, für verschmerzbar, dafür kann man dann die Einheiten wenigstens lesen. Und auf kleinen Anzeigegeräten wie Smartphones sieht man die Tabelle eh nicht vollständig und die Zeilen werden beim versuch des Browsers, die Tabelle darzustellen, entgegen eures Wunschlayouts an allen möglichen Stellen umgebrochen. Der vermeidliche Hervorhebungsaspekt ist auch ein Irrglaube, das sage ich dir als Außenstehender. Denn durch die unterschiedlichen Schriftformatierungen, Schriftgrößen Verlinkungen und mittendrin platzierten Fußnoten wird das ganze Layout nur noch unruhiger und der Leser erfasst dadurch nicht schneller um was es geht. Aber das ist dir natürlich alles klar und das aktuelle Layout ist das absolute Optimum.

Beispieltabellen

Pegel	Lü0 1 in m	LoM 2 in km	EZG in km²	Diff- EZG 3 in km²	MNQ in m³/s	MNq in l/(s·km²)	MQ in m³/s	Diff- MQ 3 in m³/s	Mq in l/(s·km²)	Diff- Mq 3 in l/(s·km²)	MHQ in m³/s	MHq in l/(s·km²)	Reihe (Nachweis)
Eisfeld-Bahnbrücke	427,9	283	51,2	51,2	0,15	2,85	1,09	1,09	21,3	21,3	12,4	242	1961/2010

Pegel	1 Lü0 [m]	2 LoM [km]	EZG [km²]	Diff 3- EZG [km²]	MNQ [m³/s]	MNq [l/(s·km²)]	MQ [m³/s]	Diff 3- MQ [m³/s]	Mq [l/(s·km²)]	Diff- 3 Mq [l/(s·km²)]	MHQ [m³/s]	MHq [l/(s·km²)]	Reihe (Nachweis)
Eisfeld-Bahnbrücke	427,9	283	51,2	51,2	0,15	2,85	1,09	1,09	21,3	21,3	12,4	242	1961/2010

 

Der Parameter Lü0 bezeichnet die Lage über NHN.

 

Der Parameter LoM bezeichnet die Lage oberhalb der Mündung bzw. die Entfernung von dieser.

 

Die Diff-Werte der Hauptpegel beziehen sich immer auf das Einzugsgebiet des Pegels abzüglich des vorherigen Hauptpegels; bei Nebenflusspegeln entspricht sie direkt dem Pegeleinzugsgebiet.

 

Die Differenzzeile errechnet sich immer aus den Diff-Werten des nachfolgenden Hauptpegels abzüglich der unmittelbar oberhalb aufgeführten Nebenpegel.

Und wenn du meinst auf die Einheiten kann man ganz verzichten und ein Laie würde sich schon informieren oder die Tabelle eh nie lesen wollen, warum werden die Einheiten nicht gleich ganz entfernen?

Sei's drum, ich wollte nur einen guten Rat zur Verbesserung geben. Aber irgendwie habe ich das Gefühl, dass hier gleich die Barrikaden hochgezogen werden und man sich verteidigen muss. Nunja, ihr macht das schon. Bis irgendwann. --Cepheiden (Diskussion) 19:39, 2. Nov. 2012 (CET)

Lieber Cepheiden,

ich komme selber aus Mathematik und Physik und nicht etwa aus der Geographie.

Was die Anzeige in Smartphones, aber auch bei schmalerer Bildschirmauflösung anbetrifft:

Wir arbeiten daran, daß immer nur max. 10 Spalten angezeigt werden und man zwischen 3 Standardansichten wechseln kann, s. u..

Zu Deinen Tabellenansichten:

So, wie Du die Version mit "in" formatiert hast, ist die Übersicht durch ein völliges Chaos ersetzt. Ich wies bereits darauf hin, daß man im "in"-Fall entweder mit geschützten Leerzeichen (breitere Zeilen) oder aber mit Umbrüchen (vierzeiliger Kopf) arbeiten muß. Sonst bilden die eigentlichen Spaltentitel Schlangenlinien und man findet dort nichts.

Und noch einmal das konsequent von Dir Ignorierte:

>>Ich sehe nicht nur einen Platzvorteil, sondern auch eine Hervorhebung des Wichtigen (Spaltenkennzeichnung) gegenüber dem Unwichtigen (Einheit).

De facto liest man doch nur keinmal oder einmal die Einheit nach, während man als Betrachter und Interpretierender der Tabelle immer wieder schaut, wo denn die MQ-Spalte (oder eine andere) sei.<<

Selbstredend wäre diese Hervorhebung auch anderweitig herstellbar - z. B., wenn die Einheiten nicht klein, dafür aber auch nicht fett geschrieben wären. --Elop 20:17, 2. Nov. 2012 (CET)

Lieber Elop,

da du aus dem Bereich Mathematik und Physik kommst, wird dir ja bekannt sein, dass diese Angabe von Einheiten in eckigen Klammern eine alte, seit längerem nicht mehr übliche Konvention darstellt.

Interessant, dass ihr an einer solchen Umsetzung arbeitet. An der 14-spaltigen Tabelle der Vorlage lässt sich das leider nicht erkennen. Daher entschuldige bitte meine Unkenntnis. Wo kann man mehr zu diesen Umsetzung erfahren?

Nein, man muss im "in"-Fall ganz und gar nicht mit umbruchgeschützen Leerzeichen arbeiten. Im Gegenteil, denn eine solche Formatierung kann bewirken, dass bei einer zu schmalen Spalte der Umbruch erst innerhalb von "l/(s·km²)" erfolgt (so wie es auch bei der Anzeige der derzeitigen Version auf Smartphones zu beobachten und natürlich vom Browser abhängig ist) statt zwischen "in" und "l/(s·km²)". Das kann ja wohl kaum erwünscht sein. Des Weiteren würde ein verhinderter Umbruch wiederum bewirken, dass eine durch den Browser vorgenommene Verkleinerung der Spaltenbreite behindert wird und daher die Spalte auf kleinen Anzeigeräten wiederum größer als notwendig ist. Entgegen dem Wunsch einer möglichst schmalen Tabelle. Wo ist also der Vorteil eines umbruchgeschützen Leerzeichens? Übrigens, wenn man keine "Schlangenlinien" im Tabellenkopf möchte, dann wäre die derzeitige Form auch nicht erwünscht, denn die Zwangs-Schlangenlinien durch festgelegte Umbrüche, zementiert diese von dir bemängelte Anzeige für jedes Anzeigegerät.

Und was soll ich ignoriert haben? Die Hervorhebung oder den Aspekt, dass du der Meinung bist, die Einheit sei unwichtig? Beides habe ich nicht ignoriert. Wie ich schon gesagt habe, ist die MQ-Spalte usw. wegen den diversen unterschiedlichen Formatierungen im Kopf eben nicht schneller zu finden. Ich gebe zu, dass ist subjektiv, aber ich sagte ja, dass ich nur einen guten Rat geben wollte. --Cepheiden (Diskussion) 21:05, 2. Nov. 2012 (CET)

Namntnochma Cepheiden!

Sollte es so sein, daß eine größere Tabelle dieser Art auf Smartphone nicht sinnvoll darstellbar ist, würde ich das so hinnehmen. Die WP-Seiten sind ja nicht für Smartphone optimiert, sondern für übliche Medien wie PC, Laptop, etc.. Aus dem Bauch heraus hielte ich es jedenfalls für witzlos, auf dem Smartphone größere Tabellen zu analysieren. Genau so wie ich es für witzlos hielte, sich Fußnalländerspiele auf dem Handy-Display anzusehen.

Auf einem Bildschirm mit normaler Auflösung sollte aber selbstredend eine solche Tabelle gut ablesbar sein. Im Extremfall vielleicht 800*600 mit großer Schrift.

Und da müßte schon viel passieren, bevor das System einen Umbruch innerhalb von "l/(s·km²)" erzeugte. Aber dadurch, daß z. B. u. U. Spalte 4 drei Zeilen hätte und Spalte 5 vier, käme extremes Zickzack in die Übersicht.

Zum Bemühen, die Tabelle je in drei Ansichten aufzuteilen, kannst Du in Wikipedia:Vorlagenwerkstatt#Abflusstabelle nachlesen. Aber die weitere Diskus findet ja hier, einen Abschnitt tiefer ff, statt. darkking (Duck?) hat da offenbar schon eine Struktur im Kopf, die ich abwarte. Ich bin klammertechnisch da noch absolut in der Einarbeitungsphase und als (übrinx) bis zu einem gewissen Grade Fehlsichtiger da schnell genervt, weil ich immense Probleme mit dem Klammerzählen habe. Gewohnt bin ich von früher noch die verbalen Programmiersprachen, wo ich, wenn was nicht funzt, deutlich schneller die Fehler finde.

Aber Dein Begehren ist bislang ja eh ein primär layouttechnisches, das nicht nur diese tabelle beträfe (die man jederzeit binnen Minuten ändern könnte).

Ich fühle mich keiner DIN-Norm verpflichtet, fände es aber gut, wenn immer alles einheitlich dargestellt würde und nicht von Autor X anders als von Autor Y. Dafür bräuchte man einen Konsens innerhalb der Portale.

Könntest Du abwarten, bis die hiesige Vorlage in technischer Hinsicht ihre Endform erreicht hat und im Beispiel Werra der Doku auch mal mit Fließtext in einen Artikel eingebaut ist?

Ich nehme mal an, daß Du zu den Nichtflußpferden gehörst und Dir Größen wie Mq oder MHQ bislang so gut wie nichts sagen. Dergleichen ist, wie ich festzustellen glaube, bislang sogar bei den WP-Flußpferden der Fall.

Deine Grundüberzeugungen könntest Du portalweit darstellen, sobald erstmal das Ding hier prinzipiell rund wäre. Davon wären auch X Artikel betroffen, die, anders als globale Vorlagen, nicht in einem einzigen 5-Min-Edit überführbar wären.

Schlaschö, --Elop 01:20, 3. Nov. 2012 (CET)

Hallo Elop,

Egal ob auf einem Smartphone oder einem 30″-Monitor, die von dir erwähnten mehrzeiligen "Zickzack"-Tabellenköpfe sind schon da und weitere Zeilen kommen nur zustande, wenn die Anzeigebreite des Displays nicht mehr ausreicht um die Tabellenbreite darzustellen. Und wenn der Browser es mit 5-Zeilen darzustellen versucht, hat es seinen Grund, dann ist die Tabelle zu breit für Anzeige. Mir persönlich ist es in solchen Fällen lieber der Tabellenkopf bekommt eine Zeile mehr als dass die Tabelle rechts abgeschnitten wird. Und wie gesagt, wenn ihr solche "Zickzack"-Tabellenköpfe nicht wollt, sollte man von Zwangsumbrüchen absehen und es den Browsern überlassen wann sie den Umbruch machen. Kleinere Schrift und nicht mehr korrekte Einheitenangaben, verkleinern zwar etwas die Tabellenbreite, wirklich Besserung in dieser Hinsicht bringen sie aber nur in Grenzfällen, bei denen die Tabelle im aktuellen Layout gerade so auf den Bildschirm passt. Ich hoffe das ist dir klar.

Warum du mich nochmals bitten abzuwarten, versteh ich nicht. Ich habe einmalig die Tabelle geändert und nachdem das nicht gewünscht war, mich nur auf der Diskussionsseite gemeldet. Ich habe auch nie gesagt, das ihr die Tabelle umstellen müsst oder dass ich dies durchdrücken will. Lediglich habe ich meine Meinung zu dem Thema geäußert und die Fakten genannt. Von der Ansicht steht es außer Frage, dass ich aberwarte. Darüber hinaus sollte die Tabelle nicht auf weitere Erklärungen (z.B. Einheiten) aus dem Fließtext bedürfen.

Natürlich wäre eine portal- oder wikiweite Umsetzung sinnvoll, aber gibt es denn derzeit eine Regelung dazu im Portal Geografie?

Ich denke nun habe ich wirklich genug zum Thema gesagt. bye bye--Cepheiden (Diskussion) 11:15, 3. Nov. 2012 (CET)

Da ihr gerade so herrlich über die Darstellung von Einheiten streitet: Beide hier genannten Varianten würde ich als falsch bezeichnen. Korrekterweise müsste etwa etwa eine Angabe von U = 10 V im Tabellenkopf als U/V dargestellt werden ;) --darkking3 ^Թ 10:23, 3. Nov. 2012 (CET)

Ja, "U/V" ist korrekt, genauso wie "U in V" und "U" mit der Angabe "10 V". Einheitenangaben in eckigen Klammern waren mal erlaubt, sind es aber nicht mehr. --Cepheiden (Diskussion) 11:15, 3. Nov. 2012 (CET)

Eine Darstellung wie U/V würde ich bei komplexeren Brüchen nicht einmal erwägen.

@ ceph:

>>die von dir erwähnten mehrzeiligen "Zickzack"-Tabellenköpfe sind schon da<<

Das verstehe ich nicht. Selbst wenn ich meinen Browser (trifft auf alle 3 verfügbaren zu) auf nur 500 px Breite öffne, hat der Tabellenkopf genau 3 Zeilen Höhe, wobei die 2. je die Kenngröße (Fettschrift und normale Größe) angibt, die leicht auffindbar ist. (Bei den Q- und q-Werten werden übrinx in verbaler Kommunikation übrinx die Einheiten gar nicht genannt).

Völlig analog wäre es, würde man die "in"-Form nehmen, aber nach dem "in" ein geschützes Leerzeichen verwenden. Und bei "In" mit Umbruch wäre der einzige Unterschied, daß es 4 Zeilen gäbe und in Zeile 4 die Einheit stünde. Kenngröße je hervorgehoben nebeneinander und Einheiten nebeneinander.

Und so steht Gleichartiges Nebeneinander und die eigentliche Kenngröße ist problemlos auffindbar, da man nicht irgendwo in den Zeilen sucht, sondern stets in der durch Größe hervorgehobenen Zeile 2.

In Deinem obigen Beispielkopf hingegen sehe ich bei normaler Darstellung im Kopf in Spalte 1 eine Zeile, in Spalte 2 zwei, in den Spalten 3 und 4 drei Zeilen, in Spalte 5 vier, etc., die je höhenmäßig zentriert sind, das heißt die je mittlere in der Höhenmitte. Die Kenngröße ist weder durch Schriftgröße (oder -Dicke, ginge ja auch) hervorgehoben noch durch einheitliche Position im Tabellenkopf bequem auffindbar.

Btw:

In den Gewässerjahrbüchern wird in Zeilen statt in Spalten gelistet. Dort steht die Einheit, ohne Trennlinie/Bruchstrich/"in", gleich dahinter, also z. B. "MHQ m³/s". Aber auch dort stehen die Einheiten auf gleicher Höhe (hier: untereinander) und nicht mal weiter links, mal weiter rechts.

"U/V würde ich bei komplexeren Brüchen nicht einmal erwägen". Musst du auch nicht, ist aber wenigstens korrekt (eigentlich sollte man aber Formelzeichen kursiv setzen).

Zu den "Zickzack"-Tabellenköpfe: genau, es sind 3 Zeilen! Allein dadurch ist erzwingt man immer eine Zickzackform, vollkommen unabhängig ob neben der Tabelle noch ausreichend Platz ist oder ob die Tabelle breiter ist als die Anzeige. Gut zusehen an der Spalte "Diff-³Mq [l/(s·km²)]". Hierbei wird auch nicht in der mittleren/2. Zeile die Kenngröße dargestellt, denn dann hättest du zwei Spalten mit der Kenngröße Mq, EZG und MQ in der Tabelle, so wie ich das Verstehe sind es aber die Kenngrößen EZG, MQ, Mq und Diff-EZG, Diff-MQ, Diff-Mq. Man kann auch nicht sagen, dass die ersten beiden Zeilen die Kenngröße darstellen, da zumindest in zwei Spalten in der obersten Zeile eine Fußnote steht. Fußnoten werden aber eigentlich nie vor sondern immer nach einem zu erklärenden Begriff gesetzt. Daher steht auch nicht immer gleiches neben gleichem, was zwar günstig sein kann, ich aber nicht als notwendig erachte. Mein obiges Beispiel war auch nicht diesbezüglich ausgerichtet, sondern sollte lediglich den Unterschied in der Tabellenbreite zeigen, wenn auf kleinere Schrift verzichtet und die "in-Form" genutzt wird.

Und wie gesagt die unterschiedlichen Schriftgrößen/-formatierungen mögen für dich die Übersichtlichkeit erhöhen, ich bin da anderer Meinung. Darüber könnte man viel philosophieren, Fakt ist aber, dass die Ziele die mit der Zwangsformatierung verfolgt werden, aus genannten Gründen nicht erreicht werden. Aber aus irgendwelchen Gründen meinst du sie werden es und die Formatierung wäre quasi optimal. Das kann ich nicht nachvollziehen.

Der Umbruch nach dem Schrägstrich in "m³/s" usw. kann ich im IE9, Android-Browser, Wiki-Android-App und Opera (11 und Android) nachvollziehen (PC, Smartphone und Tablet). Firefox macht es nicht (weder PC noch Android). Aber das war ja nie mein Kritikpunkt, sondern ich wollte ja nur zeigen, dass die Variante mit geschütztem Leerzeichen keine Verbesserung bringt.

Und wie gesagt, was mancherorts (z.B. Gewässerjahrbüchern) üblich ist, ist nicht immer korrekt.

-- Cepheiden (Diskussion) 13:59, 3. Nov. 2012 (CET)

Zeilen

Ich habe hier mal eine Beispiel erstellt. Dies kann als noch nicht fertig betrachtet werden. Neben den Berechnungen pro Zeile könnte auch in der Vorlage alles summiert werden. Derzeit halte ich auch die Klasse hintergrundfarbe5 als zu dominant. --darkking3 ^Թ 19:40, 31. Okt. 2012 (CET)

Was die Einfärbung anbelangt, bin ich offen. Hauptsache, man kann farblich zwischen den Hauptpegeln und den Teileinzugsgebieten unterscheiden.

Vorlage:Abflusstabelle/Zeile geht aber nur für die Hauptpegel und man bräuchte noch eine Zweite Zeilenvorlage für die "Neben"pegel, oder?

Die Quelltextersparnis leuchtet mir schon jetzt ein. Auch die einfachere Erweiterbarkeit.

Aber wie genau ginge es, Spalten im Paket ein- und ausschaltbar zu machen? Läßt man die komplette Tabelle berechnen und sagt "Zeige an: Spalten 1-5; 8-11; 14", per Knopf umschaltbar auf "1-5; 6-8; 10; 12-14"?

Übrinx steht noch die Frage mit "if" im Raum. Die Zeile:

| {{#if: {{{Pegel-MNQ|}}}|{{FormatNum|{{#expr: {{{Pegel-MNQ}}} / {{{Pegel-EZG}}} * 1000 round 2}} }}|}}

führt ja zu einer Fehlermeldung, wenn kein Pegel-EZG bekannt ist (auch wenn das bislang nie vorgekommen ist). --Elop 12:27, 1. Nov. 2012 (CET)

Nochne Frage:

Ist es möglich, in der einzelnen Anzeige bestimmte Linien zu verdicken (in der q-Anzeige z. B. zum Trennen der Blöcke Kenndaten, MNQ/q, MQ/q, MHQ/q und Reihe? --Elop 12:42, 1. Nov. 2012 (CET)

Die Lösung sieht so aus:

| {{#if: {{{Pegel-MNQ|}}}|{{FormatNum|{{#expr: {{{Pegel-MNQ}}} / {{{Pegel-EZG|1}}} * 1000 round 2}} }}|}}

Oder man fängt eine Fehlerhafte Ausgabe ab.

Der Nebenpegel hat doch nur weniger Daten? Dann würde eine Zeilenvorlage ausreichen, an die dann halt nicht alle Parameter übergeben werden ;)

Einzelne Linien dicker zu gestalten ist möglich, ebenso das Ausblenden einzelner Spalten. Für das Ausblenden würde sich eine Zeilenvorlage aber anbieten, da dann ein parameter übergeben werden müsste um häufige switch-konstrukte zu vermeiden. --darkking3 ^Թ 13:49, 1. Nov. 2012 (CET)

Mit der obigen "Lösung" würde ein Pegel ohne EZG aber riesige q-Werte erhalten anstatt gar keiner. Und wenn wir die 1 durch eine astronomisch hohe Zahl ersetzen würden, käme "0" raus. Gibt es kein If mit exclusivem Und? Oder schachtelt man einfach zwei If-Schleifen hintereinander (und verzählt sich bei den Klammern möglichst nich)?

Nochwas zur Rundung:

Kann man erzwingen, daß von der Genauigkeit her korrekte Nullen hinter dem Komma angezeigt werden und im Falle nicht gerechtfertigter Nullen die Zahl entsprechend nach links rückt - siehe z. B. die in die Doku integrierte Werratabelle:

Dort ist der MNQ des Pegels Ebenhards mit 0.400 angegeben, wird aber als 0,4 dargestellt und liegt deshalb weiter rechts als die Werte der anderen Pegel. Ich nehme da sogar an, daß mit Genauigkeit nur die 4 bzw. maximal die 40 gesichert wären (Angabe ist in l/s statt m³/s), aber die 4 sollte schon unter der 1 aus Eisfeld/Bahnbrücke und über der 7 aus Schleuse/Rappelsdorf stehen!

Dürfte doch einen einfachen Formatierungsbefehl dafür geben ... --Elop 14:16, 1. Nov. 2012 (CET)

Es gibt in dem Sinne kein exklusives und, dafür aber {{Booland}} und {{Booland3}}. Auch sollte es Möglichkeiten geben, die Zahlen entsprechend darzustellen. Allerdings muss ich da auch erstmal nachschauen bzw. in der WP:WVW nachfragen ;) --darkking3 ^Թ 14:25, 1. Nov. 2012 (CET)

Morty hatte Booland hier mal versucht, aber das funzte nich. Oder fehlten da einfach Klammern? Ich bin mit nich so großem Klammerzähltalent ausgestattet ... --Elop 15:08, 1. Nov. 2012 (CET)

Da wird ein text übergeben und keine Variablen ;) --darkking3 ^Թ 15:11, 1. Nov. 2012 (CET)

So ähnlich dachte ichs mir. Issja merkwürdig, wenn durch das Booland plötzlich eine Klammer weniger da ist statt zweier mehr. Wäre es so:

{{!}} align="right" {{!}} {{#if: {{Booland|{{{Pegel2-MNQ}}}|{{{Pegel2-EZG}}}}}|{{FormatNum|{{#expr: {{{Pegel2-MNQ}}} / {{{Pegel2-EZG}}} * 1000 round 2}} }}|}}

korrekt? --Elop 15:21, 1. Nov. 2012 (CET)

Fast! hinter den Parameternamen muss eine Pipe |, damit der Parameter bei nichtbelegung auch leer ist. --darkking3 ^Թ 15:23, 1. Nov. 2012 (CET)

Also in der Zeilenvorlage so:

{{#if: {{Booland|{{{Pegel-MNQ|}}}|{{{Pegel-EZG|}}}}}|{{FormatNum|{{#expr: {{{Pegel-MNQ}}} / {{{Pegel-EZG}}} * 1000 round 2}} }}|}},

analog die Zeilen für Mq und MHq?

Was ich indes noch nicht ganz schnalle:

Die Spalten 5, 9 und 11 verwenden Einträge aus vorhergehenden Zeilen. Wie soll das gehen, wenn es nur "Pegel" gibt? Da bräuchte man doch "Pegel-k" und "Pegel-(k-1)", ferner würden in "Pegel-k.j" für das kleinste j, für das kein Eintrag existiert, die anderen "Pegel-k.j" sowie "Pegel-k) und "Pegel-(k+1)" mit eingehen. --Elop 15:41, 1. Nov. 2012 (CET)

Man kann als Parameter auch eine Berechnung übergeben. Auch sind weitere Parameter unnötig, da du ja die bisher verwendeten weiter benötigst und die zeile entsprechend die vorhandenen parameter bekommt. --darkking3 ^Թ 07:17, 2. Nov. 2012 (CET)

Ist in nächster Zukunft noch mit einer entsprechenden Umstellung der Tabelle zu rechnen? --Elop 09:27, 2. Jan. 2013 (CET)