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.
Es wäre gut, wenn die Vorlage ihre Daten direkt aus Wikidata übernehmen könnte, wenn nichts weiter angegeben ist. Sodass die einfache Einbindung von {{Coordinate}} bei vorhandenem Wikidata-Satz direkt zum gewünschten Ergebnis führt. --Christian140 (Diskussion) 09:06, 2. Nov. 2019 (CET)[Beantworten]
Fände ich auch sehr schön. Allerdings wird der ISO 3166-2-Code in Wikidata nur selten verwendet. Zumindest die Kurzform des Staates gibt es aber meist. --Newt713 (Diskussion) 18:19, 2. Nov. 2019 (CET)[Beantworten]
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) 09:42, 4. Nov. 2019 (CET)[Beantworten]
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. --SilvicolaDisk10:31, 4. Nov. 2019 (CET)[Beantworten]
Gibt es irgendwo ein Tool, mit dem ich die Region gem. ISO 3166-2 aus der geographischen Position ermitteln kann? Geonames bietet da bei Hierarchie schon einen kleinen Ansatz, entspricht aber nicht den bei WP erwarteten Codes (z.B. Berlin: DE-11 statt DE-BE). Theoretisch wäre es eine Datenbank mit < 1.679616e13 Einträgen je nach Auflösung und Algorithmus--Klaus-Peter (ex und hopp)08:22, 17. Mär. 2020 (CET)[Beantworten]
Ich nutze OSM. Mit der Objektabfrage (Button "Pfeil und Fragezeichen") den Ort anklicken, dann unter "Umschließende Objekte" die gewünschte Relation anklicken (z. B. Landesgrenze Berlin) und dort findet sich der ISO-Code. Nicht ganz benutzerfreundlich, aber es funktioniert. Die Tools von Wikipedia:WikiProjekt Georeferenzierung/Hilfe/Tools liefern m. W. nur ISO-3166-1-Codes. --тнояsтеn⇔18:19, 17. Mär. 2020 (CET)[Beantworten]
Danke, dieser Ansatz via OSM war mir noch nicht geläufig. Keine Blitzlösung, aber -- wenn man auch die Verwaltungsgliederung im Ausland kennt -- brauchbar (in D habe ich so was im Kopf). Irgendwann ist mir mal ein Bot aufgefallen, der falsche Regionen-Zuordnungen korrigiert. Da fragte ich mich, auf welchem Topf die korrekten Werte kommen, denn eindeutig sind ja nur lat/lon--Klaus-Peter (ex und hopp)20:00, 17. Mär. 2020 (CET)[Beantworten]
Ihr habt den Bot gerufen, es kommt der Meister selbst. Der Bot macht die Änderung automatisch (teilweise auch händisch), auf Basis von kognitiver Leistung des Meisters und manueller Konfiguration durch den Meister. Abhängig ist der Bot in seinen Teilaufgaben von der korrekten Kategorisierung nach ISO 3166-2 Einheiten (etwa Bundesland in DE). Der Bot hat sich auf seiner Userseite erklärt. Der Bot macht keine Zuordnung der Iso-Codes auf Basis der Koordinaten. Eine gute Quelle für ISO-Codes ist btw. die WP (hüstel). Die Codes in de:WP sind gepflegt und erfüllen bis auf die aktuellen Ausnahmen die Existenzbedingung (DE-SA existiert nicht, DE-SN ist der richtige Code; NO ist grad schief). Die Codes in den Artikeln zu Gemeinden, Orten, oder administrativen Einheiten haben in aller Regel den korrekten ISO-Code in den Koordinaten. Sobald die Zuordnung eines Objekts zu einer ISO-2 Region klar ist, ist auch der Code klar (Achtung bei Objekten in Grenzlage oder bei nicht punktförmigen Objekten). Der mögliche, aber komplizierte Weg über OSM ist meist nicht notwendig. lg --Herzi Pinki (Diskussion) 09:47, 18. Mär. 2020 (CET)[Beantworten]
Oh, ich lese den Wunsch, dass der Bot aus OSM die region automatisch bestimmen könnte? Sollte natürlich gehen, aber ich muss mich erst mit dem Interface zu OSM vertraut machen. Weiß jemand, wie das programmatisch geht? lg--Herzi Pinki (Diskussion) 09:53, 18. Mär. 2020 (CET)[Beantworten]
Welche Ehre, der Bot höchstpersönlich und dann noch mit klarer, verständlicher Ansage. Herzlichen Dank! Das das noch so händisch und mühsam läuft, wundert mich. Aber die OSM-Geschichte geht mir auch nicht aus dem Kopf. Da rumort es gewaltig. Immerhin könnte man so sicher Festlandspunkte regionalisieren, denn bei den Meeren gibt es bei OSM keine Einträge zur Region. Das könnte man aber gewiss noch nachtragen, steht aber erst mal außen vor. Ich vermute mal, dass man im Dunstkreis Overpass_API fündig werden könnte. Werde ich mir zeitnah mal reinziehen.--Klaus-Peter (ex und hopp)16:42, 18. Mär. 2020 (CET)[Beantworten]
@Gadacz, Thgoiter, Herzi Pinki: Hallo zusammen, wenn ich die Ausgangsfrage richtig verstehe, macht das die Rückwärtssuche bei Nominatim. Ich nutze genau das schon per Skript für die unkategorisierten Fotos bei Commons. Ich nehme die Koordinate und werfe die in die API rein. Beispiel URL:
In dem Ergebnis kriege ich das passende Wikidata-Objekt und kann mir dort dann die passende Commons-Bilderkategorie holen. Wenn die unterste administrative Hierarchieebene noch keine Wikidata-Verlinkung hat, gehe ich eine Ebene höher, bis nur noch das Land übrig bleibt. Funktioniert für alle Koordinaten auf Landfläche! -- sk (Diskussion) 21:43, 28. Apr. 2020 (CEST)[Beantworten]
@Herzi Pinki: Der Bot von c:User:Rudolphous hat ab und an mal ein paar gemacht. Ich hab dann oft mal händisch tausende Bilder kategorisiert, aber eigentlich ist das eine Arbeit, die sollte direkt beim Upload der Bilder in Commons passieren oder kurz danach durch regelmäßige Botläufe. Arbeit geht da nie aus, solange Bilder mit Koordinaten hochgeladen werden. - Freue mich, über deinen Enthusiasmus. Schön das ich dir mit der API einen möglichen Weg aufzeigen konnte. -- sk (Diskussion) 23:29, 28. Apr. 2020 (CEST)[Beantworten]
@Herzi Pinki: In meinem Skript versuche ich Doppelabfragen zu vermeiden und speichere das Ergebnis, für den Fall das eine Koordinate mehrmals kommt. Und 1 Ergebnis pro Sekunde ist IMHO völlig ok. -- sk (Diskussion) 00:03, 29. Apr. 2020 (CEST)[Beantworten]
also das da, liefert mir mehrere Areas um den Punkt (brauche ich für Grenzkoordinaten und mehrfach ISO-Regionen, zumindest um die Grenzfälle nicht automatisch zu kategorisieren), mit deinem Aufruf oben habe ich nur immer einen Punkt und einen Satz hierarchisch gegliederter Areas bekommen. Meine Fragen:
@Herzi Pinki: Kann dir die Fragen nicht beantworten. Manche Objekte haben bei OSM eine Relation andere haben keine. Ich bin da noch nicht schlau draus geworden, wann genau eine Relation angelegt wird und wenn nicht. In Wikidata können wir aber nur auf Relationen verlinken. Ich wünschte mir das in OSM auch Straßen zu Relationen zusammengelegt werden. Weiß selber nicht wie so eine Relation erstellt wird. Ich bin froh, dass ich überhaupt eine API gefunden habe, die ich so nutzen kann. -- sk (Diskussion) 12:07, 1. Mai 2020 (CEST)[Beantworten]
Servus, Ich fände einen Parameter für Quellenangaben praktisch, da es bei Verwendung ohne Icon nicht praktikabel ist, ein ref-Tag zu setzen. Danke & Gruß, Ciciban (Diskussion) 14:10, 2. Mai 2020 (CEST)[Beantworten]
Artikel mit Geokoordinaten werden nicht auf der Karte angezeigt[Quelltext bearbeiten]
Sieht gut aus. Kann man das wie bei WIWOSM auch kombinieren, so dass eine Relation angezeigt wird und zusätzlich die Koordinaten der Wikipedia-Artikel im Kartenausschnitt? --тнояsтеn⇔19:12, 8. Jun. 2020 (CEST)[Beantworten]
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) 00:12, 9. Jun. 2020 (CEST)[Beantworten]
Ich denke die WIWOSM-Geometrien können wir auf WMF-API umstellen. Dazu müsste ich mal bei der Wikimap von DB111 schauen dürfen, wie er die Wikidata-ID aus dem Seitennamen rausbekommt. Das einfachste wäre ich dürfte DB111 api.php mitbenutzen. Und ich muss hoffen, das es die Dinge nicht zu sehr verlangsamt. --Kolossos22:42, 8. Jun. 2020 (CEST)[Beantworten]
Bei dem Datenbestand für die Wikipedia-Koordinaten bin ich mit der WMF-API weniger zufrieden. Es fehlen die niedrigen Zoomlevel, die Gebäudelisten, Klassen, etc. . Den letzten Update-Vorgang hatte ich aber nach mehr als 3 Tagen entnervt abgebrochen. Die Verbindungen zur Datenbank waren einfach nicht mehr stabil wie früher. Mal sehen wie es da weitergeht. --Kolossos22:42, 8. Jun. 2020 (CEST)[Beantworten]
Hallo zusammen. Ich extrahiere seit ein paar Tagen wieder Koordinaten aus diversen Wikipedias fuer den WikiMiniAtlas. Dabei erstelle ich auch automatisch eine Fehlerliste mit kaputten Koordinaten. Vielleicht habt ihr das auch schon, weil von den knapp zwei Millionen Koordinaten in der deutschen Wikipedia NULL kaputt sind :-). Na ja, hier ist trotzdem der link http://wma.wmflabs.org/logs/log_de.html --Dschwen (Diskussion) 02:03, 23. Jan. 2021 (CET)[Beantworten]
тнояsтеn, ja, daran kann es natuerlich liegen. de.wp hat wohl einfach eine bessere Fehlerpruefung mit dieser Kategorie! Leider sieht das nicht bei allen anderen ca. 80 wikipedias - bei denen ich Koordinaten extrahiere - so aus. Koennt ihr hier dann wohl ignorieren :-). Eine Uebersicht gibts hier, wen es interessiert: http://wma.wmflabs.org/status.php --Dschwen (Diskussion) 18:00, 26. Jan. 2021 (CET)[Beantworten]
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:
Höhlen als Landmark zu kennzeichnen ist ja auch nicht optimal, Man sieht sie aber nicht (Landmarke?) wird doch nur da eingeordnet weil "landmark" der große Restecontainer ist. freundliche Grüße aus dem Süden von Hamburg Jmv • Sprich mich an16:27, 2. Mai 2021 (CEST)[Beantworten]
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) 18:22, 2. Mai 2021 (CEST)[Beantworten]
Das Problem scheint ungelöst und wurde hier schon mehrfach ventiliert. Da war jemand an der Doku, der es scheinbar nie selbst probierte. --→ KPF ← 11:14, 18. Sep. 2021 (CEST)--→ KPF ←11:14, 18. Sep. 2021 (CEST)[Beantworten]
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.
Verstehe ich das richtig: 12/45/37 als Angabe soll es zukünftig nicht mehr geben, nur noch 12.760278 oder 12° 45′ 37″ (samt Varianten mit verschiedenen Apostrophen, Komma statt Punkt usw.)? NNW09:21, 14. Sep. 2022 (CEST)[Beantworten]
Im Jahr 2050 sollte es im ANR kein 12/45/37 mehr geben, und dieser kuriose lokale Sonderweg aus dem Bewusstsein verschwunden sein.
Weil es in BNR und archivierten Diskussionen vorkommt, muss es aber auf ewig unterstützt bleiben („legacy“).
Zunächst mal geht es darum, dass per C&P von irgendwoher auch 12° 45′ 37″ ermöglicht werden soll. Was die Bearbeitung erleichtern dürfte.
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 --Crazy188020:18, 14. Sep. 2022 (CEST)[Beantworten]
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.
Warum ist es eine offene Frage, was man mit Angaben < 0 oder >90 Grad macht? In Wilhelm Sunder-Plassmann findet sich die Angabe NS=951.966214179757635, solche Sachen sollten einfach eine Wartungskategorie auslösen bzw. mittelfristig einen dicken Fehlerhinweis im Artikel. 84.137.75.6923:18, 18. Sep. 2022 (CEST)[Beantworten]
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.
Oder – ganz verrückt – einfach in Deutsch und kollidiert mit nix? „Coordinate“ war seinerzeit genommen worden, damit es projektübergreifend genommen werden kann. Wollte aber offensichtlich keiner. NNW17:35, 19. Sep. 2022 (CEST)[Beantworten]
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.
Hmm...bei vielen anderen Vorlagen sollen die Eingaben möglichst standardarisiert sein, und hier soll plötzlich quasi jedes Format unterstützt werden?! "GeoLoc" ist übrigens schlecht, weil die Vorlage nicht nur für die Erde verwendet werden kann/soll. 84.137.74.21418:41, 19. Sep. 2022 (CEST)[Beantworten]
Das zielt auf maximale Autorenfreundlichkeit ab.
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).
Wieso nicht einfach CoordinateParse? Direkt eingebunden wird sie ja nirgendwo, da kann sie auch einen technischen Namen bekommen, der zum Koordinaten-Vorlagensatz passt. -- hgzh08:53, 20. Sep. 2022 (CEST)[Beantworten]
Wäre mir auch recht.
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.
Zur Autoren-Verwendung bestimmt sind wohl nur Vorlage:Coordinate, Vorlage:CoordinateSky sowie Vorlage:All Coordinates und Konsorten. Idealerweise wären alle Subvorlagen von Coordinate auch nur deren echte Unterseiten, aber wenn du das Ding eh in Lua neuschreiben willst (?), kann auch das Modul alles packen und dann gäbe es eine halbwegs sinnvolle Benennungssystematik mit Coordinate, CoordinateSky und CoordinateParse als auch anderweitig verwendbare Hilfsfunktion. -- hgzh22:01, 21. Sep. 2022 (CEST)[Beantworten]
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.
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 ?
Wohin übernimmt? Die Tabelle zeigt die möglichen Ausgabeformate und die Himmelsrichtung gehört natürlich dazu, sonst weiß man ja nicht ob Nord oder Süd bzw. Ost oder West. --тнояsтеn⇔16:52, 28. Nov. 2023 (CET)[Beantworten]
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
Hallo, die Vorlage:Coordinate#Breiten- und Längengrad hilft viellt jemanden, der das "täglich" macht, aber nicht der das mal benutzt und auch nicht sofort erkennt. Kann man fürfür eine Spalte einfügen, wie das "richtig" Format hierzu einzutragen ist??--Vielen Dank und viele Grüße Benutzer:Woelle_ffm (Diskussion) 08:51, 29. Nov. 2023 (CET)[Beantworten]
Die Parameter NS und EW sind im Abschnitt Breiten- und Längengrad doch mit viel Erklärungen und Beispielen beschrieben. Findest du das unvollständig oder missverständlich? Was würdest du dort denn geändert haben wollen? Oder erwartest du die Beschreibung von NS und EW im Abschnitt Ausgabevarianten bei den Parametern article und text? Ernsthaft? --Spischot (Diskussion) 13:41, 29. Nov. 2023 (CET)[Beantworten]
Hallo,
es wäre schön, wenn dies dann so aussehen könnte
mögliche Formate
Code
Erklärung
Beispiel
Wird zu (Einzutragen bei der Vorlage)
DMS
Standardformat „Degrees Minutes Seconds“
46° 48′ 31″ N, 9° 59′ 20,8″ O
NS=46/48/31/N|EW=9/59/20.8/E
DM
nur Grad und Minuten
46° 49′ N, 9° 59′ O'
NS=46/49//N|EW=9/59//E
DEC
Dezimalgrad
46,8086° N, 9,9891° O
NS=46.8086|EW=9.9891
vielleicht gibt es auch bessere Ideen für den Text Wird zu (Einzutragen bei der Vorlage)
Kannst du mal erklären, warum du Beispiele für bestimmte Eingabeparameter in der Beschreibung von ganz anderen Ausgabeparametern suchst? Für mich ist das unlogisch und würde die Dokumentation verschlechtern. --Spischot (Diskussion) 15:28, 29. Nov. 2023 (CET)[Beantworten]
Hallo, ich suche mir die Koordinaten bei z.B. G.Earth pro raus (setzt Ortsmarkierung), kopiere den Wert und denke, wird schon alles passen .... ne, naürlich nicht, du musst es noch auf Wiki format umschreiben. Deswegen mit rein.--Vielen Dank und viele Grüße Benutzer:Woelle_ffm (Diskussion) 13:19, 30. Nov. 2023 (CET)[Beantworten]
Du hast jetzt dreimal hintereinander (einmal von Benutzer Diskussion:Thgoiter und zweimal von mir) den Hinweis auf den Abschnitt nicht verstanden. Ich werde keinen erneuten Versuch unternehmen, das zu erklären. Vielleicht gibt es jemand anderes, der mit dir auf der gleichen Wellenlänge liegt und damit dir oder uns weiterhelfen kann. Besten Gruß. --Spischot (Diskussion) 15:08, 30. Nov. 2023 (CET)[Beantworten]
@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) 15:47, 30. Nov. 2023 (CET)[Beantworten]
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) 22:26, 15. Feb. 2024 (CET)[Beantworten]
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.
jetzt komm ich ins grübeln. aber mir war so, als ob die da bis vor kurzem oben rechts waren sich allerdings überlagert hatten mit anderen elementen (den sprachlinks). aber vector 2022 ist ja im fluss, da wundert es mich nicht wenn es da jetzt eine änderung gab und sie verschwunden sind.. --Wetterwolke (Diskussion) 16:37, 16. Feb. 2024 (CET)[Beantworten]
Und deshalb und weil dynamisch und kein fester Ort mit freiem Platz vorhersagbar soll Vector 2022 dort „rechts oben“ überhaupt nichts mehr darstellen; vielmehr sollen die enzyklopädischen Inhalte im Inhaltsbereich angezeigt werden. VG --PerfektesChaos14:12, 17. Feb. 2024 (CET)[Beantworten]
Skin: Vektor 2022, Browser FF, aktuelle Version, Windows, Desktop-Darstellung. Alle Koordinaten sind jetzt unter dem Artikel, nicht mehr oben rechts. Grüße --h-stt!?17:53, 16. Feb. 2024 (CET)[Beantworten]
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.
@Hgzh: Der Safemodus-Link zeigt bei mir das fehlerhafte Verhalten mit Vector-2010, auch nach mehrmaligem Neuladen. Im Normalmodus als angemeldeter Benutzer ist dagegen alles in Ordnung. —Speravir – 01:19, 17. Feb. 2024 (CET)[Beantworten]
Ja, der Safemode blockiert offenbar auch die projektweiten Stildefinitionen, das war mE noch nicht immer so, deshalb hatte mich das zusätzlich verwirrt. -- hgzh10:42, 17. Feb. 2024 (CET)[Beantworten]
