Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/Neue Koordinatenvorlage/2007

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

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/Neue Koordinatenvorlage/2007#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:WikiProjekt_Georeferenzierung/Archiv/Neue_Koordinatenvorlage/2007#Thema_1

Konsens aus Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/2007-III#Ausgabetext_durch_Vorlage_automatisch_erstellen

erste Schritte

Grandios! Also ich würde bei UTM noch ein Leerzeichen zwischen Zahl und "N" setzen. Sieht besser aus. -- sk 12:22, 4. Sep. 2007 (CEST)

sind zur Zeit eh nur Platzhalter ;-)-- visi-on 12:27, 4. Sep. 2007 (CEST)

Buh! Betrug! ;-) Sehe jetzt erst, dass das nicht die wirklichen Werte sind. Sah täuschend echt aus. -- sk 13:07, 4. Sep. 2007 (CEST)

prototyping! -- visi-on 14:55, 4. Sep. 2007 (CEST)

Fehlerausgabe

Sollten wir auch eine Fehlerausgabe einbauen? Siehe Vorlage:Geo-Koordinate (ganz unten) -- sk 16:43, 29. Aug. 2007 (CEST)

Fehler Prüfungen sind sicher hübsch. Die Frage ist für welche Parameter. text und article sind durch defaults abgesichert. WE kann man in Formatiervorlage auch noch ein Modulo 360 einbauen. NS sind Werte größer 90 und kleiner -90 definitiv falsch. Prüfung aber auf jedenfall ebenfalls in der Untervorlage, ergibt sich dort von selbst, da ja mit den Werten gerechnet werden muss. dim hat default Wert. Wird dim zur Rundung gebraucht knallts sobald es keine Zahl ist. negative Werte sind halt einfach kleiner 20m und ob dim größer als der Erdumfang ist muss nicht wirklich geprüft werden.Bleibt eine Plausibilisierung von pop und height gegen type. Mein Vorschlag war height generell zuzulassen, müsste man nur noch auf Zahl prüfen. pop macht nur bei country, state, adm1st, adm2nd, city und isle Sinn. landmark mit pop=2 können wir uns sparen, it aber nicht unbedingt falsch. Ein airport ist unbewohnt, waterbody in der Regel ebenfalls (mal sehen was mit den aufgegebenen Tagebauflächen passiert). Mit etwas goodwill kommen wir ohne Prüfungen aus. es sei denn ich habe etwas übersehen.-- visi-on 20:09, 29. Aug. 2007 (CEST)

Meine auch mehr die Tippfehler, also Komma statt Punkt in den Zahlen oder Tausenderpunkt bzw. -strich. -- sk 21:03, 29. Aug. 2007 (CEST)

Komma statt Punkt, fällt auf sobald du mit dem Wert rechnest. Wird nicht gerechnet stört es nur dich bei der Auswertung.

Tausenderpunkt ({{{1|0}}}0 ≠ expr:{{{1|0}}}*10) prüfen? Das machen doch bereits die Infoboxen. Doppelt gemoppelt. -- visi-on 21:26, 29. Aug. 2007 (CEST)

Ich habe jetzt im Prototyp mal ein paar Fehlerprüfungen eingebaut, bin aber der Meinung, dass jede dieser Prüfungen einer Diskussion bedarf. -- visi-on 22:29, 18. Sep. 2007 (CEST)

Für eine ausführlichere Fehlerbehandlung schlage ich eine weitere Untervorlage CoordinateMSG vor. -- visi-on 20:18, 28. Dez. 2007 (CET)

Prüfung auf Pflichtfelder

Längen- und Breitengrad muss immer angegeben sein. An den Polen ist der Längengrad nicht definiert. Eine Eingabe wird gleichwohl gefordert. Sinnvollerweise 0°. -- visi-on 22:29, 18. Sep. 2007 (CEST)

erledigtErledigt Fehlt Breiten- oder Längengrad so ist dies ein Lagewunsch mit entsprechendem Eintrag in die Kategorie:Wikipedia:Lagewunsch -- visi-on 19:28, 28. Dez. 2007 (CET)

Wertebereich CH1903

Fehlermeldung mit Wartungslink

Um die Schweiz ist ein Rechteck (480000/62000) (840000/320000) gelegt. Bis auf zwei LK50 Karten (248^bis und 259^bis) sind sämtliche Schweizer Kartenwerke innerhalb dieser Fläche. Außerhalb machen Schweizer Landeskoordinaten keinen Sinn mehr. In Dezimalgrad entspricht dies seitenmittig:

45.707064°< «NS» <47.865722°

und

5.867254°< «EW» <10.580148°

gerundet

45.7°< «NS» <47.9° und 5.8°< «EW» <10.6°

-- visi-on 22:29, 18. Sep. 2007 (CEST)

eine genauere Definition der Umfläche zB. auf Basis des LK50 Kartenwerks erachte ich für unnötig, denn die Default-Ausgabe im Artikel wird über die «region#»-Codes vorgenommen. Allenfalls bei der östlichen Begrenzung (248^bis und 259^bis und Schweizer Alpenführer) könnte man noch etwas großzügiger sein und noch ein bis zwei Zentelgrad dazugeben. -- visi-on 22:46, 18. Sep. 2007 (CEST)

"Geohack" Parameter

Fehlermeldung mit Wartungslink

Prüfung in der Geohack Parameter Aufbereitung. -- visi-on 22:29, 18. Sep. 2007 (CEST)

1. «type»

Gradzahl Numerisch

Fehlermeldung mit Wartungslink

Prüfung auf numerischen Wert von Breiten- und Längengrad -- visi-on 19:33, 28. Dez. 2007 (CET)

Groß - Klein ns ew ?

Sollen wir nicht die Parameter NS und EW nicht einfach auch klein schreiben, so wie wir es bei allen anderen Parametern auch tun? Wäre einheitlicher. -- sk 19:42, 29. Aug. 2007 (CEST)

man kann auch mit der function uc: beide Schreibweisen zulassen. Ich finde Großschreibung sticht, mehr und zu recht, ins Auge.-- visi-on 20:09, 29. Aug. 2007 (CEST)-- visi-on 21:35, 29. Aug. 2007 (CEST)

Ich würde für die Himmelsrichtungen ebenfalls die Großbuchstaben beibehalten. Allerdings würde ich diese beiden Parameter optional auch mit ihren Positionen 1 und 2 erlauben, also ganz ohne NS und EW davor. Siehe hierzu mein Diskussionsbeitrag weiter unten. --TM 22:33, 29. Aug. 2007 (CEST)

erledigtErledigt-- visi-on 14:26, 17. Nov. 2007 (CET)

Formatkombinationen

Formatkombinationen ließen sich auch durch einen Parameter text2 mit geringerer Wertemenge abbilden.-- visi-on 21:14, 29. Aug. 2007 (CEST)

ok, lassen wir das

erledigtErledigt-- visi-on 11:27, 4. Sep. 2007 (CEST)

Fragen und Denkanstöße zur Vorlagenprogrammierung

Ich habe eine Reihe von kleinen Fragen:

1. Soll es gar nicht mehr möglich sein, die Zahlen in sexagesimaler Schreibweise einzugeben, also Grad, Minute und Sekunden getrennt? Das würde tatsächlich vieles vereinfachen. Aber das Problem ist, dass man oft nur Grad, Minuten und Sekunden hat. Was soll man dann tun?
2. Das Format der englischen Vorlage Coord ist in der Tat katastrophal. Eine vernünftige Vorlagenauswertung ist damit so gut wie unmöglich. Die Parameter sollten alle feste Namen haben. Bei den ersten beiden Parameter könnte man trotzdem erlauben, die Namen wegzulassen, also zum Beispiel verkürzt {{Koordinate|49.759681|6.6440194|type=landmark|dim=25|region=DE-RP}} zu schreiben (ohne NS= und EW=). Was haltet ihr von dieser Idee? Das sollte aber nur bei diesen beiden Parametern möglich sein, keinesfalls bei weiteren.
3. Das mit den durchnummerierten Parametern region2, region3 usw. gefällt mir nicht. Wo legt man da die Grenze fest? Bei 9? Gibt es dafür keine bessere, flexiblere Lösung?
4. Die Möglichkeit, zum Beispiel mit article=DMS|text=Lage den Anzeigetext rechts oben und den Anzeigetext im Artikel getrennt festzulegen, gefällt mir sehr. Dafür ein großes Lob an den Autor.
5. Wenn die beiden Parameter article=… und text=… fehlen, wird vom Standard article=DMS ausgegangen. Das ist gut so. Wenn nur der Parameter text=… angegeben ist, sollten meiner Meinung nach trotzdem beide Ausgaben erfolgen, also auch oben rechts im Artikel. Das Problem hierbei ist: Wie realisiert man dann eine Koordinate, die nur im Text zu sehen ist? Mit article=|text=DMS, also ohne einen Wert hinter dem Parameter article=? Oder mit article=NONE? Ist die Vorlagenprogrammierung überhaupt in der Lage, zwischen einem nicht vorhandenen und einem leeren Parameter zu unterscheiden? Meiner Erfahrung nach gab es damit immer große Probleme, vor allem weil dieser Unterschied den Benutzern nicht klar ist. Sie vergessen dann das Gleichheitszeichen, löschen Kommentare nicht, geben Freitext ein, erfinden selbst neue, wirkungslose Parameter usw.

Mein Fazit aus diesen Problemen ist, dass diese Aufgabe gar nicht durch eine Vorlage sondern durch eine MediaWiki-Extension übernommen werden sollte. Genau wie zum Beispiel bei <imagemap> oder <ref> gäbe es dann ein Element <coord>. Der Vorteil wäre, dass man dort sehr flexibel mit dem vollen Sprachumfang von PHP arbeiten könnte und nicht an die doch recht starken Einschränkungen der Vorlagenprogrammierung gebunden wäre (dort gibt es zum Beispiel praktisch keine Funktionen zur Zeichenkettenverarbeitung, das Abfangen von Eingabefehlern fällt sehr schwer etc.). Eine solche Extension war sogar schon einmal im Gespräch, wenn ich mich nicht täusche, sogar eine, mit der man kleine Karten mit roten Punkten erzeugen konnte. Wer weiß da Näheres? --TM 22:29, 29. Aug. 2007 (CEST)

Antworten zu:

1. lässt sich mit einer substituierbaren Vorlage "DMS to DEC" lösen. Gibt ein bischen zu schreiben
2. wir haben uns auf nur key-values verständigt. Nachteil deines Vorschlags ist, dass die Werte in der richtigen Reihenfolge eingegeben werden müssen.
3. Zugegeben ein Kompromis, aber es gibt glaube ich nur in der Antarktis den Südpol, wo sich noch mehr als 4 Regionen in einem Punkt treffen. Grenze ist bis auf weiteres 4. Man benenne mir einen Punkt mit mehr und ich erhöhe.
4. Danke
5. Ich hatte nicht vor zwischen leer und nicht vorhanden zu unterscheiden. Aber Überraschungen bleiben dem Programmierer bekanntlich selten erspart.

-- visi-on 00:09, 30. Aug. 2007 (CEST)

Zu 2) nein, das wäre schlecht, die Parameter wegzulassen. Es gibt immer wieder verwechselung, was vorne steht und was nicht. Und die 6 Zeichen (NS=EW=) helfen bei der Lesbarkeit enorm. Außerdem kann bei der Vorlagenauswertung gleich mit dem richtigen Namen des Parameters gearbeitet werden. -- sk 09:30, 30. Aug. 2007 (CEST)

Zu 2.: Ok, ihr habt Recht.

Zu 3.: Flüsse durchfließen oft mehrere Länder und in jedem Land mehrere Bundesländer. Da können schnell zehn oder sogar noch mehr Regionen zusammen kommen.

Zu 5.: Ja, ok, aber wie soll die neue Vorlage dann die alte Vorlage:Koordinate Text ersetzen?

Häufigkeit	Alte Vorlage	Neue Vorlage, Variante 1	Neue Vorlage, Variante 2
46000	{{Koordinate Artikel}}	{{Koordinate}} Die Anzeige oben rechts ist Standard.	{{Koordinate}} Die Anzeige oben rechts ist Standard.
6000	{{Koordinate Text Artikel}}	{{Koordinate| text=DMS}} Die Anzeige oben rechts ist Standard.	{{Koordinate| text=DMS|article=DMS}} Sobald der Parameter text vorhanden ist, gilt der Standard nicht mehr und man muss die Anzeige oben rechts gezielt einschalten.
4000	{{Koordinate Text}}	{{Koordinate| text=DMS|article=NONE}} Da die Anzeige oben rechts Standard ist, muss man sie gezielt abschalten.	{{Koordinate| text=DMS}} Sobald der Parameter text vorhanden ist, gilt der Standard nicht mehr und die Anzeige oben rechts verschwindet.

Außerdem wünsche ich mir ein Ausgabeformat DM, um die Sekunden gezielt ausblenden zu können. --TM 12:52, 30. Aug. 2007 (CEST)

Wozu brauchst du DM genau? -- sk 18:34, 30. Aug. 2007 (CEST)

Ich will, dass unten im Artikel nur kurz „1° 2' N 4° 5' E“ steht. Das vermeidet unnötige Zeilenumbrüche innerhalb der Vorlage:Infobox Ort in Deutschland. Wer die Sekunden benötigt, soll sie oben rechts im Artikel sehen können. --TM 20:13, 30. Aug. 2007 (CEST)

Ich habe mir mal ein paar Orte angesehen. Jede Menge Platz. Die Himmelsrichtung steht sehr weit weg von der Zahl. Hinter der Koordinate ebenfalls noch Freiraum. Sind das wieder die leidigen unterschiedlichen Browserdarstellungen? Dein Wunsch ist für mich am konkreten Beispiel nicht so richtig nachvollziehbar. Aber unter generellen Betrachtungen lass ich das gerne mal so stehen. -- visi-on 18:51, 31. Aug. 2007 (CEST)

Die flexiblen Möglichkeiten zur Anzeige von HTML- und CSS-Quelltexten als „leidig“ zu bezeichnen, ist etwas kurzsichtig. Das ist der Sinn des Sprachenpaares HTML und CSS: Es ist eine Empfehlung an das Endgerät, wie die Seite dargestellt werden kann, aber jeder darf diese Empfehlungen an seine persönlichen Bedürfnisse anpassen. Ich zum Beispiel arbeite mit einer minimal vergrößerten Schrift, und da wird es mit dem Platz schon eng (siehe Bildschirmfoto rechts). Deshalb wird die Möglichkeit benötigt, die Anzeige der Sekunden auch bei sehr kleinen Objekten gezielt auszublenden. Um das Objekt auf einer Deutschlandkarte einordnen zu können, genügt die minutengenaue Anzeige völlig. Wie gesagt: Wer die Sekunden benötigt, findet sie nach einem Klick auf die Koordinaten. --TM 12:01, 11. Sep. 2007 (CEST)

Ah jetzt ist es nachvollziehbar, unsere Browser arbeiten bei gleichen Einstellungen identisch. Es liegt kein «leidiges» Problem vor. Nun wie gesagt, ich stemme mich nicht gegen ein solches Anliegen. Es soll einfach überschaubar bleiben.-- visi-on 12:34, 11. Sep. 2007 (CEST)

Das gibt nur so marginal wenig mehr an Code, dass man da schwerlich gute Argumente gegensetzten kann.-- visi-on 17:12, 13. Sep. 2007 (CEST)

erledigtErledigt-- visi-on 14:25, 17. Nov. 2007 (CET)

Ein- und Ausgabeformat

Ich halte den Wechsel des Formates für problematisch. Eingabe dezimal und Ausgabe DMS macht die Sache meiner Meinung nach unnötig schwer. Da DMS wohl doch das populärere Format ist, sollte es auch zur Eingabe genutzt werden (eventuell alternativ zum dezimalen). --Obersachse 09:45, 3. Sep. 2007 (CEST)

Die Eingabe von Zahlen im Sexagesimalsystem ist sehr fehleranfällig und nur schwer zu handhaben. Es ist unverhältnismäßig aufwendig, daraus eine korrekte Dezimalzahl zu ermitteln. Die automatisierte Auswertung von georeferenzierten Artikeln wird um ein Vielfaches erschwert. Ich weiß, dass es hart ist, aber ich halte die Entscheidung, nur noch Dezimalzahlen zuzulassen, für völlig richtig. --TM 11:00, 3. Sep. 2007 (CEST)

Vorlage:Dezimalgrad: {{subst:Dezimalgrad|47|25|0|N|subst=subst:}} substituiert die sexagesimale Eingabe. -- visi-on 11:15, 3. Sep. 2007 (CEST)

Es geht also doch. Ich denke, den technischen Aufwand sollte man treiben, wenn dadurch die Benutzung der Vorlage einfacher wird. --Obersachse 13:36, 3. Sep. 2007 (CEST)

Ganz so einfach ist es nicht mit dem technischen Aufwand treiben. Die neu zu schaffende Koordinatenvorlage profitiert sicher davon, wenn wir auf verschiedene Eingabeformate verzichten. Was wir anbieten können, sind Vorlagen (wie obiges Beispiel), die die Eingabe substituieren. Das ist sicher nicht so bequem, aber man kann immerhin im gewohnten Format die Eingabe vornehmen. Das Vorlagenbeispiel Dezimalgrad würde übrigens noch gewaltig an Komplexität zunehmen, wollte man alle möglichen DMS Eingabemöglichkeiten berücksichtigen. Die Aufteilung auf vier Parameter für einen Wert, eröffnet ungeahnte Möglichkeiten, von Fehleingabe bis Fehlinterpretation. -- visi-on 19:01, 3. Sep. 2007 (CEST)

Ich kann also eine noch zu schaffende Vorlage {{DMS to DEC}} verwenden, in die ich wie gewohnt DMS eingebe? Wenn ich auf <Speichern> drücke, wird die Vorlage in {{Koordinate}} umgewandelt und enthält die Daten im Dezimalformat? Wenn das so klappen würde, könnte man die Daten wie gewohnt eingeben und hätte am Ende trotzdem die neue Vorlage. (Und ich würde aufhören, zu meckern.) --Obersachse 20:50, 3. Sep. 2007 (CEST)

Ja, du schreibst dann einfach sowas wie

{{Koordinate|NW={{subst:Dezimalgrad|50|45|53.66|N}}|EW={{subst:Dezimalgrad|3|14|42|E}}|...}}

(oder wie die Vorlage dann auch immer heißt) in den Artikeltext rein, also die Vorlage {{Dezimalgrad}} anstelle der dezimalen Parameter. Durch das subst: wird der Ausgabetext der Umwandlungsvorlage beim Speichern direkt in den Artikeltext eingefügt, sodass du im Endeffekt

{{Koordinate|NW=50.764906|EW=3.245|...}}

im Artikeltext stehen hast. Ohne subst wird ja das Auswerten im Dump wieder kompliziert. --Rohieb 会話 +/- 21:03, 3. Sep. 2007 (CEST)

Anmerkung: Würde ich heute diese Vorlage Dezimalgrad nochmals schreiben, wäre die Himmelsrichtung an erster Stelle. Man darf und soll sich also über Name und Gestalt einer solchen Vorlage Gedanken machen! -- visi-on 21:52, 3. Sep. 2007 (CEST)

Warum das? Ich finde die Eingabe so in Ordnung, mit der Himmelsrichtung hintendran. Ist natürlicher. --Rohieb 会話 +/- 21:54, 3. Sep. 2007 (CEST)

weil es dann nicht drauf an käme ob Minuten und Sekunden leer oder gar nicht geschrieben werden. -- visi-on 22:55, 3. Sep. 2007 (CEST)

Ich denke es ist auch schnell eine Webseite gestrickt, die die Umrechnung vornimmt. Alle bestehenden Koordinaten werden ja per Bot umgewandelt. -- sk 19:18, 3. Sep. 2007 (CEST)

erledigtErledigt DMS ist möglich -- visi-on 14:31, 17. Nov. 2007 (CET)

Runden bei OSGB36

Ich habe mich mal noch näher mit den Briten beschäfftigt. OSGB36 beschreibt immer eine Fläche in der das Objekt liegt. Die Flächegröße ergibt sich aus der Anzahl Stellen. Ganz schön clever, von wegen, die spinnen die Briten (Asterix). OSGB36 sollte also auf jedenfall abhängig von dim gerundet werden. -- visi-on 11:39, 4. Sep. 2007 (CEST)

Nützlich: [1] -- visi-on 14:35, 9. Nov. 2007 (CET)

ICON

Die Idee war gut. Aber wie unterlege ich dem Icon einen parametrisierten Link?-- visi-on 15:14, 4. Sep. 2007 (CEST)

Schau doch mal, wie es der WikiMiniAtlas macht. -- sk 15:40, 4. Sep. 2007 (CEST)

Dazu gibts auch ein neues Symbol, welches neben jedem Koordinatenlink eingeblendet wird ... -- visi-on 15:49, 4. Sep. 2007 (CEST)

Alternativ ein Zeichen: ⌔⊻⊥⊙⊚⊡≚≜∇▼▽◆◇◈◉▾▿ Welches dieser Zeichen wird am ehesten als Koordinate gelesen? ▼ kommt in den meisten Schriftsätzen vor.-- visi-on 08:47, 14. Sep. 2007 (CEST)

Bei mir werden nur ⊥⊙∇▼▽◆◇◈ ordentlich angezeigt (IE6), dabei kommt ⊙ für mich einem Punktziel eindeutig am nächsten. Kolossos 09:11, 14. Sep. 2007 (CEST)

kommen wir der Sache bereits näher, meine Favoriten sind: ⊙▼▽. ▽ Verbreitete Notation bei Vermessern (Feldbuch). ⊙ entspricht den Farbspray-Markierungen, wie sie auf Baustellen verwendet werden (Oma-Test). ▼ ist wahrscheinlich das kompatibelste Zeichen.-- visi-on 09:51, 14. Sep. 2007 (CEST)

So sehen die Varianten aus:

• Der Eifelturm ⊙50.314427.01015 ist das Wahrzeichen von Paris
• Der Eifelturm ^▼50.314427.01015 ist das Wahrzeichen von Paris

*Der Eifelturm 50.314427.01015 ist das Wahrzeichen von Paris-- visi-on 14:41, 9. Nov. 2007 (CET)

mir gefällt ▼ am besten-- visi-on 14:15, 14. Sep. 2007 (CEST)

⊙ und/oder ▼ stehen noch zur Wahl. -- visi-on 20:34, 27. Okt. 2007 (CEST)

UTM

Hat schon mal einer ohne die Cosinus-Funktion Dezimalgrad in UTM umgewandelt? Ansonsten werde ich wohl selber die Polynomiale Näherung angehen müssen. -- visi-on 18:57, 4. Sep. 2007 (CEST)

Schade um die Mühe. Konzentrieren wir uns lieber auf die wichtigere Aufgabe, zuerst eine Vorlage zu entwickeln, die allen Ansprüchen gerecht wird. Der jetzige Vorschlag ist zwar schon sehr gut, aber noch nicht der Weisheit letzter Schluss (siehe die diversen Diskussionen oben). Außerdem bin ich nach wie vor der Meinung, dass das eine Aufgabe für eine MediaWiki-Extension ist. Da diese in PHP geschrieben wäre, wären dort keine irrwitzigen Vorlagenprogrammierungs-Kopfstände nötig. --TM 19:07, 4. Sep. 2007 (CEST)

Spielverderber ;-) jetzt darf ich hier noch nicht mal mit meinen Numerikkenntnissen auftrumpfen. Natürlich hast du recht, dass erst mal eine Einigung bei der Vorlage selbst anzustreben ist. Eine MediaWiki-Extension würde ich natürlich auch gerne annehmen. Ich lasse mich ungern vertrösten. -- visi-on 19:25, 4. Sep. 2007 (CEST)

Tja dazu muss sich aber jemand finden, der das jetzt programmiert. Ich kenne niemanden. Du vielleicht? -- sk 19:21, 4. Sep. 2007 (CEST)

Es muss auch noch einer sein, der das darf-- visi-on 19:25, 4. Sep. 2007 (CEST)

Dürfen ist erst mal nicht die Frage. Eine Extension schreiben kann jeder. Nur die Admins dann auch dazu zu bringen, die zu installieren, ist wohl ein wenig schwerer ;) --Rohieb 会話 +/- 20:38, 4. Sep. 2007 (CEST)

Wie es aussieht werden die Extensions einiges schneller geschrieben als aktiviert. MediaWiki-Extension Danke Obersachse. Wir werden also die Aktivierung abwarten. -- visi-on 21:39, 4. Sep. 2007 (CEST)

Anmerkung: Da UTM nur bis zum 84. Breitengrad definiert ist und sich dort bereits sowieso erhebliche Projektionsfehler ergeben, ist eine Taylorentwicklung bis zum dritten Grad mehr als ausreichend. -- visi-on 20:45, 15. Sep. 2007 (CEST)

Nützlich: UTM Formulas -- visi-on 14:24, 9. Nov. 2007 (CET)

freies Textformat

Zahlenbereiche in der Form a – b können auch ausgewertet werden. Sowohl die untere Limite a als auch die obere Limite b können arithmetisch ermittelt werden. (z.B. Russland). Benutzer:Visi-on/bis. -- visi-on 22:26, 18. Okt. 2007 (CEST) erledigtErledigt kein Bedarf -- visi-on 14:31, 17. Nov. 2007 (CET)

Alternativen

Ich würde das jetzt mal gern thematisieren, welche Alternativen es zu einer konventionellen Vorlage gibt, Vor- und Nachteile derselben beleuchten und die Realisierungchancen bewerten. -- visi-on 22:45, 4. Sep. 2007 (CEST)

Geo Extension

... wurde ja alles schon x-mal auf der Hauptdiskussionsseite dikutiert. Ich sehe eigentlich nur Vorteile. Das Programmieren ist dabei das geringste Problem. Schwierig wird es bei der Umsetzung. Solange kein Interesse seitens der "Georeferenzierer" besteht, werden Die "Developer" eine entsprechende Extension / Erweiterung der Mediawiki-Software nicht iplementieren.

• Vorhanden (http://meta.wikimedia.org/wiki/Gis)
• Trennung von Dateneingabe und Datendarstellung (Eingabe per Extension, Ausgabe/Einbau in verschiedenster Form per Variablen)
• Online Update der Datenbank. Die abrufbaren Daten sind +/- aktuell.
• Kein "ewiges" Anpassen von Koordinatenextraktionstools an sich ändernde Vorlagen
• Weltweit einheitliches Eingabeformat (WGS84 u.a.)

--Arcy 12:54, 5. Sep. 2007 (CEST)

Vielleicht sollten wir das mal testweise in der deutschen Wikipedia einbauen. Gibt es eine andere Webseite die Mediawiki und diese GIS-Extension nutzt? Eine Beispielseite wäre interessant. -- sk 13:45, 5. Sep. 2007 (CEST)

Die Extension ist von Benutzer:Magnus Manske. Für den testweisen Einbau sollte er vielleicht kontaktiert werden. Darüberhinaus wäre eine Datenbank nötig, die man auf dem Toolserver einrichten könnte. --Arcy 21:16, 5. Sep. 2007 (CEST)

Ich versteh noch nicht ganz, wie diese Erweiterung funktioniert. Werden die Koordinaten direkt in den Artikelquelltext geschrieben, oder erfolgt die Eingabe über ein externes Tool? Denn so wie ich das verstanden habe, sollen die Koordiaten ja in der Datenbank abgelegt werden. --Rohieb 会話 +/- 20:46, 5. Sep. 2007 (CEST)

Bei der obigen Extension werden die Koordinaten dir eckt in den Artikeltext geschrieben. --Arcy 21:17, 5. Sep. 2007 (CEST)

Die Beschreibung von region ist etwas schwammig. Mir ist nicht klar wie ich die Information erhalte in welchen Land sich der Punkt befindet. Es soll ja nicht nur deshalb zu einer Flut von Objekt in Land Infoboxen kommen, ganz abgesehen von den Grenzfällen. Eingabe in Dezimalgrad wird wohl auch gehen, auch wenn das nicht explizit erwähnt ist. -- visi-on 22:11, 5. Sep. 2007 (CEST)

Sicherlich sollte an der Extension noch einiges dran geschraubt werden. --Arcy 23:30, 5. Sep. 2007 (CEST)

Ok, schon mal gut zu wissen. Nach meinem Verständnis müsste es also noch eine Funktion {inRegion:RR} geben die je nachdem ob sich der Punkt in Region RR befindet oder nicht, 1 oder 0 zurückgibt. Eine Variable kann dies nicht erfüllen, da ein Grenzpunkt zu mehr als einer Region gehört.-- visi-on 23:54, 5. Sep. 2007 (CEST)

Nächstes Problem: Kann ich den Punkten einen Namen geben, so dass ich diese im Artikel referenzieren kann. z.B. {Eifelturm.latdegdec} von {Louvre.latdegdec} im Artikel Paris?-- visi-on 23:54, 5. Sep. 2007 (CEST)

Punkte im Artikel referenzieren ? Wofür soll das gut sein? --Arcy 16:40, 11. Sep. 2007 (CEST)

Na dann Spiel mal ein Beispiel mit mehreren Koordinaten durch. -- visi-on 21:30, 12. Sep. 2007 (CEST)

Irgendwie stehe ich bei deinen Fragen auf dem Schlauch.

1. Variablen ?
   1. Georeferenzen andere Artikel benutzen ? Da wäre dein obiges Beispiel umgedreht interessant: {{longitude:artikelname}}, {{coord:artikelname}}, ...
   2. Georefernzierung des eigenen Artikel nutzen {{longitude}}, {{coord}}, ...
2. Dateneingabe ?
   1. siehe http://meta.wikimedia.org/wiki/Gis_geo_tag#page:P
   2. ... beliebig erweiterbar.

--Arcy 20:13, 13. Sep. 2007 (CEST) Ok: dann versuch ich's mal:

• Geo tag in Artikel: <geo>48 46 36 N 121 48 51 W</geo>
• zum die Koordinaten im Artikel sichtbar machen schreibe ich zb {latdegdec}

habe ich zwei geo tags kann ich sie nicht mehr unterscheiden. Ich müsste sie benennen. zB: <geo>48 46 36 N 121 48 51 W name:Eifelturm </geo> Genau gleicher Zweck wie auch der Parameter «name» im Vorlagenvorschlag -- visi-on 21:10, 13. Sep. 2007 (CEST)

*g* aso. du wusstest also Lösung schon ;-) --Arcy 21:49, 13. Sep. 2007 (CEST)

Aber klar doch, wenn schon denn schon. «height» ist nicht unterstützt und es lässt sich für jeden Objekttyp ein Beispiel finden bei dem «pop» Sinn macht. D.h. am besten man erweitert den Geo-Tag noch um die Attribute «name», «height», «pop» und «dim». Ich kann mich natürlich erst für die Geo-Tag-Extension entscheiden, wenn diese alles liefert. Da kann ich dann sogar über den eigenen Schatten springen und die Sexagesimaleingabe gutheißen. Aber bis dahin habe ich lieber den Spatz (die Vorlage) in der Hand als die Taube (die Extension) auf dem Dach.-- visi-on 00:23, 14. Sep. 2007 (CEST)

• g* genau wenn schon den schon. Niemand backt eine Torte wenn alle nur trockenes Brot essen wollen. Und die neue Koordinatenvorlage ist schon wieder nicht kompatibel mit der weltgrößten WP.... usw... Vielleicht sollte man doch mal anfangen nach der Taube auf dem Dach zu streben. Ist ja nicht unmögliches. Und mit deinem Spatz/Taube-Vergleich scheinst du ja selber nicht so ganz von der Vorlagenlösung überzeugt zu sein. ...Guten Appetit ;-) --Arcy 10:23, 14. Sep. 2007 (CEST)

also ich würde mich für täglich Brot entscheiden. Die Vorlagenprogrammierung hat so ihre Limiten. Diese sind mit dem jetztigen Vorschlag erreicht. Um das gleiche zu erreichen muss ich nicht unbedingt auf eine Extension ausweichen.-- visi-on 11:57, 14. Sep. 2007 (CEST)

Das Gleiche wie das gleiche oder wie oder was? Wie werden in deiner Vorlage die Koordinaten gleichzeitig auch in einer Koordinatendatenbank gespeichert ? Also Wie isses mit täglich Brot + was zu trinken ? --Arcy 12:47, 14. Sep. 2007 (CEST)

Ach, dass gute Quellwasser ist hierzulande noch nicht versiegt. Das läuft aus jedem Brunnen. Du hast recht, aber der Vergleich ist beidseitig unfair. Trotzdem wieso sollte ich jetzt den Spatz aus der Hand geben. Siehst du denn nicht die Parallelen zwischen den beiden Ansätzen?

• <geo>50.31442 N 7.01015 W type:landmark name:Eifelturm dim:200 </geo>
• {{Coordinate|NS=50.31442|EW=7.01015|type=landmark|name=Eifelturm|dim:200}}

Es soll aber nicht verschwiegen werden, dass ich im Falle der Extension immernoch zur Darstellung in Text und Artikel eine Vorlage der Art {{Coordinate|article=X|text=y|name=identifier}} benötige. Von der Datenbank hat der normale WP Benutzer erst mal wenig. Kolossos und sk können erst in vollem Umfang davon profitieren, wenn diese Extension in allen WPs etabliert ist. Nun ja, aller Anfang ist schwer. Man könnte die Vorlage auch als Wegbereiter für die Extension sehen.-- visi-on 13:33, 14. Sep. 2007 (CEST)

Prototyp

Über ungelegte Eier lässt sich bekanntlich viel und lange debatieren. Ich liebe die nachträglichen Überraschungen beim Implementieren nicht so sehr. Das hat mich veranlasst schon mal einen Prototyp auf meiner Benutzerseite anzulegen. Das Resultat ist weniger komplex geworden, als ich das anfänglich befürchtet hatte. Ich wünsche viel Spass beim ausprobieren. Hinweise auf Fehler nehme ich gerne entgegen. -- visi-on 17:54, 13. Sep. 2007 (CEST)

Ah, das sieht toll aus. Nur gibts da ein kleines Schönheitsproblem mit dem Icon: Der WikiMiniAtlas zeigt nämlich vor jeder Koordinate schon einen Erdball zum Klicken an, wenn ich deinen Protoyp mit text=ICON verwende, kommen also zwei Erdbälle raus ;-) Könnte man nicht vielleicht nur ein Zeichen nehmen, zb ☼ oder ⌂? Die sind (zumindest bei mir auf WinXP) in vielen Unicode-Schriften vorhanden. --Rohieb 会話 +/- 07:49, 14. Sep. 2007 (CEST)

Wusst ich doch, dass es sich am Konkreten Beispiel besser diskutieren lässt. zum ICON-Problem-- visi-on 08:51, 14. Sep. 2007 (CEST)

erledigtErledigt Der Prototyp ist nun Serienreif -- visi-on 14:33, 17. Nov. 2007 (CET)

«dim» und «scale»

• «dim» beschreibt die größe des Objekts und wird daher auch folgerichtig für die Rundung herangezogen
• «scale» legt den Kartenmaßstab 1:«scale» fest

Die Werte sind nicht völlig unabhängug voneinander. Aber weder eine große Dimension impliziert automatisch einen kleinen Maßstab («scale» groß) noch eine kleine Dimension einen großen Maßstab («scale» klein). Geohack scheint nach wie vor «scale» zu verwenden. Hier wäre also die vorerst letzte Gelegenheit nochmals über den Parameter «scale» nachzudenken. Die Schwierigkeit bestand darin, dass nicht jeder versteht warum ein großer Maßstab durch ein kleines scale ausgedrückt wird und, dass ich einen kleinen Maßstab brauche um viel auf der Karte abzubilden. Der Maßstab ist die Vergleichsstrecke auf den Karten. Entspricht 1km der Wirklichkeit 10cm Kartendarstellung so ist das ein großer Maßstab.-- visi-on 14:01, 14. Sep. 2007 (CEST)

Für den Geohack gilt offenbar:

2*«dim» = «scale»

-- visi-on 21:09, 15. Sep. 2007 (CEST)

2 * Dim = Scale ???: Bei einer Länge von 2000 km ist dann Scale = 4000..... ;-). --Arcy 21:33, 20. Sep. 2007 (CEST).

2*2'000'000 = 4'000'000 ergo ist der Kartenmaßstab 1:4'000'000 -- visi-on 21:45, 20. Sep. 2007 (CEST)

Als Anwender wünsche ich mir statt "scale" einen Radius oder Durchmesser. Beides kann ich mir in der Wirkung vorstellen. Maßstab verstehe ich aber nur, wenn ich dessen Bedeutung gelernt und nicht wieder vergessen habe. Und vorstellen kann ich mir die Bedeutung von Maßstab nur, wenn ich regelmäßig und praktisch damit zu tun habe. "Zoom" kennt heute jeder - ein Bild machen könnte sich der nutzer m.E. am besten, wenn er etwas über das Ergebnis erfährt, also den Bildausschnitt, am augenfälligsten als Durchmesser. --Markus 15:55, 22. Okt. 2007 (CEST)

«dim» = Durchmesser des Objekts in Meter

erledigtErledigt: no «scale» -- visi-on 20:31, 27. Okt. 2007 (CEST)

Name

Besteht eigentlich schon Einigkeit bezüglich des Vorlagenamens? Mein Stand ist immernoch: -- visi-on 16:49, 15. Sep. 2007 (CEST)

Bis auf den C/K Eiertanz scheinen wir uns ja einig zu werden. Also wenn ich das in der englischen Community richtig mitverfolgt hatte, auch dort gab es Kritik an der «Coord» Vorlage, war der Tenor: «Macht mal in der deutschen WP, wir achauen uns das dann mal an.» Eine Vorlage mit Deutschem Namen werden die sich wohl kaum näher ansehen. Ja so sind sie nun mal die Amerikaner und die Briten. Die Deutschen stehen ihnen übrigens, in dieser Beziehung, in nichts nach. Das Kopieren zwischen den WPs ist nicht «one-way» Englisch→Deutsch. Mit einem «C» sind wir international dabei. Mit einem «K» bleibt es deutsche Provinz. Aus meiner Sicht ein kleines Zugeständnis an die internationale Gemeinschaft. Ich habe kein Problem mit dem «K», wenn es denn unbedingt sein muss. Aber dieses «Deutsch» Argument kann ich nicht mittragen, zumal bereits Parameter und Werte bereits in Englisch sind.-- visi-on 11:37, 21. Sep. 2007 (CEST)

Koordinate

Argumente

bereits belegt

 Pro

1. --Rohieb 会話 +/- 18:15, 15. Sep. 2007 (CEST) Wir sind ja schließlich in der deutschen Wikipedia.
2. --Arcy 20:04, 15. Sep. 2007 (CEST) Koordinate ist auch mit "K" statt "C" international verständlich. Solange international keine einheitliche Vorlage verwendet wird, ist eine Änderung imho nicht notwendig.
3. --TM 20:52, 16. Sep. 2007 (CEST) Wir sind hier in der deutschsprachigen Wikipedia, also sind deutschsprachige Autoren die vorrangige Zielgruppe. Etwas Sprachübergreifendes ergibt nur in Form einer WikiMedia-Extension Sinn (z. B. <coord>).
4. --BLueFiSH.as (Langeweile?) 18:33, 17. Nov. 2007 (CET) als Redir auf Coordinate

 Kontra

1. -- visi deutsche Vorlage / englisch (internationale) Parameter Gemisch
2. -- sk Alte Belegung ist kein Problem. Aber nicht international.

 Neutral

1. Ob mit "K" oder "C" ist m.M.n. ziemliche egal. Der Sinn ist verständlich. --Obersachse 07:24, 17. Sep. 2007 (CEST)

Ist es möglich, sowohl die internationale, als auch die deutsche Bezeichnung zu verwenden? (Bei den Artikeln heißt das Redirect). Oder gibt es da technische Hinderungsgründe? --Markus 15:40, 22. Okt. 2007 (CEST)

einen redirect auf Coordinate könnte man machen, das geht.-- visi-on 22:46, 27. Okt. 2007 (CEST)

Coordinate

Argumente

verständlich und international

 Pro

1. -- visi-on 16:49, 15. Sep. 2007 (CEST)
2. -- sk Sicherlich die beste Wahl.
3. -- Herzi Pinki 23:23, 6. Okt. 2007 (CEST) im Zweifel dafür, aber warum eigentlich nicht #Coordinates? Sind ja eigentlich zwei, Länge und Breite.
4. -- тнояsтеn ⇔ 14:13, 5. Nov. 2007 (CET)
5. --BLueFiSH.as (Langeweile?) 18:33, 17. Nov. 2007 (CET) mit Redir von Koordinate

 Kontra

1. --Rohieb 会話 +/- 18:15, 15. Sep. 2007 (CEST)

 Neutral

Ob mit "K" oder "C" ist m.M.n. ziemliche egal. Der Sinn ist verständlich. --Obersachse 07:24, 17. Sep. 2007 (CEST)

Argumente

verständlich und international, plural technisch korrekter als singular, sind ja eigentlich zwei, Länge und Breite!

Plural vs Singular

• Im Englischen bezeichnet Coordinate ein n-Tupel von Skalaren.
• Im Deutschen besteht das Tupel aus der geordneten Menge von Koordinaten. (siehe Koordinatensystem)

 Pro

1. -- Herzi Pinki 23:23, 6. Okt. 2007 (CEST) falls nicht diese Variante, dann #Coordinate

 Kontra

#-- visi-on 15:27, 8. Nov. 2007 (CET)

Hallo Visi-on, dein Kontra sei dir unbenommen, nur die Begründung dafür kann ich nicht nachvollziehen. Unter en:Geographic coordinate system heißt es: A geographic coordinate system enables every location on the earth to be specified by the three coordinates .... Unter en:Coordinate system heißt es (nicht ganz im Einklang mit deiner Aussage oben): a coordinate system (not a coordinate) is a system for assigning an n-tuple of numbers or scalars to each point in an n-dimensional space. Und weiter: a coordinate on a space is simply a function from the space [...] to the scalars (was mir allerdings in dieser Form neu ist, aber auch nicht dasselbe wie deine Aussage oben). lg --Herzi Pinki 23:22, 8. Nov. 2007 (CET)

Rückzug-- visi-on 02:47, 9. Nov. 2007 (CET)

 Neutral

Coord

Argumente

Aktueller Name der Koordinatenzusammenfassung in der englischen Wikipedia. Kann zu Verwechselungen führen

 Pro

1. --Arcy 20:10, 15. Sep. 2007 (CEST) mein eigentlicher Favorit. Man sollte sich den englischen Arbeiten zur Vereinheitlichung der Koordinatenvorlage zu mindestens über den Namen der Vorlage anschließen.

 Kontra

1. wegen der Gefahr von Verwechslungen. Gleicher Name und unterschiedlicher Aufbau führt zu Verwirrungen. --Obersachse 07:22, 17. Sep. 2007 (CEST)

GEO / Geo

Argumente

kurz und prägnant

 Pro

 Kontra

1. --sk Nicht eindeutig (könnte auch: Geologie, Geographie, Geomorphologie sein)
2. -- visi-on stimmt
3. --Rohieb 会話 +/- 18:15, 15. Sep. 2007 (CEST) richtich.
4. --Arcy 21:16, 15. Sep. 2007 (CEST)

 Neutral

regionX

Wie groß soll «X» gewählt werden?

Beispiel Rhein: CH LI AT DE FR NL

X = 6 ausreichend? -- visi-on 21:11, 19. Sep. 2007 (CEST)

Der Rhein ist ein schlechtes Beispiel. Flüsse sollte man nicht nur mit einer Koordinate beschreiben. Zumindestens würde ich denken, dass man dann eher einzeln alle besonderen Punkte Quelle, Wasserfall, Mündung einzeln als "Koordinate Text" aufführt. In der Mitte der Flusslänge kann zwar eine Koordinate für den Artikel gesetzt werden, aber die sollte dann nur die angrenzenden Regionen beinhalten. In allen anderen Fällen sollten 6 Regionen ausreichen. Wenn Deutschland noch nach Subregionen DE-BW DE-RP unterteilt wird, dann brauchen wir weit mehr als 6. -- sk 07:20, 20. Sep. 2007 (CEST)

Sicher ist der Rhein ein schlechtes Beispiel, aber genau um das ging es mir. Genau deine Aussage sollte in der Gebrauchsanleitung noch besser päzisiert werden. Ich habe ja auch gleich bei der Verallgemeinerung von Höhe «height» spezifiziert, dass das die (durch die administrationseinheit «region» gegebene) amtliche Höhe der gegebenen Koordinate sein soll. Denn theoretisch habe ich an jedem Grenzpunkt unterschiedliche Höhen. Ich lege besonderen Wert auf die Feststellung, dass eine Koordinate nur vollständig ist, wenn auch die Höhe mitgegeben ist. Falls dies bisher ungenügend zum Ausdruck kam, sollte auch dies noch besser beschrieben werden. Wir beschreiben ein geographisches Objekt, dem wir eine Koordinate (B, L, H) und weitere Attribute zuordnen. Die Region ist kein Attribut der Koordinate. Es gilt nur die Nebenbedingung, dass der Punkt Teilmenge der erstgenannten Region «region» sein muss (Eindeutigkeit der Höhe). Das Objekt Frankreich ist durch den Code FR, Elsass durch FR-A, Haut-Rhin durch FR-68 vollständig beschrieben. Die jeweiligen Subregionen sind jeweils bereits durch die Definition des Codes mitenthalten. Zurück zum Rhein:

• CH-GR, CH-SG, CH-TG, CH-SH, CH-AG, CH-BL, CH-BS, LI, AT-8, DE-BY, DE-BW, DE-HE, DE_NW, DE-RP, FR-A, NL

beschreibt den Verlauf wohl noch am besten (Aufzählung der größt möglichen Administrationseinheiten). Oder aber wir sagen: übergeordnete Objekte lassen sich keiner Region zuordnen. Kontinente sind ein ähnlich Komplexer Fall.-- visi-on 12:57, 20. Sep. 2007 (CEST)

ich lass es mal bei 4, der Rest dieser Diskussion hat weniger mit der Vorlage selbst zu tun.-- visi-on 11:52, 21. Sep. 2007 (CEST)

erledigtErledigt es können beliebig viele Regionen angegeben werden. Die ersten vier werden ausgewertet. -- visi-on 14:36, 17. Nov. 2007 (CET)

Vorgehen

Sobald Einigung über den Namen besteht würde ich gerne Die CH-Koordinate Vorlagen ersetzen. -- visi-on 11:48, 21. Sep. 2007 (CEST)

Also die Beteiligung an der Namensdiskussion hält sich derzeit in Grenzen. Ich glaube so ist das noch nicht aussagefähig. Ich werde mal einen Vermerk im Kurier machen. -- sk 22:48, 6. Okt. 2007 (CEST)

Enklave / Exklave

ein zusätzlicher Parameter «enclave»=ISO-Region-Code mit der Bedeutung „ist Enklave in Region“ würde diese nicht so seltenen und im einzelnen zum Teil recht interessanten Spezialfälle von Enklave und Exklave elegant beschreiben.-- visi-on 14:55, 27. Sep. 2007 (CEST)

Hmm, ich glaub das sollten wir vorerst mal raus lassen. Da sollte die mitauslesbare Kategorie "Enklave" doch eigentlich ausreichen um solche Spezialfälle zu filtern. -- sk 23:04, 6. Okt. 2007 (CEST)

erledigtErledigt -- visi-on 20:35, 27. Okt. 2007 (CEST)

Dezimalkoordinaten

Hallo, ich bin ja noch kein Freund von der geplanten Eingabe von Dezimalkoordinaten, aber unter http://commons.wikimedia.org/wiki/Commons_talk:Geocoding#Google_Maps_Method_Three_Use_with_Commonist findet sich eine Anleitung die die Anhänger dieses Formates freuen dürfte. --Kolossos

Ich finde Dezimalkoordinaten wunderschön einfach und einheitlich. - Aus Anwendersicht wünsche ich mir aber mehr Flexibilität, nämlich genau meine gewohnte Form benutzen zu können (zumindest die gebräuchlichen Formate). Wir können m.E. nicht erwarten, dass Nicht-Geo-Menschen eine klassische Koordinate in Dezimalzahlen umwandeln können. Wir können m.E. auch nicht erwarten, dass Anwender dazu ein wie auch immer geartetes "Tool" aufrufen (installieren und lernen). --Markus 15:48, 22. Okt. 2007 (CEST)

Habe grad nochmal das vorhergehende Kapitel über Eingabeformate gelesen. Für den Benutzer erscheint mir ein GMS-Format als Eingabemöglichkeit zwingend erforderlich! Dass dann die Verarbeitung dezimal erfolgt interessiert am Frontend nicht. Und die Profis können ja weiterhin dezimal eingeben. Wenn ich das richtig verstehe, hat Vision ja bereits etwas entsprechendes geschrieben. Nun muss dies nur noch so in den MediaWiki-Core eingearbeitet werden, dass sich der Benutzer nicht mehr mit "subst" herumschlagen muss. Erforderlich scheinen mir alle gebräuchlichen Varianten:

Eingabe einer Koordinate

im Format:

gG_mM_sS_N/S_ggG_mM_sS_E/W

gG_mM_N/S_ggG_mM_E/W

(Kleinbuchstaben = bei Null: Eingabe optional. Fehlende S oder M können weggelassen werden)

Anzeige

gG°mM'sS"N/S ggG°mM'sS"E/W ("kurz")

gG° mM' sS" N/S ggG° mM' sS" E/W ("schön")

(Kleinbuchstaben = bei Null: Ausgabe als Leerzeichen. Fehlende S oder M ganz weglassen)

Ich hoffe, dass die Geo- und Programmierspezialisten hier nun nicht über die "dummen Benutzer" schimpfen... Gruß, --Markus 16:20, 22. Okt. 2007 (CEST)

Wir haben bei der Programmierung mit ein paar Einschränkungen zu Leben.

• Es gibt zB. keine substr Funktion. Somit ist ein Parsen der Eingabe nicht möglich.
• Eine DMS Eingabe würde eine sehr komplexe Eingabekontrolle erfordern. Programmcode der immer mitinterpretiert wird. Auch dann, wenn die Eingabe korrekt ist. Ein Aufwand der die Server rasch in die Knie zwingen kann. Faktisch hätten wir dann an Stelle von zwei Parametern sogar deren sechs, falls Nord/Süd und Ost/West noch dazu kämmen, sogar deren acht. Die Benutzerfreundlichkeit wird dadurch nicht erhöht.

-- visi-on 21:03, 27. Okt. 2007 (CEST)

Hm - ich verstehe, dass es für die Programmierer dezimal einfacher wäre. Aber eine Substring-Funktion gehört doch heute zu den Basics? Vielleicht sollten wir die einfach einführen? Die Zeiten, wo Anwender sich nach "Maschinencode-Spezifikationen" richten mussten, sind im Web2.0-Zeitalter doch vorbei?! Der OMA-Test wurde zwar für Leser geschrieben, aber ich finde, etwas abgewandelt gilt er auch für Anwender von Vorlagen. In diesem Fall: die Vorlage:Koordinaten soll ja von allen Autoren genutzt werden können, nicht nur von Vermessungsingenieuren, Piloten und Nautikern. Und die Eingabekontrolle kann doch auf die Rechner der Anwender ausgelagert werden? Eine Rechtschreibprüfung haben wir ja bereits. Wäre doch gelacht, wenn WP nicht hinkriegt, was GoogleMaps kann... Gruß, --Markus 09:03, 28. Okt. 2007 (CET)

eine generelle substr Funktion darf es in Wikipedia nicht geben, denn damit hätte man "while" bzw "recursion" durch die Hintertür und das Tor für bösartige Attacken sperrangelweit offen. Ein subset ist seit längerem zur Integration vorgeschlagen. Es geht nicht darum es dem Programmierer einfacher zu machen. Das ist ein Einmaliger Aufwand. Gut es sollte noch wartbar bleiben. Unter einer übermässigen Serverbelastung hat in erster Linie der Benutzer zu leiden. Für gewisse Wünsche ist einfach der zu zahlende Preis zu hoch. -- visi-on 09:26, 28. Okt. 2007 (CET)

• StringFunctions-- visi-on 09:32, 28. Okt. 2007 (CET)

Danke Visi-on für Deine Erläuterung. Angriffe will ich natürlich auch verhindert wissen, da nehme ich lieber eine notwendige Einschränkung in Kauf. Allerdings verstehe ich als Laie nicht, wieso "alle anderen" das realisieren zu können scheinen und WP nicht. Danke für den Link zur Extension Substring. Heißt das, dass diese Funktion bald zur Verfügung steht? Dann könnte ja die neue Vorlage vielleicht bereits jetzt dafür vorbereitet werden?

Denn das Anliegen des Anwenders, Koordinaten in gewohnter Form eingeben zu können, und mein Anliegen, vom Anwender keine Umrechnung verlangen zu müssen, ist ja bisher noch nicht erfüllt. Gruß, --Markus 09:53, 30. Okt. 2007 (CET)

Bedenke einfach, dass «in gewohnter Form» für jeden etwas anderes bedeutet. Für die Britten ist das OSGB, für die Schweizer sind das die Landeskoordinaten und für nicht wenige Deutsche UTM. Da ist die Umrechnung Dezimal/Sexagesimal noch ein kleiner Fisch. Die Koordinate ist ein Zahlenpaar bestehend aus Längen- und Breitengrad. Wie du darauf kommst, dass einige Benutzer darin einfach einen Zahlencode sehen kann ich nicht nachvollziehen. Das würde ja heißen, dass diese nicht in der Lage sind eine Koordinate aufzufinden. -- visi-on 23:53, 30. Okt. 2007 (CET)

Also wenn "die gewohnte Form" sich wirklich nur auf 3..4 Formen beschränkt, dann müsste das doch machbar sein?

Das mit dem "Koordinate=Zahlencode" mag ich gerne erläutern: Durchschnittsmenschen (also Nicht-Ingenieure/Piloten/Nautiker) verstehen unter einer Koordinate einfach eine Ortsbezeichnung i.S.v. "hier". Sie stellen sich darunter nicht ein 2 oder 3-dimensionales Grid vor. Und ja: die meisten menschen sind nicht in der Lage, eine Koordinate aufzufinden (es sei denn, sie haben ein Navi und können die Koordinate i.S. einer "Ortsbezeichnung" eintippen). Drei Beispiele aus der Praxis: In der Schweizer Armee wird das "Kartenlesen" geübt. Das mit den Koordinaten verstehen viele nicht. Dabei ist es doch in der Schweiz besonders einfach, lauter quadratische Kästchen mit 1 km Kantenlänge. So richtig fit sind nur die Artilleristen (und die sind ja wieder halbe Vermessungsingenieure). Ich habe früher Sportlehrer in Orientierungslauf ausgebildet. Das mit den Koordinaten war immer etwas vom Schwierigsten. Deshalb werden sie durch fix auf der Karte eingetragene Standort-Kreise ersetzt. Bei der Ausbildung von Hochseeskippern gehört das Verständnis von Koordinaten und Maßstäben zu den schwierigeren Dingen (mal abgesehen von Astronavigation, aber das macht heute sowieso keiner mehr) und die Frauen tun sich damit meist noch schwerer als die Männer. Und da wird nichts umgerechnet, sondern es werden nur Koordinaten aus Karten ausgelesen oder in solche eingetragen. - Und WP erwartet nun von ihren Autoren, dass sie Sexagesimal in Dezimal umrechnen können sollen?! - Wie gesagt: ich fände eine Eingabe in "gewohnter Form" wesentlich fehlerfreier... Gruß, --Markus 23:50, 31. Okt. 2007 (CET)

Also mir ist sehr unwohl dabei, wenn ein Benutzer, der nicht in der Lage ist eine Koordinate umzusetzen (aufzusuchen), einen Eintrag macht. Da ist mir viel lieber er setzt einfach die Vorlage:Lagewunsch ein. In Bezug auf die Eingabefreundlichkeit bist du nicht allein. Ich selbst hatte schon wehement für die Schweizer Landeskoordinaten gestritten. UNter den jetztigen Bedingungen reizt der vorhandene Vorschlag die Möglichkeiten der Vorlagenprogrammierung aus. Zusätzliche Benutzerfreundlichkeit geht zwangsläufig mit einer höheren Serverbelastung einher. Entscheidender Vorteil der Dezimalwerte ist, dass diese auch für Positionskarten verwendet werden können. Nur im Dezimalformat können die Koordinaten auch innerhalb der WP mit vertretbarem Aufwand weiter verwendet werden. Allein diese besserer Integration rechtfertigt einige Einschränkungen bzw. Umgewöhnungen. Ich denke deine Anliegen sind nur in einer «Geo Extension» realisierbar. Aus diesem Grund bin ich auch dagegen diese neue Vorlage nun dogmatisch durchzusetzen. Ziel der Initianten war es vorallem die in gesonderten Vorlagen erzielten Teilverbesserungen zusammenzuführen. -- visi-on 11:30, 1. Nov. 2007 (CET)

Und diese Ziel habt Ihr ja erfolgreich umgesetzt - danke! Und Du hast natürlich recht: wer keine Koordinaten bestimmen kann sollte lieber den Wunsch-Baustein setzen.

Bei der potentiellen Bedeutung von Koordinaten zur Beschreibung von Wissen wäre eine "Geo-Extension" sicher hilfreich. Bis dies realisiert ist, wäre ein einfach zu bedienendes Tool zur Ermittlung von Dezimal-Koordinaten direkt aus der Karte sinnvoll. Und wie gesagt: danke für Eure Arbeit! Gruß, --Markus 13:21, 1. Nov. 2007 (CET)

erledigtErledigt DMS Eeingabe geht.-- visi-on 14:38, 17. Nov. 2007 (CET)

Hallo Visi-on und Markus, ich habe lange nicht die Diskussion gelesen und stelle mit Erschrecken fest, dass jetzt plötzlich das Konstrukt "NS=49/45/34.85/N|EW=6/38/38.47/E" möglich sein soll. Ich bin sehr dagegen, weil wir uns da wieder eine riesige Fehlerquelle einhandeln. Man glaubt gar nicht, wieviele Fehler da beim Eintippen passieren können. Wenn wir das mit einbauen, was ja Visi-on schon gemacht hat, dann tun wir uns sehr viel potential in der Zukunft verbauen. Die Auswertung wird wieder komplizierter und die Übersichtlichkeit leidet auch extrem. Bitte nochmal Nachdenken ob das wirklich sein muss. -- sk 09:20, 24. Dez. 2007 (CET)

Und ich bin sehr froh darüber, daß es möglich ist, das sehr weit verbreitete Format Grad-Minute-Sekunde direkt zu verwenden. Meiner Meinung nach werden gerade dadurch Fehler vermieden, daß nicht erst umgerechnet werden muß. --Obersachse 12:46, 24. Dez. 2007 (CET)

Ich schließe mich Obersachses-Meinung an, da die Umrechnung in Dezimalkoordinaten auch nicht verlustfrei möglich ist. Für die Auswertng ist es natürlich etwas komplizierter. Da es also Vor- und Nachteile gibt, könnte man die Entscheidung ja durchaus noch ins Meinungsbild integrieren. --Kolossos 13:19, 24. Dez. 2007 (CET)

Zugegeben D/M/S/± glänzt nicht durch besonders schöne Darstellung, aber es ist derzeit die einzige Möglichkeit dieses Format einigermaßen vernünftig (mit einem Parameter) zu unterstützen. Wie ihr unschwer aus dem Diskussionsverlauf erkennen könnt habe ich mich mit der DMS Eingabe schwer getan. Schlussendlich war für mich entscheidend, dass ich den Leuten nicht unbedingt etwas wegnehmen kann, und derzeit ist sowhl DMS- als auch DEC-Eingabe möglich. Fehlerhafte Eingaben, lassen sich weder noch ausschließen. Zusätzliche Prüfungen sind möglich, bedürfen aber einer besonderen Kosten/Nutzen-Analyse und Bewertung.-- visi-on 20:49, 27. Dez. 2007 (CET)

Funktion und Parameter

Ich habe noch nicht vollumfänglich verstanden, was die neue Funktion alles leisten soll. Als Autor habe ich folgende Anforderungen:

1. gewohnte Eingabe
2. konfigurierbares Ausgabeformat (Standard DMS, oder sehr kurz ohne Leerzeichen, oder Dezimal)
3. konfigurierbare Positionierung der Ausgabe (Standard: da wo die Koordinate steht)
4. Ausgabe als Karte (Link, mit Parameter "Durchmesser")

Das hilft dem Leser, ein Objekt im Artikel auf einer Karte (oder mit seinem GPS) zu finden.

Die Georeferenzierung wäre mir erst an zweiter Stelle wichtig. Aber vielleicht habe ich da auch etwas falsch verstanden? Ich finde es gar nicht so erstrebenswert, alle Objekte bei Google zu "melden". Ich finde es auch nicht hilfreich, wenn ich auf meinem xy-Map vor lauter Objekten "die Welt" nicht mehr sehe. Aber vielleicht habe ich da ja ganz falsche Befürchtungen?

Denoch bin ich natürlich gern bereit, durch Ausfüllen zusätzlicher Parameter einen Beitrag zum "großen Ganzen" zu machen! Nicht verstanden habe ich aber in diesem Zusammenhang die Parameter:

type

Wenn ich das richtig verstehe, beinhaltet dieser ein komplettes Kategoriensystem? Als Seefahrer fiele mir da noch ein: Seehäfen, Sportboothäfen, Ankerbuchten, Tankstellen, Werften, Segelmacher, Küstenfunk-Stationen, Gefahrenstellen, Schiffahrtstrassen, Seezeichen, etc. Wie ist das System gedacht?

Region

Welche Ausprägungen sind da möglich/sinnvoll? Gibt es da sowas wie "Saronischer Golf" oder "Attika-Küste"?

pop

spätestens hier komme ich mit meinem relationalen Denken in Konflikt: wieviele "Einwohner" hat denn ein "Wrak"? oder eine "Eisenbahnbrücke"?

Klar sind für mich die Parameter "Koordinate" (falls dreidimensional noch "Höhe"), und optional "Durchmesser", "Ausgabeformat" und "Ausgabeort". Sowie ein "Text" als eventuelle Bildbezeichnung oder so. Aber die anderenParameter? Ob das anderen Anwendern auch so geht? Aber wie gesagt: ich bin noch nicht mal sicher, ob ich das Projekt richtig verstanden habe... Gruß, --Markus 17:05, 22. Okt. 2007 (CEST)

Kartenanzeige

hier sollte für die Zukunft die Möglichkeit offen bleiben, eine bestimmte Karte direkt anzusteuern (vielleicht haben wir ja bald eine eigene "WikiMaps"?!) und diese auch in einen extra Fenster zu öffnen (Popup). Der heutige Umweg über die vielseitige "Auswahl" ist ja eher ein Tribut an das Gebot zur "Unabhängigkeit", und für den Anwender eher lästig. Der Anwender will einfach kurz sehen, wo das denn ist worüber er gerade liest, und sich nicht in anderen Websiten verfangen. Gruß, --Markus 17:14, 22. Okt. 2007 (CEST)

Anwenderfreundlich wäre auch ein Popup-Fenster in der Größe der angezeigten Karte (damit der zugehörige nicht einfach "verschwindet". --Markus 15:41, 25. Okt. 2007 (CEST)

Koordinate

hier empfehle ich dringend die zusammenhängende Schreibweise für yx. Der normale Nutzer denkt da an eine schlichte Ortsbezeichnung, nicht an ein Grid mit 2 bis 3 Dimensionen und möglicherweise noch einer Krümmung oder Verzerrung. Im Backend können die Dimensionen selbstverständlich getrennt verarbeitet werden. Für Getrenntverarbeitung im Artikel (Tabellen) muss es sogar eine Vorlage geben, die x und y trennt - aber eben nur für spezielle Anwendungsfälle. Gruß, --Markus 17:22, 22. Okt. 2007 (CEST)

Es geht um den möglichst vollständigen Ersatz der in Kategorie:Vorlage mit Koordinate unter ! aufgeführten Vorlagen und Vereinfachung der Programierung von Infoboxen insbesondere wenn diese, wie die Vorlage:Infobox Ort in Deutschland, eine Positionkarte enthalten. -- visi-on 21:16, 27. Okt. 2007 (CEST)

Decken denn die alten, zu ersetzenden Vorlagen, und die neue, "meine" oben beschriebenen Wünsche ab? Wie funktioniert das System hinter den Parametern "typ" und "pop"? Eine "Koordinate" ist für den durchschnittlichen Anwender einfach eine Ortsbezeichnung, die er einem String eingeben und ausgegeben haben will. Gruß, --Markus 09:20, 28. Okt. 2007 (CET)

Die Parameter sind im Wikipedia:WikiProjekt Georeferenzierung beschrieben. Neu ist eigentlich nur, dass die Koordinate nun ein Zahlentupel ist und der Parameter typ keinen kontextabhängigen Wert mehr hat. Diese Werte haben nun eigene benannte Parameter (population und elevation). Wäre evtl noch zu überlegen auch population auszuschreiben. Im wesentlichen sehe ich deine Anforderungen erfüllt, wenn auch im Detail durchaus Differenzen und andere Gewichtungen erkennbar sind. Ganz Recht wird man es wohl niemandem machen können. Auch ich hätte da noch so ein paar Wünsche. Insgesamt bin ich aber mit dem erreichten Kompromiss sehr zufrieden. -- visi-on 23:33, 30. Okt. 2007 (CET)

erledigtErledigt

height

Der Parameter height soll für die Höhe über dem Meeresspiegel stehen. Unter height würde ein Englischsprecher aber eher die Höhe über Grund verstehen. Wenn die Parameter schon englisch benannt werden, sollte es elevation genannt werden. --08-15 22:33, 27. Okt. 2007 (CEST)

Danke für den Hinweis-- visi-on 22:40, 27. Okt. 2007 (CEST)

erledigtErledigt auf elevation angepasst -- visi-on 23:06, 27. Okt. 2007 (CEST)

neue Vorlage

Wo kann ich mir die neue Vorlage anschauen? --Markus 09:58, 30. Okt. 2007 (CET)

Gefunden:

• Vorlage:Coordinate
• Coordinate/Test
• Angewendet in: Seehafen (benutzt Vorlage:Seehafen und Vorlage:Coordinate)

hm - was habe ich da falsch gemacht? Die Koordinate wird nicht angezeigt. --Markus 11:45, 30. Okt. 2007 (CET)

deshalb

• kleinschreibung
• plus Kosmetik bei mir und dir (default Behandlung)

in diesem Sinne Danke fürs testen -- visi-on 23:01, 30. Okt. 2007 (CET)

Danke fürs Verbessern! Das Ganze ist für mich schon noch etwas verwirrend. Hier ein etwas komplexerer Versuch mit if:

• Angewendet in: Törnbericht (benutzt Vorlage:Törn, Vorlage:BS und Vorlage:Coordinate.

Wo bin ich diesmal gestolpert? Gruß, --Markus 23:18, 31. Okt. 2007 (CET)

an den externen Links -- visi-on 12:53, 4. Nov. 2007 (CET)

Die sind doch für die Kartendarstellung erforderlich? Wie gehts richtig? --Markus 13:41, 4. Nov. 2007 (CET)

In Seehafen (Vorlage:Seehafen) habe ich zwei Koordinaten mit unterschiedlichem "dim=" angegeben. In der Anzeige ist aber keine Unterschied sichtbar. Sie ist auch in beiden Fällen wesentlich größer als dim+x. Unter "Durchmesser" verstehe ich den Durchmesser des Objektes in Metern, und die Anzeige der Karte mit Zoom=Durchmesser+x als Inkreis des Bildschirmes (oder so). --Markus 14:28, 4. Nov. 2007 (CET)

das ist einerseits davon abhängig was Magnus auf dem Toolserver mit dieser «dim» Angabe anstellt und andererseits wie die Onlinekarten einen gewünschten Maßstab wiedergeben, auf einen eigenen Raster abbilden oder ignorieren. -- visi-on 22:03, 4. Nov. 2007 (CET)

erledigtErledigt

Ideen

1. als Standard wäre "text=DMS" vorzuziehen. Verschiedene Koordinaten im Text sind häufiger als generelle für einen ganzen Artikel. Das würde den Code verkürzen. Wäre auch bei der Vorlagenprogrammierung einfacher und in Listen und Tabellen. Also immer da wo die Vorlage aufgerufen wird, wird standardmässig auch die Koordinate angezeigt. --Markus 14:08, 1. Nov. 2007 (CET)

2. Bei type wäre "type=port" sinnvoll, um die Seehäfen zu lokalisieren. (siehe "type=airport") --Markus 14:08, 1. Nov. 2007 (CET)

zu 1: bisher war es das vornehmliche Ziel Artikel mit Koordinaten zu versehen. Falls es vermehrt zu dem Wunsch kommt Kootdinaten im Text einzubauen sollte man sich noch dringend über einen Parameter «notextlink» gedanken machen. -- visi-on 13:07, 4. Nov. 2007 (CET)

zu 2: für mich schlüssig, einen diesbezüglichen Entscheid kannst du direkt auf der Projektseite herbeiführen.-- visi-on 13:07, 4. Nov. 2007 (CET)

sorry, ich meinte hier: Wikipedia Diskussion:WikiProjekt Georeferenzierung-- visi-on 22:06, 4. Nov. 2007 (CET)

3. Output "text=GMS" unterdrückt Nullen. Das macht in Tabellen einen unschönen und schwer zu lesenden Flattersatz (der wahrscheinlich so auch nicht sortierbar ist!). Besser fände ich führende Nullen anzugeben oder durch Leerzeichen zu ersetzen. --Markus 17:59, 5. Nov. 2007 (CET)

Puh, ich glaube nicht, dass sich der Sinn von 001° 02' 03" jedem sofort erschließt und zusätzliche Leerzeichen würden nur in einem Schrifftsatz mit konstanter Zeichenbreite Sinn machen. Aber auch hier wirkt   1°  2'  3" im Fließtext recht störend auf den Lesefluss. Zur Sortierbarkeit muss ich mich noch schlau machen.-- visi-on 21:24, 5. Nov. 2007 (CET)

Bei Sortierbedarf: Vorlage:SortKey -- visi-on 21:54, 5. Nov. 2007 (CET)

SortKey analog obiger Vorlage eingebaut. -- visi-on 23:11, 5. Nov. 2007 (CET)

erledigtErledigt

Längengrad an Süd- und Nordpol

Ich hab mir den Code nicht angeschaut, aber die Ergebnisse sehen schon ganz gut aus. Bei den Polen würde ich ruhig auch einen Längengrad mit angeben. -- sk 10:28, 13. Sep. 2007 (CEST)

die Längengrade sind doch mit 0-360° nicht definiert.-- visi-on 14:24, 13. Sep. 2007 (CEST)

Dann setze ihn einfach auf Null, das ist besser, als wenn der Längengrad fehlt. Wenn die Zahlen fehlen, bereitet das bei der Auswertung nur zusätzliche Schwierigkeiten. -- sk 16:56, 15. Sep. 2007 (CEST)

Du meintest, die Eingabe eines Breiten- und Längengrades soll Pflicht sein. Naja erstmal alles so programmieren, dass es auch ohne Eingabe tut war einiges schwieriger. ich weiß nun wo ich die Nullen entfernen muss. -- visi-on 00:15, 16. Sep. 2007 (CEST)

Besser: Test ob Längen- und Breitengrad gegeben und Berechnungen so lassen wie sie sind, gibt sonst unübersichtliche Fehlerwürmer. -- visi-on 01:48, 16. Sep. 2007 (CEST)

erledigtErledigt -- visi-on 10:55, 27. Sep. 2007 (CEST)

Exponential-Darstellung von Zahlenwerten

bereitet mir mehr Mühe. Die FUnktion #expr, gibt unkontrolliert einmal das Resultat in Exponential Darstellung und einmal normal zurück.-- visi-on 15:06, 13. Sep. 2007 (CEST)

ich meine gefunden zu haben (Integer + Integer in Vorlage:WGS84-CH1903). Falls Bern wieder mit (6E+5/2E+5) Koordinaten daher kommt bitte melden. -- visi-on 14:17, 15. Sep. 2007 (CEST)

Umgehung mit {{#switch:{{{1}}} |7.0E+5=700'000 |6.0E+5=600'000 |5.0E+5=500'000 |3.0E+5=300'000 |2.0E+5=200'000 |1.0E+5=100'000 |#default={{{1}}} }} erledigtErledigt -- visi-on 10:54, 27. Sep. 2007 (CEST)

Format DEC

Für das Format DEC hatte ich mir mal ausgedacht, dass die Werte genau so dargestellt werden wie sie eingegeben wurden. Dann werden aber nicht die gleichen Werte an Geohack übergeben. Ich denke diese Ausnahme für DEC war keine so gute Idee. Falls es keine Einwände gibt ändere ich das ab.-- visi-on 00:22, 16. Sep. 2007 (CEST)

erledigtErledigt bereits getan -- visi-on 02:02, 16. Sep. 2007 (CEST)

Test

Der Entwickler ist bekanntlich der schlechteste Tester und die Dokumentation ist meist auch nicht von bester Qualität. Es wäre also schön wenn sich dieser Aufgabe noch ein paar Freiwillige annehmen würden.-- visi-on 13:30, 10. Nov. 2007 (CET)

Tester

• тнояsтеn ⇔ 13:43, 10. Nov. 2007 (CET)

Lektoren

• тнояsтеn ⇔ 13:43, 10. Nov. 2007 (CET)

Dokumentation

• --Mcaviglia 15:57, 23. Jan. 2008 (CET)

Status

Vorlage:Coordinate ist nach gröberem Umbau wieder stabil.-- visi-on 14:47, 17. Nov. 2007 (CET)

Beta - Version -- visi-on 12:59, 4. Dez. 2007 (CET)

Anregungen

Ost oder Est

Sollte bei östlicher Länge in der Ausgabe statt E nicht besser O verwendet werden? --тнояsтеn ⇔ 16:44, 17. Nov. 2007 (CET)

Wohl eher nicht. E ist international üblich. Siehe dazu auch Windrose. "Osten wird in der Seefahrt immer mit E (Englisch East) abgekürzt, um eine Verwechslung mit der Null (O ↔ 0) zu vermeiden." --Obersachse 17:36, 17. Nov. 2007 (CET)

Bei den Artikeln zu Windrose finde ich allerdings folgende Bilder: 1, 2, 3. Der gewöhnliche Wikipedia-Nutzer ohne Seefahrtkenntnisse weiß wahrscheinlich mit einem E wenig anzufangen. --тнояsтеn ⇔ 18:09, 17. Nov. 2007 (CET)

das O (in der Ausgabe) wäre konform zu WP:GEO#Koordinaten-Wert, das E nicht. Außerdem, immer an die Oma denken, die ist eventuell noch nicht zur See gefahren. --Herzi Pinki 18:19, 17. Nov. 2007 (CET)

Nur keine Sonderbehandlung von Text oder Artikel. Einigt euch! -- visi-on 17:14, 27. Nov. 2007 (CET)

Ich vermute, im Französischen ist das Problem mit O(Ouest) und E(Est) nochmals anders gelagert, d.h. bei O besteht eher nicht die Verwechslungsgefahr mit der Null, sondern mit dem französischen Ouest. Allerdings schreiben wir für die deutsch(sprachige) WP, nicht für die Schweizer WP, oder? Oder haben wir da wieder eine Schweizbezogenheit, wie bei der Schreibweise von Zahlen, dem ß -ss-Problem? Da der Anzeigestring aber jetzt nicht übergeben, sondern generiert wird, lässt sich dieses Problem in der Vorlage jederzeit anders lösen. Mein Vorschlag als Nicht-Schweizer nach wie vor O --Herzi Pinki 01:41, 28. Nov. 2007 (CET)

Es hat mal Ausnahmsweise nichts mit den Schweizern zu tun, Aber das «O» ist international nicht eindeutig und kann nicht nur mit 0 verwechselt werden. Es müssen in zwei Untervorlagen («to DEC» und «to DMS») je ein Buchstabe ausgetauscht werden. Das ist alles. -- visi-on 01:50, 28. Nov. 2007 (CET)

Verstehe noch nicht so ganz, warum es international eindeutig sein muss, wenn es in deutschsprachigen Artikeln verwendet wird. --тнояsтеn ⇔ 09:16, 28. Nov. 2007 (CET)

Es muss nicht, es kann und man kann es jederzeit wieder ändern. Da die gleiche Untervorlage für Text und Artikel verwendet wird, mag ich nur nicht zwischen Text und Artikel unterscheiden.-- visi-on 11:45, 28. Nov. 2007 (CET)

Das ist klar, es sollte für Artikel und Text dasselbe sein. Naja, an O oder E sollte die Einführung der neuen Vorlage nicht scheitern ;-) --тнояsтеn ⇔ 11:51, 28. Nov. 2007 (CET)

In einem deutschen Text wird das E wohl manche stören. Im Artikel oben rechts wäre es, weil eindeutiger, eher zu bevorzugen. -- visi-on 12:20, 28. Nov. 2007 (CET)

Ich habe mal «to DEC» auf deutsch umgestellt und noch mit Tipps versehen. Ich bitte um Feedback bevor ich das auch noch für «to DMS» ausbeineln tu.-- visi-on 15:44, 28. Nov. 2007 (CET) erledigtErledigt Ost -- visi-on 14:08, 1. Dez. 2007 (CET)

Mikroformat

Wenn es so einfach ist, dann kann man es auch machen erledigtErledigt-- visi-on 20:12, 15. Dez. 2007 (CET)

Ausgabe

Wie auch immer das passieren konnte, ist die ganze Sache mit der neuen Koordinatenvorlage bisher an mir vorbeigegangen, obwohl ich ja regelmäßig Koordinaten erstelle und auch die Basis-Projektseite auf meiner Beobachtungsliste habe. Jetzt musste ich die Projektseite hier erst zweimal lesen, bevor ich alles einigermaßen verstanden habe. Die Beschreibung müsste wohl noch einmal etwas klarer gefasst und die vielen Dopplungen entfernt werden.
Mit den meisten der vorgeschlagenen Änderungen kann ich gut leben. Mir gefällt allerdings die Koordinatenausgabe (in DMS) im Test nicht. Das fehlende Leerzeichen zwischen der Grad- und der Sekundenangabe finde extrem irritierend. Wenn, wie im dargestellten Beispiel, auf das Gradsymbol direkt eine 1 folgt, fließen die beiden Zeichen auf meinem Monitor ineinander, was ich sehr verwirrend finde. Ich wäre sehr dafür, hier wieder ein Leerzeichen zur Trennung von Minuten und Sekunden vorzunehmen. --Martin Zeise ✉ 12:02, 18. Dez. 2007 (CET)

Stimmungsabfrage

Ist denn nun noch jemand gegen die Vorlage, kann man das überhaupt noch sein ;-) -- visi-on 17:14, 27. Nov. 2007 (CET)

Benutzer:Visi-on ist glaube ich noch etwas unglücklich über die Nichtberücksichtigung des Schweizer Systems (als Eingabeformat Anmerk.: -- visi-on 02:26, 28. Nov. 2007 (CET)), aber sonst sind mir keine Klagen zu Ohren gekommen ;-) --Obersachse 20:13, 27. Nov. 2007 (CET)

Braucht es noch ein Meinungsbild wenn bereits ein Konsens erzielt wurde?-- visi-on 16:36, 28. Nov. 2007 (CET)

Von mir ein klares Ja. Es braucht ein kleines Meinungsbild auf WP:GEO um später eine breite Basis zu haben und damit sich die Leute damit beschäftigen. Zudem bin ich mir selbst noch nicht sicher, ob ich nicht dagegen sein soll, aber nachdem selbst DMS sauber unterstützt zu werden scheint und es somit kein Umrechenungenauigkeiten geben sollte, spricht eigentlich nix dagegen. Bin nur leider zur Meinungsbildvorbereitung noch nicht gekommen.

Wieviel Vorlagen werden eigentlich für das neue System gebraucht? Und wieviele Leute außer Vision verstehen die Vorlagenprogrammierung? Das wäre noch mal ein wichtiges Argument Richtung Zukunftssicherheit, die Dokumentation sieht ja sehr gepflegt aus. --Kolossos 17:12, 28. Nov. 2007 (CET)

Vorlage:Coordinate#Struktur gibt da Auskunft (12 ich zähle mal KoordinateURL mit Nachtrag -- visi-on 18:56, 28. Nov. 2007 (CET)). Zur Zeit besteht die Dokumentation der Unter-Vorlagen nur aus einem Link auf die Hauptvorlage. Eine ausfühliche Dokumentation, auch der angewendeten Programmiertricks, möchte ich aber erst im Hauptnamensraum machen, denn das verschieben von Seiten macht auch Arbeit. Außerdem ist gedacht, die Untervorlagen, die nur von der Vorlage Coordinate gebraucht werden sollen auf deren Unterseiten zu verschieben, im englischen Template Coord machen sie das auch so, die haben auch in der Kategorie:Vorlage:für Vorlagen nichts zu suchen. Der Vorlagenprogrammierer soll nicht auch noch eingeladen werden diese Vorlagen außerhalb zu verwenden.-- visi-on 18:13, 28. Nov. 2007 (CET)

Ohne Feedback kann ich das natürlich schlecht beurteilen, wie leserlich der Code ist. Was ich bis jetzt gesehen habe, gibt es auf jedenfall wenig vergleichbares in der deutschen WP. Auf die Syntax habe ich keinen Einfluss. Die interpretierende Einbindung der Vorlagen erfordert ebenfalls ein paar nicht sofort nachvollziehbare Tricks deren Funktionsweise leider nur in englisch auf en:Wikipedia:Template limits umfassend beschrieben sind. Dafür sind die einzelnen Vorlagenteile jeweils klein, kompakt und übersichtlich geworden. In der Regel kann der gesamte Code im Fenster betrachtet werden. Die Schlüsselstellen sind beschrieben. den Vergleich mit en:Template:Coord brauche ich auf jedenfall nicht zu scheuen. Befürworter dieser Vorlage dürfen mir gerne mal den Code von Coord erklären. Ich lehn mich schon mal zurück ;-) -- visi-on 17:35, 29. Nov. 2007 (CET)

Die Komplexität der alten Vorlage könnte man aber auch als Vergleich nehmen:

<span class="coordinates">[{{KoordinateURL}}{{{1}}} {{{2}}}]</span>

Ok, das ist gemein. --Kolossos 18:33, 29. Nov. 2007 (CET)

Das relativiert sich dann wieder, wenn ich auch noch die Verwendungen, wie zB. in Vorlage:Infobox Gemeinde in Deutschland oder Vorlage:Infobox Ort in der Schweiz, in einem vorher nachher Vergleich mit einbeziehe. Die x-fache Verlagerung der Komplexität auf andere Vorlagen schlägt auch kräftig zu Buche. Aber ich seh schon du sammelst bereits pro und kontra Argumente für das Meinungsbild. Da will ich dich natürlich nach Kräften unterstützen. -- visi-on 19:15, 29. Nov. 2007 (CET)

Glücklicherweise müssen wir hier auch nicht zu einer ganzen Coor-Vorlageninflation Rückwärtskompatibel sein.-- visi-on 13:05, 4. Dez. 2007 (CET)

Meinungsbild

Was wollen wir durch das Meinungsbild klären und dokumentieren. Ich denke es gibt drei Abstufungen

1. es bleibt beim Status Quo
2. Ersetzen der früheren Versuche zu einer besseren Vorlage
   1. Vorlage:CH-Koordinate (Provisorium)
   2. Vorlage:CH-Koordinate Text Artikel (Provisorium)
   3. Vorlage:Geo-Koordinate (ca. 60 mal im Hauptnamensraum)
   4. Vorlage:Geo-Koordinate Text Artikel (ca. 40 mal im Hauptnamensraum)
   5. Vorlage:Koordinate (Provisorium, aus Vorhaben Wikipedia:WikiProjekt Georeferenzierung/Vorlagen entstanden)
   6. Vorlage:Coor dm (in der en:WP durch Coord ersetzt)
   7. Vorlage:Coor dms (in der en:WP durch Coord ersetzt)
3. die neue Vorlage ersetzt alle älteren

• zu 2 und 3 den Namen der Vorlage

-- visi-on 13:23, 4. Dez. 2007 (CET)-- visi-on 22:14, 6. Dez. 2007 (CET)

Parameter "MouseOver"

Wie kann man beim Parameter "text=ICON1" einen Zusatztext angeben, der bei "MouseOver" erscheint? Bei WikiMiniAtlas erscheint beispielsweise "Ort auf interaktiver Karte anzeigen". Bei coordinate erscheint das Artikellemma - aber das ist bei Koordinaten im Text meist falsch. Gruß, --Markus 12:06, 18. Dez. 2007 (CET)

Der Tool-Tip enspricht dem Namen des Objekts. Ich denke ein Roman ist kaum erwünscht. Koordinaten im Text sollten zur Unterscheidung immer auch mit einem Namen bezeichnet sein. Steht wohl zu wenig deutlich in der Dokumentation.

|name= Punkt

⊙47.6543217.654321 -- visi-on 12:20, 18. Dez. 2007 (CET)

Ja, genau danach hatte ich gesucht, danke. Seit der Freischaltung von Wikiatlas erscheint der Globus, aber der ist für Fließtexte zu groß. Gruß, --Markus 13:19, 18. Dez. 2007 (CET)

Nicht meine Baustelle ;-), aber ich habe nach einer kleinen Änderung auch noch die Dokumentation ergänzt. -- visi-on 13:35, 18. Dez. 2007 (CET)

Sieht in Tabellen irgendwie noch unschön aus... (liegt an beiden Baustellen) Gruß, --Markus 16:26, 18. Dez. 2007 (CET)

Du könntest aber auch an Stelle von {{BS}} selbst was stricken. -- visi-on 16:42, 18. Dez. 2007 (CET)

Tools?

Sieht auf den ersten Blick sehr brauchbar aus. Einzige für mich (als Anwender, nicht Entwickler) offene Frage: Habt ihr ein Tool fertig - oder wird es spätestens zum Beginn des geplanten Meinungsbildes fertig sein, das mindestens so komfortabel wie http://www.mcaviglia.ch/gmap/coor_de_v2.html (aber natürlich ohne den lästigen Fehler bei den Bundesländern in region) ist? --h-stt !? 13:13, 20. Dez. 2007 (CET)

Ich werde versuchen mein bestes bei der Modifikation meiner Tools zu tuen, wobei ich natürlich lieber das Meinungsbild abwarten würde, um Planungssicherheit zu haben. --Kolossos 13:23, 20. Dez. 2007 (CET)

Kenne ich dein(e) Tool(s)? Ich glaube nur das obige und das ältere aus dem GISWiki von hjl zu kennen. Ich wollte eigentlich nur nochmal betonen, wie wichtig es für die Anwender ist, von Anfang an ein wirklich einfach zu bedienendes Tool zu haben. Denn von der Funktionsseite scheint euer Vorschlag wohl durchdacht zu sein. --h-stt !? 15:08, 20. Dez. 2007 (CET)

Beachte bitte denn beachtlichen Umstellungsaufwand. Mit dem Abschluss des Meinungsbildes ist noch kein einziger Artikel umgestellt. Mit der offiziellen Freigabe ist nicht vor Februar zu rechnen. Die eigentlichen Koordinatenvorlagen (Meinungsbild [3a],[3b]) werde ich zuerst intern umbiegen. Ich denke damit ist der Tool-Anpassung ein genügend großes Zeitfenster gegeben. -- visi-on 15:25, 20. Dez. 2007 (CET)

Lagewunsch (obsolet)

Vorlage:Lagewunsch ist sozusagen im vorbeigehen auch noch überflüssig geworden, denn die leere Einbindung

{{Coordinate}}

entspricht diesem.-- visi-on 14:57, 20. Dez. 2007 (CET)