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
[[Vorlage Diskussion:Coordinate/Archiv#Thema 1]]
oder als Weblink zur Verlinkung außerhalb der Wikipedia
Letzter Kommentar: vor 14 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo zusammen, gibt es eigentlich auch eine Möglichkeit Koordinaten bei Zwischenüberschriften in Artikeln einzubinden, also das es so ähnlich wie bei der Artikelüberschrift kleingedruckt und rechts am Rand steht? Ich finde das wäre ein gute Möglichkeit, um Abschnitte eines Artikels zu verlinken, z.B. bei Sammelartikeln über irgendwelche Bauwerke etc. -- мorıтz11:25, 31. Aug. 2010 (CEST)
Letzter Kommentar: vor 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Ist der Parameter "elevation" wirklich nur für Regionen gedacht? Wäre doch auch bei Objekten (wie Bauwerken) sinnvoll, oder? --Hydro12:57, 20. Okt. 2010 (CEST)
Elevation gilt für alle möglichen Objekte, also auch Bauwerke. Der Text
Höhe über dem Meeresspiegel (amtliche Höhe der Region region)
Letzter Kommentar: vor 12 Jahren5 Kommentare5 Personen sind an der Diskussion beteiligt
Bei verschiedenen Listen, in denen die Vorlage sehr häufig verwendet wird (beispielsweise Liste der Schaltanlagen im Höchstspannungsnetz in Deutschland), ist zu beobachten, daß dies das Laden der Seite extrem langsam macht; im Extremfall läd die Seite garnicht mehr. Das Problem scheint dabei auf Seiten des Servers zu liegen, nicht beim Client.
Kann jemand erklären, woran das liegt und wie man das Problem vermeiden kann (außer die offensichtliche Methode: Vorlage weniger oft verwenden)? --TETRIS L20:59, 17. Mär. 2011 (CET)
Wie es vermieden werden kann hast Du bereits besntwortet. Die lange Ladezeit ist natürlich zu Zeiten in denen die meisten Nutzer die wp besuchen durch die Serverlast zu erklären. Morgens um 05:00 Uhr wird es gehen. Die Seite hat allerdings umgerechnet eine Größe von ca. 1,5 MB. Die wp läßt maximal 2 MB zu. Da kommt man schon nahe dran. Siehe den html-Quelltext ziemlich weit unten
Letzter Kommentar: vor 12 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, wie kann man den Namen eines Ortes, der auf der Karte angezeigt wird, angeben? Beispiel Saar (Bahrain), da sollte auf der Karte nur "Saar" stehen statt "Saar (Bahrain)". --androl☖☗08:20, 1. Apr. 2011 (CEST)
Das lässt sich über den Parameter "name" in Vorlage:Coordinate regeln. Im genannten Beispiel habe ich die Ergänzung schon eingebaut. --Telford19:49, 2. Apr. 2011 (CEST)
Letzter Kommentar: vor 12 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Wir haben in Nuklearunfälle von Fukushima-Daiichi ein Problem mit dieser Vorlage. Es wurde zusätzlicher Text mit zusätzlichen references im Artikel eingefügt, und seitdem spinnt sie.
Die Vorlage ist am Ende des Artikels und momentan auskommentiert. Kommentiert man sie ein, kommen irgendwelche wüsten Fehlermeldung. Verschiebt man sie an den Beginn des Artikels, erscheint die Warnung "Diese Seite enthält mindestens ein Argument in einer Vorlage, das expandiert zu groß ist. Diese Argumente werden ignoriert."
Hat sich gerklärt: Der Artikel enthielt zu viele Vorlagen, daher ist der interne Vorlagenspeicher "übergelaufen". Wir haben ihn nun in drei Teile zerlegt, den Artikel. --PM322:00, 2. Apr. 2011 (CEST)
Letzter Kommentar: vor 12 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Bin gerade beim Basteln einer Vorlage für das Konvertieren eines Parameters für die Verwendung in einer Infobox. Sieht so aus: [[Benutzer:Amga/Test]]. Wieso und warum und ob nicht auch anders lösbar, ist erstmal egal - die Vorlage *an sich* macht jedenfalls, was sie soll. Wenn ich den Rückgabewert weiterverwende, hier etwa für eine Metadatenabfrage, ist auch alles korrekt. ABER wenn ich diesen zurückgebenen Metadatenwert (der stimmt, es handelt sich um die richtige Zahl, s. Beispiel unten) dann als Parameter "pop" an "Coordinate" übergebe, kommt die Fehlermeldung Einwohner Zahlenformat und der Wert ist nicht in die Koordinate eingebunden. Zur Illustration habe ich mal die Testvorlage Benutzer:Amga/Test3 (simuliert die Konstellation in der Infobox) erstellt. Wenn ich die in einen Test"artikel" (Benutzer:Amga/Test5) einbaue, kommt der o.g. Fehler (unter 1. in Amga/Test5).
Erst habe ich vermutet, ich hätte da die Aufrufe zu tief verschachtelt, das kann aber nicht sein, denn:
dem Parameter "name" weise ich den gleichen Wert zu, um mal zu sehen, was da kommt - alles korrekt, die richtige Zahl (201442), keine Leerzeichen (mit ›‹ eingeschlossen, um das zu sehen)...
mit der Positionskarte, in der ich "pop" genau den gleichen Wert zuweise (siehe 3.), funktioniert es!
wenn ich eine andere "Untervorlage" aufrufe (Benutzer:Amga/Test4), die exakt dasselbe zurückliefert (siehe 2.), funktioniert es auch mit "coordinate"!
Hallo, ohne das jetzt genau nachvollzogen zu haben, würde ich meinen, dass das Problem bei ungültigen Werten für den Metadatenschlüssel entsteht. Dann kommt nämlich keine Einwohnerzahl zurück, sondern eine Fehlermeldung. Eine Lösung könnte es sein, die Metadatenauswertung unter #iferror zu schreiben. Damit gilt dann:
{{Coordinate|text=DM|NS=…|pop={{#iferror: {{Metadaten Einwohnerzahl DE-MV|{{Benutzer:Amga/Test|13003000}}}}}}|name=ok-Fall}}: {{Coordinate|text=DM|NS=54.08333|EW=12.13333|type=city|region=DE-MV|pop={{#iferror: {{Metadaten Einwohnerzahl DE-MV|{{Benutzer:Amga/Test|13003000}}}}}}|name=ok-Fall}} (pop wird an gehack übergeben)
{{Coordinate|text=DM|NS=…|pop={{#iferror: {{Metadaten Einwohnerzahl DE-MV|{{Benutzer:Amga/Test|13013000}}}}}}|name=nicht-ok-Fall}}:{{Coordinate|text=DM|NS=54.08333|EW=12.13333|type=city|region=DE-MV|pop={{#iferror: {{Metadaten Einwohnerzahl DE-MV|{{Benutzer:Amga/Test|13013000}}}}}}|name=nicht-ok-Fall}} (pop nicht übergeben)
Nein, das ist so nicht der Fall. Zu Testzwecken übergebe ich ja *exakt den selben* Wert nicht nur an pop, sondern auch an name ({{Metadaten Einwohnerzahl DE-MV|{{Benutzer:Amga/Test|{{{1}}}}}}} wobei {{{1}}} = "1300 3000", mit Leerzeichen, das von Benutzer:Amga/Test entfernt werden soll, das ist ja der Sinn der ganzen Konstruktion). Letzteres funktioniert auch, denn wie man unter name sieht (das zum title der Koordinate wird), kommt dort 201442 zurück (korrekt!). Aber die Zuweisung an pop *der Vorlage Coordinate* funktioniert nicht. Wenn ich *genau dasselbe* mit der Vorlage:Positionskarte mache (Zuweisung an pop, gleiche Syntax, gleicher Aufrufparameter), *funktioniert es* (und dort wird ja auch eine Koordinate generiert). -- Amga01:21, 24. Jun. 2011 (CEST)
PS Anderer Aspekt. Wenn ich das hier direkt aufrufe, also mit {{Coordinate|text=DM|NS=54.08333|EW=12.13333|type=city|region=DE-MV|pop={{Metadaten Einwohnerzahl DE-MV|{{Benutzer:Amga/Test|1300 3000}}}}|name=Funktioniert!}}, funktioniert es → {{Coordinate|text=DM|NS=54.08333|EW=12.13333|type=city|region=DE-MV|pop={{Metadaten Einwohnerzahl DE-MV|{{Benutzer:Amga/Test|1300 3000}}}}|name=Funktioniert!}}. Ich habe aber eine Vorlage (nennen wir sie MeineVorlage), in der steht {{Coordinate|text=DM|NS=54.08333|EW=12.13333|type=city|region=DE-MV|pop={{Metadaten Einwohnerzahl DE-MV|{{Benutzer:Amga/Test|{{{1}}} }}}}|name=Funktioniert nicht}}. Wenn ich die mit {{MeineVorlage|1300 3000}} aufrufe, kommt es zum Fehler → {{Benutzer:Amga/MeineVorlage|1300 3000}}! -- Amga01:32, 24. Jun. 2011 (CEST)
Oh, sehe jetzt erst, dass man bei "Georeferenzierung" fragen soll... wieso eigentlich? Aber egal, jetzt, wo ich hier angefangen habe. Die eigentliche Zielsetzung mit meiner Vorlage (s.o.) hat sich erledigt, das löse ich anders. Aber das Problem mit der Vorlage Coordinate hätte ich trotzdem gerne gelöst ;-) Habe mal zu Testzwecken die Vorlage:Coordinate in Benutzer:Amga/Coordinate kopiert, und Vorlage:CoordinateMAIN in Benutzer:Amga/CoordinateMAIN. Benutzer:Amga/Coordinate habe ich nicht verändert, außer, dass nun natürlich Benutzer:Amga/CoordinateMAIN als "Untervorlage" aufgerufen wird. Und, oh Wunder, letztere funktioniert wie gewünscht, wenn ich in die Zeile
|pop={{#if:{{IstZahl|0{{{pop|}}}|N}}|{{{pop|}}}}}
ein kleines, offenbar sinnloses Codestück einfüge (das *immer* ein leeres Ergebnis zurückgibt; unterstrichen):
Sieht für mich nach einem - allerdings unverständlichen - Bug in CoordinateMAIN aus. Oder hat der Server Probleme bei der Auflösung komplex verschachtelter Vorlagen? --Amga00:26, 28. Jun. 2011 (CEST)
Naja, steht ja da: 60 Breitensekunden geht nicht (obwohl in der Quelle so, aber das ist Unsinn). Es gibt ja auch nicht 22:12:60 Uhr, sondern das ist einfach 22:13:00 Uhr ;-) Ich hab mal 'ne 59 draus gemacht: auf Google Earth & Co. ist die Gegend leider nicht genau zu sehen; 1 Breitensekunde entspricht etwa 30 Metern, Fehler sollte erträglich sein, solange keine andere Quelle auftaucht. -- Amga22:16, 22. Nov. 2011 (CET)
Ist kaputt seit der Umstellung auf die Wrapper-Vorlage, die zwischen -Simple und -Full unterscheidet. Kommt aber spätestens mit -Complex wieder. -- ✓Bergi00:48, 19. Jan. 2012 (CET)
Nein, das hat nix mit dem Wrapper zu tun - {{CoordinateFull}} erkennt diesen Fehler auch nicht. N 52°14.70456', E 009°36.96198' type ist ein unbekannter Parameter und wird daher ignoriert. --PM300:52, 19. Jan. 2012 (CET)
Die Überprüfung auf unbenannte Parameter baue ich gleich noch in den Wrapper ein, das ist trivial. --PM301:23, 19. Jan. 2012 (CET)
Ok. Hat gleich eine ganze Reihe von Artikeln mit Fehlern ausgespuckt, werd mich mal ans Abarbeiten machen. Bei der Simple-Variante baue ich das morgen noch rein, gibt sicher nochmal einen Schwung Fehlermeldungen. --PM302:10, 19. Jan. 2012 (CET)
Generell: (thumb-)Bildeinbindungen mitten in einem Absatz führen immer zu einem Aufbrechen des Textes in zwei Teile (hier ist der zweite Teil nur der Punkt).
Konkret liegts an Tidy. Die neue Koordinatenvorlage ist zwar eigentlich dafür vorbereitet alles "inline" auszugeben, der HTML-Postprozessor lässt aber keine tables oder divs innerhalb eines Absatzes zu. Überlisten lässt er sich neuerdings, wenn die Einbindung in einem Wikisyntax-block erfolgt, etwa ein Listenpunkt oder eine Einrückung.
In diesem Beispiel würde ich auf den Satz und die Textausgabe einfach verzichten. Karte und Artikelkoordinate genügen für einen derartigen Stub imho auch. -- ✓Bergi16:59, 23. Jan. 2012 (CET)
Alternativ könnte man die Vorlage aufdoppeln, eine oben vor den Absatz für die Positionskarte+Artikelkoordinate und eine unten im Text. Aber Letzteres finde ich hier auch überflüssig. --PM317:11, 23. Jan. 2012 (CET)
Es waren ja bis heute früh noch zwei Vorlagen. Ich dachte nur, es lässt sich vielleicht einfach beheben. Danke --тнояsтеn⇔20:35, 23. Jan. 2012 (CET)
Das dürfte gleichbedeutend mit Umwandlung von "/" in "DMS" sein. Was passiert mit den Schweizer Koordinaten? Evtl. könnte man ja explizite Angabe von CH1903 verlangen, aber werden dann auch schweizer Koordinaten und Länge/Breite oben in den Artikeln ausgegeben? --Telford16:24, 12. Jul. 2011 (CEST)
dagegen: Verlagert die Frage der Koordinatendarstellung in neutral formulierte Infoboxen, die das bisher von Vorlage:Coordinate erledigen lassen. Abgesehen von den Schweizern. lg --Herzi Pinki22:06, 15. Jul. 2011 (CEST)
Letzter Kommentar: vor 12 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Google maps hat bei mir eben folgende Koordinate ausgegeben: +10° 16' 45.68", -67° 42' 44.91" Doch wie kann ich diese in das in der Wikipedia verwendete Format umsetzen? Negative Koordinaten werden nicht übernommen. Und lasse ich das Minus weg (also: Coordinate|NS=10/16/45.68/N|EW=67/42/44.91/E|type=landmark|dim=25|region=VE), so lande ich anstatt in Venezuela westlich von Indien. Wäre super, wenn mir da jemand weiterhelfen könnte. --TheAutoJunkie09:27, 1. Feb. 2012 (CET)
Ich seh keinen neuen Absatz in dem Artikel? Ob Positionskarte üblicherweise neben kurzen oder langen Abschnitten stehen weiß ich nicht. -- ✓Bergi14:28, 8. Feb. 2012 (CET)
Also bei mir beginnt der Abschnitt "Literatur" erst unterhalb der eingebundenen Karte von Sewernaja Semlja. Dadurch entsteht vor diesem Abschnitt eine große Lücke. --тнояsтеn⇔14:38, 8. Feb. 2012 (CET)
Bei mir ist es mit Win7 & Firefox 10 ok, dito mit IE8. Ich habe auch Vector-Skin. --PM316:04, 8. Feb. 2012 (CET)
Fehler mit Win7, IE9 im IE8-Modus reproduzierbar (erst ab einer bestimmten Fensterbreite, unter ≈800px gehts) – nicht aber nachvollziehbar :-) ☠!☢☣*⚔⚡ InternetExplorer, kein Fehler der Vorlage. -- ✓Bergi17:37, 8. Feb. 2012 (CET)
Muss sie das sein? Auf der Karte sind nur die Markierungen (Geohack-Links) anklickbar, damit man gerade kleine Icons besser trifft. Zur Dateibeschreibungsseite gelangst du weiterhin über das Magnify-Icon (in nicht-Thumb-Einbindung ist die Karte selbstverständlich klickbar). -- ✓Bergi19:04, 9. Feb. 2012 (CET)
Fehler in Kartendarstellung? Keine Linien und Flächen mehr sichtbar.
Letzter Kommentar: vor 11 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, ich habe bemerkt das in tausenden Karten der Wikipediaartikel nicht mehr Linien und Flächen hervorgehoben werden, sondern nur noch Punkte als Koordinaten dargestellt werden wenn man die Koordinaten mit z.B. {{Coordinate|NS=53.5457|EW=9.9670|type=landmark|region=EU}} angibt. Könnt Ihr mir da weiterhelfen, ich habe in der Vergangenheit hunderte Artikel mit diesem String versehen und überall ist die Line oder Fläche nicht mehr sichtbar. Beispiele: Fluss Aare, Landkreis Harburg, Naturschutzgebiet Lüneburger Heide, Freudenthalweg. Es ist leider schon geschehen dass aus Artikeln die Koordinaten wieder herausgelöscht werden mit der Begründung das ein Punkt nicht die Linie darstellt (siehe Europäischer Fernwanderweg E1). Smarties (Diskussion) 01:48, 24. Jan. 2013 (CET)
Was genau meinst du? Die Anzeige des Koordinatenpaares oben rechts in der Ecke des Artikels? Was soll dort deiner Meinung nach stehen und seit wann ist das anders? Oder die Karten, die man aufklappen kann? Dort sehe ich zum Beispiel die rote Linie des Freudenthalwegs. Ich kann in keinem der von dir genannten Artikel einen Hinweis auf einen Fehler finden. Punkte mit der Argumentation zu löschen, dass das Objekt kein Punkt wäre, ist Blödsinn. Auch Berge, Orte und Gebäude sind keine Punkte und bekommen trotzdem Koordinaten. Die Koordinaten haben einen einzigen Zweck: Dass der Leser beim Aufruf einer Karte ungefähr an die richtige Stelle geleitet wird, idealerweise dorthin, wo die Beschriftung des Objekts steht. Warum sollte man dem Leser diesen Service verwehren? --TMg22:15, 24. Jan. 2013 (CET)
Ich denke, es geht um WP:GEO/WIWOSM. Die "Linien und Flächen" erscheinen beim Klick auf "(Karte)" neben den Koordinaten im Artikelkopf. Kann es sein, dass es am Browser liegt? Mit dem Internet Explorer geht das bei mir nicht und es wird nur die Koordinate als "Punkt" angezeigt. Firefox dagegen zeigt die Relationen aus Openstreetmap (= Linien und Flächen). --тнояsтеn⇔22:43, 24. Jan. 2013 (CET)
Hallo, das ist komisch. Seit einigen Tagen war da ein Fehler und jetzt geht es wieder. Ich meinte die rote Line. bzw. Fläche. OK da war wohl der Wurm drin. Wer auch immer den Fehler beseitigt hat, Danke. Smarties (Diskussion) 00:41, 25. Jan. 2013 (CET)
Letzter Kommentar: vor 11 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Bei Blackburn steht im Artikel {{Coordinate |NS=53/44/51/N |EW=2/28/59/W |type=city |region=GB-BBD|map=right|mapsize=200}}
Es gibt bei mir aber keine Koordinaten und Karte rechts oben im Artikel. Ich habe mal die Leerzeichen rausgenommen (diff), aber die Änderung ist noch nicht gesichtet. Würde das denn den Fehler beheben? Oder was ist da falsch am Artikel? --87.157.94.4720:07, 28. Jan. 2013 (CET)
Als Ausgabeformat ist im Artikel |map=right angegeben und dies wird anscheinend so interpretiert, dass nur die Positionskarte ausgegeben wird. Mit der Ergänzung von |article=/ wird auch die Artikelkoordinate ausgegeben. --Entlinkt (Diskussion) 20:13, 28. Jan. 2013 (CET)
Letzter Kommentar: vor 11 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Was stimmt hier nicht? Bei einigen Coordinate-Einbindungen wird das mir nicht erklärliche Es kann nicht mehr als eine primäre Auszeichnung angegeben werden. angezeigt? Kann da jemand weiterhelfen? Danke im Voraus... --Roland.M (Diskussion) 10:51, 31. Jan. 2013 (CET)
Du hast viele Koordinaten als Artikelkoordinate eingebunden (article=DMS), es kann aber pro Seite nur eine Artikelkoordinate geben. Du siehst, dass jetzt ganz rechts oben viele Koordinaten überlappen. Mach aus den Koordinaten in der Tabelle Textkoordinaten (article=DMS entfernen) und es sollte passen. --тнояsтеn⇔11:02, 31. Jan. 2013 (CET)
Letzter Kommentar: vor 11 Jahren11 Kommentare6 Personen sind an der Diskussion beteiligt
Manche Artikel erscheinen nicht auf Google-Maps. Ich habe den Verdacht, dass der Parser von Google nicht mit dem Format ohne die Sekunden klarkommt. Deswegen würde ich vorschlagen, die Sekunden immer hinzuzunehmen.
Beispiel: Bei type=landmark wird im Format Grad°Min'Sek'' ausgegeben, und Google-Maps erhält nach ein paar Wochen das Wikipedia-Fähnchen an der Stelle. Fehlt die Sekunden-Angabe, wie z.B. bei type=city, dann erscheint das Wikipedia-Fähnchen nicht auf Google-Maps.
Das sollte imho ein Google-Problem bleiben und nicht unseres werden. Ich gehe zudem davon aus, dass der GoogleBot die microformat-metadaten ausliest, und die sind dezimal. --✓Bergi22:44, 7. Jun. 2011 (CEST)
Eine Sache, die auffällt ist, dass auf den Seiten der englischen Wikpedia <span class="geo">...</span> verwendet wird, auf denen der deutschen dagegen <span class="geo microformat">...</span>. Letzteres mag korrektes HTML sein, dennoch kann es sein, dass der Parser darüber stolpert. --Klaron11:36, 8. Jun. 2011 (CEST)
Hast du schonmal bei Google nachgefragt? Wir können ja hier nicht auf gut Glück an den - auch extrem oft eingebundenen - Vorlagen herumbasteln.--✓Bergi22:20, 8. Jun. 2011 (CEST)
Es ist nicht nötig, an den Vorlagen rumzubasteln, man kann Änderungen testweise auch an einzelnen Artikeln vornehmen. Ich habe das mittlerweile in verschiedenen Varianten getan. Beispiel: Hier habe ich die Sekunden ergänzt, ohne das Geo-Microformat zu ändern, und hier habe ich das Geo-Microformat so eingebaut wie auf der englischen Wikipedia, ohne die Sekunden einzubauen. Das könnte uns helfen zu sehen, wo das Problem ist. Ein paar Wochen muss man sich gedulden.
Ich erkundige mich aber auch gerne bei Google. Hast du eine Idee, wohin ich mich dort wenden kann? --Klaron00:47, 9. Jun. 2011 (CEST)
Für wen oder was funktionieren? Für Browser-Plugins? Zur Datenextraktion durch Google und Co? Letzteres glaube ich sowieso nicht, da die reine hCard zu wenig Infos enthält.
Man könnte anregen, das Microformat zu einer vollständigen hCard auszubauen. Das könnte z.B. folgendermaßen aussehen:
<spanclass="microformat vcard"><spanclass="fn">{{#if: {{{name}}} | {{{name}}} | {{PAGENAME}} }}</span><spanclass="title">{{{type_save}}}</span><spanclass="adr"><abbrclass="country-name"title="{{Info ISO-3166-2:{{{region}}}|0}}">{{Info ISO-3166-2:{{{region}}}|top}}</abbr>
-<abbrclass="region"title="{{Info ISO-3166-2:{{{region}}}|1}}">{{Info ISO-3166-2:{{{region}}}|acronym}}</abbr></span><spanclass="geo"><spanclass="body">{{{globe}}}</span><spanclass="latitude">{{{NS}}}</span><spanclass="longitude">{{{EW}}}</span><spanclass="elevation">{{{elevation_save}}}</span></span></span><!-- leere Tags werden von Tidy entfernt -->
Wobei einem irgendwie klar wird, dass hCard nunmal eigentlich für Visitenkarten und nicht für Geo-Objekte gedacht war :-) Trotzdem steht dort: If the publisher knows and is publishing the name of the location in addition to its geo lat/long, then the publisher MUST use hCard instead of just geo to publish the name and geo lat/long of the location. Und wenn man das hier so liest, scheint es, als könnten wir als Wikipedia auch unser eigenes Format erschaffen (vor allem wenn en:WP mitzieht, aber die haben sich eher zurückgezogen). --✓Bergi15:58, 3. Aug. 2011 (CEST)
Letzter Kommentar: vor 11 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Wozu, abgesehen von der Benennung von Fließtext-Koordinaten, dient der Parameter?
Sollte man hierbei auf Typographie verzichten oder stellen UTF-8-Zeichen kein Problem dar?
Wird hier eine "alphabetische Sortierung" angestrebt, also bei einem John Holmes Housename=Holmes, John, House oder nicht, also name=John Holmes House In der Praxis sieht man beides. Aber was ist zu bevorzugen?
Benennung der Position bei der Übergabe an den Toolserver und den Geohack und darauf basierende Nachverwendungen.
Zu Beschränkungen der Zeichenauswahl kann ich nichts sagen. Ich vermute, dass da vieles funktioniert und würde bis auf weiteres die korrekte Schreibung (wie z.B. im Lemma üblich) verwenden.
Der Name ist kein Sortierschlüssel sondern nur ein Bezeichner. also name=John Holmes House
Letzter Kommentar: vor 11 Jahren11 Kommentare5 Personen sind an der Diskussion beteiligt
Gibt es eigentlich eine "Wartungskategorie" wenn der Region-typ ("|region=DE-RP") nicht genau angegeben und nur auf die ersten beiden Buchstaben beschränkt ist. Dies mag sich auf die Wahl einiger Positionskarten negativ auswirken. Wenn bei einer Insel (->Infobox) in den Vereinigten Staaten ganz Nordamerika dargestellt wird und nicht der Bundesstaat. --Atamari14:07, 18. Okt. 2011 (CEST)
Nein. Woher sollte die Koordinatenvorlage wissen, dass der Artikel sich auf eine Region und nicht auf das ganze Land bezieht? --PM315:16, 18. Okt. 2011 (CEST)
Meistens beziehen sich Artikel auf eine genau angegebene Koordinate (Insel, Berg oder Bauwerk ), die auch nach Bundesland oder Bundesstaat spezifiziert werden kann. Koordinaten, die sich auf den ganzen Staat beziehen - stellen wohl eher eine Ausnahme dar, oder? --Atamari15:30, 18. Okt. 2011 (CEST)
Leider verstehe ich nicht so recht, wo das Problem liegt. Kannst Du vielleicht konkrete Beispiele nennen, die Dich zu dieser Frage veranlasst haben? --Telford18:37, 18. Okt. 2011 (CEST)
Leider begreife ich es immer noch nicht, aber da Du weiter unten eine offensichtlich befriedigende Antwort erhalten hast, klinke ich mich aus dieser Diskussion dann mal aus. --Telford21:06, 18. Okt. 2011 (CEST)
Der Dump ist halt teilweise nicht sehr aktuell und man findet oft schon den verbesserten ISO-Code. Aber ein Anfang ists... --тнояsтеn⇔20:53, 18. Okt. 2011 (CEST)
Siehe Vorlage:Coordinate#type. Der Type-Paramter wird von {{Coordinate}} nicht geprüft, außer wenn simple=y angegeben ist. Die reicht einfach alles an Geohack durch, was du da reinschreibst. Insofern gibt es keine undokumentierten Parameter, sondern nur unkonventionelle bzw. unerwünschte. Es könnte Probleme machen, forest in der deutschen WP zu verwenden, da unsere Tools das nicht kennen. --PM323:44, 16. Jan. 2012 (CET)
Du meinst „wird nicht geprüft wenn simple=y“? Die Full-Versionen prüfen auf alle Fälle, lassen den Wert forest aber zu. -- ✓Bergi23:50, 16. Jan. 2012 (CET)
Oops, da hatte ich mich eben vertestet; simple=y prüft auch. Dann baue ich forest auch noch in der simple-Variante ein. Warum lassen wir das durch, obwohl es laut Doku bei uns nicht verwendet wird? --PM300:09, 17. Jan. 2012 (CET)
Durch Diskussion und Konsens könnte forest auch bei uns eingeführt werden. Ansonsten plädiere ich dafür, forest durch landmark zu ersetzen. --тнояsтеn⇔10:07, 17. Jan. 2012 (CET)
forest ist damals belassen worden für flächige Gebiete, die keine Staaten, Gemeinden oder administrative Einheiten sind. landmark ist für große Areale schlecht geeignet, da von Einzelobjekten (Kapellen u.dgl) und Erdbebenepizentren ausgehend, die maximale Genauigkeit in der Koordinatenanzeige gewählt wird (unabhängig von dim zumindest DMS). Ich halte es für sinnvoll, forest zu behalten. Habe aber natürlich nix gegen Diskussion und Konsens. lg --Herzi Pinki00:31, 19. Jan. 2012 (CET)
Letzter Kommentar: vor 11 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Ich sehe bei den Ausgaben der neuen Koordinatenvorlage gepunktete Linien unter den Himmelsrichtungs-Buchstaben. Ist das Absicht? --PM317:11, 23. Jan. 2012 (CET)
Hmja, nun ist es dezenter. Scheint mir aber etwas Overkill zu sein, ausgerechnet die Himmelsrichtungen separat zu "vertooltippen" - Grad, Minuten und Sekunden werden ja auch nicht per Tooltip erklärt. Wer mit der Maus drübergeht sieht dass es sich um Breitengrade und Längengrade handelt und kann dort alle nötigen Erläuterungen nachschlagen. --PM322:03, 23. Jan. 2012 (CET)
Letzter Kommentar: vor 11 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo, ich habe nichts darüber gefunden, welcher Wert für "dim=" angenommen wird wenn keiner angegeben ist. Gibt es dafür einen Standardwert, oder hängt das nur vom Auswertungsprogramm ab ? Wäre ja z.B. interessant für Darstellung auf Google Earth o.ä. -- Gerd Fahrenhorst (Diskussion) 19:24, 11. Apr. 2012 (CEST)
Das steht in der ausführlichen Doku zur Vorlage:CoordinateComplex (Feld „dim“ in der Tabelle) - für die Auswirkung auf die Rundung relevant. Was allerdings der Geohack aus dem dim-Parameter in der url macht und wie sich das auf Kartendienste (bzw. deren Verlinkung) auswirkt weiß ich nicht. -- ✓Bergi21:07, 11. Apr. 2012 (CEST)
Wenn der Kartendienst eine entsprechende Möglichkeit bietet, nutzt GeoHack dim, damit das Objekt möglichst bildschirmfüllend angezeigt wird. --Tim Landscheidt05:33, 30. Nov. 2012 (CET)
Letzter Kommentar: vor 11 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, ich bin nach einigem Herumprobieren mit dem Versuch gescheitert, die Vorlage im Artikeltext und mit Ausgabe der Koordinaten sowie einem vorangestellten ICON2 einzubauen. Konkret geht es um diesen Absatz. Da der Artikel zwei unterschiedliche antike Siedlungen betrifft und ich nur für die zweite die Position angeben kann, kann ich die Koordinaten nicht als Artikelkoordinaten setzen. Da die Koordinaten aber den kompletten Abschnitt über Falerii Novi betreffen, hätte ich sie gerne etwas abgesetzt und dazu auch das ICON2 eingesetzt. Wie muss die Syntax aussehen, wenn man einen Textlink setzen möchte, der als Linktext zuerst ICON2 und dann DMS (also die Koordinaten) darstellt? text=ICON2/DMS hat nicht funktioniert (es erschien nur das Icon). Wo ist mein Denkfehler? Vielen Dank im Voraus! --Fl.schmitt (Diskussion) 14:50, 7. Jun. 2012 (CEST)
Ok, alles klar. Vielleicht sollte dann aber die Erläuterung zur ICON-Verwendung präzisiert werden. Die lautet derzeit: "Mit den Werten „ICON0“, „ICON1“ oder „ICON2“ (optional vor Schrägstrich und beliebigem Text) werden die Sonderzeichen bzw. Symbole ‚⊙‘, ‚▼‘ respektive ‚‘ mit Verlinkung zum Geohack ausgegeben." Der Einschub "optional vor Schrägstrich und beliebigem Text" kann m.E. leicht dahingehend missverstanden werden, dass man ein ICON mit einem frei wählbaren Text kombinieren kann. Zudem ist nicht ganz klar, wie der beliebige Text genutzt werden kann (alt-Attribut der Grafik? Weitergabe an Geohack? Ganz was anderes?). Die Erläuterung "Der Link kann entweder durch ein Icon, den Zahlenwert der Position oder einen frei wählbaren Text dargestellt werden" wäre evtl. klarer. --Fl.schmitt (Diskussion) 09:45, 8. Jun. 2012 (CEST)
Hmm, dieses „optional vor Schrägstrich und beliebigem Text“ gibt mir zu denken. Diese Funktion ist mir nicht bekannt und funktioniert ja auch nicht (oder wir machen es beide falsch). Mal abwarten, ob hier noch jemand von den Vorlagenexperten etwas dazu beitragen kann. --тнояsтеn⇔10:22, 8. Jun. 2012 (CEST)
Ja, vielleich sollte man das lieber rausschmeißen. Es bedeutet, dass auch die Einbindung {{Coordinate|NS=|EW=|region=|text=ICON0/irgendwas}} das ICON0 ausgibt, solange nur der erste Teil „vor dem eventuellen Schrägstrich“ IconX ist. Der zweite Teil („beliebiger Text“) fällt dabei allerdings völlig unter den Tisch – sollte also auch nicht verwendet werden. -- ✓Bergi11:37, 8. Jun. 2012 (CEST)
Ich hab es mal aus der Doku entfernt. Dass man da noch mehr eingeben kann, ist völlig belanglos, wenn es eh keine Auswirkungen hat. --тнояsтеn⇔12:31, 8. Jun. 2012 (CEST)
Letzter Kommentar: vor 11 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
Zur Zeit tritt vor der Linkung mit (Lage) ein unerwünschtes Zeichen (wohl Kirchensymbol) mit einem Leerraum auf, dieses war bereits vor Monaten passiert, aber danach verschwunden: also derzeit dann so (# Lage) in Linkformatierung. ?? Ursache kann ich nicht verfolgen ... --Paule Boonekamp (Diskussion) 10:45, 28. Okt. 2012 (CET)
Für die Straßen- und Denkmallisten ist das mE. eine wesentliche Bereicherung, da Du jetzt auch mittels der eingebetteten Karte direkt zu einem anderen Objekt in der Liste springen kannst. Grade bei den Kulturdenkmallisten haben wird das Problem, dass man in einer Liste mit einigen 100 Einträgen überhaupt nicht mehr vernünftig navigieren kann. --alexrk (Diskussion) 17:50, 28. Okt. 2012 (CET)
Wie kriegt man diese teils unnötige und irreführende Doppelung abgeschaltet? Ich dachte, dafür sind hier in der Vorlage Parameter zuständig, die jetzige Neuerung scheint aber eine Parallelveranstaltung dazu zu sein. Vor allem, wenn die Koordinate oben rechts im Artikel noch einmal steht, ist dort ja auch die Karte abrufbar. Wieso muss jedes simple 13° 0′ N, 51° 0′ O1351 mit diesem irritierenden Symbol verziert sein? Meine ersten Assoziationen waren die Weiblichkeit (die ist aber anders herum) und eine Kirche. Was, wenn an der Koordinate gar keine Kirche steht? Kurz: Wenn ich text=DM angebe, will ich auch nur das haben und kein astronomisches Symbol davor. --TMg23:09, 29. Okt. 2012 (CET)
Letzter Kommentar: vor 11 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Moin moin, auf die Gefahr hin etwas überlesen zu haben: wie bringe ich der Vorlage denn bei mir die Koordinaten in Grad, Minute, Sekunde auszugeben? Hintergrund ist der Artikel Dortmund in dem in einer Fußnote im Abschnitt Lage beschrieben wird, dass es je nach Quelle minimale Abweichungen gibt. Als Parameter habe ich text=DMS angegeben. Angezeigt werden aber nur Grad und Minute. --Alex (Diskussion) 15:16, 30. Jan. 2013 (CET)
Das liegt an der Rundung, die hier erläutert wird: Vorlage:Coordinate#Ausgabeformate (zweite Tabelle). Durch die Verwendung von type=city wird auf Minuten gerundet. Lösungsmöglichkeit: text=xx° yy' zz" N, xx° yy' zz" O von Hand reinschreiben oder mit dem dim-Parameter einen kleinen Wert der Ausdehnung übergeben oder type=landmark verwenden. --тнояsтеn⇔15:37, 30. Jan. 2013 (CET)
Die Angabe von dim=10000 ist natürlich strenggenommen nicht ganz korrekt, wenn man sich auf die Ausdehnung der Stadt bezieht ;) --тнояsтеn⇔16:13, 30. Jan. 2013 (CET)
Die Karte kommt durch |map=right. Wenn du das weglässt, erscheint die Coordinate oben rechts, nehme daher |text=DMS oder ähnliches, siehe auch "um einen Koordinatenlink im Artikeltext einzufügen" unter "Kopiervorlagen" am Anfang der umseitigen Dokumentation. Der Umherirrende 17:50, 15. Feb. 2013 (CET)
Letzter Kommentar: vor 11 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Wird von den Parametern NS und EW einer weggelassen, erscheint die Fehlermeldung Fehlender oder fehlerhafter Parameter. Der betreffende Artikel wird aber nicht in eine der Wartungskategorien (Kategorie:Wikipedia:Koordinatenwartung) eingetragen. Kann man das ändern? --тнояsтеn⇔10:22, 26. Apr. 2013 (CEST)
Ich kann das nicht reproduzieren. Wie sieht der Aufruf der Vorlage in deinem Fall genau aus? --TMg11:05, 26. Apr. 2013 (CEST)
Wenn ich das in einem Artikel probeweise in der Vorschau aufrufe, wird tatsächlich die Wartungskategorie eingebunden. Es war mir hier (Eintrag An der Rehwiese) aufgefallen. Liegts am Namensraum? --тнояsтеn⇔11:21, 26. Apr. 2013 (CEST)
Ja, genau. Kategorie:Wikipedia:Koordinaten-Parameterfehler wird nur im Artikelnamensraum gesetzt, weil angenommen wird, dass es überall sonst bedeutungslos oder zumindest nicht dringend ist. In anderen Namensräumen kann gern experimentiert werden, solche Artikelentwürfe wären in der Wartungskategorie nur störend. --TMg23:56, 26. Apr. 2013 (CEST)
Vorlage:Coordinate - Rundung bei den Minuten von mir unerwünscht.
Letzter Kommentar: vor 10 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, ich will die Angaben über die Koordinaten des geomagnetischen Nordpols im Jahr 1996, der als Etappenzielpunkt für die "Polar Challenge" ausgewählt wurde, übernehmen: 78° 35,7' N, 104° 11,9' W. - - - - - Im englischen Wikipedia kein Problem. Die dortige Vorlage 'Coord' bekommt das hin: Top_Gear:_Polar_Special. - - - - - Das deutsche Wikipedia wehrt sich. Die hiesige Vorlage:Coordinate mit dem Parameter text=DM für minutengenaue Anzeige kann anscheinend keine ungerundeten Minutenwerte ausgeben. Die Vorlage rundet immer auf 78°36'N 104°12'W. - - - - - Warum ist das wichtig für mich? Nun, ein Auto sollte zur Position 78°35.7′N 104°11.9′W fahren, fuhr aber zur Position 78°35'7"N 104°11'9"W. Es verfehlte also das Ziel. - - - - - Sicherlich ist bei der Schreibweise mit Dezimalstellen hinter dem Komma der Minutenangabe eine Verwechselungsgefahr gegeben. - - - - - Da dieses aber nicht in der ausführlichen Beschreibung zur Vorlage:Coordinate angesprochen wird, gehe ich davon aus, dass es eine Ungenauigkeit entweder der Beschreibung oder in der Umsetzung bei der Vorlage ist. . . . . . Die Vorlage:Coordinate gibt auch mit hinzugefügten Parametern type=landmark (DEC-Genauigkeit ~11m) und/oder dim=10 (DEC-Genauigkeit < 0,11m) die Koordinaten auf ganze Minuten gerundet aus (DEC-Ungenauigkeit ~1000m ( ± 926 m) ), obwohl die Parameter eigentlich Einfluss auf die Rundung der Koordinatenangabe haben sollen. - - - - - Die erste Dezimalstelle würde die Genauigkeit auf ± 92,6 m verbessern. - - - - - Im Augenblick sehe ich nur die Möglichkeit die originale Koordinate als Text zu schreiben und nachgestellt der sekundengenauen Koordinate mit text=DMS in der Vorlage:Coordinate nachzubestimmen. - - - - - Oder ... gibt es eine Möglichkeit bei Parameter text=DM die automatische Rundung auf ganze Minuten zu unterdrücken und stattdessen eine Rundung auf die erste Stelle hinter dem Komma zu erzwingen? So ungewöhnlich erscheint mir eine solche Koordinatenangabe nicht. - - - - - --Temdor (Diskussion) 20:54, 22. Dez. 2013 (CET)
Ich verstehe das Problem ehrlich gesagt überhaupt nicht. Warum verwendest du nicht einfach text=DMS, wenn dir DM zu ungenau ist? Die gemischte Form mit Grad und Dezimalminuten ist im deutschen Sprachraum völlig unüblich und wird deshalb absichtlich nicht unterstützt. --TMg00:05, 15. Jan. 2014 (CET)
Ich schätze mal, er hat eine Quelle, in der die Koordinaten "78° 35,7' N, 104° 11,9' W" stehen, und will das mit Einzelnachweis exakt so in den Artikel schreiben. Das geht wirklich nur als Text. Wenn die Koordinaten über die Vorlage oben im Artikel erscheinen sollen, kann man das mit text=/ bzw. text=DMS nur in der Form "78° 35' 42" N, 104° 11' 54 W" anzeigen lassen. Beide Angaben bezeichen aber exakt die gleiche Position und sind damit gleichermaßen korrekt. Ich persönlich finde den Kuddelmuddel aus Grad und Dezimalminuten gräuslich und kenne das nur von den GeoCashern. Man sollte daher die ohnehin restlos überladene Vorlage nicht auch noch für dieses Ausgabeformat erweitern. --Telford (Diskussion) 11:07, 15. Jan. 2014 (CET)
Hallo TMg, hallo Telford. Danke für die Antworten. - - - - - Ja, genau so wie du schreibst, Telford, war das Problem gelagert. Die korrekte Zielangabe mit Zehntelminuten lasse ich dann im Text und die DMS-genaue umgerechnete Koordinate über die Vorlage in Klammern dahinter. - - - - - Interessant, dass die Koordinatenangabe mit Zentelminuten statt Sekunden nicht sehr üblich ist. Ich fand es jedenfalls lustig, dass eine ganze Polarexpedition (die Moderatoren wurden von etlichen Fahrzeugen begleitet) an den falschen Ort fuhr, weil keiner drauf kam, dass die fest installierten Geräte in den Autos mit Sekunden anstatt Zehntelminuten programmiert werden mussten. :-) --Temdor (Diskussion) 03:51, 6. Feb. 2014 (CET)
Letzter Kommentar: vor 10 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Wäre jemand so lieb zu schauen was ich bei den Coordinaten falsch gemacht habe? Im Artikel komme ich so in china raus. Wenn ich auf der englischen Seite en:Big Fish Games komme ich richting in Seatle raus. Aber ich verstehe gerade nicht warum... --Calle Cool (Diskussion) 13:08, 6. Apr. 2014 (CEST)
Du warst im Osten unterwegs... habe ein Minus eingefügt und schon landet man in der westlichen Hemisphäre. --тнояsтеn⇔13:55, 6. Apr. 2014 (CEST)
Letzter Kommentar: vor 10 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Es gibt wirklich bescheuerte offizielle Bezeichnungen, die auch so in den amtlichen Werken erscheinen. Da werden runde, eckige und geschweifte Klammern gleichzeitig genutzt. Runde Klammern scheinen kein Problem zu sein.
Beispiel:
{Landschaftsschutzgebiet im Landkreis Saarlouis - im Bereich der Gemeinden (Rehlingen und Wallerfangen) [Dillingen]}
In Listen sieht das wirklich komisch aus. Kann man das kurzfristig (WLE startet am 1. Mai) beheben oder kennt jemand einen Workaround? Gruss --Nightflyer (Diskussion) 22:46, 8. Apr. 2014 (CEST)
Müssen wir das denn wirklich 1:1 zeichengenau übernehmen? Zumindest auf die geschweiften Klammern kann man doch verzichten. --тнояsтеn⇔22:57, 8. Apr. 2014 (CEST)
Sorry für das Löschen der Klammern im Beispiel – hatte nach dem Testen vergessen, das wieder rückgängig zu machen. Ich würde vorschlagen, in der Tabellenvorlage für eure Listen einen optionalen Parameter einzuführen, wenn der Suchterm für die BFN-Datenbank vom Namen abweicht. Denn ich bezweifle stark, dass die geschweiften Klammern Bestandteil einer "offiziellen" Bezeichnung sind. Maßgeblich bei der Benennung sind die Verordnungen aus dem Landesrecht, z. B. diese für St. Ingbert. Eckige oder geschweifte Klammern gibt es da nicht. --тнояsтеn⇔08:51, 9. Apr. 2014 (CEST)
Es geht wohl um L 3.04.15? Dieses ist in der VO nicht genannt, siehe die eingefügte Anmerkung mit Sternchen auf S. 3 dieses PDFs. Die verschiedenen Gebiete sollten bei uns nicht durch eine Klammer mehr oder weniger eindeutig definiert werden (das wird nicht lange dauern, bis jemand aus Unkenntnis "überflüssig" erscheinende Zeichen löscht). Daher bleibe ich bei o.g. Vorschlag. --тнояsтеn⇔09:09, 9. Apr. 2014 (CEST)
Siehe meine Antwort in der Vorlagenwerkstatt. Die geschweiften Klammern sind kein Problem. Einfach ein Leerzeichen einfügen, damit die drei nicht direkt hintereinander stehen und die Vorlageneinbindung vorzeitig beendet wird. Eckige Klammern sind unmöglich, da sie für Weblinks reserviert sind und diese durcheinander bringen. Einfach statt dessen runde Klammern verwende. --TMg04:55, 12. Apr. 2014 (CEST)
Letzter Kommentar: vor 10 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Die Liste enthält eine Menge von Koordinaten, alle gleichartig formatiert, wenige werden angezeigt, die meisten jedoch werden nicht mehr interpretiert. Wüsste gerne,was hier passiert ist.--Bungertfünfundfünfzig14:35, 31. Okt. 2014 (CET)
War ein serverseitiges Problem mit allen Koordinaten (in der gesamten Wikipedia) und wurde repariert. Wenn ein Neuladen der Seite nicht hilft, musst du den Cache leeren: WP:Cache. --тнояsтеn⇔14:37, 31. Okt. 2014 (CET)
Letzter Kommentar: vor 9 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
in Bezug auf den Meteor bei Tscheljabinsk vom 15. Februar 2013 musste ich feststellen, dass es bei der Vorlage hier anscheinend keinen passenden Type gibt. Ich wollte event verwenden, da es das passendstewäre, landmark passt hier eigentlich vorne und hinten nicht (Großflächiges Ereignis, das in diesem Fall vor allem auch in der Luft stattfand). Da event wohl in der enwp verwendet wird, und ich eine passende Einteilung sinnvoll fände.. was spricht dagegen? (Bzw. vermutlich wurde das schon mal irgendwann diskutiert?)
Beste Grüße, --#Reaper (Diskussion) 13:51, 16. Feb. 2013 (CET)
PS: Da forest laut Disk oben ja nun anscheinend doch aufgenommen wurde, sollte es in der Doku auch nicht mehr durchgestrichen erscheinen? --#Reaper (Diskussion) 13:53, 16. Feb. 2013 (CET)
Kann man sicher lange drüber diskutieren und dies wurde auch schon getan: WD:GEO. Ich habs in der Zwischenzeit mal pragmatisch gelöst: [2]. --тнояsтеn⇔14:10, 16. Feb. 2013 (CET)
Hallo, Taktvoll. Leider hast du nicht erwähnt welchen Artikel du meinst. Aber ich habe ihn trotzdem gefunden: Teatro San Cassiano. Die Koordinaten funktionieren jetzt.
Die Fehlermeldung sagt einem ja eigentlich was zu tun ist und verlinkt sogar auf die richtige Vorlage. Mehr geht eigentlich nicht. Gruß --Tlustulimu (Diskussion) 20:18, 8. Jun. 2013 (CEST)
Hallo, Svebert. Mir ist das auch schon woanders aufgefallen. Die Vorlage ist nicht kaputt, sonder der Server "toolserver.org" läuft mal wieder nicht. Ich weiß aber nicht, ob er inzwischen nicht sogar abgeschafft wurde. Gruß --Tlustulimu (Diskussion) 17:49, 13. Jul. 2013 (CEST)
Das liegt am Typ "isle". Bei Inseln wird angenommen, dass die Angabe von Bogenminuten hinreichend genau ist (Ungenauigkeit max. 1 Seemeile). Dies ist in der Tabelle "Rundungswerte" unter Vorlage:Coordinate#Ausgabeformate nachzulesen. Umgehen lässt sich dies, wenn der dim-Parameter augefüllt wird (und kleiner als 10000 ist). --тнояsтеn⇔09:58, 30. Jul. 2014 (CEST)
Dito bei Vorlage:Infobox Fluss. Wenn man einen noch sauberen Fließgewässerartikel erwischt und Purge auslöst, platzt die Einbindung auf der Seite nach rechts aus allen Nähten, weil offenbar im Zshg. mit Koordinaten Murks passiert. Parameter, die nicht in der Flussinfobox, sondern zumindest teilweise aus der Koordinatenvorlage stammen, treten in zusätzlichen horizontalen (!) Headern auf, vielleicht Tabelle-in-Tabelle. --SilvicolaDisk16:39, 27. Okt. 2014 (CET)
Da das Problem gerade erneut auftritt: wie wäre es mit einem Fallback für die Vorlage, dass sie bei einer Fehlfunktion nicht Infoboxen zerstückelt, in der sie eingebunden ist. -- 32X12:40, 31. Okt. 2014 (CET)
Info: Dieses Problem sollte dauerhaft gelöst sein. Heute wurde eine Konfigurationsänderung gemacht, die nicht wieder #coordinates abschaltet, wenn die Suchmaschine CirrusSearch aus Performancegründen abgeschaltet werden muss. — RaymondDisk.19:32, 31. Okt. 2014 (CET)
Ort wird nicht immer auf interaktiver Karte angezeigt
Letzter Kommentar: vor 9 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Ich habe unter Zweitälersteig#Sehenswürdigkeiten einige Koordinaten eingefügt. Dabei wird bei Klick auf jeweils das erste Icon in dieser interaktiven Karte (Wikiminatlas) sogar auch der Verlauf der ersten Wanderetappe angezeigt. Die ersten Sehenwürdigkeiten wie Baumkronenweg und Thomashütte werden in der Karte korrekt dargestellt, bzw. es wird korrekt dahin gezoomt.
Bei den anderen Sehenswürdigeiten, die außerhalb der ersten Etappe liegen (2. bis 5. Etappe) werden die Punkte nicht angezeigt, oder nur ganz kurz, um dann in der Karte nur wieder den Verlauf der ersten Etappe darzustellen. Klicke ich manuell in der Karte auf das Icon "zentrieren", wird mir der Punkt dargestellt. Lasse ich hingegen die Punkte im toolserver.org darstellen, scheint alles sofort zu funktionieren (Klick auf zweites Icon).
Ich vermute, daß das mit der Visualisierung der ersten Etappe in dieser Minikarte zu tun hat und weil der Verlauf der 2. bis 5. Etappe fehlen. Um die Visualisierung des Etappenverlaufs habe ich mich darum selber nicht gekümmert, davon habe auch keine Ahnung. Ich vermute, daß da der Grund liegt.
Kann jemand helfen, oder was kann ich dagegen tun? Google-kml, oder gpx-Daten der 2. bis 5. Etappe aus offzieller Quelle liegen mir vor, bzw. können heruntergeladen werden:
http://www.wanderbares-deutschland.de/wanderwege/wanderwege-karte.html#176
--Comanderkeen (Diskussion) 17:04, 1. Nov. 2012 (CET)
Danke Dir. Was mir noch aufgefallen ist, daß im Falle dieser hinterlegten OSM-Relation nicht automatisch in die Minikarte hineingezoomt wird, es wird schlicht die ganze Etappe mit seinem Verlauf dargestellt und der Ort aus der angegebenen Koordinate ist somit kaum sichtbar. D.h. die Option |dim=10 in der Vorlage Coordinate hat offenbar keine Bedeutung mehr. Läßt sich das noch ändern? Vielen Dank!--Comanderkeen (Diskussion) 21:02, 1. Nov. 2012 (CET)
Ich habe leider nirgends mehr einen IE8, nur IE9. Da kann ich es nicht nachvollziehen. Ich habe auch recherchiert, ob region etwa eine Sonderbedeutung hat, aber nichts gefunden. Eine denkbare Erklärung wäre noch irgendwelches JavaScript (Browsererweiterungen etc.), das eine globale Variable region erzeugt und damit den Anker kaputt macht. IE vermischt diese beiden Welten leider. --TMg10:18, 28. Mär. 2013 (CET)
Hallo, Umherirrender. Mir ist gerade aufgefallen, daß in der Dokumentation von {{CoordinateLINK}} noch die gelöschte Vorlage CoordinateMAIN erwähnt wird. Leider weiß ich nicht, was dort statt dessen stehen sollte. Gruß --Tlustulimu (Diskussion) 20:35, 9. Jun. 2013 (CEST)
Bei den Koordinaten kenne ich mich auch nicht aus, weiß daher nicht, was anstelle von CoordinateMAIN in die Doku sollte, ich hoffe mal, die Benutzer des letzten Umbaus lesen hier mit. Der Umherirrende 20:32, 10. Jun. 2013 (CEST)
Sollte 1:1 sein, wenn es irgendwelche Bugs gibt bitte melden. Übrigens ist die Änderung bis jetzt noch nicht in alle Artikel vorgedrungen. --Kolossos19:57, 10. Jun. 2013 (CEST)
Hallo, Kolossos. Ich habe die Änderung heute in drei weitere Wikipedien übernommen, nämlich eowp, dsbwp und hsbwp. Dort ist sie sogar schon in den Artikeln angekommen. Allerdings weiß ich nicht, ob das für alle Artikel gilt. Gruß --Tlustulimu (Diskussion) 20:03, 10. Jun. 2013 (CEST)
Lasst die JobQueue mal arbeiten, bei über 300.000 Einbindungen kann das ein paar Tage dauern. Der Umherirrende 20:32, 10. Jun. 2013 (CEST)
Von über 700.000 Links auf das Geohack-Verzeichnis (inkl. Skyhack) sind jetzt schon nun noch weniger als 485.000 übrig ;) --тнояsтеn⇔20:42, 10. Jun. 2013 (CEST)
Letzter Kommentar: vor 9 Jahren9 Kommentare4 Personen sind an der Diskussion beteiligt
Man sollte die neue Parserfunktion {{#coordinates:}} in diese Vorlage integrieren (sofern das möglich ist), um die ganzen Koordinaten möglichst einfach in die Datenbank zu bekommen. 79.217.158.3120:48, 21. Dez. 2012 (CET)
Klar, aber bitte nichts überstürzen. Diese Vorlage hier gehört zu den kritischen in der ganzen deutschsprachigen Wikipedia. Eine erste Überlegung wäre vielleicht, wo genau man die Funktion einbauen könnte und welche Parameter man ihr wie mitgibt. Wichtig wäre auch ein externer Vorabtest, wie stark sich die Vorlage auf die Parser-Limits auswirkt. --TMg23:50, 21. Dez. 2012 (CET)
Ja, hatte ich auch gesehen. Mal schauen, woran es liegt. Ich hatte es mit einzelnen Angaben getestet, aber in CoordinateMain kommt nur dezimal an, da scheint etwas nicht zu funktionieren, oder die Doku ist da noch nicht eindeutig. Der Umherirrende 16:18, 19. Jan. 2013 (CET)
Liegt an der Art der Dezimalzahl, die erste Extension, die eine formatierte Zahl als Eingabe möchte! Ein Test mit Ganzzahlen hätte mir also auch nicht geholfen. Ich werde es morgen wiederholen, die Jobqueue soll den Revert erstmal in Ruhe verarbeiten. Der Umherirrende 16:26, 19. Jan. 2013 (CET)
Ich habe einen zweiten Versuch gestartet, aber nur für den Artikelnamensraum und für leeren globe (entspricht earth). Die Kategorie Kategorie:Wikipedia:Fehlerhafte Auszeichnung zu Koordinaten füllte sich daraufhin mit Artikeln, der häufigste Fehler ist, das zwei Artikelkoordinaten angegeben wurden. Dies führt zu einer Fehlermeldung, aber man sieht auch die Überlappung oben rechts, daher ist es nicht so schlimm, wenn der Fehler kommt. So kann man sie aber gut finden: Ich habe schon fast 150 Artikel deswegen angepasst. Einige Artikel stehen noch aus, weil die Artikelkoordinaten aus zwei Infoboxen kommen. Hier muss man der Infobox sagen, das sie eine Nebenbox/Folgebox ist. {{Infobox See}} (KEINGEOARTIKEL=1) und {{Infobox Fluss}}, {{Infobox Berg}}, {{Infobox Stausee}}, {{Infobox Bauwerk}} sowie {{Infobox Insel}} (NEBENBOX=Ja) und {{Infobox Schule}}, {{Infobox Bahnhof}} und {{Infobox Stadion}} (Nebenbox=Ja) haben dafür bereits Parameter, die man dann bei der zweiten Box setzen kann, bei anderen Infoboxen muss dies eventuell noch erfolgen. Der Umherirrende 20:36, 20. Jan. 2013 (CET)
Ja, entschuldige. Ich bin mit den Pflichtfeldern nicht ganz vertraut. Werde aber drauf achten. Der Umherirrende 20:53, 20. Jan. 2013 (CET)
Hab auch noch nen ganzen Schwung abgearbeitet. Jetzt sieht die Kategorie schon ganz gut aus. Sind nur noch 17 "Sonderfälle" übrig. --тнояsтеn⇔13:07, 21. Jan. 2013 (CET)
Ich habe die entsprechenden Infoboxen die in den Artikeln verwendet werden, um den Nebenbox-Parameter ergänzt und in den Artikel eingebaut. Es bringt nämlich nichts, die Koordinaten zu entfernen, weil dann der Lagewunsch angezeigt wird, und die anderen Koordianten überlagert. Dies lässt sich aber nicht so einfach Auswerten und kommt hoffentlich nicht so häufig vor. Der Umherirrende 11:55, 27. Jan. 2013 (CET)
Keine Ahnung, wie das Ergebnis aussehen könnte, alle 10 km sollten aber Koordinaten sein, so dass er etwas finden sollte. prop=coordinates funktioniert auf jedem Fall, so dass die Datenbanktabelle Inhalt haben sollte, nur die Suche tut nicht so wie erhofft. Der Umherirrende 16:17, 3. Mär. 2013 (CET)
Laut Max Semenik von der Foundation liegt der Fehler in der Zeile:
{{#if:{{{globe}}}|| ' nichts '
Der Globe ist als default für die Erde leer, was dieser Ausdruck.
Das ist unerheblich, weil Vorlage:CoordinateMain erst auf Stufe zwei oder drei kommt und damit alle Parameter gefüllt sind (keine direkten Aufrufe aus Artikeln heraus). An den anderen Parametern kann man ja auch erkennen, das sie auf jedem Fall gesetzt sind, weil nirgendwo ein leerer Default abgefragt wird. Die Koordinaten sind ja auch über prop=coordinates abrufbar. Aber mal schauen, vielleicht habe ich da ja noch ein Verständnisproblem gehabt, als ich das eingebaut habe. Der Umherirrende 17:16, 10. Mär. 2013 (CET)
Letzter Kommentar: vor 9 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Entschuldigt bitte, ihr seid das sicher schon tausend mal gefragt worden aber ich bin jetzt wirklich langsam am verzweifeln. Zudem bin ich ein 72jähriger Newbie, erst seid einem halben Jahr dabei. Könnte mir bitte jemand den Header so erstellen, daß die Koordinaten beim Aufruf angezeigt werden? Oder muß ich die Koordinaten bei jeder neuen Eingabe einer Brücke noch extra benennen? Wenn dem so wäre, dann müßte ich es halt so machen. Aber ich bräuchte halt einfach eine Vorlage. Ich wäre wirklich unheimlich dankbar dafür! Gruß --Nixnubix (Diskussion) 18:50, 2. Feb. 2015 (CET)
Eieiei, was 'ne Arbeit. :-) Trotzdem, vielen vielen Dank. Ist halt mehr Arbeit als ich mir machen wollte aber da werde ich wohl in den sauren Apfel beißen. Also, großes Merci! --Nixnubix (Diskussion) 20:25, 2. Feb. 2015 (CET)
Mit < und >. Der Name wird nicht mehr als Wiki-Syntax interpretiert sondern ungefiltert an HTML weitergereicht - deshalb bringt <nowiki> nichts. --Spischot (Diskussion) 09:21, 8. Mär. 2015 (CET)
Wenn man sich dann die Koordinatenseite auf Geohack ansieht, steht dort dann aber leider auch < und nicht <
Hat da nicht (wie nicht selten) ein unbedarfter Amtsnamensgeber gewütet? Er benutzt offenbar keine Umlaute und benutzt diese Spitzklammern, deren Bedeutung doch ziemlich rätselhaft ist, statt runder Klammern, vermutlich aus persönlicher Idiosynkrasie. Dann wäre ich so frei, auf die grammatisch-typographisch richtigen Zeichen zu wechseln:
{{Coordinate|NS=52.2352|EW=8.47698|type=landmark|dim=1000|region=DE-NW|text=Position|name=LSG-Tal- und Sieksystem des Ravensberger Hügellandes und des Östlichen Wiehengebirges (Nebensieke des Kilverbaches)}}
Niemand darf gezwungen werden, fremden Vormurks brav nachzumurksen.
Das von Dir enthüllte Metazeichenproblem sitzt wohl tiefer in der Wikisoftware und jedenfalls nicht in der Vorlage:Coordinate. Man kann es auch nicht mit „<“ oder „C;“ meiden. Zwar taucht dann hier in der Textdarstellung der Coordinate nicht dieses span-Konstrukt auf, aber es findet eben auch, jedenfalls bei Google Maps, keine Ersetzung der XML-Entity durch das darstellbare Zeichen statt:
{{Coordinate|NS=52.5202789|EW=13.3690929|type=landmark|dim=44|region=DE-9|name=Hier sitzt nicht das <e Problem|text=Bundeskanzleramt, Berlin}}
Danke, ich werde also die spitzen durch die runden Klammern ersetzen. Die Sachen mit den Umlauten finde ich OK, das sind ja internationale Bezeichnungen. Hält man sich nicht daran, sieht es in der europäischen Datenbank so aus:
LSG-Tal-und Sieksysteme des Ravensberger Huegellandes und des Herforder Berglandes <Siek an der Kl舐anlage>
Letzter Kommentar: vor 9 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Wenn man in einem Artikel viele Höhenangaben hat, fühlt man sich wirklich wie in einem Schreibprogramm mit Rechtschreibkorrekturterror:
600 m ü. NHN,
500 m ü. NHN,
400 m ü. NHN,
300 m ü. NHN,
200 m ü. NHN,
100 m ü. NHN
Zugegeben, man könnte noch steigern und wellig und in Rot unterkringeln. (Bloß nicht!) Aber was soll diese den Lesefluss irritierende Textauszeichnung überhaupt für einen Zweck haben? --SilvicolaDisk13:51, 10. Mär. 2015 (CET)
Das sind Tooltips. Einfach mal mit der Maus drauf stehen bleiben. Du bist hier allerdings falsch, das hat mit der Koordinaten-Vorlage nichts zu tun ;) --тнояsтеn⇔13:52, 10. Mär. 2015 (CET)
Das zumindest hatte ich bisher zum Glück noch nicht bemerkt. Ich mag keinen Pop, der eigentlich Push ist. Lenkt alles nur ab. --SilvicolaDisk16:36, 10. Mär. 2015 (CET)
Ich habe jetzt aber 5000 Koordinaten ähnlich dieses Links. Dort stehen die Koordinaten in der url als centerX=3539440.634?centerY=5982062.054? Die Daten zu extrahieren ist kein Problem, den Link zu erzeugen macht Excel.
Ich bin mir nicht sicher, ob ich dich genau verstanden habe... Suchst du die Umrechnung von Gauß-Krüger-Koordinaten (X=3539440.634, Y=5982062.054) in WGS84?
Sorry, ich bin von falschen Voraussetzungen ausgegangen. Ich dachte, man könnte die Werte mit Tricks irgendwie direkt in die Vorlage einsetzen. Hat sich also erledigt, ich kenn jemanden, der mir dir Werte per script umrechnen kann. Gruss --Nightflyer (Diskussion) 14:40, 26. Nov. 2015 (CET)
@Woelle ffm: Du rechnest Koordinaten vom einen zum anderen Datum um. ED 50 ist ein Geodätisches Datum, Gauß Krüger ein Koordinatensystem, das sind unterschiedliche Dinge. Gauß-Krüger-Koordinaten beziehen sich auch auf ein Datum (verm. Potsdam-Datum, Bessel/Krassowski-Ellipsoid). @Nightflyer: direkt in unsere Vorlage kann man keine Gauß-Krüger-Koordinaten eingeben. --тнояsтеn⇔16:08, 26. Nov. 2015 (CET)
Letzter Kommentar: vor 8 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, gibt es die Möglichkeit einen Artikel mit zwei Koordinaten zu versehen? Es handelt sich um ein Gebäudekomplex der im Laufe des Mittelalters rund 100 Meter umgezogen ist. --Tobias Karl (Diskussion) 10:01, 26. Mai 2016 (CEST)
Archäologische Funde, die nicht mehr dort sind, wo sie gefunden wurden
Letzter Kommentar: vor 8 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Nach meinem Dafürhalten sind Artikelkoordinaten für Museumsstücke wie die Venus von Willendorf falsch, richtig wäre das als Fundort zu kennzeichnen und im Artikel als Textkoordinate bei den Fund-Umständen zu setzen. Andere Meinungen? … «« Man77 »»(A) wie Autor19:14, 26. Jul. 2016 (CEST)
Eine direkte Georeferenzierung des Artikels halte ich hier ohnehin für unangemessen, da der Artikelgegenstand an sich ja nicht eindeutig auf der Erdoberfläche lokalisierbar ist. Die Fundstelle sollte besser im Artikeltext als Koordinate angeben werden. --alexrk (Diskussion) 21:29, 27. Jul. 2016 (CEST)
Letzter Kommentar: vor 8 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Bin ich hier richtig mit einer Frage? In der Liste der Baudenkmale in Schwielowsee ist die Vorlage drin. Allerdings gibt es unterschiedliche Ergebnisse bei OSM und BING (Google geht schon lange nicht mehr bei mir). Die Position Am Wasser 52 wird bei OSM korrekt angezeigt, bei Bing liegt sie irgendwo in der Pampa. Gruss--Nightflyer (Diskussion) 11:37, 17. Aug. 2016 (CEST)
Mir fällt zumindest auf, dass einerseits "Am Wasser 49, 50" (Alte Dorfschule) und "Am Wasser 52" (Dorfkirche) identische Koordinaten haben. Danach kommt aber noch ein Eintrag "Am Wasser 52" (Grabstätte) mit anderen Koordinaten. Vielleicht gerät da ein Export durcheinander? --Magnus(Diskussion)11:45, 17. Aug. 2016 (CEST)
identische Koordinaten führen nmE dazu, dass nur einer der Punkte angezeigt wird. Welcher? Keine Ahnung. Sind aber hier nicht das Problem. Google geht, du musst nur ein bisschen warten (ev. mehrfach aufrufen mit usecache=1).
Ich habe versucht, usecache=0 zu setzen aber irgendwie wird der Parameter nicht durchgereicht. Um den Cache zu löschen, weiß ich momentan keine Möglichkeit, als die Bing-Kartenanzeige für diese Seite mal einen Tag nicht aufzurufen. lg --Herzi Pinki (Diskussion) 12:30, 17. Aug. 2016 (CEST)
Neuer Versuch bei Google: Der Artikel Liste der Kulturdenkmale in Itzehoe wurde seit Monaten nicht bearbeitet. Die Koordinaten sollten aktuell sein. Trotzdem seh ich bei Google nur die Grundkarte, keinen Eintrag der einzelnen Position eines Denkmals. Mein Rechnerproblem? Gruss --Nightflyer (Diskussion) 23:32, 17. Aug. 2016 (CEST)
Mit oder ohne usecache? Geht es jetzt (bei mir hat es grade funktioniert)? Zur Erläuterung des Ablaufs: Unser google-maps proxy ruft die Erstellung des kml-files auf und übergibt das Ergebnis an google maps. Wenn die kml-file Erstellung zu lange dauert, dann kann google maps nix anzeigen (Üblicherweise bekommt man die Karte von Chicago, ehe auf die richtige umgeschwenkt wird). Die kml-file-Erstellung rennt aber im Hintergrund weiter. Ruft man das nächste Mal google maps auf (mit usecache=1), dann gibt es ev. schon was zum Anzeigen. Mit usecache=0 wird mit der Erstellung des kml-Files immer von vorne begonnen, Mehrfachaufrufe bringen nix. Wenn nur die (richtige) Grundkarte ohne Bommel angezeigt wird, dann könnte das Problem auch an deinem Rechner liegen, da kann ich dir nicht weiterhelfen. lg --Herzi Pinki (Diskussion) 02:16, 18. Aug. 2016 (CEST)
Am Äquator zwischen Meridianen, also höchstmöglicher Abstand
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Es wäre gut, wenn hinzugefügt würde für andere Breiten muß der Wert mit dem Kosinus der Breite multipliziert werden. bkb (Diskussion) 08:28, 20. Apr. 2017 (CEST)
Letzter Kommentar: vor 13 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Wie Bergi auf WP:WVW#Vorlage:Coordinate erwähnt hatte, erzeugt diese Vorlage manchmal ein <span class="geo microformat"> und manchmal <div class="geo microformat">. div wird erzeugt, wenn der Parameter text nicht angegeben oder leer ist, und letzteres dürfte ein Bug sein.
div kann Probleme machen, wenn es irgendwo im Artikeltext generiert wird. Dann entsteht plötzlich ein Zeilenunbruch, oder eine Tabellenformatierung geht kaputt. Bei der neuen Koordinaten-Wrapper-Vorlage müsste ich einen Workaround einbauen, damit dieses Problem nicht häufiger auftritt. Das kostet wieder unnötig Speicher und Performance.
Also, ich sehe zwei Möglichkeiten, das Problem in {{CoordinateMAIN}} zu korrigieren: Entweder ändert man
{{#if:{{{text|}}}|span|div}}
in
{{#ifeq:{{{text|}}}x|x|div|span}}
- so war es mit Sicherheit auch gedacht - oder man ersetzt es komplett durch ein einfaches span. Ich plädiere für Letzteres, weil es einfacher und verständlicher und idiotensicherer ist. --PM306:00, 16. Jul. 2011 (CEST)
Darf ich fragen, was der Unterschied in der Auswertung zwischen den beiden Codestücken ist (außer dass ifeq teurer ist)? Abgesehen davon bin ich auch für ein einheitliches <span>. --✓Bergi12:10, 19. Jul. 2011 (CEST)
Ähm, die Codestücke sind identisch, sry. Hab erst vor 10 Tagen mit der Vorlagenprogrammiererei angefangen und lerne noch ;)
Gibts eigentlich irgendeinen Hinweis darauf, dass die von unserer Koordinatenvorlage produzierten geohack-Tags überhaupt funktionieren? Sie unterscheiden sich wesentlich von dem, was alle anderen Wikipidia-Sprachversionen erzeugen. --PM314:38, 19. Jul. 2011 (CEST)
Parameter image_needed für Bilderwünsche
Letzter Kommentar: vor 13 Jahren9 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo zusammen, unabhängig vom Ausgang des Meinungsbildes zur Vorlage:Bilderwunsch wäre es schön, in dieser Vorlage einen optionalen Parameter imange_needed zu haben. Ist er gesetzt, soll der Artikel automatisch in Kategorie:Bilderwunsch an bestimmtem Ort einsortiert werden. Hiermit hätten wir ein unsichtbares Werkzeug, um Bilderwünsche aus Listen an Koordinaten zu binden und sie auf Botlisten und Bilderwunsch-Karten zu präsentieren (vgl. Portal:Frankreich/Bilderwünsche und [9]). Wie ihr auf Portal:Frankreich/Bilderwünsche seht, ist dies derzeit z.B. bereits für die Vorlage:Infobox Brücke realisiert. Es wäre m.E. universeller, den Parameter hier einzufügen, da man sich damit diesen Murks ersparen könnte. Spricht aus technischer Sicht etwas dagegen, diesen Code an den bestehenden Quelltext anzuhängen?
Das bläht die Vorlage wieder auf, jetzt haben wir sie gerade etwas kleiner gekriegt. Und es geht wohl nicht nur um die technische Sicht. In normalen Artikeln kann der Autor neben den Coordinaten auch ein Bilderwunsch-Papperl setzen. Hätte doch den gleichen Effekt. Und in Vorlagen können die, die sich um die Vorlage kümmern, entscheiden, ob sie einen solches Papperl wollen. Aus technischer Sicht liese sich der Code auch kürzen und das Gemurkse wäre weg:
Gerade bei Listen, in denen viele Bilder fehlen, sollte man nicht in jeder Zeile ein Bilderwunschbapperl setzen. Zudem müsste man die Koordinaten dann doppelt pflegen, was durchaus nervig ist und den Quelltext doch ziemlich aufbläht. --Flominator23:29, 8. Okt. 2011 (CEST)
Leider verstehe ich nicht, ob das Flominators Beitrag eher pro oder kontra ist. Von mir ein klares Kontra: die Vorlage ist eh überladen und wurde grade eben etwas abgespeckt. Sie sollte ganz sicher nichts enthalten, was nicht in direktem Zusammenhang zu den Koordinaten steht! Das Meinungsbilds zur Vorlage:Bilderwunsch ist grade mit einem knappen pro für das Bapperl zu Ende gegangen. Man kann dieses also – auch bei Listen – einmal (!) oben in den Artikel setzen, und gut is. --Telford10:19, 9. Okt. 2011 (CEST)
Das Meinungsbild hat ergeben, dass die Vorlage sichtbar eingebunden werden soll. Damit kommt sie hier ohnehin nicht mehr in Frage. Wo soll das Papperl denn angezeigt werden, rechts oben bei Artikelkoordinaten? Ganz unten, wo üblicherweise die Koordinaten stehen? mitten im Text, falls die Koordinaten dort stehen? In Tabellen zerschießt es das Layout. In Infoboxen macht es Probleme. Ich denke, die Listensicht ist auch durch die Denkmallisten geprägt, dass es anders auch geht, sieht man an der Einbindung des Bilderwunsches über {{Denkmalliste Österreich Tabellenzeile}}, allerdings, da unsichtbar, im Widerspruch zum Ergebnis des Meinungsbild. lg --Herzi Pinki12:14, 9. Okt. 2011 (CEST)
Nur weil das Meinungsbild ergeben hat, dass die Vorlage sichtbar angezeigt werden darf, muss das ja nicht um jeden Preis and jeder Stelle geschehen. Bei den Denkmallisten ist es m.E. wirklich eindeutig, bei welchen Einträgen ein Bild fehlt (vgl. auch die Platzhalter in Liste der Sakralbauten in Hannover). Hier geht es eher um die Möglichkeit aus den Bilderwünschen, Listen und Karten erstellen zu können. --Flominator13:23, 9. Okt. 2011 (CEST)
Letzter Kommentar: vor 12 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Was haltet ihr davon, wenn wir aus dieser Seite ein Redirect nach WD:GEO machen? Siehe der Disclaimer ganz oben. Das Archiv kann man auch dort verlinken. --PM300:13, 17. Jan. 2012 (CET)
Das oben war mal ein Versuch von mir, die Diskussion auf WD:GEO zu bündeln... hat so leider nicht funkioniert. Ich würde eine Weiterleitung begrüßen. --тнояsтеn⇔10:05, 17. Jan. 2012 (CET)
Eine Weiterleitung ist mir dann doch zu viel. Ich würde technische Probleme mit der Vorlage durchaus auf der Vorlagendisk behandeln, alles andere (Verwendungsrichtlinien, Feature-Requests und was sonst so anfällt) auf WD:GEO. Ich würde „das oben“ erstmal deutlicher formulieren, in der jetzigen Form war es natürlich eigentlich eine WL.
Die Verschiebung vieler Themen begrüße ich daher, die WL habe ich aber erstmal zurückgesetzt. Wobei: eigentlich sollte imo auch diese Disk nach WD:GEO gehören :-) -- ✓Bergi23:53, 17. Jan. 2012 (CET)
Verstehe nicht, wie du das trennen willst. Hier auf der Seite kommen doch zu 99% Rückfragen zur Benutzung oder zu Problemen mit der Vorlage. Willst du die dann ständig manuell rüberschieben? Ich seh inhaltlich keinen Unterschied zwischen dem hier und WD:GEO.
Ich hab den Kasten oben mal angepasst. Eigentlich beschäftigen sich nur die Threads zu #Slash abschaffen und #bilderwunsch-parameter nicht direkt mit der Vorlage:Coordinate. Auf WD:GEO hingegen werden Ideen, Probleme mit externen Tools, bevorzuzugende Einbindungsvarianten, alles was sonst mit Georeferenzierung zu tun hat und die Projektarbeit disktutiert. Ich hoffe, das macht es klarer; auch jetzt sehe ich bis auf nur sehr wenige Ausnahmen diesen inhaltlichen Unterschied. -- ✓Bergi01:02, 18. Jan. 2012 (CET)
Auf WD:GEO gibts immer wieder mal Anfragen wegen technischen Problemen mit der Vorlage, z.B. aktuell die Abschnitte Nr. 4, 5, 17, 21. Und du selbst hast dort auch technische Änderungen zur Vorlage angesprochen, nicht hier. Umgekehrt stehen oben mehrere Fragen und Wünsche zur Verwendung: Nr. 4, 5, 8. Das ist ein frommer Wunsch mit der Aufteilung - funktioniert aber nicht wirklich. Die Übergänge zwischen beiden Bereichen sind ohnehin fließend. Wie soll ein Nutzer denn entscheiden, ob es ein technisches Problem gibt oder er nur die Verwendung nicht verstanden hat? --PM301:24, 18. Jan. 2012 (CET)
Bislang fehlt auf WD:GEO halt auch der Einleitungskasten… Klar ist eine strikte Trennung nur ein frommer Wunsch, und bei DAUn die nicht wissen was sie überhaupt fragen wollen ist sie kaum möglich. Ich hatte halt vor, spezifische Fragen zur Vorlage, die nicht tut wie/was sie soll, hier zu klären, und darüberhinausgehendes (wo, wann, nicht-Vorlage) auf der Projektdiskussion zu behandeln. Dass es vom Bugreport zum Featurerequest nicht weit ist, ist mir dabei klar. -- ✓Bergi14:06, 18. Jan. 2012 (CET)
Das wär dann ein Sonderweg - meines Wissens gibt es sonst keine Vorlage, bei der wir die Diskussion zwischen technischen Problemen und Sonstigem aufzuteilen versuchen. Die Seite hier wird kaum beachtet, sie hat nur 38 Beobachter - WD:GEO hat 215! --PM314:40, 18. Jan. 2012 (CET)
Minutenbruchteile
Letzter Kommentar: vor 12 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Der Platz für die Sekunden kann dabei auch leergelassen werden, nicht ganzzahlige Werte sind dann auch bei den Minuten erlaubt.
Ich würde dieses Feature lieber nicht dokumentieren - erfahrungsgemäß werden die Nachkommastellen der Gradzahlen gerne mit Minutenzahlen verwechselt, und das gleiche droht hier dann auch mit den Minuten-Nachkommastellen. --PM322:00, 24. Jan. 2012 (CET)
Mir gefällt dieses Feature ehrlich gesagt auch nicht. Die Stelle in der Doku bezieht sich darauf, dass eine DMS-Koordinate immer drei Schrägstriche vor der Himmelsrichtung beinhalten muss. 15/34.7/S führt zu Breitengrad: DMS-Formatfehler. Habe ich mehr oder minder rückwärtskompatibel übernommen. Ehrlich gesagt fände ich es fast sinnvoll, alles zuzulassen: Bis zu 3 Zahlteile, und eine Himmelrichtung am Schluss. Dann könnte man auch 15.5783/S, 15/34.7//S oder 15/34/42/S schreiben; auch die invalide Syntax aus unserem IB-Problem würde akzeptiert werden, sobald man auch noch negative Zahlen zulässt (sinnvollerweise nur bei leerer Himmelsrichtung). Müsste funktionieren, indem man die Himmelsrichtung mit {{#titleparts:{{{NS}}}|1|-1}} an {{Coordinate/LatDMS}} übergibt. Diese müsste dann nicht nur auf Vorhandensein, sondern auch auf Gleichheit mit {{{4}}} prüfen. Sollen wir das zulassen? Würde die Eingabe denke ich deutlich benutzerfreundlicher machen (und die Vorlage nur beschränkt langsamer). -- ✓Bergi23:20, 24. Jan. 2012 (CET)
Die Variante 15/34.7//S würde ich nur sehr ungern zulassen, da das häufig ein Missverständnis sein dürfte und tatsächlich 15/34/7/S gemeint ist. Bei der Koordianteneingabe werden erfahrungsgemäß die Zeichen / . | gerne verwechselt. Da würden eine Menge Fehler unerkannt durchrutschen. --PM323:26, 24. Jan. 2012 (CET)
Hm, es ist aber schon zugelassen. 424 Artikel verwenden das Format in einer direkten Coordinate-Einbindung (und das sind nur die Hälfte der Koordinateneinbindungen, ob das in IB häufiger ist kann ich nicht sagen). Daher würde ich auch gerne 15/34.7/S zulassen, das erscheint intuitiver und ich glaube nicht dass Punkte oft mit Schrägstrichen verwechselt werden. -- ✓Bergi00:42, 25. Jan. 2012 (CET)
Nur ein kleiner Teil der 424 verwendet es bei den Minuten, und mir gings eigentlich nur um die Frage, ob wir das dokumentieren wollen. Aber ich sehe gerade, dass z.B. in der französischen WP solche Angaben üblich sind, da fehlen (teils?) die Sekundenfelder in den Vorlagen - ist also praktisch, wenn sowas bewusst übernommen werden kann. Und die wenigsten Verwendungen in der Liste sehen nach potenziellen Fehlern aus. Ok, hast mich überzeugt. --PM300:54, 25. Jan. 2012 (CET)
Ich hab mir fast die Finger wund getippt bei den Versuch, mit dieser Doku zurechtzukommen. Immer wieder die nichtssagende Fehlermeldung "Formatfehler" ohne Rückmeldung, warum: Es sollte unbedingt dokumentiert werden, dass der dritte der /// gerade nicht weggelassen werden darf, obwohl man die dazugehörige Sekundenangabe weglassen kann. Erläuterungen halte ich nicht nur für die Nord->Süd Ost->West Koordinaten sondern auch für die Gegenrichtungen Süd->Nord West->Ost für erforderlich. Alternativ negative Werte zu verwenden, wie im Artikel angegeben, scheint bei ///-Angaben nicht zu funktionieren, ohne Rückmeldung, warum. Und selbstverständlich sollten alle Funktionen lückenlos dokumentiert werden, damit man bei bereits vorhanden Artikeln auch nachvollziehen kann, wie diese entstanden sind. Ein oder zwei Beispiele würde der Vorlage gut tun, nicht jeder ist von Beruf Programmierer und will die Zeit investieren, das alles durchzulesen, nur um eine einzige Zeile zu verfassen.-- RöntgenTechniker (Diskussion) 15:47, 30. Mai 2012 (CEST)
Ausrichtung
Letzter Kommentar: vor 12 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
Vielleicht habe ich in der Doku etwas übersehen, aber ich finde nichts, womit sich in einer Tabelle Koordinaten ordentlich ausrichten lassen, z.B. so, dass jeder Teil (NS/EW) gleich breit und jeweils linksbündig/rechtsbündig angezeigt wird. --LeastCommonAncestor (Diskussion) 01:24, 1. Mär. 2012 (CET)
Nein, so ist das nicht erwünscht. Sortkey in einer nicht sinnvoll sortierbaren Tabelle kann auch nicht die Lösung sein. Gebraucht würde ein Parameter, mit dem man die Breite eines NS/EW-Teiles (sounsoviel em-width) angeben kann. --LeastCommonAncestor (Diskussion) 01:41, 1. Mär. 2012 (CET)
Zur Verdeutlichung: es verhaut einem die Ausrichtung einerseits dadurch, dass das West-W breiter ist als das Ost-O (Ich hoffe, dass es keine gebräuchlichen Schriften gibt, bei denen die Ziffern unterschiedlich breit sind.) und andererseits dadurch, dass führende Nullen durch "Nichts" ersetzt werden:
Das Problem mit den führenden Nullen könnte man IMHO in den Griff bekommen dadurch, dass die führenden Nullen nicht durch "Nichts" ersetzt werden, sondern durch ein Leerzeichen von Ziffernbreite ( ), am besten wahlweise mittels einer Erweiterung des "text"-Parameters (Ggfalls den Quelltext des folgenden angucken!):
"DM" (wie bisher):
66° 8′ N, 6° 8′ O blabla
66° 8′ N, 16° 8′ O blabla
66° 8′ N, 16° 18′ O blabla
166° 8′ N, 16° 8′ O blabla
"DMM" (Minuten immer vollstellig (zweistellig)):
66° 08′ N, 6° 08′ O blabla
66° 08′ N, 16° 08′ O blabla
66° 08′ N, 16° 18′ O blabla
66° 08′ N, 116° 08′ O blabla
"DDMM" (Grad und Minuten immer vollstellig (Achtung, d.h. Längengrade dreistellig, der Rest zweistellig!):
66° 08′ N, 6° 08′ O blabla
66° 08′ N, 16° 08′ O blabla
66° 08′ N, 16° 18′ O blabla
66° 08′ N, 116° 08′ O blabla
Analog wäre es dann natürlich noch für den Sekunden-Parameter S zu realisieren: SS.
Vielleicht kann das jemand so umsetzen, der Vorlagenprogrammierung beherrscht?
Für das Problem
66° 08′ N, 16° 18′ O blabla
66° 08′ N, 16° 18′ W blabla
ist das natürlich keine Lösung, aber vielleicht doch besser als gegenwärtig?
Hallo Patagonier! Die Idee mit dem figure space-Zeichen finde ich gut. Das Problem ist aber mE nicht in erster Linie das Wie, sondern das Ob, dh ob eine entsprechende Erweiterung erwünscht ist. Wenn ja, könnte ich das selbst implementieren. Ich denke an einen zusätzlichen Parameter "align" mit einer aus den folgenden Beispielen ersichtlichen Funktion (Unterstrich deutet dabei figure space an):
Koordinatenwert align-Wert Format Ausgabe
1.23456 y DM __1° 14′
1.23456 y DMS __1° 14′ _4″
1 y DMS __1° _0′ _0″
1.23456 4 DEC ___1,2346°
1.23456 3 DEC ___1,235°
1 3 DEC ___1,000°
Ich find's gut. Der von Dir vorgeschlagene align-Parameter bietet dann zwar nicht alle Formatierungsmöglichkeiten, die ich oben vorgesehen hatte, aber vermutlich braucht man die volle Flexibilität gar nicht. Und es soll ja auch handhabbar bleiben.
Zum "Ob" meine ich, dass wenn der align-Parameter optional ist, sich ja keiner an seiner Existenz stören sollte. Wer nicht will, braucht ihn ja nicht zu benutzen. Zu diskutieren wäre IMHO allerdings, wie die Koordidaten standardmässig (also wenn "align" nicht verwendet wurde) angezeigt werden sollen. Ich persönlich würde standardmässig aligned bevorzugen, aber ich traue mir nicht zu, den Impact abzuschätzen, schließlich wird die Vorlage vieltausendfach in der Wikipedia verwendet. Vielleicht gibt es ja auch anerkannte typografische Regeln oder bei den Geographen übliche Konventionen, die für das eine oder andere sprechen, aber da kenne ich mich leider nicht aus. [Hier] werden standardmässig keine führenden Nullen verwendet.--Patagonier (Diskussion) 22:16, 14. Apr. 2012 (CEST)
Ich denke, es ist good use, den Default so zu machen, dass sich nichts ändert. Wenn keine weiteren Stimmen kommen, würde ich in einer Woche die Änderung machen. --LeastCommonAncestor11:19, 15. Apr. 2012 (CEST)
Uh, dass das so leicht ist bezweifle ich mal. Bitte erst in einer unabhängigen Testvorlage probieren. Ich würde eher empfehlen, neue Formatvorlagen (siehe Vorlage:CoordinateLink #Formate) zu erstellen.
Allerdings verstehe ich das Problem nicht ganz. Für Tabellen gibt es den Sortkey-Parameter (die reine Erzeugung eines Sortkeys setzt keine Sortierbarkeit vorraus), der zu einer ausgerichtete Darstellung führt. Die Nullen zu verstecken (vgl. Vorlage:0) wäre ein nachvollziehbarer Wunsch (kann ich sofort umsetzen), wobei es mit dem Unicode-Figure-Space vermutlich Browser/Betriebsystem-Problem gibt - sonst wäre er bereits verwendet worden (lieber 0 als �). Im Fließtext und anderen nicht-tabellarischen Umgebungen wird es aber sicher keine Leerzeichen geben, das verstößt gegen die Formatierungsregeln. -- ✓Bergi23:37, 15. Apr. 2012 (CEST)
Die #expr ist notwendig, weil {{#titleparts:ab/cd|1}} „Ab“ zurück gibt (statt „ab“). Das liegt daran, dass die Funktion für Seitentitel entwickelt wurde und das heißt auch, dass Titel mit einem Großbuchstaben beginnen müssen. Die Vorlage:ParmPart umgeht diese Einschränkung, indem sie alle Teile um eins nach hinten verschiebt.
Aus dem selben Grund führen bestimmte Sonderzeichen dazu, dass bspw. {{#titleparts:a/b#c|1|2}} nur „b“ ergibt (statt „b#c“). Das kann die Vorlage nicht lösen, aber sie fängt es ab und gibt in solchen Fällen nichts zurück.
Beides kann hier, wo es um Koordinaten geht, niemals vorkommen und wenn doch, dann wird es in einem späteren Schritt der Vorlagenkette so oder so zu einer Fehlermeldung führen. Also können die 22 Vorlageneinbindungen ganz einfach gegen direkte Aufrufe der Parserfunktion ersetzt werden. In meinem Test wirkt sich das wie folgt aus:
Da es ein Vorlagen-Paar ist, verdoppeln sich einige der Werte noch, von der Vervielfachung bei mehreren Einbindungen ganz zu schweigen. Seltsamerweise – das muss ich noch einmal betonen – ist das Problem dieses Mal nicht, dass eines der Limits gesprengt wird, sondern „nur“, dass die Vorlagenexpansion beim Speichern oder schon in der Vorschau unfassbar lange dauert. Laut Anzeige im Quelltextkommentar dauert es 37 Sekunden, bis 100 Einbindungen der Vorlage:Positionskarte gerendert sind (50 dauern halb so lange, also lineares Laufzeitverhalten).
In meinen Tests konnte ich nur zwei funktionale Unterschiede ausmachen:
Vorlage:ParmPart schlägt fehl, wenn die Eingabe mit einem Zeilenumbruch beginnt, weil die Parserfunktion dieses tilgt und es dann im Vergleich fehlt. Die Parserfunktion allein stört sich nicht daran, sie entfernt das ungewollte Zeichen schlicht.
Enthält die Eingabe eines der nicht unterstützten Zeichen, liefert Vorlage:ParmPart wie erklärt nichts zurück und auch die beiden Coordinate-Vorlagen tun dann so, als hätten sie keine Eingabe erhalten. Nach der Umstellung greifen die Fehlermeldungen der Coordinate-Vorlagen, da Eingaben mit diesen Sonderzeichen natürlich weder Zahlen noch Himmelsrichtungen sein können.
Beide Unterschiede sind damit sogar von Vorteil. Und tatsächlich, die Umstellung reduziert die Renderzeit in meinem Test von 37 Sekunden auf immerhin 21. Ich hoffe, ich habe nichts unbedacht gelassen und bitte um Meldung, falls sich nun doch etwas anders verhalten sollte. --TMg03:52, 7. Jan. 2013 (CET)
Wenn ich das richtig sehe, ist das mein oben beschriebener 1. Unterschied. Das heißt, diese Fehleingaben haben vorher dazu geführt, das die entsprechenden Positionskarten mit falsch positionierten oder gar keinen Punkten angezeigt wurden, weil der Koordinatenteil mit den Leerzeichen schlichtweg ignoriert wurde. Jetzt werden diese Fehler angezeigt. --TMg05:50, 7. Jan. 2013 (CET)
Koordinatenübergabe zu GeoNames
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, mir ist aufgefallen, dass bei GeoNames einige aber bei weitem nicht alle alle Koordinaten aus der Wikipedia (erfasst mittels der hier dikutierten Vorlage) vorhanden sind. Offenbar sind es die neueren Artikel, deren Koordinten nicht oder noch nicht übernommen worden sind. Werden die Koordinaten in regelmäßigen Abständen übernommen, oder ist das in der Vergangenheit einmalig passiert?
Die Folge ist, dass über die Umkreissuche bei Anwendungen wie z.B. Wikipanion nicht alle nahegelegenen Orte gefunden werden, auch wenn entsprechende Wikipedia-Artikel mit gepflegten Koordinaten existieren.
Viele Grüße, Marcus --ᛗᚨᚱᚲᚢᛊ ᚨᛒᚱᚨᛗ (Diskussion) 22:40, 3. Feb. 2016 (CET)
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
In der Beschreibung sollte unter den Varianten auch "/" erklärt werden, das derzeit nur in der Parametertabelle erwähnt wird. --SilvicolaDisk00:40, 15. Feb. 2016 (CET)
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Moin! Bitte korrigieren: Überschriften werden stets mit Großbuchstaben begonnen (hier insbes. mehrfach: "mögliche Werte") und sind nicht mittels Semikolon zu erzeugen, so es nicht um Definitionslisten geht, um die Barrierefreiheit zu fördern. Vielen Dank, --GUMPi (Diskussion) 10:22, 26. Dez. 2016 (CET)
Letzter Kommentar: vor 7 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
ich möchte gerne einen Artikel erstellen, der eine Liste beinhaltet, in der die Koordinaten-Vorlage ca. 1000 mal aufgerufen wird (eine lange Liste mit mehr als 1000 Einträgen). Bei den ersten Tests (allerdings nicht abgespeichert, sondern nur in der Vorschau-Funktion) habe ich aber das Gefühl, dass das Probleme gibt. Nach etlichen Hundert korrekten Darstellungen wird die Vorlage nicht mehr in den Text umgesetzt. Gibt es eine Beschränkung der Zahl der Aufrufe? Ich will in diesem Artikel auch noch die Vorlage SortDate verwenden, die mehr als 1000 Mal aufgerufen werden soll. Und auch hier ergibt sich dasselbe Problem. Gruß --Furfur ⁂ Diskussion14:50, 7. Jan. 2017 (CET)
In {{CoordinateSimple}} fehlt mE der Aufruf von {{#coordinates}}. Das hat zur Folge, dass die Koordinaten aus Listen, die CoordinateSimple verwenden (was sie in der Regel aus Performancegründen tun), nicht in die DB extrahiert werden und für weitere Funktionalitäten (wie Anzeige in diversen Karten-APIs) nicht zur Verfügung stehen. Thomas Ledl hat in die Vorlage {{Gemeindebau Wien Tabellenzeile}}einen hack eingebaut, der dazu führt, dass die erzeugten Sekundärkoordinaten über das API abgefragt werden können [10]. Quasi als proof of concept.
Damit das für alle Sekundärkoordinaten (z.B. Denkmallisten, Naturdenkmallisten, usw.) funktioniert, darf das wohl nicht extern aufgeflascht werden (wie im obigen hack), sondern muss in {{CoordinateSimple}} analog zu {{CoordinateMain}} implementiert werden. Ich glaube nicht, dass das mit Performanceargumenten weggewischt werden sollte. Folgender Code
Super, dass du (im Gegensatz zu mir) die Stelle gefunden hast, wo #coordinates bereits eingebunden ist, was das gegenwärtige Verhalten erklärt! Ich stimme dir absolut zu!
Aus Performancesicht sehe ich wenig Risiko. Das Ding zeigt ja nichts an, bei Änderungen werden die zugehörigen Datenbankeinträge performanceoptimiert indirekt über die Queue erstellt. --Thomas Ledl (Diskussion) 10:24, 12. Aug. 2016 (CEST)
Habe scharf gemacht. Koordinaten scheinen in DB auf [11]. Der Einbau der Parserfunktion hat keinen Einfluss auf die Größe und berührt daher die Parserlimits nicht. Falls es doch irgendwo Probleme geben sollte, bitte um feedback. lg --Herzi Pinki (Diskussion) 21:54, 25. Aug. 2016 (CEST)
Ausgezeichnet! Dank!
Somit haben wir von 1971443 Wikiseiten (ohne Weiterleitungen) auf 408706 Koordinaten. Insgesamt sind es 1053580 Koordinaten. Eigentlich hätte ich eine größere Anzahl erwartet. Dazu wirken die 200000 Bilderwünsche geradezu übertrieben. --Thomas Ledl (Diskussion) 09:46, 26. Aug. 2016 (CEST)
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Bin gerade über den Artikel Petersberg (Erdweg) gestolpert, wo der gesamte Artikelinhalt in die Bildunterschrift der durch die Vorlage erzeugten Karte gequetscht ist. Hab mal probiert das irgendwie zu reparieren und der Fehler scheint nur bei Entfernung des Parameters mapsize zu verschwinden. Könnte da mal jemand die Vorlagenprogrammierung checken? --Kam Solusar (Diskussion) 08:28, 12. Aug. 2017 (CEST)
Hallo,
wenn ich einen Koordinaten-Link anklicke, gelange ich zu einer Seite, auf der eine Weltkarte gezeit wird, bei der jedoch der Zeiger falsch gesetzt ist (mitten im Südatlantik – immer an derselben Stelle unanbhängig von der Ausgansgkoordinate). Wenn ich auf diesen Positionsmarker klicke, lande ich wieder korrekt bei der Zielmarkierung. Woran kann das liegen?
Hallo @Nightflyer: ok, vielen Dank. Das fiel mir erst jetzt auf, nach Jahren der Nutzung. Was ich auch eigenartig finde ist, dass es in der englischen Sprachversion nicht auftritt. --Furfur ⁂ Diskussion11:34, 10. Dez. 2017 (CET)
Letzter Kommentar: vor 6 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Standardmäßig werden Koordinaten bei adm1st für den Text-Output auf ganze Grade gerundet. Wie ich anhand einiger Dutzend Stichproben (DACH-Raum, Spanien, Aserbaidschan) festgestellt habe, liegt die gerundete Koordinate (die angezeigte, nicht die nicht-gerundete verlinkte) ziemlich oft außerhalb des zu geokoordinierenden Gebiets. Ein Fehler von bis zu ca. 100 km mag bei größeren Einheiten wie US-Bundesstaaten, chinesischen Provinzen und ähnlichem nicht ins Gewicht fallen, wenn eher mittige Koordinaten hinterlegt wurden, aber erstens sind nicht immer mittige Koordinaten hinterlegt, und zweitens gibt es viele Dutzend Länder, deren Einheiten auf Bundesländerebene im Schnitt deutlich kleiner sind als 100 km im Durchmesser.
Was spricht eigentlich dafür, bei adm1st auf ganze Grade zu runden? … «« Man77 »»(A) wie Autor10:53, 1. Jan. 2018 (CET)
Das automatisierte Runden von Koordinaten und die Unterdrückungsmöglichkeit nur (?) per dim führt bei eher kleinen, aber weit verstreut sich ausdehnenten Verwaltungseinheiten dazu, dass man, ohne zu lügen, keine Koordinate outgeputtet kriegt, wo diese Verwaltungseinheit tatsächlich verwaltet. Bsp: Puducherry (Unionsterritorium), gewissermaßen auch Präfektur Tokio, außer man nimmt eine Ganzgradkoordinate mitten im Ozean. … «« Man77 »»(A) wie Autor01:19, 3. Jan. 2018 (CET)
Seh ich persönlich auch so. Dass standardmäßig bei jedem adm1st zehntelbogensekundengenau Werte angezeigt werden, brauch ich auch nicht. In der Praxis scheinen Ganzgrade aber auf dieser Ebene zu ungenau zu sein. … «« Man77 »»(A) wie Autor10:36, 3. Jan. 2018 (CET)
Letzter Kommentar: vor 6 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
nicht sicher, ob es hier reinpasst.
Ich habe neben der Anzage der Lage des Artikels auf der OSM-Karte (nach Anklicken der Koord.) immer alle benachbarte Artikel im Kartenbereich mit angezeigt bekommen. Sehr interessant für "Artikelhopping". Seit ca. 3 Wochen sehe ich nur noch den Artikel selbst??? Habe ich irgendwo an meinen Einstellungen was verhauen? Jemand eine Idee? Danke für Hilfe - mfg --commander-pirx (diskbeiträge)12:30, 27. Aug. 2018 (CEST)
Hey, erstmal Danke für die Info. Verstehe zwar das ganze DB Geschiebe in der Phab-Meldung nicht... Ist das nur mir aufgefallen und hat keiner der anderen User "gemeckert"? Egal, Hauptsache, das tolle Feature kommt zurück. MfG --commander-pirx (diskbeiträge)09:37, 29. Aug. 2018 (CEST)
Letzter Kommentar: vor 6 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich würde die "Stecknadeln" bei der Darstellung in den Maps gerne andersfarbig markieren oder mit Buchstaben versehen (wie: Grün=Burg, Blau=Ruine, Rote=Ruinenreste, Schwarz=Burgstall) geht das irgendwie durch erw. Funktionierung? MfG --commander-pirx (diskbeiträge)16:09, 30. Jun. 2017 (CEST)
Schweizer Koordinaten – Probleme bei der mobilen Seite
Letzter Kommentar: vor 9 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
(Anmerkung: Ich wurde von der Vorlagen-Diskussion „Infobox Ort in der Schweiz“ auf diese Seite verwiesen worden.)
Wenn ich über den mobilen Browser beispielsweise auf den Artikel Genf zugreife, wird bei den Koordinaten folgendes angezeigt: (500532 / 117325)46.2000136.149985375 – Das sieht so in einem Stück hintereinander nicht schön aus in der Infobox. Was mich wundert, ist, dass in der «normalen» Browserversion lediglich ein Teil – nämlich (500532 / 117325) – angezeigt wird. Würde eventuell ein Zeilenumbruch nach den Koordinaten in den Klammern Sinn machen? – PsY.cHo, 22:21, 9. Dez. 2011 (CET)
Nein, das liegt an der nicht-Ausblendung des Geo-Microformats im css der mobilen Version. Kann man als Bug melden, aber ich glaube nicht dass das schnell gefixt wird. Und ein Mediawiki:mobile.css, das von de-wp-Admins änderbar ist und auf der mobilen Seite geladen wird, gibts m.W. nicht. -- ✓Bergi22:55, 10. Dez. 2011 (CET)
Die Mobilversion hat das selbe Problem mit den deutschen Gemeinden. Ich habe mich jetzt nicht im Detail damit beschäftigt. Was wäre denn nötig, um das zu beheben? --TMg01:25, 1. Aug. 2012 (CEST)
Letzter Kommentar: vor 9 Jahren12 Kommentare5 Personen sind an der Diskussion beteiligt
Ich bitte um freundliche Beachtung. An sich ist der Vorschlag sehr simpel: Ich schlage vor, in der Vorlage:CoordinateMain das vom article-Parameter erzeugte span-Element einfach komplett in {{nicht drucken|…}} einzupacken. Dann wird es in Druck- und PDF-Ausgaben unterdrückt. Möglicherweise habe ich aber etwas vergessen (etwa, wenn das die einzige Koordinate war und dann gar keine mehr gedruckt wird). --TMg22:45, 3. Sep. 2012 (CEST)
Gibt es da kein Stylesheet für? Bzw: Hat sich da was an der Buchfunktion geändert, oder war das schon immer so? Die Metadaten (.geo) werden doch auch nicht dargestellt.
Sind das Fragen an mich oder allgemeine? Für eine Druck-Untervorlage müsste man extrem viel Code duplizieren, deswegen schlug ich ganz bewusst ImDruckVerbergen vor. Den Fehler der doppelten Anzeige im Druck gibt es schon immer. --TMg03:54, 6. Sep. 2012 (CEST)
Durchaus allgemein :-) Mit der ImDruckVerbergen-Vorlage habe ich das Problem, dass sie ein weiteres Expansion-Level hinzufügt, welches bei dieser Vorlage eh schon kritisch ist - duplizierter Code stört mich weniger, die Vorlage ändert sich ja nicht so häufig -- ✓Bergi16:05, 6. Sep. 2012 (CEST)
Ja, hatte ich auch überlegt, aber da das eine leere Vorlage ist, sollte das theoretisch nur 1 Level ausmachen. Andernfalls wäre wohl Vorlage:CoordinateComplex/Druck die erste Wahl, da dort wesentlich weniger Code kopiert werden müsste. (Das wäre auch konsistent zur schon eingeführten Vorlage:CoordinateSimple/Druck, die primär in Listenartikeln Verwendung findet und mit der ich in jeder Hinsicht sehr zufrieden bin.) Im Prinzip beschränkt es sich auf das Leeren des article-Parameters (nicht ganz weglassen, da sonst {{#if:{{{article}}} immer wahr ist). Wollen wir das einfach mal probieren? --TMg01:55, 7. Sep. 2012 (CEST)
Ja, klar, da kann man gerne rumprobieren an den Druckvorlagen, die wirken sich ja auf nichts direkt aus. Ob man dazu jetzt Untervorlagen von Complex oder normal erstellt, ist eigentlich egal -- ✓Bergi16:06, 7. Sep. 2012 (CEST)
Kann man so nicht sagen. Der Inhalt der Infobox wird in der PDF-Ausgabe gar nicht mehr dargestellt, weder Koordinaten noch Bild (die Bildquelle wird aber angegeben...) --Magnus(Diskussion)für Neulinge09:03, 4. Mär. 2015 (CET)
Ich war eben auch sehr überrascht, dass die Entwickler des PDF-Exports es offenbar aufgegeben haben, Tabellen zu übernehmen. Schräg. Das ursprüngliche Problem existiert unabhängig davon noch. Ich hab es jetzt einfach mal gewagt, die entsprechenden CSS-Klassen zu setzen, siehe Vorlage:CoordinateMain. --TMg19:08, 5. Mär. 2015 (CET)
Der aktuelle PDF-Renderer stammt nicht mehr von PediaPress, sondern wurde von der WMF neu entwickelt. Manches besser als bei PediaPress, manches fehlt dafür leider jetzt :-( — RaymondDisk.19:23, 5. Mär. 2015 (CET)
Parserfunktion - Fehler bei anderen Himmelskörpern
Letzter Kommentar: vor 9 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Die Parserfunktion {{#coordinates:}} ist erstmal nur für die Erde aktiv, weil sie bei den anderen Himmelskörpern teilweise ein "ungültige Breitenangabe" gibt. Beispiel:
Die Angabe im Artikel Eberswalde (Marskrater) führt zu folgender Bestückung der Parserfunktion:
{{#coordinates:-24|-33|globe=mars|dim=63000}}
Ohne nowiki gibt das aber den Fehler "ungültige Breitenangabe". Hat jemand eine Idee dazu? Der Umherirrende 20:36, 20. Jan. 2013 (CET)
Nach mw:Extension:GeoData (verlinkte Liste dort) gibt es nur den Wertebereich 0 - 360 für mars, erlaubt aber "wrap", nur wird von der Extension -33 abgewiesen und nicht als 327 erkannt. Ich habe Bug 44216 erstellt. Mal schauen, was der Entwickler dazu sagt. Der Umherirrende 20:43, 21. Jan. 2013 (CET)
Es ist nichts passiert, der Entwickler stellt aber auch die Frage, ob das überhaupt notwendig ist oder sich um einen Fehler handelt. Ich kenn mich damit garnicht aus, um da zu diskutieren. Der Umherirrende17:44, 4. Mär. 2015 (CET)
Vorlage funktioniert nicht mehr
Letzter Kommentar: vor 5 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo. Hatte gerade ne Info von einem Kollegen, dass der von mir in einem Artikel eingefügte Link mit der Vorlage nicht funktioniert. Habe das überprüft. Geht wirklich nicht. Auch von anderen Seiten aus funktioniert das nicht mehr. Frage ist nun Server down oder Vorlage defket / nicht aktuell? LG --Starkiller3010 (Diskussion) 11:06, 7. Sep. 2019 (CEST)
Letzter Kommentar: vor 8 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Hat jemand kurzfristig Lust, mir im Vereinswiki zu Helfen die derzeitigen Probleme dort mit der Vorlage:Coordinate zu lösen. Die Koordinaten werden dort wie in dem Beispiel oben Ordnungsgemäß angezeigt, aber unten am Ende der Seite wird dann zusätzlich: Schwerwiegender Fehler: Parameter location muss einem gültigen Standort entsprechen. angezeigt. Gruß Frank schubert (Diskussion) 12:57, 5. Feb. 2016 (CET)
Kleine Ergänzung. {{Coordinate |NS=49.8770 |EW=8.6673 |type=landmark |dim=50 |region=DE-HE}} meldet:
49° 0' 0" N, 877° 0' 0" ODie folgenden Fehler wurden in der Syntax gefunden:
Der Wert „8,6673“ ist nicht gültig für den Parameter format. Nur die folgenden Werte werden akzeptiert: float, dms, dm und dd.
Error
Der Wert „primary“ ist nicht gültig für den Parameter directional. Nur die folgenden Werte werden akzeptiert: yes, no, on, off, 1 und 0.
0. Wie kann man dort den Quelltext anschauen? Nur mit Anmeldung?
1. Wird dort wirklich dieselbe Vorlage benutzt? (Gleiche Definition.) Bei unserem Coordinate hier gibt es nämlich nach der Dokumentation gar keinen „Parameter format“, der dort moniert wird, noch „primary“. (Jedenfalls nicht als benannten Parameter. Vielleicht soll das „primary“ aber, und nur im Fehlertext, einen ersten unbenannten, also einen Stellungsparameter bezeichnen? Nur sieht man oben in der angegebenen Einbindung nicht, wo der wäre …) Dagegen funktioniert obige Coordinate-Einbindung hier anscheinend klaglos. Ich würde zuallererst mal die dortige Definition – nur für einen Vorschaublick bitte, um dort nichts zu zerschießen – durch die von hier übernommene ersetzen und dann die Vorschau-Differenzdarstellung anschauen, ob nicht Unterschiede bestehen. Falls darin wiederum Vorlagen benutzt werden, kann man das Spiel ggf. bei denen fortsetzen.
2. Naiverweise würde man annehmen, der Wert 8.6673, eigentlich für EW vorgesehen, sei in einen anderen Parameter gerutscht. Rätselhafterweise.
Alles frei Verfügbar, auch ohne Anmeldung. So wie es sich gehört. Es sind auch alle Vorlagen Abhängigkeiten auf dem neuesten Stand. Die hatte ich in den letzten 3 Monaten frisch importiert. Ich selbst tippe eher auf eine Abhängigkeit mit Time und habe deshalb vorhin auch noch die Sommerzeit Vorlage für Infoboxen nach installiert. Weiß eventuell jemand, wo wir noch ein paar Änderungen im Vergleich zu wp.en vorgenommen haben. Was ich bislang nicht getestet habe, ist die Installation der Java Scripte. Die müssten ja eigentlich unabhängig davon laufen. Gruß Frank schubert (Diskussion) 19:31, 6. Feb. 2016 (CET)
Die Vorlage liefert in der mobilen Wikipedia (Wikipedia-App) kein vernünftiges Ergebniss. Aus {{Coordinate|NS=51.2708|EW=9.5376|type=landmark|dim=2000|region=DE-HE}} wird 51.27089.5376 und die App will das mit dem Telefon aufmachen. --codc Disk14:53, 15. Okt. 2014 (CEST)
Bei meinem aktuellen Versuch, es gab zwischenzeitlich Updates und ich erinnere mich nicht mehr genau daran wie es damals war, werden die Coordinaten als Zahlensalat angezeigt wie oben mit 51.27089.5376 beschrieben - zb im Artikel Landwehrhagen (Ich habe versucht einen Screenshot zu machen aber klappt mit meinem Smartphone irgendwie nicht). Bei den Geokoordinaten wie im Artikel Liste der Stolpersteine in Kassel hingegen habe ich einen Link und bekomme OSM-Karten im Browser angezeigt. --codc Disk14:30, 4. Mär. 2015 (CET)
Es betrifft also nur die "Artikelkoordinaten" rechts oben? Mal als Beispiel der Artikel Salzach: du siehst die Koordinaten in der Infobox unter "Quelle" und "Mündung" korrekt, nicht aber die Koordinaten des Artikels (in der Desktopvariante ganz rechts oben)? --тнояsтеn⇔14:43, 4. Mär. 2015 (CET)
Der Fehler steckt meiner Meinung nach eher in unserer Vorlage als in der App. Die Vorlage schreibt „Zahlensalat“ („Geo-Microformat“) in die HTML-Seite, fügt aber kein style="display:none;" ein, um das Ganze auszublenden. Die Ausblendung geschieht in MediaWiki:Common.css und MediaWiki:Mobile.css, aber es gibt keine Garantien, dass jeder Client die CSS-Dateien auswertet, und offenbar tut die App das auch nicht.
Grundsätzlich sollten Vorlagen eigentlich möglichst keinen „Zahlensalat“ in die Seiten schreiben, und wenn doch, sollten sie ihn per Inline-CSS-Anweisungen ausblenden. Zusätzlich wurde im Abschnitt #Bug im geo-microformat-Tag oben bereits die Frage aufgeworfen, ob der „Zahlensalat“ überhaupt etwas bringt. --Entlinkt (Diskussion) 01:43, 22. Mär. 2016 (CET)
Kannst du die Ausblendung per CSS vornehmen? Ob unsere Vorlage das Geo-Mikroformat richtig auswirft, kann ich nicht beurteilen. Die Spec ist auf Geo (Mikroformat) verlinkt. --тнояsтеn⇔07:28, 22. Mär. 2016 (CET)
Ich habe die Spezifikation jetzt mal kurz überflogen und bin der Meinung, dass das Mikroformat bei uns falsch verwendet wird. Die Spezifikation sieht mehrere Auszeichnungsvarianten vor, darunter im Abschnitt http://microformats.org/wiki/geo#Example_from_RFC2426 eine Variante für den Fall, dass die Dezimalgrade sichtbar ausgegeben werden sollen. Unsinnigerweise gibt unsere Koordinatenvorlage das Markup für diesen Fall aus („Zahlensalat“) und geht dann davon aus, dass irgendein CSS es wieder ausblenden wird.
Im Abschnitt http://microformats.org/wiki/geo#with_value-title ist eine Auszeichnungsvariante für den Fall beschrieben, dass die Dezimalgrade nicht sichtbar ausgegeben werden sollen. Dies würde zu unserer Koordinatenvorlage passen, zum Beispiel nach folgendem Muster:
<spanclass="geo"><spanclass="latitude"><spanclass="value-title"title="37.386013"><spantitle="Breitengrad"><!-- verhindert "Zahlensalat" im Tooltip -->
37° 24′ N
</span></span></span><spanclass="longitude"><spanclass="value-title"title="-122.082932"><spantitle="Längengrad"><!-- verhindert "Zahlensalat" im Tooltip -->
122° 8′ W
</span></span></span></span>
Da man, um dies sinnvoll umzusetzen, die Vorlage (inkl. notwendiger Tests) in einer Art und Weise umprogrammieren müsste, für die ich keine Zeit habe und der jetzige „Zahlensalat“ unter keinen Umständen sichtbar sein sollte, werde ich einfach den „Zahlensalat“ in Vorlage:CoordinateMain und Vorlage:CoordinateMap per Inline-CSS (style="display:none;") ausblenden. Das sollte hoffentlich für alle Clients wirken. Um einen sinnvollen Einbau des Mikroformats müsste sich aber jemand anderes kümmern. In der jetzigen Form ist es meiner Meinung nach nicht sinnvoll. Gruß --Entlinkt (Diskussion) 21:53, 22. Mär. 2016 (CET)
Letzter Kommentar: vor 4 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Bei der durch die Vorlage durchgeführten Verlinkung auf //tools.wmflabs.org/geohack/geohack.php werden protokoll-relative Links benutzt. Diese werden aber sowieso auf https://tools.wmflabs.org/geohack/geohack.php gesetzt, siehe hier. Wäre es möglich das https: bei den Links noch zu ergänzen? Da protokoll-relative Links immer beide Links (http: und https:) als externen Link in der Datenbank anlegen (siehe hier), würde die Änderung viele unnötige Links aus der Datenbank entfernen.--Doktor Wu (Diskussion) 07:21, 9. Mai 2020 (CEST)
Vielen Dank für die Bearbeitung. Erstaunlicherweise scheint diese aber (bisher?) keine Auswirkungen zu haben. Die Links verweisen immernoch auf //tools.wmflabs.org/geohack/geohack.php statt https://tools.wmflabs.org/geohack/geohack.php. --Doktor Wu (Diskussion) 07:01, 18. Mai 2020 (CEST)
@Doktor Wu: Du müsstest etwas Geduld haben. Bloß weil da in einer Vorlage was umgestellt wurde, ist die davon beeinflusste Drittelmillion Artikel nicht zehn Sekunden später bereits neu aufgebaut worden. Die stehen jetzt in einer Warteschlange aufzubereitender Inhalte, und wenn der Server sich langweilt, dann knabbert er an dieser Warteschlange. Schau halt nächste Woche nochmal drauf. VG --PerfektesChaos22:40, 18. Mai 2020 (CEST)
Ich hatte mich nur ein wenig gewundert, weil immerhin schon eine Nacht vergangen war. Mittlerweile sind auch schon die ersten Auswirkungen zu sehen. Ich werde weiter geduldig warten.--Doktor Wu (Diskussion) 05:43, 19. Mai 2020 (CEST)
Naja, gute Software darf sich etwas Mühe geben, damit Bediener weniger Mühe haben... sollte sich hier rechnen. --itu (Disk) 22:24, 24. Apr. 2016 (CEST)
Die Vorlage führt intern zahlreiche Berechnungen durch, unter anderem für Zwecke der Fehlererkennung (siehe Kategorie:Wikipedia:Koordinaten-Parameterfehler). Dafür benutzt sie die Parserfunktionen der „klassischen“ Vorlagenprogrammierung, insbesondere #expr für mathematischen Berechnungen.
Die Parserfunktionen der „klassischen“ Vorlagenprogrammierung bieten nur sehr wenig Spielraum beim Eingabeformat. Als die Vorlage im Jahr 2007 erstellt wurde, gab es keine anderen Möglichkeiten. Durch Lua-Programmierung wäre es mittlerweile vielleicht möglich, das Eingabeformat flexibler zu gestalten, dazu müsste aber die gesamte Vorlage neu geschrieben werden und das hat bisher niemand in Angriff genommen. Prinzipiell wäre das aber – auch aus anderen Gründen – wahrscheinlich durchaus sinnvoll (unter anderem auch aus Performancegründen, da die „klassische“ Vorlagenprogrammierung ziemlich langsam ist). Gruß --Entlinkt (Diskussion) 21:50, 27. Apr. 2016 (CEST)
Problem mit Space in mehrteiligen Regionen
Letzter Kommentar: vor 8 Jahren8 Kommentare2 Personen sind an der Diskussion beteiligt
Seit neuesten (?) verträgt die {{Coordinate}} keine spaces in mehrteiligen Regionen, etwa „region=FR-43 / FR-66“. Ursprünglich erfolgte die Zerlegung mittels {{#titleparts:}}. Da sich aber {{#titleparts:}} nach wie vor wie erwartet verhält, vermute ich mal eine nicht vollständig getestete Optimierung in Coordinate. Die wenigen Auftreten der spaces um den Trenner dürfte ich gefixt haben. Es wäre schön, wenn individuelle, an vielen Stellen übliche, Benutzerschreibweisen nicht zu Problemen führen. lg --Herzi Pinki (Diskussion) 05:29, 19. Jun. 2016 (CEST)
Meiner Meinung nach liegt das wirklich am ehesten an irgendwelchen Änderungen im Verhalten von #titleparts, es sind lediglich die Testfälle oben nicht optimal gewählt. Neue Testfälle:
Eingabe
Ausgabe
x{{#titleparts:FR-43 / FR-66|1|2}}y
x FR-66y
x{{#titleparts:FR-43 / FR-66|1|1}}y
xFR-43 y
Man bedenke bitte auch, dass die Parserfunktion #titleparts eigentlich für die Zerlegung von Pfadangaben gedacht ist (siehe mw:Help:Extension:ParserFunctions##titleparts) und hier missbräuchlich zweckentfremdet wird.
Die Zweckentfremdung technischer Mittel ist immer ein Problem, weil sie zuerst lange funktionieren kann, dann aber plötzlich nicht mehr, weil Änderungen natürlich auf die zweckgerechten Verwendungen hin optimiert werden und nicht auf die Zweckentfremdungen (für Pfadangaben ist das Erhalten der Leerzeichen möglicherweise sinnvoll).
Denkbar wäre aber auch, dass einfach nur die Erinnerung täuscht und dass das Verhalten der Parserfunktion #titleparts in Wirklichkeit „schon immer“ so war, wie es jetzt ist. Gruß --Entlinkt (Diskussion) 14:36, 19. Jun. 2016 (CEST)
PS: Äh, nein, #titleparts ist wirklich die völlig falsche Fährte. Für die Konstruktion des Links auf den Geohack wird der {{{region}}}-Parameter einfach nur 1:1 durch zig Untervorlagen gereicht und landet am Ende 1:1 in Vorlage:CoordinateLink, wo keinURL-Encoding stattfindet. Daher entspricht das Verhalten bei Leerzeichen im {{{region}}}-Parameter den Erwartungen. (An einigen anderen Stellen wird der {{{region}}}-Parameter auch mit #titleparts manipuliert, diese sind aber für die Konstruktion des Links auf den Geohack nicht relevant.)
Prinzipiell wäre es wohl möglich, an geeigneter Stelle einen Aufruf der Parserfunktion urlencode einzubauen. Ich würde das aber als relativ riskant einschätzen, da dies zu einem Anstieg der Post-expand include size bei jeder Einbindung führen würde (unabhängig davon, ob der {{{region}}}-Parameter in der jeweiligen Einbindung Leerzeichen enthält oder nicht). In Anbetracht der bekannten Performanceprobleme der Vorlage würde das mit hoher Wahrscheinlichkeit dazu führen, dass einige Seiten in der Kategorie:Wikipedia:Maximale Seitengröße durch Vorlageneinbindungen überschritten aufschlagen und nicht mehr korrekt angezeigt werden. Gruß --Entlinkt (Diskussion) 15:19, 19. Jun. 2016 (CEST)
Danke für die Analyse, ich stimme dir in vielem zu, aber der Mangel war nicht die Verwendung von #titleparts (zum damaligen Zeitpunkt), sondern die für Programmierer enttäuschende Ohnmacht der MediaWiki-SW in Bezug auf Stringmanipulation (ev. lässt sich ja #titleparts an dieser Stelle durch Lua ersetzen). Erinnerung kann täuschen (d'accord), und alle Fehlverwendungen, soweit ich sie gefunden habe, stammen von user Århus aus jüngerer Zeit. Könnte also sein.
{{Str replace|{{{region|}}}|[%s]|||ja}}
an der Übergabe an Vorlage:CoordinateLink würde denselben Zweck erfüllen, ISO-Codes sind mW nach spacefrei. Aber auch das würde den Code aufblähen. Wenn wir davon ausgehen, dass das nicht durch eine jüngst erfolgte Änderung verursacht wurde, dann kann das Verhalten auch so bleiben. Danke. lg --Herzi Pinki (Diskussion) 15:57, 19. Jun. 2016 (CEST)
Hallo, erstmal zum historischen Aspekt: Die Entwickler hatten gute Gründe, die Stringfunktionen seinerzeit nicht freizuschalten, da so ein Schritt einerseits unumkehrbar ist (Vorlagenprogrammierer machen von solchen Mitteln sofort Gebrauch und geben sie niemals wieder aus der Hand) und man andererseits bereits vorhergesehen hat, dass es nicht lange dauern wird, bis die Vorlagenprogrammierer noch mächtigere Werkzeuge einfordern werden. Darüber hinaus hatte die Implementierung der mw:Extension:StringFunctions auch Performanceprobleme. Deshalb hat man sich dafür entschieden, die Stringfunktionen nicht freizuschalten und stattdessen an der Einführung einer vollwertigen Programmiersprache zu arbeiten, die mittlerweile verfügbar ist. In der englischen Wikipedia ist die entsprechende Vorlage übrigens bereits in Lua neu geschrieben worden (en:Module:Coordinates), bei uns hatte man die Geduld nicht.
Und wieder on-topic: Meines Wissens wäre der Einbau von urlencode im Hinblick auf die Post-expand include size effizienter als ein Aufruf der Vorlage {{Str replace}}, da die Vorlage wiederum ein Lua-Modul aufruft. Das Komplexitätsmaß bei der Post-expand include size ist aber (leicht vereinfacht gesprochen) die Stringlänge multipliziert mit der Verschachtelungstiefe (vgl. phab:T15260#170708). Die Verschachtelungstiefe ist bei Verwendung der Vorlage um 1 größer.
Alles in allem könnte man es durchaus einfach mal ausprobieren (und bei Problemen reverten), ich würde darauf aber eher verzichten, da die Einschränkungen im Gebrauch nur gering sind. Längerfristig führt m. E. kaum ein Weg daran vorbei, die Vorlage in Lua neu zu schreiben (allerspätestens dann, wenn die in phab:T15260#170708 angedrohte Senkung der Parserlimits kommt, wobei nicht klar ist, ob sie kommt; es gibt aber auch genug andere Gründe für einen Neuschrieb, z. B. die Wartbarkeit des Codes). Gruß --Entlinkt (Diskussion) 16:30, 19. Jun. 2016 (CEST)
@Die Entwickler hatten gute Gründe, …: Aber die user sind erfinderisch. Man kann nichts idiotensicher machen, weil die Idioten so erfinderisch sind. Oder: Geht nicht - Gibt's nicht! Für die Komplexität der {{Coordinate}} und die notwendigen Info-Vorlagen und passenden Karten und die vielhunderttausendfache Verwendung funktioniert das doch alles prächtig. Und natürlich lässt sich das iterativ verbessern (wie schon einmal geschehen). Was alles geht siehst du auch an z.B. der Stringarithmetik. Daran hat auch keiner gedacht. lg --Herzi Pinki (Diskussion) 16:59, 19. Jun. 2016 (CEST)
Hallo Herzi Pinki, jetzt werden wir wirklich off-topic, aber ich denke, das ist schon OK, weil in der Sache wohl nicht wirklich etwas zu tun ist …
Also off-topic: Gerade die besonders „erfinderischen“ Hackereien der Vorlagenbastler sind mit ein Grund dafür, dass in diesem Bereich die Entwicklung der Software tendenziell eher zögerlich verläuft, weil man bei jedem Mittel, das man den Vorlagenbastlern vielleicht sogar gern zur Verfügung stellen möchte, zuerst genauestens untersuchen muss, wie es im Worst-Case missbraucht werden kann, da in der Praxis auf alle Fälle jeder Worst-Case-Missbrauch, der möglich ist, auch gemacht werden wird. Die „erfinderischen“ Hackereien zahlen sich also vor allem kurzfristig aus, langfristig kommt es dadurch zu einem Innovationsstau.
Reales Beispiel: Die Diskussion über die Einführung von Lua in der Vorlagenprogrammierung lässt sich mindestens bis 2009 zurückverfolgen (vgl. phab:T8455#110965), tatsächlich eingeführt wurde es aber erst 2013. Das liegt nicht an Faulheit der Entwickler, sondern einfach daran, dass man zuerst alle performancekritischen Missbrauchsmöglichkeiten erkunden und so weit wie möglich ausschließen wollte, da ein freiwilliger Verzicht der Vorlagenbastler auf performancekillende Praktiken ziemlich utopisch wäre. Auch interessant: mw:User:Sumanah/Lua vs Javascript (zur Wahl der Programmiersprache, die letztlich hauptsächlich durch Performance motiviert war).
Mit der „iterativen Verbesserung“ und dem „prächtigen Funktionieren“ ist das so eine Sache. Ich habe eigentlich eher den Eindruck, dass bei jeder bisherigen Iteration ein Stück des ursprünglich zwar nicht besonders performanten, aber zumindest stringenten Designs der Vorlage verloren gegangen ist, weil der jeweils aktuelle Programmierer es einfach nicht vollständig verstanden hat; siehe hierzu auch Softwareerosion.
Beispiele:
Früher konnte man im durch die Vorlage generierten Markup leicht unterscheiden, ob die Vorlage nur eine Artikelkoordinate erzeugt oder ob sie eine Artikelkoordinate zusätzlich zur Textkoordinate erzeugt. Verlorengegangen, weil der Programmierer nicht verstanden hatte, warum es manchmal ein <div> und manchmal ein <span> war.
Früher gab es eine Einbindung der Vorlage:Info ISO-3166-2:??, wenn der {{{region}}}-Parameter mit einem inexistenten Code befüllt war, mittlerweile hat die Koordinatenvorlage das komplett verlernt und erkennt nur noch einen komplett fehlenden Parameter (Difflink habe ich nicht parat, tippe aber darauf, dass das mal entfernt wurde, weil man’s nicht verstanden hat). Die Positionskartenvorlage kann es übrigens noch.
Früher haben alle Koordinaten dieselben Konsistenzprüfungen durchlaufen und der Code war weitgehend frei von Redundanzen. Durch die Spaltung in Vorlage:CoordinateComplex und Vorlage:CoordinateSimple ist das verlorengegangen, seitdem durchlaufen die Koordinaten im letzten Fall nur noch wenige Konsistenzprüfungen und der Code ist in großen Teilen redundant vorhanden. Wäre durch Warten auf Lua vermeidbar gewesen, jetzt muss es aufwendig wieder zusammengeführt werden – oder eben auch nicht.
make it run, make it right, make it fast, make it small (und dann wieder von vorne, refactoring, …). Das Problem heute, du musst mit halbfertigen Zeugs auf den Markt, sonst kommst du nie. Ich verstehe deine Argumente wohl, aber Legacy-code ist kein WP-spezifisches Problem. Ich finde es eh toll, dass du so dahinter bist, den Legacy-code wegzubekommen, es dauert halt. Die {{Coordinate}} hat damals eine wesentliche Datenqualitätsverbesserung bewirkt, durch die vielen Prüfungen. Meine Anmerkungen sind philosophisch zu werten, und ja, die Neuimplementierung von {{Coordinate}} ist ein Kompromiss. lg --Herzi Pinki (Diskussion) 18:45, 19. Jun. 2016 (CEST)
Prüfung auf fehlerhafte Region
Letzter Kommentar: vor 8 Jahren15 Kommentare3 Personen sind an der Diskussion beteiligt
Mit der Neuimplementierung der {{Coordinate}} ist, so scheint es, die Prüfung auf zulässige Werte des Parameters region entfallen. Mit Absicht (?) oder aus Versehen. Jedenfalls führt das dazu, dass sich ein paar 1000 falsche regionen angesammelt haben. In der simple Variante ist diese Prüfung per Design entfernt worden, wenn ich mich richtig entsinne. Auf Anregung von @Thomas Ledl: habe ich eine umfassende DB-Abfrage zusammengestellt, die diese Prüfung offline macht: https://quarry.wmflabs.org/query/11685 (da sind jetzt die simple Coordinaten nicht dabei, da diese in der DB fehlen).
Da das Versorgen der Region offensichtlich, da mit Finden und Lesen der Doku verbunden, schwierig ist (siehe die paar 1000 Fehler), würde ich es befürworten, die Prüfung + Wartungskategorie wieder zu aktivieren. Vielleicht weiß jemand von euch auf die Schnelle, wo das zu geschehen hätte. lg --Herzi Pinki (Diskussion) 01:20, 16. Aug. 2016 (CEST)
Prüfung durch die Vorlage:Coordinate ist insofern ungünstig, da diese dann ja bei jedem Abruf des Artikels durchgeführt wird, was sicher überflüssig ist. Besser wäre eine Prüfung nur vor dem Abspeichern von irgendwelchen Änderungen, aber so etwas gibt die Software vermutlich nicht her. Daher erscheint mir die Lösung mit der DB-Abfrage garnicht so schlecht; wenn man entsprechende Queries auf den Lagewunsch-Seiten verlinkt, werden die (hoffentlich) öfter abgerufen, und dieser Riesenstau entsteht erst garnicht. --Telford (Diskussion) 13:25, 16. Aug. 2016 (CEST)
Wie kommst du darauf? Der Aufruf des Artikels erfolgt gegen den Cache, da erfolgt keine Prüfung. Außer beim Aktualisieren des Cache, und damit natürlich beim Abspeichern. Wenn sich ISO-Codes ändern, kommt an und ab vor, dann müssen alle Artikel markiert werden, die den dann falschen Code enthalten. Auch ohne Änderung am Artikel selbst. Es geht hier, wenn um Performance, dann um die Parserlimits.
Wir hatten mal über Massenänderungen per bot gesprochen. Sieht so aus, dass UA-19 in UA-56 umgebogen wurde. Bzw. VN-64 -> VN-HN. VN-65 -> VN-SG. Lässt sich das per bot machen? lg --Thomas Ledl (Diskussion) 14:41, 24. Aug. 2016 (CEST)
652! Die Gemeinden in Finnland waren gut kategorisiert und effizient zu bearbeiten. So wie ich das machen würde. Die ISO-Region wird aus der Kategorie erstellt, nicht umgekehrt.
Philosophisch gesehen habe ich den Eindruck, diese ISO rechtfertigt ihre Existenz mit derartigen Änderungen, obwohl eine weitsichtige Normierung sich aber dadurch ausweist, dass sie lange hält... --Thomas Ledl (Diskussion) 09:18, 25. Aug. 2016 (CEST)
Durch die Aktivierung von simple sind's jetzt wieder zwischendurch mehr geworden. Apropos gibt es nur in De: in enwiki: 1900 Fehler; in fr 1100; in ru ~450, in it 36 (!); in commons 1600 lg --Herzi Pinki (Diskussion) 13:47, 26. Aug. 2016 (CEST)
Prüfung auf fehlerhafte Region - Verlinkung von quarry results
Letzter Kommentar: vor 8 Jahren10 Kommentare3 Personen sind an der Diskussion beteiligt
ein bisschen SQL nachgeholt. Trotzdem habe ich es nicht zuwege gebracht. Es scheint so zu sein, dass im Output html-tags (insbesondere < und >) escaped werden. Da der Quarry-Aufruf live auf der DB erfolgt, macht es eher wenig Sinn, das Ergebnis eines querys downzuladen, zu formatieren und abzuspeichern. Mein aktueller Stand, vielleicht weiß wer weiter:
Ist ne Webapp, nur mit der Doppeleckklammer wird daraus noch kein Wikilink. ? Aber wenn du eine Lösung erfolgreich vergessen hast, dann gibt es eine Lösung? lg --Herzi Pinki (Diskussion) 20:57, 21. Aug. 2016 (CEST)
Ich hab's direkt im putty und sql getestet. Da hab ich natürlich keinen funktionierenden http-Link. Klingt so als ob sich quarry erfolgreich gegen deine Injection-Versuche wehren würde. --Thomas Ledl (Diskussion) 12:25, 22. Aug. 2016 (CEST)
Letzter Kommentar: vor 4 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Ich bin zu doof... Wie wandle ich denn so etwas coord|29|58|23|N|98|43|15|W|region:US-TX|display=inline,title in de-Koordinaten um? (es handelt sich um Sisterdale, Texas) --Concord (Diskussion) 21:07, 5. Nov. 2020 (CET)
"In der Nähe": Problem bei mehreren Koordinaten in einem Artikel
Letzter Kommentar: vor 7 Jahren9 Kommentare4 Personen sind an der Diskussion beteiligt
Moin, ich hoffe ich bin hier mit meiner Frage richtig: Ich nutze unterwegs ganz gern die In der Nähe-Funktion in der mobilen Ansicht und habe festgestellt, dass das offenbar nur funktioniert, wenn im Artikel nur eine einzige Geo-Koordinate angegeben ist. Manchmal kann es aber aus inhaltlichen Gründen sinnvoll sein, mehrere Koord. im Text zu haben (z.B. Landwehr (Hamburg) oder Sievekingsallee) - allerdings werden solche Artikel dann vom o.g. Tool nicht gefunden bzw. nicht angezeigt. Kann man das irgendwie lösen, indem man z.B. einer Koordinate eine Art Vorrang einräumt? --Uwe Rohwedder (Diskussion) 11:39, 10. Jan. 2017 (CET)
Als Mobilnutzer möchte ich solche "Monsterlisten" lieber nicht angezeigt bekommen, zum einen weil die Ladezeiten über mobiles Internet viel zu hoch sind und zum andern auch das Tabellenlayout für durchschnittliche Smartphonedisplays kaum vernünftig darstellbar. Straßen- oder Parkartikel, in denen zusätzlich einzelne Sehenswürdigkeiten georeferenziert sind, hingegen schon. --Uwe Rohwedder (Diskussion) 17:26, 24. Jan. 2017 (CET)
Die Spezialseite listet ja erstmal nur Artikel auf. Man kann ja selbst entscheiden, ob man einen Listenartikel anklicken möchte. --тнояsтеn⇔18:57, 24. Jan. 2017 (CET)
Man kann natürlich eine der Koordinaten zur "Hauptkoordinate" machen. Diese wird dann rechts oben angezeigt und man müsste die Vorlage:All Coordinates an anderer Stelle im Text unterbringen. Beides geht nicht rechts oben im Artikel. --тнояsтеn⇔16:42, 24. Jan. 2017 (CET)
Hm, ich fürchte, dass sich die beiden Vorlagen gegenseitig ausschließen. Sinn der "All Coordinates"-Vorlage ist m.W. doch, dass alle im Artikel genannten Punkte auf der ausklappbaren OSM-Karte bzw. im Geo-Hack dargestellt werden. Wenn sie im Artikel drinsteht (egal wo im Quelltext), erscheint sie in der Leseansicht vermutlich immer rechts oben. --Uwe Rohwedder (Diskussion) 17:26, 24. Jan. 2017 (CET)
@UweRohwedder: Bei homogenen Listen (die Beispiele oben) halte ich eine willkürliche Hervorhebung einer Koordinate für schlecht. Und es hülfe nicht, alle anderen angezeigt zu bekommen. Anders sieht das bei einer Firma mit Zentrale und Tochterunternehmen aus. Wenns um die Fotolücken geht, dann hilft das Bilderwunsch-API, über den geohack verlinkt und für Liste der Baudenkmäler in Thalkirchen etwa [15]. Üblicherweise erzeugen fehlende Bilder in den Listen implizit Bilderwünsche. lg --Herzi Pinki (Diskussion) 11:32, 20. Apr. 2017 (CEST)
Problem bei Name im Geohack und genereller Lösungsvorschlag
Letzter Kommentar: vor 8 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, seit Jahren gibt es das Problem, dass markup im Parameter Name zu unschönen Anzeigen im geohack und auf den Kartendiensten führt (dort wird z.B. der Wiki-Markup klarerweise nicht interpretiert, aus einem sinnvollen Link wird dann [[sinnvoller Link|sinnvollen Link]]. Dazu kommt, dass der geohack nicht mehr gewartet wird. Parameterwerte für Name kommen von weit außen, aus Lemmata, Infoboxparametern, Userangaben und sind außerhalb einer generellen Kontrolle.
Ich habe in diversen Listen und Infoboxen (Denkmallisten, Naturdenkmäler) im Zusammenhang mit Koordinaten gute Erfahrungen mit der Lua-Funktion WLink:getPlain() gemacht. Ich denke, es ist an der Zeit, diesen Filter tiefer in die Koordinatenimplementierung zu schieben.
in {{Coordinate}} (wohl die einzige Stelle?) schlage ich folgende Änderung vor:
Vom Ergebnis her auf jeden Fall zu unterstützen. Wenn das keine negativen Begleiterscheinungen mit sich bringt (kenne mich mit Lua nicht aus), bin ich dafür. --тнояsтеn⇔20:04, 1. Dez. 2014 (CET)
Kenne mich mit Lua ebenfalls nicht aus, wäre aber sehr dankbar, wenn eine Lösung für das Problem gefunden würde, insbesondere, da Geohack auch nicht in der Lage ist, HTML-Enititäten wie aufzulösen und daher Geschützte Leerzeichen nur als Schriftzeichen an den GeoHack übergeben werden können, diese sind aber wegen ihrer fehlenden Unterscheidbarkeit von normalen Leerzeichen problematisch und werden zudem bei Verwendung des wikEd automatisch durch die HTML-Entität ersetzt (wird gar kein Geschütztes Leerzeichen verwendet, kann dies zu unerwünschten Zeilenumbrüchen in der Namensangabe im Geohack füren). Ließe sich diesbezüglich eventuell die Vorlage:Coordinate dahingehend anpassen, dass sie ein im Parameter name eingetragenes Geschütztes Leerzeichen auf eine Weise an den Geohack übergibt, die der wie gewünscht interpretiert? Verstärkt wird das Problem noch dadurch, dass bei einer reinen Artikelkoordinate der Parameter „name“ nicht über den erzeugten Link übergeben wird, nicht mal dann, wenn er vom Artikelnamen abweicht (eine solche Abweichung ist gemäß den Dokumentationen Vorlage:Coordinate#Bezeichnung und Wikipedia:WikiProjekt Georeferenzierung/Kurzanleitung#Parameter in begründeten Fällen zulässig und vorgesehen). Dies verhindert, dass man bei einer reinen Artikelkoordinate den Parameter „name“ benutzen kann, um eine geohack-konforme Schreibweise des Objektnamens festzulegen und an Geohack zu übergeben. --X:: black ::X (Diskussion) 04:56, 16. Jan. 2016 (CET), aktualisiert 13:52, 8. Feb. 2018 (CET)
DMS wird zu DM
Letzter Kommentar: vor 2 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Wenn der dim-Parameter nicht belegt ist, wird abhängig von type eine Annahme für dim getroffen, und die ist bei type=city ziemlich groß --> es wird automatisch gerundet. Abhilfe: dim sinnvoll setzen, dann erscheinen auch die Bogensekunden. --Telford (Diskussion) 11:44, 15. Mär. 2020 (CET)
Letzter Kommentar: vor 2 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
deshalb wäre eine Abschnittsüberschrift oder zumindest ein Anker ersatzweise hilfreich vor folgendem nötig:
"Für Objekte auf anderen Himmelskörpern als der Erde wird dieser mit dem Parameter globe angegeben. Er ersetzt die Angabe der region, ISO-3166-Codes bezeichnen ausschließlich Regionen auf der Erde. Mögliche Werte sind die englischen Namen der Himmelskörper in Kleinschreibung; eine vollständige Liste findet sich mit der Kategorie:Vorlage:Info globe. Eine Angabe von globe=earth ist überflüssig."
Letzter Kommentar: vor 2 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin zusammen, mich würde gerne mal interessieren, was der Parameter "lw" macht, da dieser nicht dokumentiert zu sein scheint. Vielen Dank für eine Info. mfg --Crazy188009:48, 21. Mai 2022 (CEST)
Ahhh @DB111, dann heißt es ja übersetzt, wenn Parameter lw= "+" dann "einfach", "-" dann "schwierig" und "h" wäre "historisch", lese ich das richtig? Darf ich dies dann so in das TemplateData ergänzen? mfg --Crazy188019:11, 21. Mai 2022 (CEST)
Letzter Kommentar: vor 2 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Guten Abend! Ich habe soeben den Artikel Liste der Straßennamen und Ortschaften Klagenfurts eingestellt und einen Fehler bemerkt, gegen den ich nicht ankomme: ganz offensichtlich habe ich zu viele Koordinaten-Infos dazugegeben, sodass ab dem Buchstaben K die Fehlermeldung "Vorlage:Coordinate" kommt. Nun, ich verstehe nicht ganz, warum man heutzutage noch immer nur etwa 500 oder 600 solcher Vorlagen verwenden darf. Sind es Speicherplatz- oder Rechenprobleme? Wo doch jedes größere Bild mehr Speicher und Ladezeit benötigt. Das Problem zieht nämlich einen langen Rattenschwanz hinterher: auch alle anderen Vorlagen wie zum Beispiel TOC (oder Vorlage:DEU-1935 und Vorlage:AUT-1934) funktionieren deswegen ab einer gewissen Stelle nicht mehr. In diesem speziellen Fall passt alles nur noch bis zu dem Buchstaben K, danach, ab L, kommt die Fehlermeldung "Vorlage:Anker". Auch wenn ich für die Links Vorlagen verwende (wie zum Beispiel ANNO-Links), würde eine Fehlermeldung kommen, wenn ich die Links nicht so umgeformt hätte, dass ich keine Vorlage mehr benötige. Kann mir da jemand helfen? Den Artikel in mehrere Teile zerlegen würde ich nicht wollen, weil man die Tabelle dann zum Beispiel nicht mehr nach den jüngsten Straßenumbenennungen ordnen könnte, ohne alle Teile untersuchen zu müssen. Auch die vielen Koordinaten-Informationen würde ich nicht missen wollen, denn aktuell kommt man mit einem Klick sofort zu einer Landkarte, auf der man die Straße sehen kann und ich bin der Meinung, dass der Artikel ohne diese Koordinaten einiges an Charme verlieren würde. Außerdem wundert es mich, dass nicht automatisch ein Inhaltsverzeichnis angelegt wird bei diesem Artikel (Laut der Hilfe:Inhaltsverzeichnis erscheint sie standardmäßig ab der Verwendung von vier Überschriften unmittelbar oberhalb der ersten Überschrift – was in diesem Fall aber leider nicht passiert). --DJGrandfather (Diskussion) 15:35, 25. Jun. 2022 (CEST)
Wenn man die Vorlage mit Parameter simple=y benutzt, was dann aber Angabe der Koordinaten in Dezimalform erzwingt, dann bewältigt der Wiki-Parser etliche Koordinateneinbindungen mehr, meiner Erinnerung nach 1500–2000, was aber von der „Schwere“ der Seite abhängt. Die Einbindungsbeschränkung rührt von der Laufzeitschranke des Wiki-Parsers her, und die wird wohl auch nie fallen, denn sonst müsste man gewärtigen, dass irgendwelche bösen Buben hier Denial-of-Service-Attacken reiten.
Tausend Dank, @Silvicola: Das war genau der Tipp, den ich gebraucht habe. Jetzt sind alle Koordinaten-Links funktionsfähig und auch alle anderen Vorlagen funktionieren jetzt... Ich verstehe nur noch nicht, warum nicht automatisch ein Inhaltsverzeichnis angelegt wird bei diesem Artikel... --DJGrandfather (Diskussion) 19:03, 25. Jun. 2022 (CEST)
Letzter Kommentar: vor 6 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, die Frage ist vermutlich schon mal gestellt worden, aber wurde mal über die Reduzierung der Vorlagengröße nachgedacht? Ich arbeite gerade an der Liste der Kulturdenkmale in Herrnhut und trage dort alle Koordinaten nach. Dabei wird aber nach dem Einbinden der Koordinaten die maximal zulässige Artikelgröße überschritten. Natürlich kann der Meinung sein, dass die Liste eh viel zu lang ist, oder den Artikel problemlos durch Auslagerung von Inhalten in neue Artikel kürzen, was ich dann auch notgedrungen machen würde - aber wenn das nur wegen der Vorlagengröße der eingebundenen Koordinaten nötig ist, finde ich das schon recht überflüssig.
Was genau zur Reduzierung der Vorlagengröße beitragen kann, durchblicke ich zwar nicht, vermute aber, dass es die Vielzahl der Links bei Klick auf die Koordinate sein könnte (?). In dem Falle ein paar laienhafte Fragen:
Gibt es irgendwelche Statistiken, welche der Kartendienste gar nicht geklickt werden und deshalb entbehrenswert sind?
Müssen bei einer sächsischen Koordinate unbedingt die Sowjetische Generalstabskarte, Berliner Stadtkarten oder die Kartendienste aller anderen Bundesländer eingeblendet werden (die teilweise tote Links sind)? Kann man die Einblendung passenderder Links irgendwie vom Ort der Koordinate abhängig machen?
Ein paar andere Links sind auch tot und könnten gelöscht werden.
Das nur mal als Anregung, wie geschrieben komme ich auch so klar, würde mich aber über eine Reduzierung des Aufwandes zur Unterteilung von Listen freuen. Dankeschön.--Lguenth1 (Diskussion) 20:20, 6. Jun. 2018 (CEST)
Kennst du schon den Parameter simple=y (siehe Vorlage:Coordinate#simple)? Dadurch lassen sich deutlich mehr Vorlagen-Aufrufe pro Seite unterbringen.
Vielleicht habe ich ja Tomaten auf den Augen, oder meine Wikipedia spinnt: Im eingangs genannten Artikel sind überhaupt keine Koordinaten drin, und Lguenth1 hat da nicht editiert. Die Liste verwendet die Vorlage Denkmalliste Sachsen Tabellenzeile und somit indirekt Denkmalliste Tabellenzeile, welche ihrerseits Coordinate simple aufruft: wo soll da ein Problem sein? Und dass die maximal zulässige Artikelgröße überschritten werden könnte, halte ich auch für ein Gerücht. @Lguenth1: kannst Du uns mal einen Difflink/Permalink geben, dass wir das Problem sehen können? --Telford (Diskussion) 09:10, 7. Jun. 2018 (CEST)
Das sind jetzt aber Dummy-Koordinaten, die alle auf dem gleichen Wert sitzen. Wenn sich Koordinaten unterscheiden, werden sie auch getrennt angezeigt [18]. Ich denke, man müsste so vorgehen, dass man Abschnitt für Abschnitt mit den richtigen Koordinaten versorgt und schaut, wann es knallt. @Lguenth1: Mich interessiert weiterhin, wo genau (Permalink!) Du das Problem beobachtet hast. --Telford (Diskussion) 10:43, 7. Jun. 2018 (CEST)
Danke für die nochmalige Problemschilderung – heute fällt bei mir der Groschen pfennigweise :-( . In der Sache bin ich erst mal ratlos; mehr als Coordinate simple geht eigentlich nicht, und die wird ja verwendet. --Telford (Diskussion) 12:03, 7. Jun. 2018 (CEST)
Danke für die Rückmeldungen. ich mache solche große Bearbeitungen immer im Word und schaue mir die in der Vorschau an, deshalb war der Link unglücklich (sorry!). Ein besseres Beispiel wäre Liste der Kulturdenkmale in Chemnitz-Kaßberg gewesen. Wenn allein die Vorlagenbeschränkung das Problem ist und sich keine andere Lösung als die Aufteilung der betroffenen Artikel anbietet, muss ich das halt machen. Vielleicht greift jemand trotzdem meine Hinweise zu den vielen toten Links auf den Geohackseiten auf. Ich weiß, dass solches Verteilen von Aufgaben unerwünscht ist und man das besser selber machen sollte. Aber für das Herumpfuschen an einer so wichtigen Vorlage bräuchte man wenigstens ansatzweise Ahnung vom Programmieren, womit ich leider nicht dienen kann. Vielen Dank.--Lguenth1 (Diskussion) 19:14, 7. Jun. 2018 (CEST)
type bietet jetzt nicht wirklich eine Alternative an. Am ehesten würde noch state passen. Oder island / mountain. duck und weg. Um das sauber zu machen, bräuchte es einen zusätzlichen Wert oberhalb von state / country, der sich dann auch für supranationale Gebilde wie die EU, OAU, etc. eignen würde. Die Frage ist, ob sich das für die absehbare Anzahl an Kontinenten lohnt. lg --Herzi Pinki (Diskussion) 12:52, 3. Jan. 2018 (CET)
Bei der aktuell angebotenen Auswahl an "types" eignet sich am ehesten "landmark" mit entsprechend großer "dim"-Angabe. --тнояsтеn⇔12:53, 3. Jan. 2018 (CET)
Das Problem mit landmark ist nur, dass das auch für Erdbeben genutzt wird und die wollten möglichst genaue Angaben, da hilft dim nichts: {{Coordinate|NS=0|EW=20|type=landmark|region=CI|name=irgendwo in Afrika|text=/|dim=10000000}} 0° N, 20° O020. Aber ich habe das mit den Erdbeben schon damals nicht verstanden. Vermutlich braucht es zwei Parameter, einen für die Objektgröße und einen für die Genauigkeit (=Anzeigegenauigkeit). lg --Herzi Pinki (Diskussion) 13:50, 3. Jan. 2018 (CET)
Verstehe den Bezug zu Erdbeben nicht?! Laut Vorlage:Coordinate#Ausgabeformate sollte die Rundung mit text=DEC und text=DMS funktionieren (nicht mit text=/). Wie man am Beispiel sieht, geht es aber nur mit text=DEC:
{{Coordinate|NS=0|EW=20|type=landmark|region=CI|name=irgendwo in Afrika|text=DEC|dim=10000000}} → 0° N, 20° O020
{{Coordinate|NS=0|EW=20|type=landmark|region=CI|name=irgendwo in Afrika|text=DMS|dim=10000000}} → 0° N, 20° O020
{{Coordinate|NS=0.6666666|EW=20.6666666|type=landmark|region=CI|name=irgendwo in Afrika|text=DEC|dim=10000000}} → 1° N, 21° O0.666666620.6666666, obwohl bei Kontinenten nicht notwendig.
Dann ist also die Aussage in der Doku "Eine automatische Rundung erfolgt bei der Standardausgabe DMS sowie bei DEC, wobei der Parameter dim, also die Größe des Objekts, in die Rundung einfließt." falsch? --тнояsтеn⇔15:44, 3. Jan. 2018 (CET)
Wir können gerne über landmark diskutieren (und alles andere, was nicht oben rein passt.), ich halte das aber für Kontinente nicht für geeignet, v.a. wegen der dahinter stehenden Landmarkenfantasie. Maximal als workaround für fehlende types. Gerundet wird nach Doku und Implementierung bei landmark, aber bestenfalls auf Sekunden. Wikipedia:Technik/Cloud/geohack (mw:GeoHack#params) hat allerdings auch keinen passenden Vorschlag (ev. satellite). D.h. dann type=landmark|text=DM (Rundung auf Minuten)? @Man77: magst du damit leben? lg --Herzi Pinki (Diskussion) 17:50, 3. Jan. 2018 (CET)
Ich kann mit vielem leben. Aber eigentlich denke ich primär an die Artikelkoordinaten, und weniger an die Textkoordinaten. Dafür ist type=landmark|text=DM nicht wirklich die Lösung.
Auch beim Kalifornischen Längstal, das wohl auch eher ein landmark als alles andere ist, finde ich den sekundengenauen Output trotz Mega-dim etwas störend.
Und ein Erdbeben ist meiner Meinung nach kein geographisches Objekt, bzw. ein Epizentrum etwas, das mit kleinem dim so gesteuert werden kann, dass es einen weniger hart gerundeten Output haben darf, als ein Kontinent oder eine Tal bei der WMF-Zentrale. … «« Man77 »»(A) wie Autor18:46, 3. Jan. 2018 (CET)
Sorry, mein Fehler, Artikelkoordinate kümmert sich nicht um deine Wünsche. Hast Recht. Also bleibt ein type≠landmark (entweder einer von den existierenden (pragmatischer Weg) oder ein neuer). Alternativ kann die Implementierung so geändert werden, dass für Erdbeben was anderes passiert. Ich verstehe allerdings das Bedürfnis, für Erdbeben das Epizentrum mit den Koordinaten zu markieren. Alles was nicht pragmatisch ist, kann länger dauern. lg --Herzi Pinki (Diskussion) 23:03, 3. Jan. 2018 (CET)
Persönlich würd ich sagen, dass, wenn sich schon jemand die Mühe macht, ein dim einzutragen, dieses dim mehr zählen soll als ein Defaultdim eines type. type=landmark|dim=5000000 soll, würd ich sagen, auf Ganzgrad runden, type=landmark|dim=100000 auf Bogenminuten, type=landmark|dim=1 von mir aus auf Millisekunden. Bei den anderen types wird das ja auch so gemacht, wenn ich das richtig sehe. … «« Man77 »»(A) wie Autor12:23, 4. Jan. 2018 (CET)
Ein Kontinent oder das Kalifornische Längstal als Landmarke ist halt schon eine semantische Überdehnung des Begriffs Landmarke, die dadurch zustandekommt, dass alles andere, was nicht oben rein passt unter landmark einsortiert werden soll. Dein Wunsch steht halt im Widerspruch zu der Erdbebenforderung von @Matthiasb: und Erdbeben gibt es mehr als Kontinente. D.h. man kann das nicht so einfach ändern, ohne die Erdbebenanforderung nicht zu erfüllen oder einen neuen type dafür zu definieren. dim beschreibt übrigens die Größe des Objekts, nicht die Genauigkeit der Koordinate (Koordinaten sind immer konkrete Punkte). Und so funktioniert dim auch, über den geohack wird der richtige Kartenausschnitt passend für die Objektgröße ausgewählt. Das Problem ist die Kombination eines großen dim-Wertes mit type=landmark. Der Vorschlag für die Kontinente landmark zu verwenden stammt nicht von mir (state ist genauso unzutreffend wie landmark, hätte aber all die Probleme nicht, die hier aufgeworfen und diskutiert werden, vielleicht könnten wir die nächsten Beiträge mehr auf type≠landmark fokussieren. Das hülfe für die Kontinente. Alternative wäre das von geohack unterstützte satellite (wäre aber kein Objekttyp, sondern eine Angabe der Größe basierend auf der Aufnahmeentfernung, aber es sind ja nur wenige.) Einen zusätzlichen Parameter für die Festlegung der Koordinatenrundung in Coordinate einzubauen, halte ich für zu aufwändig und zu riskant für eine Vorlage dieser Verwendungshäufigkeit und auch nicht im Interesse zentral definierter gleichartiger Formatierungen. Zusammenfassend:
type=landmark: Konflikt mit der Erdbebenforderung, d.h. würde man die Anzeigegenauigkeit ändern, braucht es für Erdbeben eine andere Lösung.
type=state: würde gehen, wenn auch nicht ganz der Spezifikation entsprechend, insb. für große geografische Gebilde
type=satellite: relativ einfache Erweiterung, kann an geohack durchgereicht werden (wird auch in der enwiki nur selten verwendet, aber es wird)
type=<neu>: ist von seiner Auswirkung schwer abschätzbar (geohack?, db?, externe Auswertungen)
Zusatzparameter zur expliziten Auswahl der Anzeigegenauigkeit: Aufwändig zu realisieren, bricht das Ziel einheitlicher algorithmischer Formatierung
Man darf dann aber schon auch dazusagen, dass ein Erdbeben oder ein Epizentrum auch keine Landmarken sind. "Echte" Landmarken, die sekundengenau angegeben werden wollen, aber sinnvollerweise auf einer recht groben ("ganz China") Karte dargestellt werden sollen, sind wohl eher entweder eine Ausnahme oder persönliche Vorliebe des Individuums.
Was wär denn eigentlich ein korrekter satellite? Klingt für mich nach etwas im Orbit um die Erde. … «« Man77 »»(A) wie Autor14:27, 4. Jan. 2018 (CET)
Ehrlich gesagt, ist das vorgetragene Problblem der Kontinente wg. der Uneinheitlichkeit ärgerlich, aber ich habe keine Probleme damit, Kontinente hier als "country" zu definieren, weil es eine Fläche ist, aber ich glaube, daß wir eigentliich zwei neue Parameter brauchen:
building, um die Möglichkeit zu haben, all die Gebäude und Denkmale aus Karten auszublenden, die man im topographischen Zusammenhang womöglich net haben will. In der englischen Wikipedia werden Bauwerke und große Objekte (Antennen, Museumsschiffe) als "landmark" bezeichnet, was ein falscher Freund zu unserer Landmarke ist, die auch als "landmark" definiert werden. Ist wohl schwer zu implementieren, weil im Geohack nicht vorgesehen. Aber vielleicht kann man ja damit anfangen airport und railwaystation (die Parameter gibt es im Geohack) herauszunehmen.
event, dasselbe in Grün für die ganzen Schlachten, Flugzeugabstürze etc., die auch net gerade soviel mit Geographie zu tun haben; vermutlich einfacher zu realisieren, weil es den Parameter in EN gibt (damit wäre eigentlich auch meine "Erdbebenforderung" erfüllt – in EN gelten diese schon lange als "event", im Sinne von event = Ereignis; der eigentliche Mangel, den ich 20085 gemeldet hatte, ist durch die in der Infobox verwendeten Positionskarte weitgehend unbedeutend geworden; außerdem ist der Maßstab im Geohack bei event 1:50.000, also 5mal kleiner als bei landmark).
Eine Einführung der Parameter event, airport und railwaystation (d.h. die Umstellung in den Artikeln) wäre in vielen Artikeln nur eine Frage der Infobox, Nacharbeit fiele da vor allem bei Fließtextverwendungen an.
Und wenn wir schon dabei sind: Geohack kennt auch den Parameter "forest". Wälder sind auch net so richtige Landmarken, und wir bekommen inzwischen mehr und mehr Waldgebietsartikel, knapp 1350 sind es derzeit. --Matthiasb – (CallMyCenter)16:02, 4. Jan. 2018 (CET)
Wenn wir schon mit englischen Vokabeln um uns werfen: Für Halbinseln, Täler, Wüsten, etc., also Dinge, die weder Landmarke noch Gewässer, Insel oder ein anderes extra typisiertes Gebilde sind, würde sich "landscape" anbieten. Ob so eine Neuerung innerhalb eines Jahrhunderts durchgesetzt werden kann und unsere Urenkel die Implementierung noch erleben: Keine Ahnung.
Zu Events: Bin wohl nicht der Progressivste, was das Wann und Wie von Geokoordinaten für einzelne oder wiederkehrende Events ist, aber ein eigener type wär wohl schon passend. … «« Man77 »»(A) wie Autor16:40, 4. Jan. 2018 (CET)
zur Info: auf enwiki herrscht das blanke type-Chaos (577 verschiedene Werte, es ist gut, dass das hierzuwiki auf Werte geprüft wird), davon ~8500 events. Mein Vorschlag wäre das Problem zu teilen:
das ursprüngliche Problem mit den Kontinenten lässt sich lösen, wenn type=state (country ist für Länder (=Staaten) reserviert) verwendet wird. type=landmark könnte, wenn ich @Matthiasb: richtig verstehe, wieder auf die ursprüngliche Rundung in Abhängigkeit von dim zurückkehren, wäre aber für Kontinente mE falsch. Die größten dims auf enwiki kommen übrigens in en:List_of_giant_squid_specimens_and_sightings vor.
Erweiterung um zusätzliche type-Werte in Richtung Vorschlag Matthias. Ich vermute mal, dass der geohack beliebige Werte von type schluckt und die Angabe von dim akzteptiert [19], im Falle unbekannter Werte wird dim=300000 angenommen [20]. Da wir aber dim immer definieren, ist nur der erste Fall im Geohack für neue type-Werte relevant. Außerdem landen auch unbekannte types in der DB. Matthias, kannst du dich noch erinnern, warum damals Werte wie forest nicht unterstützt wurden, lag das an deren Flächenhaftigkeit (shape würde besser passen als Punkt)? Soweit ich das überblicke, sind {{CoordinateComplex}}, {{CoordinateSimple}} und {{Coordinate/XML}} die einzigen drei Stellen, wo der Wertebereich von type geprüft wird. Trotzdem schlage ich ein defensives Vorgehen vor, um Wildwuchs zu vermeiden. --Herzi Pinki (Diskussion) 21:39, 4. Jan. 2018 (CET)
Mir ist da ganz dunkel ein Beirag (von Benutzer:Visi-on?) in Erinnerung, in dem es als Erwiderung auf (m)eine Frage, warum wir einige Werte aus EN nicht unterstützen, sinngemäß hieß, das wäre zu detailiert für unsere Zwecke, und wir kämen mit "landmark" für alles Andere zurecht. Habe ich damals so hingenommen, weil ich von dem Projekt Georeferenzierung damals null Ahnung hatte. Und bezogen auf den damaligen Artikelbestand traf das vielleicht auch so zu oder man hat das Potential im Denkmalprojekt, neuerdings werden auch die tolpersteine georeferenzier, nicht gesehen. (Hinweis: Ob das wirklich Visi-on geantwortet hat, und ob die Frage von mir stammte, würde ich nicht vor Gericht beeiden wollen.)
Ich kann übrigens die herrschende Unterscheidung zwischen "state" und "country" nicht ganz nachvollziehen. Und auch die umseitige Dokumentation ist in diesem Punkt ziemlich vage bzw. widersprüchlich, definiert "country" für Länder und "state" für "andere Staatengebilde" (welche sollen das ein?) und "nicht-souveräne Staaten". Letzteres ist eigentlich Quatsch per se, weil eine Eigenschaft von Staaten ja die Souveränität ist. Gemeint waren aber wohl bestimmte (vielleicht alle?) abhängige Gebiete wie Bahamas, Westsahara oder die Palästinensischen Autonomiegebiete, oder? Ich bin bisher noch nicht in die Verlegenheit gekommen, solche Artikel zu erstreferenzieren, würde aber gefühlsmäßig "state" für Objekte wie Frankreich oder Island, aber auch Bahamas und Co. nehmen. Bliebe "country" für alle Flächenobjekte, die kein Staat, keine Verwaltungseinheit (adm1st bis adm3rd) und kein Gewässer (waterbody) sind, etwa Naturregionen wie Kraichgau (im Sinne von "the country between Odenwald and Schwarzwald") oder Wachau, aber auch Großregionen wie Norddeutschland. Oder Westeuropa. Wälder würde ich da jedenfalls tendenziell nicht zuordnen, weil diese allfällig viel geringe Ausmaße (im Bereich bis unter wenige hundert Meter) annehmen können, während das, was wir üblicherweise mit "country" verwenden mindestens eine Dimension von Dutzenden Kilometern hat. Was du übrigens mit "shape" statt Punkt meinst, das spräche übrigens zusätzlich dafür, Wälder aus den Landmarken herauszunehmen und "forest" entsprechend zu definieren. --Matthiasb – (CallMyCenter)04:55, 5. Jan. 2018 (CET)
natürlich: ich sehe jetzt keinen Grund mehr, der dagegen spricht, nach einer Abstimmungsphase neue types einzuführen.
Erweiterung des Wertebereichs von type - Geohack / weitere Kartendienste
@Kolossos, NordNordWest:, oben wurde vorgeschlagen, die für Koordinaten zulässige Werte von type zu erweitern. Könnt ihr aus Sicht von Geohack beurteilen, welche Risiken damit verbunden sein könnten? Es gibt die folgenden Fälle:
Erweiterung um Werte, die im Geohack vorgesehen sind (z.B. event) siehe mw:GeoHack#params - ich vermute mal ohne Probleme
Erweiterung um Werte, die im Geohack nicht vorgesehen sind (z.B. building). Auf enwiki gibt es alle möglichen Werte. Und die scheinen primär mal nicht zu stören.
Für den Kartographer sind jede Menge von Objekttypen vorgesehen, wenn sie im Kontext der Koordinaten definiert sind, dann sind sie einfacher zu übernehmen.
Das oben muss ich mir erstmal in einer ruhigen Stunde zu Gemüte führen, bevor ich hier was beitragen kann. NNW12:06, 9. Jan. 2018 (CET)
Da ich vom Geohack wenig Ahnung habe, kann ich gar nichts dazu sagen. Eine Erweiterung der type-Palette könnte ich mir aber schon sinnvoll vorstellen. NNW11:01, 11. Jan. 2018 (CET)
Mut kann man nicht kaufen und v.a. kann keine anderer den Mut haben, deine Aktionen vorab abzusegnen. Mein Vorschlag:
Wir erweitern type vorsichtig um neue Werte.
anfangs an ausgewählten Stellen
unsere Coordinate-Vorlagen müssen den Parameter akzeptieren
dann in ausgewählten Infoboxen (die Strategie ist, das einfach wieder rückgängig machen zu können)
erst dann, wenn alles funktioniert, erfolgt die allgemeine Freigabe und Dokumentation auf der Vorderseite.
dim würde ich zumindest für airport und railwaystation heruntersetzen. Ich kenne zumindest keinen Flughafen oder Bahnhof, der mehr als 10 km im Durchmesser misst. --тнояsтеn⇔07:59, 23. Jan. 2018 (CET)
Die Werte oben sind die Standardwerte, wenn du dim nicht explizit angibst. Wenn du andere Werte einträgst, wird der Standardwert überschrieben. Was meinst du mit Kontrolle? Was soll kontrolliert werden? --тнояsтеn⇔15:27, 23. Jan. 2018 (CET)
@Woelle ffm: momentan gibt es nix zu ändern und du sollst auch nix ändern. Hier 7 Tage, dann probeweise Umsetzung an einigen ausgewählten Stellen und jedenfalls nicht im ANR, dann kann man z.B. in der DB schauen, ob die Werte dort ankommen, ob das BWapi diese Objekte immer noch anzeigt, ob sie im Kartographer funktionieren. Dann auf Beschwerden warten. Du kriegst Bescheid, wenn es was zu tun gibt. lg --Herzi Pinki (Diskussion) 16:24, 23. Jan. 2018 (CET)
Mein grundsätzliches OK steht ja oben schon irgendwo. Ich glaub halt weniger gut im Blick zu haben, was das Einführen neuer Types eigentlich genau impliziert. Ich vertrau Herzi Pinki aber, dass er weiß, was er hier tut, wenn er was tut :) … «« Man77 »»(A) wie Autor10:34, 30. Jan. 2018 (CET)
so, war mutig. Neue types event, railwaystation, building, landscape & continent. Ich habe getestet, bitte aber um weitere Augen.
Es gibt zwei Stellen, wo ein dafault-dim durchgereicht wird ({{{dim}}} und {{{dim_save}}}, das erste geht an den geohack, das andere an {{CoordinateLink}}, der geohack hat ein sinnvolles Defaultverhalten (im Gegensatz zu neuen Parametern wie continent), und nach {{CoordinateLink}} wird auch für forest eine dim durchgereicht, dort bestimmt sie die Anzeige in D, DM, DMS, DMS,dd. Benutzerdefinierte dims werden immer in beiden Fällen durchgereicht. Ja, das war Absicht. Aber natürlich kann man das diskutieren. lg --Herzi Pinki (Diskussion) 08:54, 13. Feb. 2018 (CET)
Schiffswracks ??? welche Zuordnung ??? Vorlage:Coordinate#type
Unterpunkt für Erweiterungen
Ahoi, es gibt mehr Schiffswracks als Länder. Vorlage:Coordinate#type gibt keinen Hinweis was für Schiffswracks richtig wäre. Oft wird "landmark" oder "waterbody" eingetragen. Die Wichtigkeit des Labels für die Kartenübersicht z.B. per Openstreetmap ist kaum bekannt. Gibt es hier Ideen zur Verbesserung ? LG 80.187.108.9614:32, 11. Feb. 2018 (CET)
ahoi auch, nach dem was Matthiasb oben gesagt hat, würden Erdbeben, Flugzeugabstürze, Schiffsversenkungen und Konzert- wie Sportevents unter event fallen. Die Wichtigkeit des Labels, dein Beispiel ist relativ dramatisch, ist durch Kommunikation und Nacharbeit in die Köpfe zu versenken. lg --Herzi Pinki (Diskussion) 19:37, 12. Feb. 2018 (CET)
Ich würde ein Wrack eher als Teil des waterbody sehen. Aber weder waterbody und auch erstrecht nicht landmark ergibt da wirklich Sinn. тнояsтеn, wo ist denn da das land das markiert wurde? --Jmv (Diskussion) 10:31, 13. Feb. 2018 (CET)
angesichts der neuen types muss die doku noch angepasst werden. Ich habe das noch nicht gemacht, um nicht die Heerscharen zu wecken. Ich mag die neuen Werte mal auf kleiner Flamme beobachten. event würde über landmarke stehen und es ist zu definieren, ob Wracks jetzt events sind. Ich stimme Thgoiter zu, Untergang ist ein event, das wrack ist eine landmark (mit Unschärfen dazwischen). waterbody ist es aber wohl definitiv nicht. lg --Herzi Pinki (Diskussion) 12:45, 13. Feb. 2018 (CET)
Das wäre wahrscheinlich das Beste, allerdings wie bei den anderen Typen auch, in englischer Schreibweise: "wreck". Eine Landmarke sind sie ja wirklich nur, falls sie noch an der Oberfläche zu sehen sind. Die Titanic gehört da bestimmt nicht dazu. --PaterMcFlyDiskussionBeiträge22:12, 18. Feb. 2018 (CET)
Ich bin kein Fan einer immer weiteren Aufgliederung. Wo hören wir auf? Typ "stone", "house", "tree", "church", "harbor", "river" usw. usw. --тнояsтеn⇔22:25, 18. Feb. 2018 (CET)
Ja, das ist genau die Frage, ich weiss auch nicht, wie weit man hier gehen soll. Vielleicht wäre eine Unterstruktur hilfreich, wo dann gleich die ganzen Openstreetmap-Attribute ergänzt werden könnten? --PaterMcFlyDiskussionBeiträge08:00, 19. Feb. 2018 (CET)
Moin, ich glaube die Disk ist nicht zielführend und viel zu ausschweifend. Ein Wrack ist, wenn es der Schifffahrt störend werden könnte in Seekarten verzeichnet, quasi eine landmark, eine Orientierungshilfe . Wo wollt Ihr hin. Eine Insel ist keine Halbinsel (peninsula). Was bedeutet landmark? Wenn ich mich recht erinnere soviel wie Orientierungshilfe oder Grenzstein oder auch Orientierungspunkt oder was dachtet Ihr? landmark gleich Landmarke? Das wäre etwas zu kurz gedacht glaube ich jedenfalls. Gruß -- Biberbaer (Diskussion) 09:17, 19. Feb. 2018 (CET)
Wie schon oben angemerkt, ist der Parameter "landmark" bisher ein Sammler "für Sehenswürdigkeiten, Landmarken, Gebäude, Ortswüstungen und alles andere, was nicht oben rein passt." Also auch Wracks. --тнояsтеn⇔09:44, 19. Feb. 2018 (CET)
+1 Den pragmatischen Vorschlag von Biberbaer finde ich nachvollziehbar und schlage vor, entsprechend in der Beschreibung zu modifizieren: "type=landmark für Sehenswürdigkeiten, Landmarken, Gebäude, Ortswüstungen, Schiffswracks und alles andere, was nicht oben rein passt. " Bei fehlendem Konsens gern zurück. Besten Gruß 80.187.100.23113:08, 22. Feb. 2018 (CET)
Nachdem ich mir einiges im Bereich Schifffahrt angesehen hab, hab ich herausgefunden das uns da noch einiges umfangreiches im Bereich Wracks bevorsteht: Es gibt da U-Bootlisten, deren Einträge bisher da als Wracks rumliegen, (in der Größenordnung 1000-3000, habs nicht genau nachgezählt, es sind die Listen in der Kat: [:Kategorie:Militär-U-Boot (Kriegsmarine)] und + natürlich die Listen der gegnerischen Parteien) für die aber bisher keiner einen Lagewunsch eingetragen hat (aber da finden sich dann noch Leute die es tun, ich werde keine Benutzernamen nennen denn . Aber es wäre wirklich sinnvoll einen "type=wrack" einzuführen: einmal weil es wirklich so viele sind (anscheinend mehr als wir bereits jetzt für alle nicht nur wracks im Lagewunsch-Bereich "landmark" haben, z.Zeit >4000) und weil es dann besser zu verwalten sein wird.
Die Kategorie:Wikipedia:Lagewunsch mit Anmerkung mit ihren Unterkats hat ja bisher keine größere Übersichlichkeit geschaffen. Vielleicht wäre eine Kat "Nicht Auffindbar" (dann aber auch mit grundsätzlicher Ausblendung aus den anderen Lagewünschen, sodas man sich nicht immer wieder durch den Dschungel der Nichterfüllbaren kämpfen muß (ich arbeite meist von bis zu 6 verschiedenen Pcs an verschiedenen Orten, da ist die Markierung der schon besuchten Seiten des Browsers nicht hilfreich)). Das Problem das ich da sehe ist: Wer darf da für alle den Eintrag markieren ( ein Flag setzen), und wie Qualifiziert ist der? (so ne Art Koordinatensichter? Ist vieleicht ja garnicht so schwierig, da ja bisher nur ein kleiner übersichtlicher Kreis von Benutzern, die die Lagewünsche anderer erfüllen vorhanden ist, der sich aber vielleicht mal in Form eines Portals organisieren sollte, oder gibts da schon was von dem ich nix weiß?)
Letzter Kommentar: vor 2 Jahren29 Kommentare8 Personen sind an der Diskussion beteiligt
Hallo,
ich habe ein Problem mit der Vorlage, das ich derzeit nicht lösen kann. Im Artikel Manzhou (Pingtung) will ich unter Verwendung des Globus-Symbols (ICON2, ) mehrere Koordinatenlinks zu Geohack in den Fließtext einbinden. Das klappt leider nicht, und ich weiß nicht, was ich hier falsch eingegeben habe. Könntest sich das bitte jemand mal ansehen?
Seltsamerweise funktioniert die Bild-Koordinaten-Kombination rechts in Labyrinth, aber nicht hier. Sobald man ICON2 durch bspw. „Lage“ ersetzt, klappt alles. NNW12:37, 11. Nov. 2018 (CET)
Hallo @NNW: ist Dein Eintrag an mich gerichtet, oder ist das eine neue Frage? Wenn ersteres der Fall ist:
Mir ist wie gesagt nicht klar, warum folgender Ausdruck nicht funktioniert:
Dieses Problem wird für mich immer undurchschaubarer. Anfänglich gingen nur die Koordinatenlinks in dem o.g. Artikel nicht, jetzt funktionieren auch Koordinaten-Verlinkungen in anderen Artikeln nicht mehr, die vorher ganz eindeutig funktioniert hatten, z. B.
Das sollte nur helfen, das Problem von mehr Seiten zu fassen. Irgendwie hakt es beim ICON2, aber eben nicht immer. Text oder ICON1 haben keine Probleme. NNW13:19, 11. Nov. 2018 (CET)
Mir fällt dieses Problem jetzt zum ersten Mal auf. Ich habe in vielen Artikeln ICON2 benutzt. Das ist ja dann vielleicht ein Fehler in der Vorlagenprogrammierung. Ich hätte gedacht, dass ICON1 einfach nur ein anderes Symbol ist. --Furfur ⁂ Diskussion13:51, 11. Nov. 2018 (CET)
21.98834120.841859 (ICON2), (ICON2, simple), ▼21.98834120.841859 (ICON1) verlinken auf
Der Unterschied besteht im zweiten Parameter ¶ms. Was erklärt, warum der erste Geohack-Link nicht funktioniert. Der link wird zentral in {{CoordinateLINK}} zusammengebaut, die Vorlage hat sich aber schon lange nicht geändert. Hier wird für ¶ ¶ (¶) eingesetzt. So das ist mal ein Ansatz. Ich mach weiter. --Herzi Pinki (Diskussion) 14:34, 11. Nov. 2018 (CET)
Hallo Herzi Pinki, vielen Dank für Deine Hilfe. Dass in dem Link irgendwie der Ausdruck ¶ms= trunkiert wird, hatte ich auch schon gemerkt, aber dann wusste ich nicht weiter. Handelt es sich dann um einen Fehler in {{CoordinateLINK}}? Wer kümmert sich jetzt um die weitere Bearbeitung, nachdem Du das in Phabricator eingetragen hast? Grüße --Furfur ⁂ Diskussion01:27, 12. Nov. 2018 (CET)
es hat nix mit {{Coordinate}} und Untervorlagen zu tun. Sondern mit den Parser, der das Konstrukt, das lt. Hilfe:Bilder korrekt ist, falsch parst. Muss von der MediaWiki-Entwicklung behoben werden, deshalb das Phabricator-Ticket. Du kannst subscriben oder voten, das beschleunigt die Bearbeitung. lg --Herzi Pinki (Diskussion) 01:37, 12. Nov. 2018 (CET)
Erstaunlich ist natürlich das andersartige Verhalten von CoordinateSimple. Ich habe den Vorlagenaufruf im o.g. Artikel als kurzfristige Lösung auf CoordinateSimple umgebaut: funktioniert tatsächlich (auch wenn der Fehler eigentlich ganzwoanders passiert). --Telford (Diskussion) 13:00, 12. Nov. 2018 (CET)
Danke für den Denkanstoß (hab mir selber nicht zugehört), ich versuche das auf
[//tools.wmflabs.org/geohack/geohack.php?pagename=Hirtenberg&language=de¶ms=47_N_16_E [[Datei:Erioll world.svg|15px|alt=Welt-Icon|link=]]] umzustellen und damit sollte dann das Problem im Parser nicht mehr schlagend werden. lg --Herzi Pinki (Diskussion) 15:30, 12. Nov. 2018 (CET)
Hallo @Herzi Pinki:, was macht denn nun ein User, der auf obigem Niveau nicht mitreden kann und einfach die Vorlage "Koordinate im Text" anwenden möchte, die bisher weder mit Icons noch mit Text an deren Stelle funktioniert? Beste Grüße --Martin Geisler13:38, 18. Nov. 2018 (CET)
Wo ist das der Fall? Hier geht's: Beispielirgendwo4816, Beispiel⊙4816, Beispiel▼4816. Nur ICON2 macht Probleme und Bilder: Beispiel4816. Ein Subscribe auf das Ticket oben würde ev. Druck machen, die Behebung in der MediaWiki-SW zu beschleunigen. lg --Herzi Pinki (Diskussion) 14:26, 18. Nov. 2018 (CET)
Hallo @Herzi Pinki:, danke, alles klar. Es ging um bereits existierende Seiten mit ICON 2 (Beispiel Bernhard Hüffer). Bei der Prüfung an einer im Namensraum im Entstehen begriffenen Seite mit „Text“ als text hatte ich wohl das Hochladen vergessen. Sorry und danke für deine schnelle Antwort. Mit besten Grüßen --Martin Geisler15:20, 18. Nov. 2018 (CET)
PS: Das Subscribe ist etwas verunglückt. Bei der Registrieung stand da „Nur Zahlen eingeben“, nun läuft mein Konto als Zahl. Habe das Subscribe wieder rausgenommen. Was wäre denn zu tun? --Martin Geisler16:00, 18. Nov. 2018 (CET)
Ich find das eine ziemlich krasse Regression, welche die Koordinaten auf einem ganz schön großen Haufen Seiten kaputtmacht. 😧 Ist das normal, dass das Ticket jetzt seit 11 Tagen im Phabricator liegt und noch nicht mal eine Prio zugewiesen bekommen hat (bzw. die Prio wieder resettet wurde)? --Ebab (Diskussion) 13:05, 22. Nov. 2018 (CET)
Vom Original übertragen durch Telford (Diskussion) 21:13, 18. Nov. 2018 (CET)
@Tschubby: Bei mir sind in Salvador (Bahia) der Link auf der Poskarte in der Infobox und in Bahia der Link auf Salvador in der Tabelle auch kaputt. Meinst du den?
Das Problem tritt auch bei dem weiter oben konstruiertem Link auf, der nichts mehr mit Coordinate zu tun hat. Vielleicht wollt ihr auch das ticket subscriben @Telford, Tschubby:? lg--Herzi Pinki (Diskussion) 22:31, 18. Nov. 2018 (CET)
Hallo Herzi Pinki, ist ja interessant. Bei mir funktioniert in Bahia der Link auf Salvador korrekt. Ich benutze Windows 10 und den Chrome Browser. Etwa bei der hälfte der Seiten die den Globus als Link verwenden funktioniert bei mir der Link, bei der anderen Hälfte jedoch nicht. Eine Logik kann ich nicht erkennen. Gruss --Tschubby (Diskussion) 23:19, 18. Nov. 2018 (CET)
Ich kann das von Tschubby ursprünglich beschriebene Verhalten nachvollziehen, was meine Theorie, es hätte etwas mit Coordinate:Simple zu tun, erschüttert. – Die Links in Bahia funktionieren bei mir, die gleichen Links in der Vorschau im Bearbeitenmodus jedoch nicht. Restlos ratlos, --Telford (Diskussion) 07:27, 19. Nov. 2018 (CET)
Es geht mir darum, bei der Diagnose caching-Probleme zu eliminieren. In meinem Bahia steht in der Sourceansicht im Browser Cached time: 20181119103948 (FF - yyyymmddhmmss). Auf Chrome schaut das anders aus, Cached time: 20181102010359 und siehe da, das Datum ist anders. Beim Bearbeiten und Vorschau wird immer durch den Parser gejagt, also eine aktuelle Version erzeugt. Das würde erklären, warum die Parserprobleme gelegentlich auftreten. Und, dass sich die Probleme mit jedem Edit verschärfen. lg --Herzi Pinki (Diskussion) 11:58, 19. Nov. 2018 (CET)
tipp bekommen, selbst auf den kopf geklopft, workaround eingebaut, problem ist zwar nicht behoben, aber nicht mehr schlagend. aus meiner sicht hier erledigt. seiten müssen erneut durch den parser gejagt werden (für ungeduldige). lg --Herzi Pinki (Diskussion) 22:03, 23. Nov. 2018 (CET)
Benutze Edge, Firefox, Opera. Bei allen Browsern sind die Koordinaten halb in der Box, halb darüber. Als Benutzeroberfläche "Modern". Wahrscheinlich liegt es bei meinen Einstellungen, soviel habe ich verstanden. Aber welche ist die richtige? Tokota (Diskussion) 05:56, 5. Dez. 2018 (CET)
+1, ich auch. merci, тнояsтеn. @Tokota:, hat mit den Koordinaten nur insoferne zu tun, als die Koordinaten dort oben rechts stehen, wo sie stehen. Denke ich schick dich weiter zu WP:VWS, die können dir eventuell helfen. Löst nicht das Problem, aber beantwortet deine Eingangsfrage. lg --Herzi Pinki (Diskussion) 09:35, 5. Dez. 2018 (CET)
Habe ein Problem mit eventuell unterschiedlicher Behandlung von Coordinaten im geohack oder irgendwo dazwischen. Hilfe von Insidern der nachgelagerten Schichten ist willkommen.
Wo könnte die Stelle sein, die hier in Abhängigkeit von der Hierarchietiefe / nach Herkunft über Artikel oder Kategorie die CoordinateSimple einmal so und einmal so behandelt? lg --Herzi Pinki (Diskussion) 00:28, 29. Nov. 2018 (CET)
Boah, schwierige Frage. Ich hoffe ich habe sie richtig verstanden
wiki-osm.pl nutzt im Hintergrund die Links auf den Geohack da diese Links in der external Link Tabelle stehen. Das ging auch schon 2007. Allerdings macht das das Tool auch nicht selber sondern meines Wissens ein anderes Tool von User:Para und vielleicht ist dessen Datenbank nicht aktuell.
quarry nutzt den später entwickelten Weg Geocoordinaten in die offizielle Geodatenbank zu schreiben https://www.mediawiki.org/wiki/Extension:GeoData Dazu muss es wohl in irgendeiner Untervorlage ein {{#coordinates...}} geben. Aber wo?
Coordinates simple ist ja gemacht wurden, um wie der Name sagt Simple zu sein, also um auch in Listen mit 300 Objekten noch performant zu laufen, das geht vermutlich nicht, wenn man gleichzeitig probiert eine Datenextrationsauswertevorlage drauss zu machen.
@Kolossos: danke für die Angaben, quarry können wir also aus dem Spiel lassen. Ganz hast du das Problem noch nicht verstanden. Meiner Meinung ist es so, dass CoordinateSimple einmal aufscheint (Alle Koordinaten in einer Liste) und einmal nicht (Alle Koordinaten in einer Kategorie solcher Listen: Hier fehlen dann die CoordinateSimple), d.h. an CoordinateSimple allein kann es mE auch nicht liegen oder nur in Kombi mit der Suchtiefe. Dem {{#coordinates...}} kann ich mal nachgehen. lg --Herzi Pinki (Diskussion) 20:58, 3. Dez. 2018 (CET)
Ich habe mal die Tabelle externallinks durchsucht: https://quarry.wmflabs.org/query/31881. Simple und Complex unterscheiden sich in der Parameterreihenfolge, aber mir ist nicht klar, was davon für das Herauslesen relevant sein könnte.
Einbettung in Bildbeschreibung führt zu fehlerhaftem Link
Letzter Kommentar: vor 5 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo zusammen, bislang wurde in der Projektdiskussion Ostfriesland ein Sachverhalt zur Sprache gebracht, der anscheinend auftritt, wenn die Vorlage innerhalb einer Bildbeschreibung verwendet wird. Wenn die Vorlage mit text=ICON2 und simple=y verwendet wird, wird der nachfolgende Text außerhalb der Bildbeschreibung velinkt. Unter Verwendung eines anderen ICONS ist dies anscheinend nicht der der Fall. Bitte einmal prüfen und ggf. beheben.
Durch das Entfernen des Parameters simple (diff) wurde das Problem im Artikel schon behoben. Das fehlerhafte Verhalten ist relativ neu, hat immer gut funktioniert. --тнояsтеn⇔20:35, 17. Dez. 2018 (CET)
Ich bin einfach bloß über und versuche uns über Wasser zu halten. Ich habe {{Coordinate}} weder geschrieben noch die Optimierungen in {{CoordinateSimple}} durchgeführt. Was sich da serverseitig abspielt und in der DB, null Idee. That said: Im konkreten Fall sehe ich keinen Grund, simple=y zu verwenden. simple=y wurde v.a. für viiiiele Koordinaten in Tabellen und Listen eingeführt und um das Limit weiter nach oben zu heben. Das Problem besteht natürlich trotzdem, ich habe am 23.11. als Workaround für phab:T209236 die Reihenfolge der url-Parameter vertauscht: [28] hat aber nur Einfluss auf CoordinateComplex. Inzwischen ist der Bug als behoben gemeldet … Hier geht es aber um {{CoordinateSimple}}. Ist ev. ein anderes Problem. Ich schau mal. lg --Herzi Pinki (Diskussion) 23:01, 17. Dez. 2018 (CET)
Letzter Kommentar: vor 5 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Warum wird beim Anklicken des Lupenzeichens über dem Artikel die OSM-Karte in der Darstellung „Base Layer International“ angezeigt und nicht wie früher in „Base Layer osm“? OSM ist doch wesentlich informativer, und wer einen deutschen Artikel liest, kann doch auch eine informative deutsche Karte vertragen. Nicht jeder weiß, dass man die osm-Darstellung per Hand anwählen kann. Mit freundlichen Grüßen --Martin Geisler19:14, 26. Dez. 2018 (CET)
Das mit dem internationalen Layer war ein Entscheidung, weil wir Jahre lang dafür gekämpft haben, dass es so einen Layer gibt und weil er deutliche Vorteile bietet wenn du dir mal Orte in Thailand oder Ägypten anschaust. Der internationale Stil sollte wenn Labels in der Sprache vorhanden sind immer diese in Benutzersprache anzeigen, also üblicherweise deutsch für Deutschsprachige Nutzer, während der Standard-OSM-Stil nur die Sprache vor Ort (name-Tag) kennt. Ich sehe die deutschsprachige Wikipedia eher als deutschen Reiseführer bzw. deutschen Schulatlas und da erwartet man auch deutsche lesbare Labels. Das selbe gilt auch für andere Sprachversionen in dennen die Karte eingebunden ist. Das die Karte weniger Informationen enthält sehe ich nach vielen Diskusionen mit Kartographen und OSMlern ebenfalls als Vorteil da sie so weniger Überfrachte ist. Der Standard-OSM Stil enthält einach alle Informationen für Mapper das ist nicht unbedingt optimal für Kartennutzer, insbesonders wenn noch Overlays drüber kommen. Wer den Standard-OSM-Stil haben will, muss halt umstellen. --Kolossos11:39, 16. Jan. 2019 (CET)
Letzter Kommentar: vor 5 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Wie kann man die Verankerung unterdrücken, damit insbesondere in Denkmallisten wie in diesem Beispiel Liste der Pässe in Österreich nicht mehrere identische Linkziele, hier 2× #Kerschbaumer Sattel entstehen? Ebenso dort Liste der Kulturdenkmale in Eckernförde 2× #Alte Bauschule, so dass der untere Eintrag „19157 Reeperbahn 57 Alte Bauschule (Erweiterungsbau) siehe auch: Kieler Straße 78“ nie erreicht werden kann. Ich finde die Funktion sollte lieber explizit über die Zuweisung Anker= verwirklicht werden, wem nutzen denn redundante Anker, die immer nur das obere Ziel erreichen können? --Liebe Grüße, LómelindeDiskussion12:12, 15. Jan. 2019 (CET)
Keine Antwort auf die eigentlich Frage, aber m. E. sollten die Koordinaten-Bezeichnungen nicht doppelt vergeben werden, sondern eindeutig so bzw. so. --тнояsтеn⇔15:21, 15. Jan. 2019 (CET)
Ja das wäre sicherlich sinnvoll, aber wer pfüft schon immer alle Parameter durch wenn er etwas ergänzt? Und was ist wenn da jetzt schon ein Link drauf lag? Dann geht das hinterher eventuell kaputt. Oder wenn jemand nichtsahnend einen Eintrag dort ändert, es weiß ja nicht jeder, dass sich dort ein Anker verbirgt. Ich finde das Ganze sehr fehleranfällig. Anker sollte man erkennen können, damit man sie gezielt festlegen oder ändern kann. Mir macht diese Vorlage immer wieder Probleme. Vielleicht verwende ich sie daher auch eher selten bis nie. --Liebe Grüße, LómelindeDiskussion16:09, 15. Jan. 2019 (CET)
Der Anker wird von externen Applikationen verwendet, z.B. hier. Inzwischen sind die Anker auch nicht mehr mehrdeutig, sondern wurden mit Klammerzusatz eindeutig gemacht. Allerdings funktioniert der Anker auf den Kerschbaumer Sattel (Oberösterreich) wegen eines encoding-Fehlers nicht (mehr). Kerschbaumer Sattel (Tirol) funktioniert allerdings. Kann mir das bei Gelegenheit näher ansehen. Da die Anker von WP:GEO verwendet werden, gibt es auch keine Abschaltmöglichkeit. Diese sind auch eher nicht dafür gedacht, manuell drauf zu verlinken. Siehe auch Vorlage:Coordinate#Bezeichnung. Für sonstige Zwecke sollte daher zusätzlich eine manuelle Verankerung verwendet werden. Aber eine explizite Ankerangabe Anker= (als Erweiterung von {{Coordinate}}) oder außen vor über die Vorlage {{Anker}} sorgt mW auch nicht für eindeutige Namen. lg --Herzi Pinki (Diskussion) 15:34, 21. Jan. 2019 (CET)
Umfließen der Karte durch Text gestört
Letzter Kommentar: vor 5 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
In den Artikeln Orcadas-Station und Signy-Station wird die durch {{Coordinate}} erzeugte Karte zwar von der Einleitung erwartungsgemäß umflossen, die Abschnitte nach dem Inhaltsverzeichnis beginnen aber erst unterhalb des letzten Bildes, als ob die Überschrift die Eigenschaft clear:right oder clear:both hätte. Bei Orcadas-Station verschwindet der Effekt, wenn man {{Coordinate}} entfernt, bei Signy-Station lässt sich das (bei nur einem Bild) nicht testen. Verbergen sich da irgendwelche unsichtbaren Zeichen im Wikitext, oder woran kann das liegen? -- Olaf Studt (Diskussion) 13:18, 6. Feb. 2019 (CET)
bei anderen Artikeln, etwa Halley-Station, ist die Anzeige ja auch bei mir (im Browser Edge) normal. Wenn es an Edge liegt, muss also auch etwas im Artikel etwas sein, das von Edge missverstanden wird. -- Olaf Studt (Diskussion) 19:02, 6. Feb. 2019 (CET)
"Es kann nicht mehr als eine primäre Auszeichnung angegeben werden."
Letzter Kommentar: vor 1 Jahr7 Kommentare3 Personen sind an der Diskussion beteiligt
Bei Verwendung der Vorlage Coordinate|NS=47/09/59/N|EW=27/34/12/E|type=railwaystation|region=RO-IS bekam ich die in Überschrift genannte Fehlermeldung. Im Artikeltext sind keine anderen Koordinaten angegeben. Auch nicht als Infobox o.ä. Was kann ich tun? --Kabelschmidt (Diskussion) 19:27, 26. Jun. 2023 (CEST)
Im Quelltext findest du {{Einbindung von Wikidata-Koordinate|building|RO-IS}}. Die Koordinaten kommen also schon von Wikidata. NNW19:54, 26. Jun. 2023 (CEST)
Genau über diesen Punkt habe ich mich gerade ebenfalls gewundert. Die Bildunterschrift für die Karte sollte aus meiner Sicht in jedem Fall beeinflussbar sein. --AFBorchert🍵18:59, 25. Mai 2019 (CEST)
Tippfehler??
Letzter Kommentar: vor 1 Jahr3 Kommentare3 Personen sind an der Diskussion beteiligt
Unter 'Siehe auch' steht 'veralted'. Das schrieb man auch vor der Rechtschreibreform mit einem 't' am Ende. Ich bin übrigens Perfektionist. --ThomasJa276 (Diskussion) 10:21, 11. Sep. 2023 (CEST)
ISO-Region als Pflichtparameter verursacht unnötigen Zusatzaufwand, Redundanzen und verringert die Nutzbarkeit
Letzter Kommentar: vor 5 Jahren14 Kommentare5 Personen sind an der Diskussion beteiligt
Da die Frage nach dem Nutzen des ISO-Region-Parameters bereits vor einigen Jahren gestellt wurde Vorlage_Diskussion:Coordinate#ISO-Region ohne dass sie wer beantworten konnte, frage ich mal, wer dafür ist diesen Parameter optional zu machen oder noch besser gleich ganz zu streichen?
Ein Neueinsteiger, bzw. jemand mit einer geringeren Resignationsschwelle, hat Schwierigkeiten den Wert zu befüllen. Es ist zunächst unklar wofür dieser Wert überhaupt steht und wo eine vollständige Liste zu finden ist. Eine gewöhnliche Suche über Wiki oder auch Google liefert keine sinnvollen Ergebnisse. Die Doku in diesem Template liefert keine Links auf die zugehörigen Listen (wären auch derer zu viele). Bei Gegenden außerhalb des deutschsprachigen Raumes (ohne Schweiz, siehe Kanton_Uri) ist dieser Wert auch in der Wiki oft nicht zu finden. Selbst in Frankreich hatte ich so einen Fall, wo vermutlich Departements zusammengelegt oder getrennt wurden. Da stand im Artikel noch nicht vergeben. Einen Fall hatte ich in Portugal (versuche Lissabon), da fehlen die ISO-Codes offenbar vollständig. Der Wert ist ausschließlich in der deutschsprachen Wiki gesetzt.
Am allerschlimmsten ist aber sicher, dass sich der Code ändern kann, und das meistens nicht durch glatte Zusammenlegung von mehreren Distrikten sondern Teilung irgendwo in der Mitte. Dann ist diese Redundanz sehr gut geeignet, um veraltete Daten zu hinterlassen.
Und nicht zuletzt ist überhaupt nicht klar, wofür der Parameter überhaupt gut ist, außer zusätzlichen Aufwand zu schaffen. Wenn diese Information wirklich so wichtig ist ist sie besser über Wikidata abgebildet abzufragen.
Danke, liebe IP, für den Hinweis und für das Nachtragen der von mir nicht gefundenen ISO-Regionen. Was wäre die Auswirkung gewesen, hättest du es nicht getan? lg, --Thomas Ledl (Diskussion) 09:01, 6. Aug. 2016 (CEST)
Hallo Thomas Ledl, nach unserem gestrigen Gespräch nochmals kurz hier schriftlich, damit auch für andere nachvollziehbar.
ISO-Regionen stellen ein hierarchisches Modell der administrativen Gliederung unseres Planeten dar, und dieses wird in der WP für mannigfaltige Zwecke verwendet. Modelliert ist das Ganze in >5200 Vorlagen.
In Infoboxen u.Ä. für die automatische Generierung von Namen / Lemmas von administrativen Einheiten (z.B. Land Salzburg vs. Salzburg (Bundesland) an einer zentralen Stelle) - dies erleichtert die Codierung allgemein verwendbarer Infoboxen an vielen Stellen.
Zusammen mit einer Gemeindekennziffer u.Ä. Selektion von Metadaten (z.B. Einwohnerzahlen).
In Infoboxen u.Ä. für automatische Kategorisierung von geografischen Objekten wie Bergen oder Seen
In Infoboxen u.Ä. für die automatische Auswahl von Positionskarten
Der ISO-Code steuert die Auswahl der angebotenen Kartendienste im Geohack.
Kein Neueinsteiger muss die region eintragen, es kümmert sich schon jemand ums Nachtragen [29]. Die allermeisten Neueinsteiger tragen überhaupt keine Koordinaten ein, und wenn, dann bewegen sie sich oft im Heimatbereich (ein einziger ISO-Code, den sie mit ähnlichen Artikeln leicht herausfinden sollten.)
Die allermeisten Koordinaten werden aus Infoboxen u.Ä. oder Vorlagen für Tabellenzeilen generiert und müssen idR nicht manuell angegeben werden.
Es stimmt einfach nicht, dass es unklar ist wo die passenden Werte zu finden sind. Wer zu Vorlage:Coordinate#region findet (zwei klicks), darf lesen. Es ist traurig, dass der Wert von einer ausgefeilten Dokumentation oft nicht größer ist als der Wert einer fehlenden Dokumentation.
Die Welt lebt, administrative Strukturen ändern sich. Wie eben in Frankreich, wie 2015 in der Steiermark, wie unlängst auf der Krim, wie Israel / Palästina, wie Südsudan, … Die ISO-Codes hupfen das nach (mit Verzögerung). Wir hupfen das nach und manchmal haben wir temporär schiefe Zustände (etwa seit Jahren der Kosovo, oder gerade FR). Du bist der erste dem das in dieser Absolutheit weh tut.
Natürlich ist der ISO-Code redundant in den nackten Koordinaten, aber es halt schwierig, den Code aus den Koordinaten abzuleiten (Kartendienste machen das mW nicht).
Zunächst mal danke für die Antwort. Ich erkenne die Schwierigkeit, hier Änderungen durchzuführen, als Unmöglichkeit an, und akzeptiere diese, behalte mir aber das Recht vor, das Konzept weiterhin als unsinnig zu bezeichnen, ohne das dabei aber trollmäßig als Provokation mit der Notwendigkeit einer Verneinung verstanden zu wissen ;-)
Nicht zuletzt rühr(t)en meine Probleme bei der Suche des richtigen ISO-Codes daher, dass die gewünschte Information sich in der Doku (nach einem verwirrungsstiftenden Hinweis in die Antarktis) erst hinter dem elften Link innerhalb des Absatzes verbirgt und auch dort nur als Attributsatz hinter einer weiteren Verwirrungsstiftung zu den Ozeanen.
Auch das erste Beispiel mit four corners ist verwirrend. Diese Art der Verwendung findet lediglich bei 4782 Artikeln statt (ca. 1%). Und ist auch seltsam, weil mehrere Regionen für einen konkreten Punkt, das geht schlecht. Das erste Beispiel sollte ein Standardbeispiel sein.
Dass es eine Möglichkeit gibt, die Koordinaten ohne ISO-Code anzugeben wusste ich nicht und steht auch nicht in diesem Doku-Abschnitt. Wie? Einfach leer lassen? Das hat mich auf jeden Fall angespornt mal nachzuforschen und in der Tat gibt es eine nicht ganz ignorierbare Anzahl von Artikeln, bei denen es Auffälligkeiten gibt. Siehe erstes und zweites Statement unten.
Wir hatten auch drüber geredet, dass es irgendwo eine Plausibilitätsprüfung geben soll. Sieht nicth danach aus. Hier finde ich relativ schnell Einträge, die nicht stimmen. Siehe drittes Stmt.
Wenn mir alle Prozesse klar sind und ich sie verifiziert habe mache ich einen Dokuanpassungvorschlag!
Zumindest hab ich jetzt mal einiges gefunden, das wohl zu tun ist.
Es geht mir nicht nur um Bilderwünsche sondern um die Gesamtthematik GEO.
Punkte können an der Grenze liegen (etwa Berggipfel), die Grenze ist die Schnittmenge beider Regionen und daher hat ein Punkt an der Grenze beide Regionen. Extrembeispiel ist Four Corners.
Mir sagen die Select-statements oben nix. Vielleicht hülfe eine verbale Beschreibung. Es ist ja die Frage, was steht in der DB, schon interessant, aber spiegelt sich das auch in der Quelle, der WP? Welche konkreten Fehlerfälle meinst du damit?
zu deiner ersten Tabelle: Ich habe mir das mal im Detail angeschaut:
Aus region = AT-3 wird gt_country=AT und gt_region=3
Aus region = AT wird gt_country=AT und gt_region=null
Die Regionen sind hierarchisch, AT > AT-3, aber beides sind gültige Regionen. Manchmal ungenau (wie in [30]), manchmal bewusst so gewählt (wie in Österreich). Die Modellierung in der Tabelle ist anders als in {{Coordinate}}. Da es in AQ keine Unterstrukturen gibt, erklärt das die erste Zeile (keine regionseinträge in der Antarktis). Wo ist das konkrete Problem? lg --Herzi Pinki (Diskussion) 14:51, 12. Aug. 2016 (CEST)
Nochmal zurück zum Start.
Was muss einer bei ISO-Region eintragen, der den ISO-Code nicht findet, so dass der fehlerhafte Eintrag in irgendeiner Liste auftaucht und dann von irgendjemandem bearbeitet wird?
Welcher Mechanismus, bzw. welche Liste soll dafür sorgen, dass Einträge wie in Liste_der_Kapellen_im_Großarltal dieser Liste der zugehörigen Region (allesamt Salzburg) zugeordnet werden?
Welcher Mechanismus soll dafür sorgen, dass das Literaturhaus_Henndorf im Bundesland Salzburg oder das Holzmuseum_Murau nicht bei Region den Wert AT-9 (Wien) eingetragen hat?
Schade, von vorne mag ich eigentlich nicht anfangen. Ich verstehe den Sinn deiner selects oben nach wie vor nicht. Nach was suchst du? Und wenn du danach suchen kannst, beantwortet das deine Fragen nicht teilweise?
das Wiki-Prinzip. Es gibt keinen allumfassenden Mechanismus. Aber wenn du dein Select einer regelmäßigen Abarbeitung zuführst, gäbe es einen Mechanismus.
Ich denke, wir sind inhaltlich einig, sind nur unterschiedlicher Meinung wie das zu interpretieren ist.
Die Fälle, die ich oben selektiert habe, sehe ich allesamt als falsch an. Dort wo die Region fehlt ab der vierten Zeile (DE) das sind allesamt Fälle (habe etwa 20 überprüft), wo eigentlich ein Bundesland zuordenbar wäre. Das erste und das zweite Select sind identisch, im zweiten werden ein paar Beispiele aus dem ersten geliefert.
Im dritten Select habe ich Datensätze selektiert, die absteigend weit vom Zentrum meiner Selektion entfernt sind. In diesem Fall Wien. Dass die Pfarrkirche_Telfs-Schlichtling nicht in Wien ist leuchtet ein.
Und jetzt überspringe ich wieder ein paar Zwischenschritte (Beweis, dass eh alles...), über die zu diskutieren es sich eh nicht lohnt und komme auf die Schlussfolgerung:
Wie kann ich eine größere Anzahl Personen motivieren die Fehler aus meinen obigen Statements systematisch zu kontrollieren und ggf. zu korrigieren? Allein kriege ich die 10000 Eintragungen mit fehlender Region nie korrigiert.
Ich kann ev. ein Statement machen, wo die Koordinaten gegen die ISO-Region rudimentär (liegt innerhalb des zugehörigen nord-süd-ost-west-Rechtecks) überprüft werden.
Ist die Koordinaten-Parameterfehler-Kategorie die einzige Wartungskategorie oder hat das was ich hier beschreibe wer anderer auch schon gemacht, bzw ist dir bekannt? --Thomas Ledl (Diskussion) 07:43, 13. Aug. 2016 (CEST)
Ungenau ist nicht falsch. region=DE in Thüringen ist bloß ungenau, AT-9 in Tirol falsch. Über ungenau macht es wenig Sinn (sofort) zu reden, ist andere Baustelle. Falsch ist falsch und gehört gefixt.
Wir haben über einen Algorithmus gesprochen, der aus den Koordinaten die Region extrahiert, den scheint es aber nicht so einfach zu geben. Insoferne hast du mit der Redundanz Recht, nur ist es manchmal sinnvoll, teuer zu berechnende Attribute redundant zu führen (der aktuelle Algorithmus lautet: schau auf einem GIS-Dienst nach). Und WP ist keine DB. Es gelten keine Normalisierungsregeln (die mir bei Kopie von Inhalten aber wesentlich mehr aufstoßen).
Zu deinen Fragen:
Die Gretchenfrage. Am ehesten noch mittels viralem Marketing, Gamifizierung, Punktetabellen, … (so wie Aka das macht mit den Klammer- und Auszeichnungsfehlern). In diesem Spezialfall lohnt vielleicht auch edukatives Ansprechen der Hauptverursacher.
Das ist gut. Besser vielleicht eine Funktion, die alle Koordinaten zu einer Region selektiert und auf Kartendiensten anzeigt. Ev. Ausreißer sind da optisch leicht zu sehen. (Ließe sich auch auf die ungenauen erweitern). Analog zu [31]
Andere Wartungstools: [32] (entspricht deiner Rechtecksprüfung für Denkmalbilder auf Bundeslandebene), Kategorie:Wikipedia:Koordinatenwartung, [33] (visuelle Prüfung der Region über den Umweg region -> automatische Kategorie -> Anzeige aller Artikel in Kategorie)
Denkbar, aber wohl schwer umsetzbar (wg. der Stabilität von {{Coordinate}}, gegen die inzwischen erreichte Performance), alle Koordinaten in versteckte Wartungskategorien einzubauen, die dann (immer noch) visuell kontrolliert werden könnten. Ginge mit dem Einbau von {{ISO Kat|Region-ISO={{{region|}}}|Kat-Root=Koordinate|Kat-Schema=in}} in die Coordinate (und versteckte Anlage der interessanten 5000+ Kategorien). Aber man kann identische Funktionalität an die DB-Tabelle der exrahierten Koordinaten anflanschen. D.h. alle Koordinaten zu einem vorgegebenen ISO-Code aus der DB extrahieren und in einer geeigneten Karte darstellen.
Das 3. select ist eine gute Heuristik. Ich habe mich mal betätigt und dir Testdaten weggenommen. Meist war die Region falsch, aber einige Mal doch auch die Koordinaten weit daneben. lg --Herzi Pinki (Diskussion) 16:27, 13. Aug. 2016 (CEST)
Für mich ergibt sich noch ein Problem mit der ISO-Region als Pflichtfeld. Wenn ich Koordinaten z.B. in einer Infobox aus Wikidata übernehmen will (z.B. für headquarter locations) sind dort in der Regel keine ISO-Regionen angegeben. Zur Zeit sind diese bei headquarters location (P159) nicht einmal erlaubt. --newt713 (Diskussion) 22:38, 18. Sep. 2019 (CEST)
Typ "earthquake"
Letzter Kommentar: vor 10 Monaten3 Kommentare2 Personen sind an der Diskussion beteiligt
Wir hatten vor Jahren mal diskutiert, ob die Koordinatentypen (damals gab es nur fünf, wenn ich mich richtig erinnere), um einige ergänzt werden sollen. Aufgrund dieser Diskussion wurden dann die neuen Parameter eingeführt, wie etwa "airport" oder "railwaystation", doch "earthquake" scheint unter den Tisch gefallen zu sein. Kann man das bitte noch nachholen? --Matthiasb – (CallMyCenter)Wikinews ist nebenan!22:32, 3. Jan. 2024 (CET)
Letzter Kommentar: vor 4 Jahren17 Kommentare4 Personen sind an der Diskussion beteiligt
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)
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)
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)
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)
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)
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)
@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)
@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)
@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)
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)
Artikel mit Geokoordinaten werden nicht auf der Karte angezeigt
Letzter Kommentar: vor 4 Jahren10 Kommentare4 Personen sind an der Diskussion beteiligt
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)
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)
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)
Klar, da können wir nochmal in Ruhe schwätzen, da wäre vieles denkbar. Die api.php ist auch nur ein Mini-Wrapper ums WMF-API. Ich könnte Dir sogar eine KML-Emulation liefern, falls Du eine Gegenimplementation des relativ langweiligen WikiMap-Frontends bauen willst bzw. ein 2. Backend-Standbein (neben KMLExport) für osm4wiki brauchst. Kleinigkeiten wie die Ermittlung der Wikidata-ID kannst Du fast schon alleine machen (https://de.wikipedia.org/w/api.php?action=query&titles=Berlin&prop=pageprops&ppprop=wikibase_item). --DB111 (Diskussion) 00:12, 9. Jun. 2020 (CEST)
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)
Koordinaten Fehler Log
Letzter Kommentar: vor 3 Monaten4 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)
тноя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)
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)
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)
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)
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)
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)
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)
@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)
Letzter Kommentar: vor 3 Monaten24 Kommentare10 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)
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.
bei mir (chorme 121, windows 10, verctor 2022) sieht hollenburger brücke normal aus, aber in kloster tatew sind die koordinaten gar nicht zu sehen. gruss, --Wetterwolke (Diskussion) 15:14, 16. Feb. 2024 (CET)
Bei Vector 2022 und bei Mobilgeräten gibt es überhaupt kein „rechts oben“ – deswegen machen wir ja diese ganzen Umstellungen auf den Hinweiskasten. Somit auch nicht bei Kloster Tatew. VG --PerfektesChaos15:45, 16. Feb. 2024 (CET)
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)
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)
Details zur Einkreisung erforderlich
Weil das nicht bei allen, jedoch ab heute bei mehreren auftrat, sind in diesem Abschnitt von allen Betroffenen folgende Infos erforderlich:
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)
PS: Ausgeloggt ist die Darstellung wie vorher, das scheint also ein Problem des Skins zu sein. Grüße --h-stt!?17:54, 16. Feb. 2024 (CET)
Moin zusammen, also Vector2010, Opera aktuell, Windows, in beiden Versionen keine Darstellungsprobleme. mfg --Crazy188018:14, 16. Feb. 2024 (CET)
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)
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)
(CallMyCenter) 09:01, 12. Jul. 2011 (CEST)
--Spischot 06:17, 8. Jun. 2011 (CEST)
Bungertfünfundfünfzig 14:35, 31. Okt. 2014 (CET)
Bungertfünfundfünfzig 15:32, 31. Okt. 2014 (CET)
Gruss --Nightflyer (Diskussion) 10:19, 8. Mär. 2015 (CET)
commander-pirx (disk beiträge) 12:30, 27. Aug. 2018 (CEST)
commander-pirx (disk beiträge) 09:37, 29. Aug. 2018 (CEST)
itu (Disk) 21:43, 21. Apr. 2016 (CEST)
itu (Disk) 22:24, 24. Apr. 2016 (CEST)
(CallMyCenter) 16:02, 4. Jan. 2018 (CET)
--Herzi Pinki (Diskussion) 21:39, 4. Jan. 2018 (CET)
. Aber es wäre wirklich sinnvoll einen "type=wrack" einzuführen: einmal weil es wirklich so viele sind (anscheinend mehr als wir bereits jetzt für alle nicht nur wracks im Lagewunsch-Bereich "landmark" haben, z.Zeit >4000) und weil es dann besser zu verwalten sein wird.
) mehrere Koordinatenlinks zu Geohack in den Fließtext einbinden. Das klappt leider nicht, und ich weiß nicht, was ich hier falsch eingegeben habe. Könntest sich das bitte jemand mal ansehen?
umzustellen und damit sollte dann das Problem im Parser nicht mehr schlagend werden. lg --Herzi Pinki (Diskussion) 15:30, 12. Nov. 2018 (CET)
. Ein Subscribe auf das Ticket oben würde ev. Druck machen, die Behebung in der MediaWiki-SW zu beschleunigen. lg --Herzi Pinki (Diskussion) 14:26, 18. Nov. 2018 (CET)
