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.
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.
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.
Letzter Kommentar: vor 1 Jahr7 Kommentare6 Personen sind an der Diskussion beteiligt
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
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
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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
Letzter Kommentar: vor 3 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
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
Dieser Abschnitt kann archiviert werden. тнояsтеn⇔ 16:35, 1. Aug. 2024 (CEST)
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:
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
Letzter Kommentar: vor 1 Jahr13 Kommentare7 Personen sind an der Diskussion beteiligt
53.0699722222228.8083055555556
Olbers-Planetarium
Moin, der maplayer funktioniert nicht. Wenn man ihn einbaut versucht Der Artikel etwas aufzurufen wie Vorlage:Positionskartenlayer Deutschland. Sieht man in der Vorschau ganz unten unter dem Editfenster dort wo Folgende Vorlagen werden von dieser Seitenvorschau verwendet steht. Unter der Karte steht nicht der gewünschte Text. Könnte sich das mal jemand ansehen? Danke --2003:DE:743:8CB0:FDDF:61F3:CDC5:C54010:19, 18. Sep. 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
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.
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.
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 ?
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
Dieser Abschnitt kann archiviert werden. тнояsтеn⇔ 16:37, 1. Aug. 2024 (CEST)
Letzter Kommentar: vor 5 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) 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