Benutzer Diskussion:Silvicola/Vorlage Zuflusslistenzeile

Weitere mögliche Segmente

Von der Vorlage erzeugte Segmente

Gruppe	Segmentname	Datentyp	Beschreibung	Optional	Anmerkungen
Allgemein	Einrücktiefe	INTEGER	Regelt die Position im Flusssytem	nein
Allgemein	Lemma	STRING	Eindeutiger Name	ja	Notwendig wegen Verlinkungen
Allgemein	Verlinkungsschalter	BOOLEAN	Regelt Verlinkung	ja
Allgemein	Alternativnamen	STRING ARRAY	Weitere Namen	ja
Allgemein	Artikel des Gewässer	CHARACTER		ja	wird vielleicht mal benötigt

--Anarabert (Diskussion) 12:11, 24. Jan. 2013 (CET)

Danke für Deine Vorschläge!

Ich versuche vorsichtshalber um nichts zu übersehen die Sache von zwei Seiten anzugehen: Was will man haben? Was muss man liefern?

1. Die Segmente aufführen, aus denen sich eine per Vorlage generierte Zeile zusammensetzt, sozusagen deren Bildungsblöcke, darunter etwa das Segment der verlinkten Mündungskoordinaten, in die ja mehrere Parameter der geplanten Vorlage eingehen müssen:

1. die zwei nackten Koordinatensätze für longitude und latitude

2. der Name des (Zu)flusses, den man für den obligatorischen name-Parameter von Coordinate braucht

3. evtl. bei unbenannten ersatzweise die GKZ, weil etwa "Mündung Unbenannter Zufluss"/"Abgang Unbekannter Kanal" wenig sinnvoll erscheint und überdies mehrfach auftreten könnte

4. ob es ein Zu- oder Abfluss ist, je nachdem hierfür name=Zufluss X oder name=Abzweig X oder name=Verbindung X

5. evtl. ein noch fehlender TYP des verbundenen Gewässers (Quelle, Hafenbecken usw., das beeinflusst ja andererseits auch das Flusslauficon, das man dort nun nicht gerade per Hand einbinden müssen sollte, sondern es sollte sich aus Schalterstellungen ergeben)

2. Die nötigen Parameter der Vorlage erheben, aus denen auf einer zumindest begrifflichen Ebene erst einmal die Segmente zusammengebastelt werden, die dann ihrerseits vielleicht noch in veränderter Stellung oder Auswahl in verschiedenen Views Verwendung finden können.

Im Sinne der Unterscheidung Segment/Parameter schlägst Du neu insofern eher Parameter als Segmente vor.

Da Du außerdem Datentypen im Sinne gewöhnlicher Programmiersprachen benennst, scheinst Du eher auf WikiData vorauszudenken oder Dich an einer SQL-Datenbank als Datenquelle zu orientieren. Denn zumindest bei händischer Verwendung der Vorlage, also im bisherigen Sinne, wo die Parameter explizit in der Einbindung stehen, sind diese hingeschriebenen Parameter fundamental gesehen ohnehin immer nur Text (mit minimen Beschränkungen, damit sie die Struktur der Einbindung nicht stören). Mit dem Datentyp bei Segmenten wollte ich andeuten, was sich mit dem Erzeugnis machen lässt, also

WIKITEXT Text, der Links enthalten kann u.a. (nur über Benutzer-Ausbau)

DEZIMAL Festkommazahl ohne Link (das fehlte noch, etwa km zu verlinken!)

ICON Bloßes Darstellungs-Icon

LINKICON Klickbares Icon

Datentyp ist insofern begrifflich von mir etwas daneben, es heißt besser Erzeugnistyp.

Nun im Detail zu Deinen Vorschlägen:

1. Einrücktiefe — Bisher hatte ich implizit angenommen, die Einrückung der Zeilen würde man selbst per : oder * vornehmen. Da Du bereits an den Layout von Datenbanktabellen (oder dem Entsprechenden in Wikidata) zu denken scheinst, sollten in dieser die Flussordnungszahl eingehen (bitte nur ein System, 0 = Meer usw.). Die Einrücktiefe ergibt sich dann bei den Zuflüssen durch Subtraktion, bei den Abzweigen und Kanälen leider nicht, denn es kann ja schlimmstenfalls ein Nebenast ins Meer münden, der Hauptfluss aber erst in einen anderen. Wenn man die Abzweige, wie bislang immer angenommen, dem aufnehmenden Flusssystem zurechnet, haben deren Flussordnungszahlen überhaupt keine Relevanz für die Positionierung im Flusssystem, aus dem einer abgeht. Also vielleicht doch lieber (erst mal) nur ein handgespeister Parameter? Oder soll man bei „zweiendigen“ eine weitere (relative) Flussordnungszahl in Bezug aufs speisende Gewässer vorsehen?

2. Lemma — Wie abgegrenzt von Name?

3. Verlinkungsschalter – Wenn ich das mit Lemma zusammen richtig verstehe, dann habe ich einen gravierenden Einwand gegen einen Schalter, der bei Name N zwischen N und N schaltet, nämlich dass es auch Klammerlemmas gibt, und was in der Klammer wirklich stehen muss, völlig unberechenbar ist. Im Hinblick auf die Datenbankzukunft ist zur Eindeutigmachung eine möglichst unsemantische ID besser, allenfalls die GKZ (die aber bestimmt doch irgendwann geändert wird, und schon hat man den Bohei).

4. Alternativnamen — In Textdarstellung können wir Arrays nur über eine Liste mit reserviertem Trennzeichen simulieren. Die bisherige Verwendung des ALTERNATIVNAME-Parameters in der Box lässt außerdem mutmaßen, dass man zu solchen Alternativnamen häufig Erläuterndes stellen wollte: alter Name: / im Oberlauf:, auf holländischer Seite: usw., das ist endlos! Vielleicht lieber einen frei formatierbaren Parameter, allenfalls mitreserviertem Trennzeichen, damit man (dereinst) die mit Label versehenen Alternativnamen in der Liste hintereinander und in der Box untereinander stellen kann. Aber die BKLs vielleicht dereinst mit allen Alternativnamen automatisch bespeisen zu lassen, hat natürlich seine Reize, dazu bräucht man allerdings die innere Struktur: Liste von Paaren aus Erläuterung und Alternativname.

5. Geschlecht — Ist eher etwas für die Datenbank-Zukunft. Ich erinnere außerdem an den Vorbach (Tauber, Weikersheim): m/f/n/mf/mn/fn/mfn/(none), also 2³=8. Sprachliches ist allerdings immer heikel, hat er erst das Gschlecht, will er bald auch noch den Kasus haben.

--Silvicola ^Disk 23:27, 24. Jan. 2013 (CET)

@1: Gut, dann händisch

@2 + @3: In der Liste soll natürlich auf bestehende Artikel verlinkt werden. Also braucht es auf jeden Fall das Lemma. Selbstverständlich soll aber in der Liste nicht ein Lemma mit Klammerzusätzen angezeigt werden. Also entweder automatisch den Klammerzusatz abschneiden oder aber einen zusätzlichen Namen. Mit einer Prüfung auf die Existenz eines bestehenden Artikels könnte man sich einen Schalter sparen, hätte dann aber nicht mehr die Möglichkeit mittels Rotlink auf eine bevorzugte Erstellung des Artikels hinzuweisen.

@4: OK, String mit definierten Delimiter

@5: Beim Parameter Artikel, dachte ich an die Möglichkeit, aus der Liste automatische Artikel (gültige Stubs) zu erstellen.

--Anarabert (Diskussion) 00:47, 25. Jan. 2013 (CET)

@2+@3: Was spricht gegen einen händisch konstruierten Parameter
    …|NAME=[[Vorbach (Tauber, Rothenburg ob der Tauber)|Vorbach]]|…
? Ob man den von Hand zusammenschreibt oder in zwei Parameter Linkname/Linktext zerschneidet, ist wohl ziemlich dasselbe, vom erhöhten Parameter-Aufwand abgesehen. Auch mit einem WIKITEXT für den NAME-Parameter unserer Vorlage kann man, wie es einem eben behagt, rot verlinken oder nicht. Außerdem schränkt man weniger ein, falls man doch einmal das damit erzeugte Segment „aufbohren“ müsste, weil man es ja explizit selbst schreibt.

@5:Freut Dich auf die Aussicht auf zahlreiche Artikel in diesem Stil? Das allgemeine Publikum hier kann man offenbar nicht mit einem Rotlink zu Gewässrigem verleiten, so mein enttäuschter Eindruck; nicht einmal ein sehr Fleißiger, der jetzt über längere Zeit einen 130k-Artikel über (mutmaßlich) sein Heimatdorf verfasst hat, hat sich des dort mündenden Epfenbachs erbarmt. Gewässerartikel zu erstellen und auszubauen bleibt immer an den üblichen Verdächtigen hier hängen. So bliebe als einziger Vorzug, dass diese einen Ausbaurahmen haben, dessen Daten sie nicht selbst zusammensuchen müssen. Die Vorstellung, mit der Abspeicherung eines {{subst:Erzeuge-Fluss|land=LLL|gkz=NNN}} so etwas in Rohform in einer halben Minute zu bekommen, statt durch Zusammensuchen in fünfen, hat natürlich für unsereins seinen Reiz, setzt aber voraus, dass die Hauptarbeit Datenbeschaffung dafür schon getan ist und irgendwo niedergelegt ist.

--Silvicola ^Disk 03:47, 25. Jan. 2013 (CET)

@2+@3: Geht auch händisch

@5: Aus so einer Zeile könnte etwa folgender gültiger Stub entstehen:

=================================================================================================================================

Der Musterbach ist ein 9 km langer orgraphisch rechter Zufluß des Musterflusses.

== Geographie ==

=== Verlauf ===

Der Musterbach entspringt westlich des Musterbergs auf einer Höhe von 999 m ü. NN. Südlich von Musterstadt B wird er auf seiner linken Seite vom Musterbächlein gespeist. Bei Musterstadt B fließt ihm von rechts sein längster Zufluß der Musterkleinbach zu. Östlich von Musterstadt C mündet der Musterbach schließlich auf 99 m ü. NN linksseitig in den Musterfluss.

=== Zuflüsse ===

Größter Zufluss des Musterbach ist der 0,9 km lange Musterkleinbach.

Hier folgt dann ggf. eine Liste der direkten Zuflüsse.

== Daten ==

Auf seinem 9 km langen Weg überwindet der Musterbach einen Höhenunterschied von 900 m, was einem mittleren Sohlgefälle von 90 ‰ entspricht. (Dabei entwässert er ein 9,9 km² großes Einzugsgebiet über Musterfluss und Rhein zur Nordsee). (Seine mittlere Wasserführung beträgt 0,9 m³/s.)

=================================================================================================================================

Dazu käme noch eine fast komplett ausgefüllte Infobox. Das wäre doch gar nicht mal so schlecht für einen (kleinen) Bach. Man hätte dann auf jeden Fall mehr Zeit für eine ordentliche Recherche zum Ausbau des Artikels.

--Anarabert (Diskussion) 12:34, 25. Jan. 2013 (CET)