Die Löschung der Vorlage „Coordinate“ wurde ab dem 27. Januar 2009 diskutiert. In der Folge wurde der Löschantrag entfernt. Bitte gemäß den Löschregeln vor einem erneuten Löschantrag die damalige Diskussion beachten.
Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind und ihr jüngster signierter Beitrag mehr als 15 Tage zurückliegt. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte. Das aktuelle Archiv befindet sich unter /Archiv.
Automatische Archivierung
Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 1500 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.
Das stimmt. Trotzdem ist es Schwachsinn, wenn jede Sprachversion der Wikipedia ihre eigenen Koordinaten verwendet. Besser wäre ein zusätzlicher Parameter, der – falls er gesetzt ist (wikidata=ja) – die Übernahme der Koordinaten aus Wikidata bewirkt. In der Beschreibung sollte es den Hinweis geben, dass man in jedem Fall vorher die Koordinaten auf Wikidata prüfen und evtl. korrigieren muss, dann haben alle etwas davon. Was den ISO 3166-2-Code betrifft: den habe ich in Wikidata noch nie gesehen, und ich wüsste auch nicht, wie man den dort einfügt. --Telford (Diskussion) Vorlage Diskussion:Coordinate#c-Telford-2019-11-04T08:42:00.000Z-Thgoiter-2019-11-02T17:47:00.000Z11Beantworten
Wenn aber die Koordinaten so „geprüft“ werden wie häufig die unter bestimmten Lemmata angelegte Artikel über Orte und Gewässer – Methode: „Ah, der von mir zu erwähende Klingenbach von Hinter- bis Vordertüttelsweiler hat also schon einen Artikel, dann nichts wie rin damit!“ – dann sind die Aussichten für korrekte Koordinaten trübe. Prüfung findet vor allem dann statt, wenn der, dem sie obliegt, nicht nur dazu aufgefördert, sondern geradezu dazu genötigt wird. --SilvicolaDiskVorlage Diskussion:Coordinate#c-Silvicola-2019-11-04T09:31:00.000Z-Telford-2019-11-04T08:42:00.000Z11Beantworten
Hm, das wird vielleicht zu verwirrend, da die Linien im Moment keine Beschriftung haben. Außerdem arbeite ich ja mit dem Nearby-API als Ausgangspunkt, Deine Bahnlinie würde z.B. nie auf einer Karte als Ergebnis auftauchen, da sie keine Eigenkoordinaten besitzt. Also erstmal muss ein Objekt überhaupt Koordinaten besitzen, um gefunden zu werden, dann erst blende ich evtl. zusätzlich vorhandene Relationen ein. Ich würde die Funktionalität erstmal beim page-Parameter belassen. --DB111 (Diskussion) Vorlage Diskussion:Coordinate#c-DB111-2020-06-08T22:12:00.000Z-Thgoiter-2020-06-08T17:12:00.000Z11Beantworten
Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
zur defintion umseitig:
Landmarken sind meist Gebäude oder Berge, die aus gößerer Entfernung sichtbar sind, in diesem Speziellen Fall menschengemachte künstliche Berge (type=biulding ?).
Wie ist das in dieser Vorlage zu verstehen? Vorlage:Coordinate#Art_des_Objekts ist da wohl nicht deutlich genug, denn es kommt da zu Meinungsverschiedenheiten:
Man sollte trotzdem nicht zu technisch-geologisch denken, "Landmark" bedeutet ja im weitesten Sinne: point of interest. So ist der Default-Zoom-Level in GeoHack dann größer, während ein Berg gleich mit 10km Größe angenommen wird und weniger gezoomt wird. Praktisch nicht so wild, da die Vorlage:Höhle ja das Zoom-Argument (dim) selber übergibt. Aber nur weil Landmark ein Sammel-Container für kleinere Objekte ist, ist der Umkehrschluss Höhle=Berg nicht unbedingt richtiger. Aber klar, am Ende ist die Liste mangelhaft und willkürlich, z.B. hat ausgerechnet der Gebirgspass (pass) einen eigenen Typ. Aber wenn andere Länder-WPs Höhlen als Landmark führen, ob wir das "aus Schönheit" nun wieder anders machen müssen... Aber wie gesagt, am Ende ist der Typ vor allem eine Schätzung für die Größe des Objekts. --DB111 (Diskussion) Vorlage Diskussion:Coordinate#c-DB111-2021-05-02T16:22:00.000Z-Jmv-2021-05-02T14:27:00.000Z11Beantworten
Letzter Kommentar: vor 1 Jahr19 Kommentare8 Personen sind an der Diskussion beteiligt
Ich beabsichtige mittelfristig und schrittweise eine Reform bis Eliminierung der diversen Koordinaten-Vorlagen.
Schrägstrich-Format:
Das war bis 2013 die einzige Möglichkeit, Zeichenketten zu splitten.
Missbrauch der #titleparts war die einzige Notlösung.
Ich habe größte Hochachtung vor der Leistung in den Nuller-Jahren, mit diesen begrenzten Mitteln eine weitgehend robuste und intelligente Lösung zu zaubern und anderthalb Jahrzehnte stabil zu halten.
Gucke ich allerdings in die Programmierung, so gruselt es mich. Dutzende von Parserfunktionen werden aufgerufen, hier und auch in den mehreren darüberliegenden Ebenen, bis ein Ergebnis produziert wurde.
Bei Denkmallisten oder Listen von Naturschutzgebieten mit Hunderten von Objekten kann das auch zum Performance- und Limit-Problem werden.
Mit Ende der 2010er Jahre war ich gefinkelt genug, um robuste und effiziente Lua-Module zu schreiben, die mit sowas umgehen können.
Das Schrägstrich-Format sollte perspektivisch aus dem ANR eliminiert werden. Der Zeithorizont wäre ein Jahrzehnt. Wegen BNR und archivierter Diskussionen muss es aber auf ewig unterstützt bleiben.
Jedenfalls sind die Schrägstriche ein kurioser Sonderweg, unverständlich und nicht zukunftsfähig.
Auf WP:BETA stehen bereit mit Demonstration alter und neuer Ergebnisse:
Eine einzige Vorlage bzw. Modul-Aufruf für alle erlaubten Koordinaten-Formate.
Die findet sich dann schon zurecht.
Das Datenformat muss eindeutig sein, aber Nickeligkeiten in der Formatierung ignoriere ich.
Typografisches oder Schreibmaschinen-Minuszeichen oder vorangestelltes Pluszeichen sehe ich leidenschaftslos.
Punkt oder Komma als Dezimaltrenner sind wumpe; Tausendertrennzeichen kommen ohnehin nicht in Frage.
Die diversen Strichelchen und Tüddelchen und Kullerchen sind mir egal; ich nehme echte Fußminutenzollzeichen oder Apostroph und Anführungszeichen von der Schreibmaschine oder auch typografische Anführungszeichen.
Auch wenn die Formatierung nicht olympiareif ist, soll sie ohne Belästigung der Autrixe klaglos hingenommen werden. Denkbar wäre die stille Auslösung einer anderen Wartungskat und Standardisierung durch Skripte oder Bots usw.
Umgang mit unzulässigen Daten; meine Sichtweise unterscheidet sich teilweise von der überkommenen Programmierung. Das kann aber auch daran liegen, dass die programmtechnischen Möglichkeiten beschränkt waren.
Ich halte nichts von 95°N – was soll das sein? Kochwäsche überm Nordpol?
Auch 547° wäre die Temperatur einer Metallschmelze, aber hab ich nicht aufm Kompass.
Mehr durch den Hack als wohl beabsichtigt ist die Möglichkeit, arithmetische Ausdrücke statt einer Gradzahl anzugeben. Also 2*(3+5-2) statt 12 zu schreiben. Falls das wirklich benötigt würde, sollte {{#expr:2*(3+5-2)}} genutzt werden.
Alle problematischen Situationen habe ich mit altem und neuem Ergebnis zusammengestellt.
Schlachtplan:
Analyse der BETA-Ergebnisse und Suche nach Lücken und unerwünschten Situationen.
Wenn diese beiden bockfrei, dann deren Einbau direkt in eine Ebene höher, und wieder abwarten.
Nach und nach die übergeordneten Vorlagen vereinfachen, bis man letztlich direkt bei umseitig angekommen ist. Löschung der diversen Zwischenstufen.
Alle Bestandsseiten bleiben zunächst unverändert, wo keine Datenfehler auffielen. Zuletzt wird die umseitige Doku geändert und die neuen Formate werden publiziert.
Ich hab da noch den einen und anderen Pfeil im Köcher.
Moin Moin, klingt nach einem Plan. Mir fallen nur gleich Fragen ein, die sollten wir schonmal hier beantworten, bevor sie aufkommen. 1) Die Koordinate in der obersten Zeile eines jeden Artikel bleibt davon unberührt insofern, dass sie da weiterhin angezeigt wird. 2) Werden Korrektur-Botläuft angestrebt, um es dann zu vereinheitlichen? 3) Was ist/wäre mit Objekten fern ab der Erde, da haben wir ja leider auch Koordinaten? mfg --Crazy1880Vorlage Diskussion:Coordinate#c-Crazy1880-20220914181800-NordNordWest-2022091408140011Beantworten
Es geht ausschließlich um das mögliche Eingabe-Format, nicht darum, was damit bereits heute oder später aus dieser Eingabe produziert wird.
Bot: Nein. Und 2022 auch keine systematischen Veränderungen, sondern erstmal ruckelfreies Durchschschleifen, was noch mühsam genug wird. In späteren Jahren kann WSTM auf Artikel-Koordinaten sowie Infoboxen einwirken. Sind aber >600.000 ANR-Verwendungen, zu einem nicht bekannten Anteil nicht-Dezimal; das zieht sich ein Jahrzehnt.
Ich hoffe, dass dort ebenfalls eine Kugel 360° hat. Falls dem so wäre, erwarte ich dort keine Probleme.
Es ist eine offene Frage, weil das bisher anscheinend teilweise oder komplett ohne Fehlermeldung blieb, also geduldet wurde; zukünftig jedoch Wartungsbedarf entstehen wird.
Ich durchschaue allerdings den über fünf Ebenen gestaffelten Dschungel der Vorlageneinbindungen (der nach alter Technologie wahrscheinlich unvermeidlich war) nicht so ganz und kann nicht vorhersagen, was bislang wann wo passieren würde, wenn solche dubiosen Angaben gemacht wurden.
Die neue Technik schreibt dann aber Fehlermeldung plus Wartungskat.
Muss dann irgendwer aufarbeiten und die korrekten Positionen recherchieren.
Die Vorlagen sollen statt zwei Parametern, oder gar sechs, nur noch einen bekommen.
In den kann dan per C&P ein Koordinatenpaar reinfallen, von einem anderen Artikel, aus OSM, aus einem anderen Wiki, aus GoogleMaps, von der Homepage einer Burgruine.
Das momentan erforderliche Auseinandergefrickel fällt weg.
Der Migrationsprozess, und die kompatible Programmiererei, dürften anstrengend werden.
Umseitig mit einem neuen unbenannten Parameter zu versehen und den halb und halb durchzureichen mag noch angehen.
Aber Hunderte von Infoboxen kompatibel umzuprogrammieren dürfte eine ziemliche Schinderei sein.
Naja, der Name dieser Vorlage ist nur in der Vorlagenprogrammierung so richtig sichtbar.
Ließe sich auch Vorlage:Position nennen, oder Vorlage:Koordinatenpaar.
Soll halt nicht mit anderen Namenssystemen bereits existierender Vorlagen kollidieren, oder zu Missverständnissen führen.
„Position“ kann auch was innerhalb eines Textes meinen, entsprechend in der Wiki-Seite oder beim Layout-Block, oder in einer Gewinnertabelle beim Turnier.
Globale, also projektübergreifende Bezeichner in der Programmierung außerhalb der direkten Verwendung durch Autoren sind durchaus angestrebt.
Sie sollen nicht mit Kleinkariertheit wegen irgendwelcher Strichelchen genervt werden, wo Angaben eindeutig sind.
Insbesondere soll einmaliges C&P aus beliebigen externen Infos unterstützt werden, ohne das in verschiedene Felder (VisualEditor) eintragen zu müssen.
Beim Datum handhaben wir es vielerorts genauso: „Verstanden“ werden sehr viele und gewohnte Formate, sofern eindeutig interpretierbar.
WSTM etwa läuft dann hinterher und wandelt das nach gleichen Regeln in einheitliche und angestrebte ISO-Darstellung um.
Kann hier genauso passieren: Eingabe beliebig, mit Komma und Minuten und Sekundenzeichen. Wird gewandelt in ASCII-Dezimalzahl mit Punkt und ist damit international austauschbar mit E, während O durchaus verstanden und akzeptiert wird.
Einer Kugel ist es egal, ob man Erde oder Jupiter oder Mond dazu sagt, und Geo-metrie wird auch auf dem Uranus betrieben. Insofern folgt aus Geo nicht zwingend der Planet Erde. „Damit ist der Mars nach dem Merkur der zweitkleinste Planet des Sonnensystems, hat jedoch eine vielfältige Geologie“ – Mars (Planet).
Manche Herrschaften wünschen allerdings auf möglichst wenige Zeichen eingekürzte Namen.
Wobei sich mit „Coordinate“ ein bunter Strauß an Vorlagen findet, die teilweise Autoren-einbindbar und teilweise programmierungs-intern sind.
Ein wirkliches Namens-Schema und vergleichbare Funktionalität kann ich darin nicht erkennen.
Ich kann auch nicht behaupten, dass ich deren Funktion und Zusammenwirken so restlos verstanden hätte, auch wenn ich irgendwann mal jeden Quellcode kurz angeguckt habe.
Die Hoffnung ist, dass womöglich einige Dutzend dieser wohl 68 Vorlagen „am Ende des Tages“ (nächsten Jahres) weggefallen sein werden, wenn dieser Spaß hier durchgeschleift worden war.
Eigentlich braucht es für alle diese internen Unter-Aufgaben nur noch die neue CoordinateParse oder wie auch immer, sofern nicht die externen URL versorgt werden.
Das Gegenstück sind die von Autoren direkt in der Seite (im Artikel) eingebundenen Vorlagen, die eine sichtbar-beabsichtigte Wirkung auslösen sollen. Von denen scheint es aber nur eine Handvoll zu geben; was die weiteren 50 so machen und wozu sie dann noch gebraucht würden, blick ich noch nicht.
Ich vermute, dass doch mehrere fremdsprachige Wikis dieses neue System von uns übernehmen werden. Dann sollte die Namensgebung projektübergreifend möglichst einheitlich sein, um Verwirrung zu vermeiden.
Im September klären wir noch die diversen Voraussetzungen; mal sehen wie das lange Wochenende mit dem 3. Oktober so ausfällt.
Die Aktion wird mich rund ein halbes Jahr beschäftigen, und das GEO-Personal muss die frisch detektierten Bruchlandungen mindestens im ANR neu verorten. Das sollte dann schon durchdacht und möglichst ruckelfrei und effizient ablaufen.
Letzter Kommentar: vor 1 Jahr1 Kommentar1 Person ist an der Diskussion beteiligt
Ich habe mich früher mit Openstreetmap beschäftigt. Inzwischen benutzt man diese Karten auch in der Wikipedia. Wenn ich bei Wikipedia auf die Seite von Berlin gehe, gibt es
als
1. Koordinaten
2. Openstreetmap
3. Relation
Wo kann ich erfahren , wie man die Karten (2) in Wikipedia einbindet ?
Hallo, ich habe die Koordinaten {{Coordinate|NS=50.328025|EW= 9.275990|type=city|region=DE-HE|text=|name=Spielberger Platte}} eintragen Trägt man die Himmelsrichtung mit ein, kommt Gradzahl-Fehler: NS: keine Zahl EW: keine Zahl
.... jedoch in den Beispielen stehen
mögliche Formate
Code
Erklärung
Beispiel
DMS
Standardformat „Degrees Minutes Seconds“
46° 48′ 31″ N, 9° 59′ 20,8″ O
DM
nur Grad und Minuten
46° 49′ N, 9° 59′ O
DEC
Dezimalgrad
46,8086° N, 9,9891° O
Also die Himmelsrichtung raus nehmen, damit der Fehlercode nicht auftritt
OK, verstanden. Wie bereits oben geschrieben, handelt es sich bei der Tabelle um "Ausgabeformate", also das was angezeigt wird.
Was in die Vorlage muss ("Eingabeformat"), wird unter Vorlage:Coordinate#Breiten- und Längengrad beschrieben. Dezimaleingabe ohne Himmelsrichtung (diese wird durch das Vorzeichen bestimmt), hexagesimal mit Himmelsrichtung.
Um bei den Beispielen aus der Tabelle zu bleiben:
46° 48′ 31″ N, 9° 59′ 20,8″ O wird zu NS=46/48/31/N|EW=9/59/20.8/E
46° 49′ N, 9° 59′ O wird zu NS=46/49//N|EW=9/59//E
46,8086° N, 9,9891° O wird zu NS=46.8086|EW=9.9891
@Woelle ffm: Ich versuch mich mal mit einer Erklärung für dich. Wenn du in Google Earth Pro eine Ortsmakierung setzt, kannst du dir dort die Koordinate in dem Format 51°27'8.51"N 11°18'3.45"E rauskopieren. Das ist eine Variante eine Geographische Koordinaten zu schreiben. Wenn du z.B. dir die gleiche Koordinate in Openstreetmap.org rauskopierst (rechte Maustaste, "Show address"), dann bekommst du das Format 51.45236,11.30109. Es gibt im Internet zahlreiche Werkzeuge zum Umrechnen (z.B. dieses Tool). Hier in Wikipedia musst du dann für die Eingabe in der Vorlage eine der drei vorgegebenen Schreibweisen nutzen. Ich persönliche empfehle Dezimalgrad (also wie bei OSM). Das wird in der Informatik so oder so genutzt und ergibt nicht soviele Umrechnungsfehler. - Hinweis in Google Earth Pro kannst du auch die Anzeige umstellen (Menü Tools/Optionen/Breite/Länge anzeigen). Stell das da mal auf Dezimalgrad. Dann geht dein Kopieren deutlich einfacher. - Zusatzhinweis: Kennst du schon earth.google.com/web, da brauchst du nichtmal was zu installieren und kannst ebenso über das Kontextmenü die Koordinate kopieren. Auch hier kannst du die Anzeige in den Settings auf Dezimalgrad umstellen. Beste Grüße --sk (Diskussion) Vorlage Diskussion:Coordinate#c-Stefan Kühn-20231130144700-mögliche Formate11Beantworten
Letzter Kommentar: vor 4 Monaten23 Kommentare9 Personen sind an der Diskussion beteiligt
Seit kurzem (heute?) ist die Darstellung nicht mehr korrekt. Die Vorlage wird bei Einbindung in einem Artikel an der Stelle der Einbindung im Quelltext dargestellt und nicht mehr rechts oben.
Die Darstellung selbst erfolgt mit vorangestelltem Text "Koordinaten:", dann folgt die übliche Darstellung der Koordinaten. Insbesondere die Darstellung in Infoboxen sieht sehr "zerschossen" aus.
Ich habe nicht finden können, wo der Fehler eingebaut wurde.
Viele Grüße --Elutz (Diskussion) Vorlage Diskussion:Coordinate#c-Elutz-20240215212600-Darstellung nicht mehr korrekt11Beantworten
Dazu müsstest du konkretere Einzelheiten liefern.
Eine Änderung ist weder bekannt noch ersichtlich.
Allerdings ist je nach Parametern dieser Vorlage eine Einbindung an Ort und Stelle durchaus möglich und kann beabsichtigt sein.
Perspektivisch wird es ohnehin kein „rechts oben“ mehr geben, und hatte es auf Mobilgeräten (Hälfte der ABrufe) auch noch nie gegeben.
Es betrifft letztendlich jede Seite, die die Vorlage verwendet. Zwei Beispiele:
Kloster Tatew, Koordinaten werden ganz unten vor den Kategorien angezeigt. Bei anderen Artikeln, wo die Vorlage ganz zu Beginn eingebunden ist, erscheint sie nun genau dort. Da hab ich jetzt im Moment kein Beispiel zur Hand.
Erstmal: Alle drei Artikel (und auch alle sonstigen Einbindungen) sehen bei mir völlig „normal“ aus; also so wie bisher.
Bei den allermeisten anderen wohl auch, sonst wäre WP:FZW schon längst explodiert.
Vor zwei Jahrzehnten hatte man mal einen schlechten Programmiertrick abgeguckt, der die optische Darstellung über eine hoffentlich freie Stelle auf dem Bildschirmfenster legen soll.
Das wird perspektivisch rückabgewickelt; es wird also zukünftig wie bei jeder anderen Vorlage auch das Ergebnis an genau der Stelle dargestellt, wo die Vorlage eingebunden ist.
Bei dir funktioniert aus nicht so ganz erklärlichen Gründen die Positionierung an anderer Stelle nicht.
Rückfrage: Was genau verwendest du zum Browsen?
Browser-Typ und Versionsnummer, Betriebssystem, Art des Endgeräts
Mobilgerät oder „App“ scheint es gemäß Bearbeitungsmarkierung nicht zu sein.
Betrifft wohl nur Vector-2022, offenbar wird MediaWiki:Vector.css nicht mehr parallel auch für Vector-2022 ausgeliefert. Hätte einem ja jemand mal sagen können. Habe deshalb in MediaWiki:Vector-2022.css die Regel für die absolute Positionierung ergänzt.