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
Letzter Kommentar: vor 17 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Bin gerade frisch zu Wikipedia gestoßen und habe in den letzten Tagen ein paar Artikel mit Koordinaten versehen, wobei die beschriebenen Sache (Burg, Bergwerk etc.) gar nicht mehr existiert. Sollte man hierfür vielleicht ein extra Flag einführen? Ansonsten wird es z.B. für das Google Earth Wikipedia Plugin schwierig, nur real noch existierende Koordinaten anzuzeigen. Evtl. wäre es aber auch besser hierfür eine eigene Vorlage zu nehmen?! --boente 20:07, 4. Jan. 2008 (CET)
Die Koordinate ist eine abstrakte Ortsangabe. Die von dir angesprochene Semantik hängt am georeferenzierten Objekt. Eine sinnvolle Filterung müsste dort über die entsprechende Kategoriserung vorgenommen werden. Theretisch gibt es abzählbar unendlich viele Filterkriterien. Das lässt sich nicht mit ein paar Flags erschlagen. -- visi-on21:54, 4. Jan. 2008 (CET)
Formatierungsproblemchen
Letzter Kommentar: vor 17 Jahren13 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo visi-on, eine Kleinigkeit, momentan steht nur nach den Gradangaben ein , entweder überall (würde mir besser gefallen), oder nirgends. Also 7° 7' 7" N oder 7°7'7"N, aber nicht 7° 7'7" N lg --Herzi Pinki22:26, 10. Jan. 2008 (CET)
Wieso die typographisch korrekten Zeichen dermaßen überlang sein müssen vermag sich mir auch nicht zu erschließen, aber sei's drum. Von mir aus erledigtErledigt -- visi-on07:15, 11. Jan. 2008 (CET)
Was meinst Du mit überlang? Werden bei Dir die Symbole wie bei dem Screenshot falsch angezeigt? Wenn ja, bei welchem Betriebssystem, welchem Browser, welchen Schriftarten und welchen Einstellungen. Ich hatte schon mal danach gefragt. Bei mir habe ich die Schriftart Verdana eingestellt und erhalte damit eine angenehme Darstellung: 7° 7′ 7″ N. --Fomafix14:30, 11. Jan. 2008 (CET)
Jepp, wie auf dem Screenshot. Bei mir OS X 10.4.11 mit Firefox 2.0.0.11 Font ist ziemlich egal ... Sieht halt – xxx – aus, aber deswegen mach ich jetzt nicht ins Hemd. -- visi-on20:51, 11. Jan. 2008 (CET)
Wenn ich das ausprobiere, fehlen die (idealerweise geschützten) Leerzeichen nach den Minuten und nach den Sekunden momentan immer noch. Mache ich etwas falsch? Beispiel: Parameter name fehlt in Fließtextkoordinate49° 45′ 35″ N, 6° 38′ 38″ O49.7596805555566.6440194444444kein Wert in type-Parameterregion-Parameter fehlt6. --TM12:07, 17. Jan. 2008 (CET)
Brauchts die wirklich hinter mm′ss″, ? Oder wieviele geschützte Leerzeichen brauche ich dann hinter DD° bis ich einen äquivalenten Abstand habe? emotionslos -- visi-on13:21, 17. Jan. 2008 (CET)
Was meinst du mit „äquivalent“? Aus typografischer Sicht gehört da eigentlich ein halbes Leerzeichen hin (ein Viertelgeviert), genau wie beispielsweise bei Maßeinheiten (49 cm). Aber da es kein funktionierendes „nicht umbrechendes halbes Leerzeichen“ gibt, wird hier in der Wikipedia üblicherweise das normale (oder  , was das Selbe ist) verwendet. Für obiges Beispiel also so: 49° 45′ 35″ N, 6° 38′ 38″ O und für die Ausgabeformate ohne Sekunden entsprechend so: 49° 45′ N, 6° 38′ O und so: 49° N, 6° O. --TM14:38, 17. Jan. 2008 (CET)
der typographisch notwendige Abstand ist doch bereits mehr als ausreichend in den Zeichen ›′‹ und ›″‹ enthalten. Hingegen muss dem Zeichen ›°‹ künstlich noch mehr Raum (›° ‹) verschafft werden. rein typographisch -- visi-on14:58, 17. Jan. 2008 (CET)
@Visi-on: Dein Browser hat ein Darstellungsproblem mit den Zeichen ›′‹ und ›″‹. Bei mir hat unter Windows mit Firefox, Internet Explorer und Opera und unter Linux mit Firefox und Konqueror und damit bei den meisten Lesern ein ›°‹ die gleiche Breite wie ein ›′‹. Diese Version ist daher schon die richtige. Vielleicht gibt es aber ein Workaround in Deinem Browser, mit dem das Darstellungsproblem bei Dir und anderen Mac-OS-X-Benutzern behoben wird. --Fomafix15:07, 17. Jan. 2008 (CET)
Zur Verdeutlichung: Bei mit und bei den meisten anderen Benutzern sie das derzeit ungefähr so aus: ›7° 7'7"N‹ (Diesmal mit den Ersatzzeichen, die das Darstellungsproblem nicht haben.) --Fomafix15:11, 17. Jan. 2008 (CET)
Letzter Kommentar: vor 17 Jahren25 Kommentare7 Personen sind an der Diskussion beteiligt
Dies ermöglicht das Einfügen dezenter Textlinks in den Fließtext, zum Beispiel „Lage“. Die Werte ›ICON0‹ und ›ICON1‹ setzen die Sonderzeichen ‚⊙‘ respektive ‚▼‘ ein und assoziert so eine Ortsangabe.
mir würde ja am besten gefallen, wenn sie sich an die <ref>-Vorlage anlehnen, also etwa:
die alte Pestleiche[Lage]
oder vielleicht ginge es sogar, den <ref> gleich miteinzuarbeiten, sodaß entsteht
die alte Pestleiche[1]
Einzelnachweise
↑ [1] 51° 1′ 41″ n. Br., 13° 39′ 14″ ö. L.
alternativ auch mit der Vorlage:FN-technik - unabhängig von <ref>
und was bedeuten ‚⊙‘ respektive ‚▼‘ - haben die in der Geodäsie eine bedeutung? könnte man ein genormtes symbol statt dem "Lage" nutzen? (für mich ist Lage die Raumlage, nicht der Ort im Raum)
sonst aber tolle sache, das neue teil, meine hochachtung, und - entgegen den Äußerungen im meinungsbild - imho sauber aufgearbeitet -- W!B:08:33, 11. Jan. 2008 (CET)
Es gibt kein genormtes Zeichen. ‚⊙‘ respektive ‚▼‘ kommen den handschrifftlichen Zeichen wie sie bei der Feldaufnahme verwendet werden am nächsten und beide sind in den meisten Schriftsätzen vorhanden. Also einfach assoziativ.
Ein weiteres Schlüsselwort analog «ICONx» zB. «REF» "Standardausgabe wie in Artikelzeile. Nachteil man muss wissen, dass auch noch <references/> im Text plaziert werden muss. Ziemlich unflexibel.
Es kann ein tags-Parameter übergeben werden. Beginn- und End-Tag umschließen die gesammte Fließtextausgabe. Vorteil, wer den <ref>-tag einsetzt weiß auch, dass er <references/> nicht vergessen darf. Mehr Freiheit kann man dem einzelnen Autoren fasst nicht mehr geben.
Ich halte die ▼ oder ⊙ Lösung für die Beste. Der Kreis ist gegenüber dem Dreieck schlechter erkennbar. Meines Erachtens würde ein farbiges Dreieck die beste Lösung sein. Farbig würde es sich trotz allem noch hervorheben, ließe sich aber noch weiter verkleinern, so dass der Lesefluss nicht gestört wird. .... etwa so: die alte Pestleiche▼ --Arcy21:49, 11. Jan. 2008 (CET)
kannst du natürlich mit meiner Version 2 auch haben ;-) Eigentlich braucht ihr euch nur noch zu einigen ... -- visi-on22:33, 11. Jan. 2008 (CET)
verstehe, das war einmal eine frage, was möglich ist - ich denke, einen sinn gibt nur, was auch für den leser sofort als geo-koordinate erkennbar ist: da es keine genormten zeichen sind, also nur dem geometer vielleicht vertraut, kommt mir das optisch sehr dezent aber unbrauchbar vor- um was es sich dreht, ist also eine art "corporate identity" des Wikipedia:WikiProjekt Georeferenzierung - und das ist traditionell das erd-symbol, dass in der FZW-klickibunti-diskussion ja eher negativ beurteilt wurde - nun gibt es in den standardfonts unter den dingbats ja leider kein unicode-erd/internet-symbol - welches Zeichen könnte man sofort mit dem geo-projekt verbinden, um nicht das icon zu nehmen oder kann man das hochstellen? wohl nicht, weil es nicht mit der schriftgröße skaliert? ♁ U+2641 „Erde“ ? -- W!B:08:50, 12. Jan. 2008 (CET)
Bitte keine Symbole in den Fließtext einbetten! Schon gar keine, bei denen der Leser auch noch raten muss, was sie bedeuten sollen. --08-1509:52, 12. Jan. 2008 (CET)
Die freie Texteingabe ermöglicht sowieso Eingaben nach Lust und Laune. «ICON0» und «ICON1» können da höchstens kanalisierend wirken. Setzt der Autor die ganze Vorlage zwischen Tags, so hat das auf die Artikelkoordinate unerwünschte Nebeneffekte. Da ist mir allemal lieber die ästhetischen Einzelwünsche bleiben auf den Fließtext beschränkt. Persönlich würde ich es noch begrüßen wir könnten uns auf ein Unicode-Zeichen einigen und da würde ich „▼“ den Vorzug geben. „♁“ ist bereits mit Bedeutungen überladen -- visi-on23:03, 12. Jan. 2008 (CET)
Aber wenn schon Symbole, dann bitte ohne Umbruch zwischen Symbol / Icon, ... und den nachfolgenden Koordinaten. Danke --Herzi Pinki00:03, 13. Jan. 2008 (CET)
Achtung! Symbol/Icon ist als Textersatz für die Koordinate gedacht, genug, dass vom Link noch ein klickbarer Rest verbleibt. -- visi-on10:27, 13. Jan. 2008 (CET)
Sorry, mein Fehler. Nur in der jetzigen Variante (Icon + Space + Koordinaten) wird umgebrochen, das habe ich gemeint. --Herzi Pinki17:43, 13. Jan. 2008 (CET)
Die alte Pestleiche[Lage], gefällt mir eigentlich ganz gut, da diese an References angelehnt ist und halbwegs selbsterklärend erscheint. --Kolossos14:30, 13. Jan. 2008 (CET)
Ich denke für Koordinaten im Fließtext sollte ein entsprechendes Meinungsbild auf breiter Basis eingeholt werden, in der die ganze QP-Autorenschaft eingebunden ist. Es gab immer wieder Einwände gegen Koordinaten im Fließtext (Klickibunti, schlechte Lesbarkeit ...). --Arcy16:34, 13. Jan. 2008 (CET)
Die Alternativen zu Koordinaten im Fließtext sind
keine Koordinaten
Tabellen
Text, der die Koordinaten-Information enthält, aber keine Funktionalität, eben nur Text. (z.B. 43°N, 10°O)
ein eigener Artikel je Koordinate, oder Koordinaten in #redirects,
Außerdem geht es hier um die Darstellung von Koordinaten im Fließtext, nicht um die Verwendung derselben im Fließtext. Muss ja keiner verwenden, aber wenn, dann sollte das Layout definiert sein. Ev. kann man die Koordinaten im Fließtext ja auch per monobook.css wegschaltbar machen. --Herzi Pinki17:47, 13. Jan. 2008 (CET)
Sorry, aber ich muss glaub nochmals nachhaken, dass alle vom gleichen reden. Im Fließtext gibt es zwei Darstellungen (siehe Formate).
Bei der textuellen Ersetzung kann man einsetzen was man will, auch Unicode-Zeichen. «ICON0» und «ICON1» machen nichts anderes. Natürlich kann man diesen «Text» kursiv, fett, kursiv und fett, groß, klein, hoch, tief und vieles mehr setzen (zB. auch als Referenz).
Bei der rechnerischen Umwandlung in die gewünschten Ausgabeformate entfallen diese stilistischen Auszeichnungen für Koordinaten, die sowohl im Text als auch im Artikel angezeigt werden sollen. Wenn man das auch noch haben will, muss man der Vorlage die gewünschten «styles» für den Fließtext mitgeben können, denn sonst gelten diese für Fließtext und Artikel. Bisher wurde dies umgangen indem man Koordinate Artikel und Koordinate Text für die gleiche Koordinate aufrief oder die Nebeneffekte auf die Artikelkoordinate ignorierte.-- visi-on21:23, 13. Jan. 2008 (CET)
Rund 40'000 verwendungen von Koordinate Text Artikel stehen immerhin rund 5000 Verwendungen von Koordinate Text und Koordinate Artikel, die gleiche Koordinate betreffend, gegenüber. -- visi-on13:07, 14. Jan. 2008 (CET)
Ich verstehe nicht ganz, wozu das gut sein soll. Solche Formatierungen kann man doch jetzt schon machen:
Beispiel mit kursivem Text (Parameter name fehlt in FließtextkoordinateLage1550kein Wert in type-Parameterregion-Parameter fehlt6)
Beispiel mit hochgestelltem TextParameter name fehlt in FließtextkoordinateLage1550kein Wert in type-Parameterregion-Parameter fehlt6
Beispiel mit Referenz<ref>Parameter name fehlt in FließtextkoordinateLage1550kein Wert in type-Parameterregion-Parameter fehlt6</ref> (der Link wird dann unten bei den <references /> angezeigt)
und jetzt zeig diese Koordinaten noch zusätzlich als Artikelkoordinate an ... unerwüschter Nebeneffekt!-- visi-on19:10, 17. Jan. 2008 (CET)
Moment, welchen Sinn soll das denn ergeben? Warum sollte man die Koordinate im Fließtext in ein <ref>-Tag packen, damit sie am Ende des Artikels in den Einzelnachweisen angezeigt wird, und dann soll sie auch noch oben rechts im Artikel zu sehen sein? Ich finde, man muss sich da schon entscheiden. Wenn man text und article gleichzeitig verwendet, darf man eben einfach nicht an der Formatierung herum basteln. Das ist eine kleine Einschränkung, klar. Aber insgesamt halte ich die Nachteile, die zwei zusätzliche Parameter mit sich bringen, für schwerwiegender als die Vorteile. (Vor allem, weil diese Parameter ein Problem, das durch zusätzlichen Code verursacht wird, mit noch mehr zusätzlichem Code kaschieren.) Was man relativ problemlos machen könnte, wäre die MediaWiki:Monobook.css so zu erweitern, dass font-style usw. für die Koordinatenanzeige nochmal ausdrücklich festgelegt werden. Dann wäre es egal, wie der Artikel an der Stelle formatiert ist, wo die Vorlage steht. --TM21:59, 17. Jan. 2008 (CET)
Wasser auf meine Mühlen. Konkret geht es den Ästheten vorallem um die Schriftgröße ...
Ja, hier erledigt. Was man konkret machen müsste, wäre in der Monobook.css die Anweisung font-size:85%; gegen so etwas wie font-size: 11px; font-style: normal; auszutauschen. Kümmert sich bitte jemand darum, dem das wichtiger ist als mir und Vision? ;-) --TM23:45, 17. Jan. 2008 (CET)
noch unterstützt aber nicht propagiert. Die unterstützten Fangwörter ermöglichen eine automatische Auswertung ohne Programmänderung durch Stefan.-- visi-on11:54, 16. Jan. 2008 (CET)
mehr als eine Koordinate
die Benamsung ist klar, entweder prefix, suffix; nummer oder String; aber wie kann erreicht werden, dass Stefan da keine Schwierigkeiten bei der Auswertung kriegt. Vorschlag: eine ausgezeichnete Koordinate, so es eine solche gibt, wird nach den Regel benannt, die restliche koordinate anders. Aber z.B. bei Vorlage:Infobox Fluss würde das nur helfen, wenn entweder Quelle oder Mündung die Artikelkoordinate sein sollen, Vorgehen eignet sich nicht für sonstige Festlegungen.
ganz ohne Handeingriff wird es kaum gehen, ich hoffe einfach, dass nun nicht jede zweite Box mindestens zwei Koordinaten haben muss. -- visi-on11:54, 16. Jan. 2008 (CET)
sortkey
Nach deiner Beschreibung wäre, nach Breitengraden (NS) aufsteigend sortiert, Kairo < Rom < Berlin < Helsinki. Ich frage mich, ob ich das nicht genau umgekehrt erwarten würde. Mit deiner Definition und aufsteigender Sortierung würde Kairo oben (d.h. im Norden) und Helsinki unten (d.h. im Süden) liegen. Nur so ein Gefühl. --Herzi Pinki00:32, 16. Jan. 2008 (CET)
du hast richtig interpretiert. Für mich logisch, dass der Südpol kleiner ist als der Nordpol, muss ich halt absteigend sortieren, wenn ich es umgekehrt möchte. Ich bin da wahrscheinlich zu emotionslos. Wichtig ist doch einfach das die Reihenfolge stimmt.-- visi-on11:54, 16. Jan. 2008 (CET)
elevation
Nur für region, oder potentiell für alle types von Koordinaten? Jedenfalls aber für type=mountain Pflicht! Wäre eine Prüfung wert. Analog für city und pop. --Herzi Pinki09:38, 16. Jan. 2008 (CET)
type=mountain braucht elevation (ohne Meldung im Text, aber Wartungslink)
type=city braucht pop (ohne Meldung im Text, aber Wartungslink)
Prüfung auf Wertebereich von Breiten- (NS) und Längengrad (EW) sollte auch in anderen Formaten erfolgen (-90 ≤ NS ≤ +90; -180 ≤ EW ≤ +180; bei Angabe in DMS muss zusätzlich gelten: 0 ≤ M < 60; 0 ≤ S < 60)
wenn wir zuviel abfragen erschlagen uns die Vorkommen. Das ist kein Grund es sein zu lassen, aber man kann das ein wenig steuern-- visi-on11:54, 16. Jan. 2008 (CET)
der zweite Test kommt von den extraterrestrischen Mond- und Mars-Koordinaten. Ich kommentiers aus bis es soweit ist. -- visi-on22:04, 18. Jan. 2008 (CET)
Bei "city", pop wäre immer wünschenswert - ist aber leider nicht immer für alle Städte auf der Welt verfügbar. Also ein Muss-Feld wäre zu hart. --Atamari17:03, 23. Jan. 2008 (CET)
Typ und Einwohner werden „verschluckt“
Letzter Kommentar: vor 17 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Ich habe gerade geschaut, wie die neue Vorlage in die Vorlage:Infobox Gemeinde in Deutschland einzubauen wäre (bitte lasst mich das machen). Dabei habe ich das Problem, dass type und pop nicht an das Geohack-Skript übermittelt werden so wie bisher. Sie werden in Vorlage:CoordinateLINK zwar überprüft, aber dann „verschluckt“. Beispiel: {{Coordinate|text=/|NS=15|EW=50|type=adm2nd|pop=50000}} wird zu Parameter name fehlt in Fließtextkoordinate15° 0′ N, 50° 0′ O1550region-Parameter fehlt6. Der Parameter pop wird vom Geohack (zumindest in der momentanen Version) nicht ausgewertet, das Fehlen dieses Parameters tut also nichts zur Sache. Aber aus dem type würde er den Maßstab ermitteln. --TM18:07, 17. Jan. 2008 (CET)
Ich habe soeben eine etwas größere aber wie ich denke sehr nützliche Änderung an der Vorlage:CoordinateLINK vorgenommen. Hintergrund ist wieder das GeoHack-Skript (siehe mapsources.php). Dort wird anhand des Typs eine standardmäßige Dimension ermittelt, falls keine andere angegeben wurde. Das ist vor allem bei sehr großen Gebilden wie z. B. Landkreisen wichtig: Ich erscheint mir sehr irreführend, die Koordinaten für einen Landkreis mit einer Genauigkeit von ≈ 30 m anzuzeigen, wenn das adressierte Gebilde mehrere Duzend Kilometer groß ist. Die minutengenaue Anzeige (≈ 2 km Genauigkeit) wirkt da einfach realistischer. Der Link selbst ist unabhängig von dieser gerundeten Anzeige natürlich weiterhin so genau wie möglich. Jetzt ergibt sich folgende Rangfolge (die weiter oben stehende Eigenschaft wird als wichtiger gewertet):
Wenn das Ausgabeformat DM lautet, hat dieses den Vorrang, es werden also Grad + Minuten angezeigt (Beispiel: Parameter name fehlt in Fließtextkoordinate50° 7′ N, 10° 7′ O50.12345610.123456region-Parameter fehlt6).
Wenn eine dim angegeben wurde, wird das Ausgabeformat wie gehabt anhand dessen ermittelt (Beispiel: Parameter name fehlt in Fließtextkoordinate50° 7′ 24″ N, 10° 7′ 24″ O50.12345610.123456region-Parameter fehlt6).
Wenn nur ein type angegeben ist, wird dieser verwendet. Bei country, state und adm1st werden nur Grad angezeigt (Beispiel: Parameter name fehlt in Fließtextkoordinate50° N, 10° O50.12345610.123456region-Parameter fehlt6), bei adm2nd, city, mountain und isle Grad + Minuten.
Die Angabe von REGION-ISO=AT-8/CH-GR (~region=AT-8/CH-GR) führt zum gleichen Ergebnis wie REGION-ISO=CH-GR/AT-8, nämlich zu ausschließlich Schweizer Koordinaten (CH1903) im Text. AT-gefühlsmäßig hätte ich bei Grenzbergen aber gerne DMS Darstellung. Als Beispiel siehe auch Umbrailpass. Lösungen:
Die Reihenfolge der Codes entscheidet, der erste Code bestimmt die Darstellung. AT-8/CH-GR -> DMS; CH-GR/AT-8 -> CH1903. Bewertung: instabil durch willkürliche Benutzereingaben, bisher hat die Reihenfolge keinen Unterschied gemacht
Zusätzlicher Parameter wird durchgeschleift. Bewertung: ebenfalls fehleranfällig
Immer gleiches Format DMS erzwingen. Bewertung: Nicht im Sinne des Erfinders und nicht im Sinne der Schweizer.
Immer Ausgabe in allen relevanten Formaten (analog zu der Koordinate rechts oben). Bewertung: bläht Infoboxen auf.
Formatierung der Artikelkoordinate (rechts oben): Da die Breite und Länge per Komma getrennt werden, wäre es vielleicht sinnvoll, DMS von CH1903 durch semicolon zu trennen, um eine deutlichere Abtrennung zu erreichen. Analog bei anderen mehrteiligen Koordinaten.
Die Fehlermeldung bei fehlenden Koordinaten ist sehr massiv (etwa als sandbox: Vorlage:Infobox_Pass). Würde nicht die alle Kat. Kategorie:Wikipedia:Lagewunsch hier auch ihren Zweck tun? Bisher war es auch eher so, dass die Fehlermeldung nicht in der Box gestanden hat, sondern im Falle des Fehlens dort die Tabellenzeile Lage überhaupt gefehlt hat.
REGION-ISO=CH-GL/CH-GR führt zu verstümmelter Box durch Verstümmelung der Positionskarte. Der Aufruf findet Vorlage:Info ISO-3166-2:CH-GL/CH-GR nicht, ich vermute, das Abtrennen des ersten Teils der regionalcodes fehlt noch in der Implementierung. Konnte ich fixen (muss beim Aufruf gefixt werden, du kannst da nichts dafür).
Trotzdem: ein fehlendes Vorlage:Info ISO-3166-2:xxx sollte nicht zu einem zerschossenen Layout führen. Das kann immer passieren, durch Tippfehler, nicht nur durch fehlende Info ISO Vorlagen.
Für die Bildunterschrift braucht es auch eine generelle Lösung: sonst kommt so was raus: test auf der Karte von Schweiz. Lösungen:
caption=: keine Bildunterschrift (ist eher als Workaround zu betrachten), falscher Text erscheint immer noch als title-text (alt-text).
durch Infobox als zusätzlichen neuen Parameter durchschleußen
für die Ortsboxen lassen sich die Karte und Beschriftung leicht als Konstante einführen (adm. Einheit ist bekannt und fix), aber für weltweit gültige Boxen (Pass, Berg, Fluss, ...) eher nicht.
ad 2: Wenn alle Infovorlagen nach dem Willen des Erfinders programmiert sind, so gibt der Aufruf nur mit code= ohne zusätzlichen unbenannten Parameter den PAGENAME: «» zurück (Defaultzweig, siehe dort). Keine Info zum Code: «». Kein Code keine Info: ›‹ Ansonsten müsste man mit #ifexist: operieren und sich mit seiner Limitierung rumplagen. -- visi-on19:14, 18. Jan. 2008 (CET)
Nachgefragt: Es geht um mehr wie nur die schlechte Deutsch in das Textfragment „auf der Karte von“? Du möchtest auch noch den Namen des referenzierten Objekts in die "Standard"-Caption übergeben.-- visi-on19:34, 18. Jan. 2008 (CET)
re: ursprünglich ja, aber inzwischen bin ich der Meinung, dass caption nicht gebraucht wird. Steht ja eh oben, um welche Karte es sich da handelt, unnötiger Text. In Vorlage:Infobox Pass gibt es ja auch keine Kartenbeschriftung. Also bleibt das schlechte Deutsch. --Herzi Pinki22:06, 18. Jan. 2008 (CET)
um beim Umbrail zu bleiben: die politisch administrative Einordnung: Graubünden (Schweiz) / Sondrio (Italien) könntest du dort aus der ISO-Info ziehen. Damit könnte sich der Artikelautor gänzlich der geographischen Lagebeschreibung hingeben.-- visi-on20:15, 18. Jan. 2008 (CET)
Gibt es eine Möglichkeit, vorhandene doppelte Artikelkoordinaten aufzulisten (z.B. vor dieser Bearbeitung: [1])? Oder wurden schon vor der Umstellung auf die neue Vorlage doppelte Koordinaten angezeigt? --тнояsтеn⇔00:10, 19. Jan. 2008 (CET)
Das war mit Sicherheit schon vorher der Fall, denn die Infobox hatte auch schon davor die Koordinaten angezeigt. Evtl. kann man das mit dem TemplateTiger rausfiltern. Wie gut dass ich nicht auf KoordinateURL abstelle. Nützt hier aber nix weil es ja noch Fließtextkoordinaten geben könnte. Am ehesten die Schnittmenge von "Koordinate Artikel" und "Coordinate".-- visi-on00:37, 19. Jan. 2008 (CET)
Fleißarbeit
Letzter Kommentar: vor 17 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Soll ich eine neue Unterseite Fleißarbeit erstellen. Kleine Handjobs die mit etwas Grips abgearbeitet werden können, werden von mir eingestellt oder zumindest bestättigt. Wer sich der Sache annimmt, gibt ein kurzes Statment ab und meldet nach verrichteter Arbeit den Vollzug. -- visi-on10:59, 19. Jan. 2008 (CET)
Halbsperrung
Letzter Kommentar: vor 17 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
führt zu Lage, die mit der ebenfalls bisher unter Lage abgelegten politischen Lage kollidiert (z.B IB Berg).
Wär's möglich, den Defaultwert auf Geographische Lage zu ändern. Oder hast du andere Vorschläge? lg --Herzi Pinki00:32, 21. Jan. 2008 (CET)
Ich war auch schon versucht es nach deinem Vorschlag zu machen. Streng genommen müsste man auf beides verlinken. Der Default {{CoordinateSYSTEM|{{{REGION-ISO|}}}}} ergibt Koordinate. Das ist ungefähr so wie bei den Höhenangaben. Eine geographische Koordinate ist erst brauchbar, wenn man das Bezugssystem kennt. -- visi-on22:45, 21. Jan. 2008 (CET)
Dann habe ich mich verschaut, ich dachte, Lage wäre der default. Solange du Koordinate retournierst, und niemals das viel zu allgemeine Lage, ist es ok. Und wir sollten das überall ohne den 2. Parameter Geographische Lage schreiben, dann gibt es eine zentrale Stelle, wo dieser Text austauschbar ist. Einverstanden? --Herzi Pinki23:12, 21. Jan. 2008 (CET)
Mir wäre am liebsten der zweite Parameter würde nie gebraucht. Aber es gibt sicher IB-Designer die nicht mit Koordinate leben können.-- visi-on23:42, 21. Jan. 2008 (CET)
Problemchen mit der Koordinate (fehlende Sekunden in DMS-Eigabe)
Letzter Kommentar: vor 17 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
{{Coordinate|NS=46/58/N|EW=11/28/E|type=city|dim=500|region=IT-BZ}} (fehlende Sekunden) führt zu einem Fehler. {{Coordinate|NS=46/58/0/N|EW=11/28/0/E|type=city|dim=500|region=IT-BZ}} hingegen funktioniert. --Herzi Pinki23:07, 21. Jan. 2008 (CET)
Letzter Kommentar: vor 17 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Ich arbeite gerade an einer Dokumentation zur neuen Vorlage. Nun bin ich beim Original (Vorlage) beim Parameter name vermutlich auf einen Fehler gestoßen.
Da steht: "Der Name ist gleichzeitig auch Link-Text."
Das ist aber meines erachtens nicht korrekt. Der Linktext wird ja über den Parameter text= gesteuert:
name: gemeint ist der Text der beim überfahren des Link mit der Maus erscheint. Auch Tooltip genannt.
:das selbe wie bei
{{Koordinate Text|...|Ein beliebiger Text}}
Deine Verbesserungsvorschläge darfst du auch direkt ins Original einbringen. -- visi-on 16:29, 23. Jan. 2008 (CET) und auch mir würde besser lesen nicht schaden-- visi-on16:48, 23. Jan. 2008 (CET)
sichtbarer Wartungslink
Letzter Kommentar: vor 16 Jahren11 Kommentare2 Personen sind an der Diskussion beteiligt
Schau mal auf [2] (ich habe temporär Schweizer Koordinaten eingebaut, die außerhalb des gültigen Bereichs liegen.) Und bekomme einen sichtbaren Wartungslink. Ich hab' jetzt eine Stunde lang Vorlage:CoordinateMSG und Vorlage:Coordinate_to_CH1903 studiert, aber ich komm nicht dahinter.
Was mir noch aufgefallen ist:
das Problem tritt nur im Artikelnamensraum auf, ist im Vorlagen oder Benutzernamensraum nicht nachvollziehbar.
die schließende Klammer der Artikel-koordinate rechts oben steht in der Box unter geografischer Lage.
die Fehlermeldung #1 (Gradzahl) erscheint ohne Wartungslink.
Der einzige mir auffallende Unterschied ist der whitespace im Fall rangeCH1903, der im Fall Gradzahl! nicht da ist. Aber bei der Häufigkeit der Verwendung der Vorlage wollte ich diesem wagen Verdacht nicht nachgehen.
btw: der für den Wartungslink generierte html code ist unnötig lang:
oh oh noch so einer. Mensch sag doch gleich was. Ich habe auch schon drei Nächte um die Ohren geschlagen. der Fehler ist: Man kann keinen Link im Link basteln. Darauf muss man erst mal kommen! -- visi-on22:09, 25. Jan. 2008 (CET)
mit deinem Hinweis (habe ich gleich umgesetzt, Danke) könnte man das fast als featcher verkaufen ... -- visi-on22:39, 25. Jan. 2008 (CET)
Dass ein Link im Link nicht geht, ist irgendwie logisch. Es geht ja wohl um den Link auf den Geohack rechts oben, die Fehlermeldung+Wartungslink müsste außerhalb angehängt werden. Ist wohl ein gröberer Umbau? Aber warum es dann bei Gradzahl! geht, versteh ich nicht. --Herzi Pinki23:34, 25. Jan. 2008 (CET)
Prüfung auf Zahl [http://www.url Formatierung mit Bereichsprüfung]
wenn ich das sauber machen wollte müsste ich zweimal den Wertebereich abfragen. Etwas viel Aufwand für den Parserinterpreter für etwas das gar nicht vorkommen darf. Ich bin also geneigt den bug als featcher zu verkaufen. Ich kann ja den sichtbaren "unsichtbaren Link" fast unsichtbar machen: ›.‹. Das fällt nur noch dem eingeweihten auf. btw trotz allem: die pre-expand-size-limit ist sinnvoll und notwendig -- visi-on00:01, 26. Jan. 2008 (CET)
aus dir möcht ich einmal auf Anhieb schlau werden. das mit dem fast unsichtbar kann ich nachvollziehen (ev. geht sogar ein ›.‹), aber es bleibt das Problem mit der schließenden Klammer, die auch betroffen ist. --Herzi Pinki00:14, 26. Jan. 2008 (CET)
Mit dem neuen Parser sind dann auch die conditional transclution – versteht OMA nie – nicht mehr notwendig. Ich werde mich dann auch dem Bug annehmen. -- visi-on10:33, 26. Jan. 2008 (CET)
Letzter Kommentar: vor 17 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Die Kombination aus beiden, WikiMiniAtlas und neuer Vorlage in Kurzform im Text sieht nicht gerade berauschend aus (nur zu sehen, falls wikiMiniAtlas aktiv). Zwei icons, die beide nicht unmittelbar intuitiv sind, treffen aufeinander. Ein Beispiel:
Mitten auf dem Damm (⊙46.50996210.728057) hat man einen Tiefblick ..
Da man als Autor nicht wissen kann, ob der MiniAtlas beim Leser installiert ist, ergibt sich ein gewisses Problem:
Du könntest dem W3C mal den conditional link – würde auch obigen Bug beheben – vorschlagen. Bis dahin musst du eine Mehrfachbelegung mit einem Popupmenu lösen. Dh die Aktivierung des WikiMiniAtlas müsste statt einen Link voranstellen beide Links in ein solches Menu setzen. -- visi-on10:53, 26. Jan. 2008 (CET)
Ich halte die Darstellung des Koordinatenlinks als Icon aus einer ganzen Reihe von Gründen für extrem problematisch: Unter anderem aus dem von Herzi Pinki genannten Grund, vor allem aber, weil kein Mensch kapiert, was dieses lustige Kringelchen (⊙) darstellen soll. Wenn man statt dessen einfach hinschreibt, was sich hinter dem Link verbirgt (zum Beispiel „Mitten auf dem Damm (Parameter name fehlt in FließtextkoordinateKoordinate46.5110.73kein Wert in type-Parameterregion-Parameter fehlt6) hat man einen Tiefblick“ oder „Mitten auf dem Damm (Parameter name fehlt in FließtextkoordinateLage46.5110.73kein Wert in type-Parameterregion-Parameter fehlt6) hat man einen Tiefblick“), benötigt das nur minimal mehr Platz und unterbricht den Lesefluss ebenfalls kaum, ist aber dafür um ein Vielfaches verständlicher. Aus diesen Gründen hätte ich übrigens nie die ICON-Parameter eingeführt. Ich würde sogar vorschlagen, sie wieder aus der Vorlage zu werfen. Sie verführen nur dazu, sie falsch zu verwenden. --TM17:38, 29. Jan. 2008 (CET)
Hilfeseiten
Letzter Kommentar: vor 17 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Letzter Kommentar: vor 17 Jahren10 Kommentare4 Personen sind an der Diskussion beteiligt
Könnte die Vorlage auf das Vorhandensein von region prüfen und einen Wartungslinks erzeugen, damit das nicht jede Box mit einem Parameter REGION-ISO o.ä. selbst tun muss? Einzig bei Offshore-Koordinaten lässt sich kein REGION-ISO code angeben. --Herzi Pinki15:56, 2. Feb. 2008 (CET)
Jaein ... den region-Parameter kann man auch bei der Vorlagenauswertung brauchen. Gut möglich, dass dieser Parameter mal entfällt. Bis dahin sollte er aber gepflegt werden. -- visi-on16:30, 2. Feb. 2008 (CET)
Das Problem sind aber Ortsangaben auf den Meeren, wo man keinen ISO-Code vergeben kann (z.B.gesunkene Schiffe). Ich hab deswegen schon mal bei der entsprechenden Fachvereinigung nachgefragt und die meinten ich sei mit dem Wunsch nach ISO-Codes für die Meere 10-20 Jahre zu früh dran. ;-) -- sk15:33, 3. Feb. 2008 (CET)
Führen ja bloß zu einer falsch postiven Fehlermeldung. So viele versunkene Schiffe wird es dann auch wieder nicht geben. Ein Workaround, um die Prüfung übersichtlicher zu gestalten, denn, ohne Zweifel ist das Fehlen eines ISO-Codes an Land zu korrigieren, wäre die Vergabe eine WP-spezifischen ISO-Codes für die Meere. Damit würden die falsch-positiven Meldungen verschwinden. --Herzi Pinki15:48, 3. Feb. 2008 (CET)
Letzter Kommentar: vor 17 Jahren10 Kommentare6 Personen sind an der Diskussion beteiligt
Hi, bin grad zum Beispiel über den Artikel Quohrener Kipse gestolpert. Dort ist mir aufgefallen dass das Koordinaten fehlen! Hilf mit. mir doch allzu auffällig ist. Nichts gegen Werbung für Euer Projekt aber für den normalen "nur Leser" der Artikel lenkt dieses Orange doch sehr vom eigentlichen Artikel ab. Kann man das etwas dezenter gestalten? Entweder gar keine Farbe oder ein Grau oder dezentes Gelb wären deutlich angenehmer. PS: Das ganze kommt aus Vorlage:CoordinateMSG - soweit ich feststellen konnte. Gruß --JuTa(♂)Talk00:13, 6. Feb. 2008 (CET)
Ich hatte mich mal davon leiten lassen, dass es schon ein bisschen wehtun muss um erstens auffällt und zweitens etwas zu bewirken. Letztlich ist abzuwägen welchen Stellenwert die Georeferenzierung hat. Je höher dieser angesetzt wird desto auffälliger darf es sein. -- visi-on16:54, 6. Feb. 2008 (CET)
Meine Meinung dazu: Reine "Nur-Leser" machen den weitaus größten Teil unserer "Kundschaft" aus. Und die lenkt es einfach nur von Artikelinhalt ab. Mitarbeiter in Euren Projekt brauchen die Farben nicht, denn ich gehe davon aus, dass sie eh drauf achten und ggf. auch andere Hilfmittel haben systematisch nach Artikeln ohne Koordinaten zu suchen. Bleiben Benutzer, die zwar halbwegs regelmäßig in Wikipedia mitarbeiten aber noch nichts mit Georeferenzieren bzw. diesem Projekt zu tun hatten, und die allermeisten davon hat kein gesteigertes Interesse an Euren Projekt mitzuwirken (sorry, is aber so). IMHO überwiegen hier die Interressen der mutmaßlichen 99,x % der Leser nicht durch eine auffällige Farbgebung des Hinweises abgelenkt zu werden. Der Hinweis steht eh sehr prominent über dem Artikel und die "Kackbalken" Farbe ist da m.M.n. wirklich zuviel des Guten. Kackbalken deshalb weil ich beim allerersten Hinschauen dachte: Oh schon wieder neue Nachrichten für mich... --JuTaTalk22:34, 6. Feb. 2008 (CET)
DIeser Argumentation kann ich halbwegs folgen. Ist Timo's Farbvorschlag genehm? Für mich wäre dieser ok. -- visi-on23:12, 6. Feb. 2008 (CET)
Von mir aus gerne. PS: Habe gerade die Vorlage:Lagewunsch entdeckt. Dort gibt es gar keine Farben :) Ist das noch ein Rest der alten Vorlagen und diese Seiten sind einfach nur noch nicht umgestellt? Bin nur neugierig --JuTaTalk23:30, 6. Feb. 2008 (CET)
Also von mir aus ist die Vorlage Lagewunsch obsolet.
PS nach der Umstellung können wir das Farbthema nochmals angehen. Bis dxahin ist es mir etwaas auffälliger lieber-- visi-on23:37, 6. Feb. 2008 (CET)
Vorschlag einer Alternative: Farbe, ja auch Anzeige überhaupt, über css für die daran interessierten einschaltbar/ausschaltbar machen? A la WP:PND? Alle nicht interessierten sehen nix. --Herzi Pinki23:42, 6. Feb. 2008 (CET)
Vorlagenname
Letzter Kommentar: vor 17 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Ich bin ja nicht unbedingt ein Freund davon, Worte die es im Deutschen gibt trotzdem unbedingt englisch auszudrücken - warum muss denn diese Vorlage unbedingt "Coordinate" statt "Koordinate" heißen, warum E statt O usw.?? --RoterraecherDiskussion09:58, 6. Feb. 2008 (CET)
Wie es dazu gekommen ist, kannst du hier nachlesen: Meinungsbild und Umfrage im Vorfeld. E statt O dient ebenso wie der Vorlagenname der möglichen Übernahme in anderen Wikipedias. Ausgegeben und somit sichtbar für die Leser ist aber O für Osten. --тнояsтеn⇔16:41, 6. Feb. 2008 (CET)
Letzter Kommentar: vor 16 Jahren21 Kommentare4 Personen sind an der Diskussion beteiligt
wenn man nicht die default-skin verwendet, funktioniert die position der koordinate rechts-oben nicht: sie steht dann hinter der koordinate (etwa in der infobox) - screenshot nötig? nach den Web Accessibility-richtlinien fällt das unter "unbenutzbare technologie" und sollte vermieden werden: vermittels welchen hacks wird eigentlich span class="geo" dorthin verschoben? (ich hatte das schon mal bei der vorigen geokoordinate gefragt, aber nie antwort bekommen) - die klasse sollte zumindest so verankert werden, dass auch die rohansicht (ohne CSS) brauchbar aussieht, oder zumindest irgendwo ein prominenter tipp, was ich (oder ein anderer) in mein CSS hacken muß, um sie auszublenden: ginge das über die benutzer-einstellungen? toll ist sie aber, die neu vorlage, und handlich auch gruß -- W!B:17:29, 6. Feb. 2008 (CET)
Wunderbschönen guten Abend, es wäre gut, wenn es eine Absprache mit den Gestaltern von den gesichteten Versionen gäbe, damit eine Überlappung der beiden Informationsboxen nicht mehr stattfindet. Liebe Grüße, Conny17:59, 19. Jun. 2008 (CEST).
Das Problem tritt immer auf, wenn der Baustein Koordinaten fehlen eingebunden wird. Es spielt dabei keine Rolle, ob die Version gesichtet ist, oder die Sichtung aussteht (da derzeit immer einer der beiden Felder rechts oben angezeigt wird). Grüße, Conny10:52, 21. Jun. 2008 (CEST).
Ist irgendwie unlogisch, dass sich hingegen die Artikelkoordinaten wie erwartet verhalten, denn der HTML-Code ist für beides der gleiche (nicht der selbe). -- visi-on11:13, 21. Jun. 2008 (CEST)
Leider noch nicht :I . Conny 13:02, 21. Jun. 2008 (CEST).
:Du hattest den Inhalt der Seite nicht gepurged. Bitte schau nochmal. -- visi-on 13:05, 21. Jun. 2008 (CEST)hattest du doch -- visi-on13:07, 21. Jun. 2008 (CEST)
Sieht für mich unter Firefox 3 und Opera 9.5 sehr angenehm aus. Auch die Symbole für gesprochen und Qualität (Lesenswert, Exzellen) fügen sich gut ein. Vielen Dank Visi-on! Grüße, Conny20:58, 28. Jun. 2008 (CEST).
Letzter Kommentar: vor 16 Jahren31 Kommentare9 Personen sind an der Diskussion beteiligt
Doppelte Koordinaten
Ich habe festgestellt, dass in der Infobox für Ortsteile die Koordintane doppelt angezeigt werden, und zwar bei Firefox. Seltsamerweise beim IE nicht. Siehe Braunsroda oder Heistern, eigentlich bei allen Ortsteilen. Wer kann den Fall lösen? --Karl-Heinz23:02, 27. Jan. 2008 (CET)
Zu sehen ist Koordinaten: 51° 19′ N, 11° 15′ O51.30888888888911.247777777778Koordinaten: 51° 18′ 32″ N, 11° 14′ 52″ O --Karl-Heinz10:43, 28. Jan. 2008 (CET)
Ich verstehe nur nicht, woher die Zahlenkombination O51.30888888888911.247777777778 kommt. Sie ist seltsamerweise nicht zu sehen, aber wenn man mit Strg+C den Text kopiert, erscheint sie plötzlich beim Einfügen. Hier spukt es. --Karl-Heinz10:45, 28. Jan. 2008 (CET)
Wenn das nur angemeldet auftritt, benutzt du vielleicht eine spezielle Skin, mit der die Anzeige nicht richtig funktioniert? --08-1502:54, 29. Jan. 2008 (CET)
a) Skin
b) du hast für die Klassen:
coordinates
geo oder (latitude und longitude) siehe Mikroformat
Ich hatte das eben auch bei Flechtorf, da war eine Koordinate über die Infobox eingebunden, und die andere stand in den Weblinks ;-) Die haben sich irgendwie komischerweise um 2 Pixel verschoben, sonst hätte ich das gar nicht gemerkt. --Rohieb会話+/-22:29, 14. Feb. 2008 (CET)
Habe mich ein bisschen mit Skins herumgespielt. Anlässlich dieses Problems. Außer bei monobook und nostalgia erscheinen die Artikelkoordinaten immer neben den Text-koordinaten und sprengen dort die Breite der Box. Keine Ahnung, ob das ein Problem ist (wer verwendet die anderen Skins schon), und wo es zu fixen ist, bei der Koordinate oder bei den Skins. Mir kommt jedenfalls vor, dass bei der alten Vorlage:Koordinate dieses Problem nicht aufgetreten ist. --Herzi Pinki21:05, 3. Feb. 2008 (CET)
ja wollte ich, der obige Absatz stammt auch von mir. Nur das obige Problem ist ein anderes, da kein anderes Skin im Spiel ist. Es handelt sich also um zwei getrennte Probleme. --Herzi Pinki21:36, 3. Feb. 2008 (CET)
ok, sorry. Mich hatte verwirrt, dass du ohne weiteren Kommentar auf einen Absatz darüber verweist, als wäre der irgendwo ganz anders. Du darfst gerne diese Diskussion bereinigen, um Platz für sinnvolle Antworten zu lassen. --WirthiÆÐÞ22:17, 3. Feb. 2008 (CET)
Die Positionierung der Koordinate oben rechts im Artikel wird durch CSS-Anweisungen realisiert, die in der Monobook.css notiert sind. Damit die Positionierung auch bei anderen Skins funktioniert, müsste es dort ebenfalls entsprechende CSS-Anweisungen geben, aber das scheint offenbar nicht der Fall zu sein. Das war allerdings schon früher so und hat mit der neuen Vorlage nichts zu tun. Trotzdem müsste man etwas an der neuen Vorlage ändern: Zwischen den beiden Koordinaten müsste ein Leerzeichen oder ein Zeilenumbruch (Whitespace) stehen, damit die beiden Koordinaten nicht direkt aneinander kleben, wenn sie beide im Text angezeigt werden. Ich habe gerade versucht, das umzusetzen, bin aber gescheitert. Entweder hat der MediaWiki-Parser das Whitespace gefressen oder es tauchte an der falschen Stelle auf. Vielleicht hat der Hauptautor Vision mehr Glück. --TM01:08, 4. Feb. 2008 (CET)
fucking parser man könnte es nun höchstens noch mit einem anderen Whitespace versuchen ... Die «tab» müssen wir gar nicht erst versuchen, die frisst er auch ...-- visi-on01:43, 4. Feb. 2008 (CET)
der CSS-id coordinates sollte man mal noch "white-space:nowrap;" beibringen, dann würde es in den andern skins auch etwas artiger umbrechen. Siehe auch [3]-- visi-on10:28, 4. Feb. 2008 (CET)
Ich verstehe nicht, warum das nowrap notwendig sein soll? Die Angabe bewirkt bei mir überhaupt nur etwas, wenn ich das Browserfenster extrem verkleinere. --TM10:49, 4. Feb. 2008 (CET)
oder wenn die Koordinaten etwas länger ausfallen (zB. Zürich). Ist auch notwendig, dass das Lesenswert-Icon nicht überschrieben wird. Ich habe es einfach aus Vorlage:Koordinate Artikel sowie Vorlage:Text oben rechts übernommen. Bei z-index:1; konnte ich mir hingegen wirklich keinen Reim drauf machen. -- visi-on10:57, 4. Feb. 2008 (CET)
doppelte Koordinaten in anderen Skins ist ein Bug. Ich habe ihn lokalisiert. Beheben, noch mit dem alten Parser wirds kompliziert ... -- visi-on23:26, 4. Feb. 2008 (CET)
Im Modern Skin sieht die Vorlage aufgrund des Dunkelblauen Hintergunds nicht besonders toll aus. Der Text "Koordinaten:" ist sehr schwer zu lesen und der Link hebt sich auch nicht wirklich ab (ist aber gut erkennbar). Kann man da irgendwas machen? --maststef20:12, 1. Jul. 2008 (CEST)
müsste man in Modern.css anpassen. Das wird aber noch etwas Zeit brauchen, den im Prinzip sollten mal noch alle Skins angepasst werden. Es ist also nicht ratsam nun an einzelnen Skins zu basteln. Aber ich werde dir einen Vorschlag für deine persönlichen CSS-Definitionen in Spezial:Mypage/modern.css machen. -- visi-on20:53, 1. Jul. 2008 (CEST)
Hab die Hintergrundfarbe neben weiterren Styles fest kodiert. Abwarten bis der Cache gespühlt ist, das braucht in letzter Zeit nach meinem Geschmack etwas zu lange, aber dann sollte gut sein. -- visi-on21:59, 1. Jul. 2008 (CEST)
OK, danke. Jetzt ist es gut lesbar. Ob der weiße Kasten innerhalb des dunkelblauen Felds gut aussieht, werd ich erst nach ein paar Tagen Gewöhnungszeit beurteilen.--maststef08:29, 2. Jul. 2008 (CEST)
Letzter Kommentar: vor 17 Jahren17 Kommentare5 Personen sind an der Diskussion beteiligt
Hallo, ich bin gerade dabei die Vorlage Infobox Distrikt in Uganda in den Artikel Kalangala (Distrikt) einzubinden dabei ist mir aufgefallen, das wenn ich für den Breitengrad nicht das gewünschte Ergebnis erhalte. Bekanntermaßen habe ich ja die Möglichkeit mit einem vorrangestellten Minus ('-') die Himmelsrechtung zu ändern. Das funktioniert in diesem Fall aber nicht. Es wird in beiden Fällen (Mit und ohne Minus) das gleiche Ergebnis ausgegeben. Ist das so beabsichitigt, oder ein Bug?
Meine eigentliche Frage ist nun wie kann ich das umgehen? In der Vorlage kann ich ja leider keinen Wert für die Himmelsrichtung angeben, da Uganda direkt auf dem Äquator liegt. Eine Angabe von 0/20/0/S halte ich für wenig Zielführend, da dies eine nicht vorhandene Genauigkeit vorspielt... MfG Monsterxxl<°))))>22:47, 11. Feb. 2008 (CET)
Ich kann in einer expression nicht «+0» von «-0» Unterscheiden. Explizit auf «-0» Abfragen macht bei zukünftig über 100'000 Einbindungen keinen Sinn. Im Prinzip ist ein negatives Vorzeichen nur bei einer reinen Dezimalangabe richtig. Eine Eingabe «-1/20» ist Formal unsauber. Dass es “richtig” interpretiert wird, eine Fehlertoleranz.-- visi-on11:31, 12. Feb. 2008 (CET)
dazwischendrängel* OK, Da stimme ich dir absolut zu. Bei Grad/M/S Angaben haben Vorzeichen wahrlich nichts zu suchen. Das verwirrt. Aber die Angabe von 0/20//S ist auch nicht wirklich eindeutiger. Klar, um es eindeutiger zu machen kann ich 0/20/0/S angeben. Nur ist dabei das Problem, dass eine nicht vorhandene Genauigkeit vorgespielt wird. Gegen eine Angabe von Koordinaten in Dezimalgrad möchte ich mich aussprechen, da das m.M.n. nicht wirklich nachvollziehbar ist. Lässt es sich nicht irgendwie einbinden, das die Vorlage automatisch erkennt, das nur Grad und Minute angegeben sind und dementsprechend im Artikel die Angabe von 0/20/S für 0°20'S ausreicht? MfG Monsterxxl<°))))>13:47, 12. Feb. 2008 (CET)
Schon mal gut dass du verstehst «1/2/S» und ähnliches könnte man zulassen, ist aber in der wikisyntax ziemlicher murx. Wenn mir etwas eleganteres als Vorlage:CoordinateLAT einfällt bin ich dabei.-- visi-on13:58, 12. Feb. 2008 (CET)
OK, bin ich dabei. Von Vorlagenprogramierung in diesen Dimensionen habe ich nur leider nicht die Ahnung, als das ich dich produktiv unterstützen könnte. :((
@vision: Irgendwas scheint da wirklich nicht zu stimmen, wie die Vorlage auf BREITENGRAD=-1/20 zeigt, die richtige Ausgabe wäre wohl 1° 20′ S und nicht 0° 40′ S. Die Vorzeichen der Minuten/Sekunden müsse sich auch ändern. --Kolossos11:44, 12. Feb. 2008 (CET)
Jo. Klemm das mal mit +0 und -0 ab, das sollte nicht sein. Lieber ein wenig mehr am Anfang rummeckern, als das wir nacher die Hälfte der Eingaben nachpflegen müssen. Ansonsten ist mir 0/20/0/S oder -0.2 gleich lieb. -- sk21:57, 12. Feb. 2008 (CET)
Klemm
Es werden nur noch positive Werte für Grad, Minuten und Sekunden akzeptiert. Ein negatives Vorzeichen ist nur noch in reiner Dezimaldarstellung möglich. -- visi-on13:41, 14. Feb. 2008 (CET)
Letzter Kommentar: vor 17 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hier, bei Tamale-Stadion (Permamentlink)Tamale-Stadion ist eine automatische Kategiorie rot und nicht sprechend. Evt. muss hier noch eine Fehlerbehandlung hinein. War es nicht die Absicht den {{Lagewunsch}}-Baustein duch die einfache Version von {{Coordinate}} (ohne Parameter) zu ersetzten? --Atamari01:56, 12. Feb. 2008 (CET)
Letzter Kommentar: vor 16 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hi.
Kann es sein, dass mache Seiten Probleme bekommen mit dem neuen Parser, dadurch dass die Vorlage noch einen Haufen Untervorlagen benutzt, die immer wieder aufgerufen werden? Hier zwei Beispiele: Liste der Einschlagkrater der Erde ab "M" und Vorlage:Infobox_Ortsgliederung/Beispiele#Ludwigshafen.2C_Ruchheim. Der Parser bricht die Auswertung irgendwann für die ganze Seite ab und schreibt in den Quelltext <!-- WARNING: template omitted, pre-expand include size too large -->. Man kann mit Spezial:ParserDiffTest sehen, dass es am neuen Parser liegt und ich denke es ist von "oben" auch so gewollt, siehe Tim Starlings Mail zu einem ähnlichen Limit. Also was nun? Die großen Seiten umbauen? --EukuB¿21:00, 12. Feb. 2008 (CET)
Das Problem mit der pre include size ist mir bekannt. Dass inzwischen der neue Parser aktiviert ist, ist mir entgangen. Mit diesem muss man das Problem etwas anders angehen als mit dem Alten drum habe ich da nicht mehr al zu viel gemacht. -- visi-on23:45, 13. Feb. 2008 (CET)
Nein, mit dem neuen Parser sind die Einschlagkrater im Butter ... und wenn ich dann noch den Code für den neuen optimiere, was beim alten zur Katastrophe führen würde, ist es noch besser. -- visi-on00:02, 14. Feb. 2008 (CET)
Weiterer Fehler beim Übertrag: {{Coordinate|text=DMS|NS=49/59/59.6/N|EW=9/59/59.6/O}} gibt »49° 0′ 0″ N, 9° 0′ 0″ O« aus. --Fomafix09:50, 15. Feb. 2008 (CET)
Entfernteres Ziel der Georeferenzierung ist zu jedem Punkt auch eine Höhe zu haben. Bedeutung ist, dass diese, wie bei tausenden andern Artikeln, fehlt. -- visi-on17:39, 19. Feb. 2008 (CET)
Und woher ergibt sich die 7? Das ist doch bestimmt keine Pauschalangabe (d.h. 7m), wenn man die Höhe nicht angegeben hat. --Mps18:01, 19. Feb. 2008 (CET)
Ich zweifle etwas am Sinn dieses Parameterfehlers. Bei besonders großen Gebilden wie z. B. Landkreise möchte ich gern (grobe) Koordinaten angeben, damit man die Kartendienste nutzen kann. Es wäre aber unsinnig, eine Höhe anzugeben, weil Landkreise häufig Höhenlagen über mehrere hundert Meter überspannen. Trotzdem wird jetzt überall angezeigt, dass es angeblich ein Problem gäbe. Wie gesagt: Ich zweifle am Nutzen dieses „Fehlers“, der (zumindest in diesem Fall) keiner ist. Könnte man ihn bitte ausblenden? --TM20:40, 5. Mär. 2008 (CET)
falsches "runden"
Letzter Kommentar: vor 16 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
hallo!
auf Diskussion:Timmendorfer Strand hat sich eine ip zu wort gemeldet: "Timmendorfer Strand befindet sich auf dem 54. Grad nördlicher Breite. Zwar wird hier der 53°59' im Google-Maps-Link angegeben. Unverständlich finde ich dennoch, dass man als Leser vom 53. Grad (ohne Minutenangabe) liest, denn der stimmt definitiv nicht. Das ist in etwa so, wie wenn etwas zum Verkauf für 54 Euro steht, im Link steht 53,95 Euro, der Leser liest aber 53 Euro. Kann das jemand bitte mal ändern?"
und das stimmt offensichtlich auch so weit... aus den linkdaten 53.994444444444_N_10.7825_E macht die anzeige ein 53° 0′ N, 10° 47′ O. wiesoweshalbwarum weiß ich nicht; vielleicht könnte ja jemand mal hier und/oder auf der disku reagieren.
Gleich noch 'ne Frage: wozu überhaupt auf Bogenminuten runden? Informationen zu Bogensekunden werden durch die Vorlage "Infobox Ort in Deutschland" auf volle Bogenminuten gerundet (Der Eintrag 53 |lat_min = 59 |lat_sec = 40 aus der Infobox wird allerdings momentan fälschlich zu 53° 0′ N bei der Anzeige im Artikel; richtiger natürlich 54° 0′ N). Wenn Bogensekunden in der Vorlage "Koordinate Artikel" (siehe etwa Niendorfer Hafen) eingetragen sind, dann kommen auch die Bogensekunden zur Anzeige: 53° 59' 37" N. Das Verhalten gegenüber dem Leser ist da z.Zt. nicht konsistent und sollte überdacht werden. Gruß -- Talaris10:30, 25. Feb. 2008 (CET)
zur Zusatzfrage, je nach Objekt vermitteln Bogensekunden eine falsche Genauigkeit. Ich kann die Schwelle des Strassburger Münsters auf Tausendstel Bogensekunde genau angeben, wenn ich diesen Punkt als Georeferenz der Stadt nehme ist das aber unverhältnismässig "genau". -- visi-on12:42, 1. Mär. 2008 (CET)
wenn du eine eindeutige Abbildungsvorschrift formulieren kannst - es darf auch in Prosa sein - Ja. Ich muss aber auch dazu sagen, dass Fließtextkoordinaten bei der Umstellung hinter den "Koordinate Text Artikel" hinten anstehen. Für die weiterverarbeitung der Koordinaten, sollten alle noch sinnvoll benannt werden. -- visi-on19:12, 4. Mär. 2008 (CET)
Tools (2)
Letzter Kommentar: vor 16 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Nachdem nun die neue Koordinatenvorlage „scharf“ ist, stellt sich mir nun doch die Frage, wie es mit entsprechenden Tools aussieht? Weder das bisher von mir genutzte giswiki-Tool noch das von mcaviglia.ch sind bisher umgestellt. Das Ganze händisch zu machen, ist mir nun doch zu aufwändig. Besteht da die Chance, dass sich da in nächster Zeit etwas tut? --Martin Zeise✉21:18, 4. Mär. 2008 (CET)
Das hier schon gesehen: [[Wikipedia:WikiProjekt Georeferenzierung/Hilfe/Tools]Wikipedia:WikiProjekt Georeferenzierung/Neue Koordinatenvorlage/Tools]]? Get Coordinate kann die neue Vorlage schon, die anderen Tools werden auf jeden Fall noch umgestellt (siehe auch Ablaufplan). --тнояsтеn⇔21:26, 4. Mär. 2008 (CET)
Danke für den Link, gefällt mir. Nur sollte es noch eine Möglichkeit geben, die Zahl der Kommastellen zu reduzieren. Sechs Kommastellen bei den Sekunden halte ich in der Regel doch für deutlich übertrieben. --Martin Zeise✉21:51, 4. Mär. 2008 (CET)
Boxkoordinaten (CH1903 und andere)
Letzter Kommentar: vor 16 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo visi-on, kannst du mal bitte unter z.B. Berninagruppe die Koordinaten in der Box anschauen, Titel (Koordinaten, (CH)) und Wert (46° 23′ N, 9° 55′ O) stimmen nicht zusammen, entweder CH auf beiden Seiten, oder gar nicht. lg --Herzi Pinki01:08, 7. Mär. 2008 (CET)
Und wie funktioniert es für die Artikel-Koordinate (ohne Text-Koordinate)? |article=DM scheint lt. Dokumentation nicht zu gehen? --WaltR08:01, 9. Sep. 2008 (CEST)
Artikelkoordinate wird klein ausgegeben
Letzter Kommentar: vor 16 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Mir ist aufgefallen, dass die Artikelkoordinate in kleinerer Schrift ausgegeben wird, wenn sie auch als Textkoordinate in einer Bildunterschrift benutzt wird (siehe z.B. bei Neandertal). --Boente17:10, 30. Mär. 2008 (CEST)
Ich habe die zentrale Symptombekämpfung ([4][5]) vorgenommen. Bis zu den CSS Definitionen der Skins reicht mein Arm nicht. Schauen wir erst mal ob sich dieser Eingriff bewährt. -- visi-on 13:42, 1. Apr. 2008 (CEST)
auf x-small nachgebessert-- visi-on14:00, 1. Apr. 2008 (CEST)
Sieht für mich bislang gut aus. Koordinate wird jetzt überall klein ausgegeben. Ich stimme dafür, dass so beizubehalten. --Boente13:03, 5. Apr. 2008 (CEST)
dim-tag ohne Wirkung
Letzter Kommentar: vor 16 Jahren20 Kommentare4 Personen sind an der Diskussion beteiligt
Nun ist die neue Koordinatenvorlage eingebunden, aber das dim-tag funktioniert offensichtlich so noch nicht. Das ist im November ja schon hier beanstandet, aber mit einer für mich unbefriedigenden Antwort als erledigt abgehakt worden. Bis das nicht funktioniert werde ich die alte Vorlage verwenden, auch wenn es jetzt umständlich zu handhaben ist. -- Godewind10:19, 2. Apr. 2008 (CEST)
Aber scale funktioniert in der alten Vorlage. Für Landmarken verwende ich das immer um befriedigende Ergebnisse zu bekommen. In der neuen Vorlage soll „scale“ durch „dim“ ersetzt worden sein (Wikipedia:WikiProjekt_Georeferenzierung/Neue_Koordinatenvorlage#Hintergrund), ist das nicht getestet worden? Wie ich eben festgestellt habe, kann statt „dim“ aber „scale“ eingesetzt werden, obwohl es den tag offiziell nicht gibt, jedenfalls ist er nicht aufgeführt. Etwas chaotisch und verwirrend zugleich. Wenn die Verortung voranschreiten soll, für Bremen mache ich das bis auf die (eigene) Bildebene, dann muß das auch klar beschrieben und getestet sein. -- Godewind10:58, 2. Apr. 2008 (CEST)
Ich habe mich in früheren Diskussionen vehement für die Beibehaltung solcher Skalierungsmöglichkeit eingesetzt. Was nützen hochaufgelöste Luftaufnahmen, wenn ich nur die ganze Stadt markieren kann. Wenn der Parameter jetzt dim heißt und den Durchmesser angibt ist das ja in Ordnung, aber es muss funktionieren und in der alten Vorlage funktioniert scale. Eine neue Vorlage einzubinden für die man nicht dokumentierte Parameter einsetzen muss finde ich nicht überzeugend. Das gibt später bei automatischen Vorlagenersetzungen Probleme. Bleibt die Frage: Soll die alte oder neue Vorlage (mit scale) verwendet werden? -- Godewind11:54, 2. Apr. 2008 (CEST)
Du sollst scale nicht mehr verwenden. Wenn du in der alten Vorlage scale und dim verwendest behinderst du wenigstens nicht die Migration. In der neuen Vorlage gibt es kein scale.-- visi-on12:49, 2. Apr. 2008 (CEST)
Ok, beide Parameter in der alten Vorlage ist ja kein Problem und die verwende ich bis dim in der neuen funktioniert. Warum beschreibt ihr das nicht mal, oder habe ich das übersehen? -- Godewind13:29, 2. Apr. 2008 (CEST)
Da scale in der neuen Vorlage offenbar funktioniert, wäre es vielleicht besser hier beide Parameter zu verwenden. Dann muss weniger migriert werden, bestenfalls löscht ein Bot später den nicht mehr benötigten tag raus. Aber bitte die gewünschte Verfahrensweise auch in der Anleitung beschreiben und nicht Funktionierendes unterdrücken und Nichtfunktionierendes propagieren. -- Godewind13:48, 2. Apr. 2008 (CEST)
Ich habe das am Beispiel Porta_Nigra#Weblinks in der Vorschau probiert. Gleicher Wert, aber statt dim mal scale eingesetzt. Bevor das zur Anwendung kommt, müssten die Entwickler ja ihr ok geben. -- Godewind
Autsch, sorry. Aber vielleicht gibt es die Möglichkeit den tag in die neue Vorlage aufzunehmen bis dim funktioniert (wann soll das den laufen?). Das würde den Migrationsaufwand verringern. -- Godewind16:21, 2. Apr. 2008 (CEST)
nein, eben nicht weil, dann ein Paramter verwendet wird der nicht mehr weiter unterstützt werden soll. Und dann haben wir den Salat. Wie gesagt du kannst bei der alten Vorlage _dim:50_scale:100_ versuchen (ohne Gewähr). Die Vorlage:Koordinate Artikel wird auch noch ein paar Monate überleben. Alle andern werden im Moment schrittweise reduziert. Da dim und scale nicht kompatibel sind kann natürlich nur dim übernommen werden. -- visi-on17:24, 2. Apr. 2008 (CEST)
Um das zu laufen zu bringen, brauchen wir wohl kurz mal die Hilfe von Magnus Manske, um im Geohack aus dim wieder scale zu erzeugen. Die Vorbereitung können wir aber übernehmen. Die Umwandlung sollte relative einfach sein.
dim = faktor / 2^scale bzw. umgekehrt
scale = log2 (faktor/dim)
Dabei schätze ich den Faktor auf faktor=88000000*cos(lat)
Basis war jetzt mal ein Standard-LCD-Monitor (1280x1024) und etwas Luft habe ich auch noch gelassen. Die 88000000 sind nebenbei der doppelte Erdurchmesser in Meter. Bitte um Prüfung. --Kolossos17:37, 2. Apr. 2008 (CEST)
etwas irritiert: Wozu den Erdduchmesser? z.B. swisstopo bildet mit etwas Luft wie du sagst bei einem Kartenbild von 600x400 und Massstab 1:20'000 etwa 3x2km ab. -- visi-on18:08, 2. Apr. 2008 (CEST)
Da würde bedeuten scale=20000 ≈ 10 x dim=2000 aber eben es ist vom Monitor des Benutzers abhängig. Die projektionsbedingte Verzerrung in Ost-West-Richtung, kann ausser Betracht bleiben. Das Objekt muss auch in der Nord-Süd-Richtung auf dem Kartenausschnitt platzfinden. Man kann sich also beim Festlegen des Faktors auf diese Richtung beschränken. Ich bitte meinerseits um Prüfung. Der Faktor 10 wäre natürlich der Einfachheit halber einem andern konstanten Faktor vorzuziehen. -- visi-on18:47, 2. Apr. 2008 (CEST)
Auch etwas irriertiert, kann man den Swisstopo überhaupt mit Parametern aufrufen? I GEohack erfolgt der Aufruf so.
Was die Verzerrungen angeht, Google Maps nutzt, genau wie openstreetmap, die Mercator-Projektion, dabei werden auch die vertikalen Abstände verzerrt. Darum ist auch Grönland in der Abbildung größer als Afrika und auch nur der Bereich zwischen 85° Nord und 85° Süd erfasst. Es bleibt also aus meiner Sicht, die Verzerrung der Breitengrade.
Die Frage der Monitorabhängigkeit zeigt nochmal, wie sehr wir eine Angabe in einer SI-Einhait wie Meter brauchen. --Kolossos19:29, 15. Apr. 2008 (CEST)
Den Aufruf mit Massstab habe ich bei swisstopo auch schon vergeblich gesucht. Aber wenn du den Aufruf mit in der Schweiz liegenden Koordinaten tätigst Bern dann kommt ein Ausschnitt im Massstab 1:20'000 heraus. Die Verzerrung der Mercatorprojektion ist ein Merkmal der Karte und nicht der dim zu scale Umwandlung. Diese Korrektur ist so oder so angebracht (wenn das der GeoHack für scale machte, wird er es auch für dim machen sollen). Aber das Verhältnis von scale zu dim bleibt konstant. Auch die frühere Scale-Angabe war von der Bildschirmauflösung abhängig. -- visi-on13:29, 23. Apr. 2008 (CEST)
PS: Cosinus(Breitengrad) ist die Mercatorverzerrungskorrektur, der Logaritmus kommt bei google über die Betrachtungshöhe ins Spiel. -- visi-on13:34, 23. Apr. 2008 (CEST)
Letzter Kommentar: vor 16 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
In der Vorlage_Diskussion:Positionskarte#Änderungen hatte sich Dschwen (WikiMiniAtlas) dafür ausgesprochen, dass pop und elevation wieder in der Schnittstelle erscheinen. Wenn ich ich ihn, in einer frühreren Diskussion, richtig verstanden habe, braucht er diese Angaben um die Anzeige von Objekten zu gewichten. Bisher konnte nur eine Grösse übergeben werden. Schnittstellenänderung? -- visi-on19:13, 2. Apr. 2008 (CEST)
Eines von beiden reicht. Zur Gewichtung verwende ich nur pop (und das auch nur bei type city). elevation waere fuer zukuenftige Anwendungen auch schoen. Noach schoener waere natuerlich wenn wir alles in 3D georeferenzieren, also bei jedem type eine elevation mitgeben wuerden. Aber das wuerde wohl weitreichende Aenderungen noetig machen. --Dschwen22:54, 2. Apr. 2008 (CEST)
Letzter Kommentar: vor 16 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo! Ich möchte anregen, die automatische Anzeige von Positionskarten in Infoboxen möglichst sparsam einzusetzen. Ich mache die Erfahrung, dass Infoboxen von Editoren wieder rausgelöscht werden, weil automatisch eine wenig informative und große Positionskarte erscheint. Dies gilt eigentlich für alle Infoboxen, die sich auf gut bekannte Regionen der deutschen Wikipedia beziehen. Beispielsweise stört es, wenn in der (umstrittenen) Infobox Kirche eine große Deutschlandkarte auftaucht. Sinnig wäre hier höchstens, einen Stadtplan mit dem markierten Standort anzuzeigen. Dies wird aber vermutlich nicht machbar sein?! Für die Akzeptanz der Georeferenzierung finde ich es daher besser, auf Positionskarten weitestgehend zu verzichten. (Wurde sicherlich schon woanders diskutiert - habe ich aber nicht gefunden). Gruß --Boente13:02, 5. Apr. 2008 (CEST)
automatisch kommt man höchstens bis auf Länderebene runter. Hast du diese der deutschen Geographie so kundigen Autoren schon mal darauf angesprochen, dass nicht jeder deutschsprachige auch automatisch in den genuss des deutschen Geographieunterrichts kam? Für mich sind die Schweizer Karten auch eher überflüssig, kann aber nachvollziehen, dass diese anderen Lesern hilfreich sein können. -- visi-on15:53, 5. Apr. 2008 (CEST)
Das mit der Länderebene stimmt nicht ganz, siehe Gatschina. Ansonsten bin ich der Meinung, dass man die Positionskarten verantwortungsbewusst einsetzen soll. Ob sie in den Artikel passt, muss in jedem Einzelfall überprüft werden. Obersachse17:13, 5. Apr. 2008 (CEST)
Konkreter Anlass für dieses Posting war Gethsemanekirche (Frankfurt). Die Information, wo Frankfurt in Deutschland liegt, gehört wohl eher auf die Seite von Frankfurt am Main. Für die Kirche selber sehe ich eine nützliche Zusatzinfo höchstens darin, die Position innerhalb von Frankfurt anzuzeigen, ggf. mit Markierung des Gemeindegebiets. Dies ist natürlich nicht automatisch möglich. Von daher ein klares Votum von mir, die Karte in den meisten Infoboxen nicht automatisch anzeigen zu lassen. --Boente12:11, 6. Apr. 2008 (CEST)
In dem Fall gebe ich Dir recht. Ich wäre trotzdem für das automatische Anzeigen der Positionskarte, jedoch mit der Möglichkeit des Abschaltens. Schau Dir mal Vorlage:Infobox Ort in Russland an. Hier gibt es z.B. den Parameter Breite der Landeskarte =. Wenn der auf Null gesetzt wird, wird die Anzeige der Landeskarte unterdrückt. Obersachse15:19, 6. Apr. 2008 (CEST)
Aufwändige Parserfunktionen
Letzter Kommentar: vor 16 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
es liesse sich mit Angabe von Dezimalgrad entschärfen. Ansonsten bleibt mir nur an der Sinnhaftigkeit solcher Listen zu nörgeln ... -- visi-on19:47, 10. Apr. 2008 (CEST)
Der Artikel wird jetzt zwar nicht mehr als Seite mit zu vielen aufwändigen Parserfunktionen gewertet, aber es dauert immer noch 45 Sekunden, um aus dem Wiki-Text XHTML zu erzeugen. Im erzeugten XHTML steht: <!-- Served by srv169 in 45.216 secs. -->. Kann die neue Koordinatenvorlage weiter optimiert werden? --Fomafix13:27, 29. Apr. 2008 (CEST)
Letzter Kommentar: vor 16 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo zusammen,
Habe jetzt mal alle Artikel die diese Vorlage eingebunden hatte auf Vorlage:Coordinate umgestellt. Wie soll jetzt weiter mit dem Rest verfahren werden? MfG Monsterxxl<°))))>14:41, 13. Apr. 2008 (CEST)
Letzter Kommentar: vor 16 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hi, eigentlich ist das Einbindungen von Koordinaten ja nicht so sonderlich schwer, zumindest nicht mit den entsprechenden Zusatzseiten, die einen anhand der Landkarte den Code ausgeben. Allerdings sind diese anscheinend veraltet? Und ich muss ehrlich gestehen, dass ein User, der sich neu diesem Thema widmen möchte, sehr bald abgeschreckt sein wird durch die Aufmachung und Unstrukturiertheit. Keine Ahnung, ob sich hier NUR Wikipedianer tummeln, die mit dem Projekt großgeworden sind, oder Geographen, für die das alles ein Klacks sein sollte, aber ich vermisse eine Kurzanleitung für Dummies, mit Beispielen, mit aktuellen Links und funzenden Tools, mit einer sehr strengen Auswahl der besten Tool-Seiten, Dummies brauchen nicht zig Varianten kennen, und alles auf einer Bildschirmseite, damit man nicht vor lauter Scrollerei wieder die Lust verliert.
Oder soll weiterhin die alte Vorlage genutzt werden? Obwohl auch die dortigen Infos übel dem Neuling aufbereitet wurden. Keine Ahnung ob die Georeferenzierungsleute damit lieber unter sich bleiben möchten oder nicht. Neulinge werden jedoch sicher schnell abgeschreckt, denn nicht jeder hat die Lust sich da durchzuwühlen, wie ich es notgedrungen tat. Ciao und Gruß, -- Lynxxx12:50, 14. Apr. 2008 (CEST)
Anscheinend hat hier niemand Interesse, mehr Leute für die Georeferenzierung zu gewinnen? Na, dann stelle ich mal eine letzte konkrete Frage, bevor ich euch wieder allein lasse:
Letzter Kommentar: vor 16 Jahren26 Kommentare8 Personen sind an der Diskussion beteiligt
Bitte beim Umstellen nicht die Unart anfangen, wie die Amerikaner Koordinaten in digitaler dezimaler Schreibweise einzugeben. --Matthiasb19:58, 14. Apr. 2008 (CEST)
Welche Gründe hast du dafür? Die Ausgabe erfolgt doch weiterhin in DDMMSS-Form. Intern brauchen wir einfach die dezimale Schreibweise und da macht es wenig Sinn immer erst DDMMSS->dezimal->DDMMSS umzurechnen. So jedenfalls der Stand bei Koordinatenneuerstellung. Bei Umstellung bleibt zugegeben das Argument, dass Aussagen über eine nur minutengenaue Präzision verloren geht und es zu geringfügigen Verschiebungen der Koordinaten kommen kann. --Kolossos20:13, 14. Apr. 2008 (CEST)
Und das nächste Projekt macht es wieder anders und schon liegen die Objekte um Längen daneben. Transparenz des Quelltextes. Unter -122.658611 kann man sich wenig vorstellen, 122/39/31/W geben schon eine Vorstellung wo sich ein Ort befindet. Was ich sehe, werde ich jedenfalls revertieren. --Matthiasb20:18, 14. Apr. 2008 (CEST)
Aber ein Coputer kann sich unter -122.658611 deutlich besser etwas vorstellen und dieses verarbeiten ohne sonderlich fehleranfällig zu sein. Wenn du dir die Links im Geohack anschaust, erkennst du dass alle Geoservices über die Dezimalschreibweise aufgerufen werden. Da sind wir also in guter Gesellschaft. Solange Längen- und Breitengrad nicht vertauscht werden, ist die Dezimalschreibweise genau so gut lesbar. Bitte also keine reverts. --Kolossos20:44, 14. Apr. 2008 (CEST)
Was der Computer kann, interessiert nicht die Bohne. Der PC ist für mich da und nicht umgekehrt. Ich sage euch, was daran sch... ist: DE ist auch Referenz für rund 190 andere Sprachversion. Leider seid ihr auf die glorreiche Idee gekommen, daß wegen der Genauigkeit bei Inseln oder Staaten oder Städten keine Sekundenangabe in der Anzeige mehr notwendig sei. Wie soll man nun den korrekten Wert herausbekommen? Dezimale Koordinaten sind böse, die Eingabe ist unnatürlich. Die Erde ist eine Kugel und keine Scheibe. Aber wenn ihr ein MB dazu braucht, von mir aus. --Matthiasb20:52, 14. Apr. 2008 (CEST)
Mit Verlaub ich staune ob deiner sphärischen Vorstellungskraft. In deinem oben gegebenen Beispiel reicht meine ungefähre Lokalierungsfähigkeit maximal auf ±5°. Dh ich kann dir nach 1Minute Nachdenken grad so knapp die Zeitzone wiedergeben. Auch bei den Breitengraden ist bei mir so ungefähr bei einer halben Minute definitiv Ende der Durchsage. Das reicht mir für die geografische Orientierung (zB mittlere Sonnenexposition und -Einfalwinkel einer Geländefläche) aus.-- visi-on21:35, 14. Apr. 2008 (CEST)
Es geht darum, daß eifrige Helfer - oh wie ich diese Mitarbeiter liebe, ich habe erst kürzlich in einem anderen Zusammenhang rund 2800 US-Ortsartikel nachkontrolliert –, die in den Artikeln vorhandenen GMS-Koordinaten auf dezimale Schreibweise umzustellen. Und das paßt mir gar nicht. --Matthiasb21:58, 14. Apr. 2008 (CEST)
Ok, mit eifrigem Helfer meinst Du scheinbar mich. Deswegen führe ich die kurze Diskussion von meiner Benutzerseite mal hier weiter. Die von Dir monierten Edits gehen darauf zurück, dass die Vorlage Coord abgeschafft werden soll und durch Coordinate ersetzt werden soll (s. MB). Falls dies falsch ist, korrigiere mich bitte. Bei der Umstellung halte ich mich erst einmal an die Empfehlungen des entsprechenden Projekts und die sind (wie man hier lesen kann) relativ eindeutig (=> dezimale Notation). Du drohst mir, mich aufgrund meiner Edits auf WP:VM melden. Mit welcher Begründung? Mir ist es relativ egal, in welcher Notation die Koordinaten angegeben werden sollen. Wenn ich jetzt aber GMS nutze, fürchte ich, dass sich morgen jemand anderes bei mir beschwert. Also warte ich erst mal ein Ergebnis dieser Diskussion ab und tue bis dahin gar nichts. Ist das in Deinem Sinne? --Boente18:51, 15. Apr. 2008 (CEST)
Woraus schließt du auf eine eindeutige Empfehlung? Im MB wurde jedenfalls nicht beschlossen, daß die Koordinaten flächendeckend umgestellt werden. Wohin diese Umrechnerei führt, sieht man bei unzähligen Konvertierungen von Meilen/Fuß in Meter – da werden in aller Ruhe Informationen, die in EN auf volle Meilen gerundet sind (about 40 miles) allen Ernstes übersetzt mit etwa 64,37 Kilometer). --Matthiasb21:10, 15. Apr. 2008 (CEST)
Wenn dir schon egal ist was Computer machen (auch wenn ich der Meinung bin, dass wir auf eine sinnvolle Zusammenarbeit mit diesen Maschinen angewiesen sind), so beachte doch wenigsten den Konsens unter den Wikipedianer die dieser Vorlage in einem ausführlichen Meinungsbild zugestimmt haben. Im Vorfeld gab es auch umfangreiche Diskussionen, dabei zeigte sich der Wille den Vorlagenwust in aufzuräumen und mit Hilfe der neuen Vorlage zu vereinheitlichen. Edits bei dennen du dahingehend Coordinate wieder durch Vorlage Coord ersetzt, kann ich da nicht nachvollziehen. Zu deiner Frage, wie du an die genauen Sekundenangaben kommst, so reicht ein einfacher Klick um im Geohack diese Daten angezeigt zu bekommen. Es gab halt wohl die mehrheitliche Meinung, dass den genau Zahlenwert nur wenige interessieren. --Kolossos22:22, 14. Apr. 2008 (CEST)
In dem MB lese ich nichts davon, Koordinaten im Quelltext flächendeckend von DMS auf D umzuwandeln. Und wenn du diesen Edit als rauspickst, dann ist das allenfalls tendenziös, vgl. meine anderen Edits. --Matthiasb09:05, 15. Apr. 2008 (CEST)
Tendenziös werden wollte ich nicht. Ich wollte nur ergründen, wo deine Problematik liegt und bin dabei auf diesen Edit gestoßen. Sorry.
Ich denke es ist klar geworden, dass es Befürworter der dezimalen Schreibweise gibt und diese auch Argumente haben. Dabei haben sich bestimmte GIS-Experten wie Geonick noch garnicht zu Wort gemeldet, die standartisierte Dezimalschreibweise für die einzig wahre halten (irgendwo im Archiv). Es gibt also auch mathematische und nicht nur IT bedingte Gründe Positionsangaben einfach über 2 Floatzahlen vorzunehmen, einfacher geht es nicht. --Kolossos 09:23, 15. Apr. 2008 (CEST
Aber nicht vergessen, daß der Geohack wegen der TS-Probleme manchaml tagelang gar nicht zur Verfügung steht (obwohl sich da die Situation zugegebenermaßen verbessert hat). --Matthiasb21:10, 15. Apr. 2008 (CEST)
Der subjektiven Wahrnehmung der besseren Überprüfbarkeit steht einfach eine 4-fach höher Fehlerwahrscheinlichkeit gegenüber. Im DMS-Format kann jede Subgrösse (Grad, Minute, Sekunde und Richtung) falsch sein. Eine Umwandlung der Quellgrössen halte ich für verfehlt, in welche Richtung auch immer, denn in der Umwandlung steckt wiederum ein Fehlerrisiko. Einzig bei den Schweizer Landeskoordinaten hatten wir uns auf eine Umwandlung in WGS84 verständigt. Für die Nachvollziehbarkeit wird dort extra der Quellcode der Umwandlung als Kommentar in die Source geschrieben.-- visi-on10:22, 15. Apr. 2008 (CEST)
Zahlendreher sind im dezimalen System viel schwerer erkennbar, weil da die Ziffern von 0-9 laufen; im DMS-System laufen die Zehner bei M und S nur von 0-5, unzulässige Werte werden da abgefangen. Zum Argument mit den Floarzahlen: Es ist einfacher drei Zahlengruppen von zwei/drei Ziffern abzutippen, als eine fünf oder sechsstellige Folge, wo nicht erkennbar ist, welche Ziffer was entspricht. --Matthiasb20:58, 15. Apr. 2008 (CEST)
Ich schließe mich Matthiasb an, die dezimale Schreibweise ist weniger eingängig. Leicht lesbar ist die Angabe von Gradangaben, und zwar inklusive Sekunden... (Warum diese plötzlich nicht mehr erscheinen sollen, ist mir ein Rätsel) --RoterraecherDiskussion22:36, 15. Apr. 2008 (CEST)
Ich kann Matthias ebenfalls nur zustimmen. Wer einmal wie ich beim Umrechnen der Dezimalschreibweise (die übrigens ein falsches Ergebnis lieferte) im Mittelmeer statt in Barcelona landete, kann die traditionelle Datenangabe nur bevorzugen. --Herrick08:27, 21. Apr. 2008 (CEST)
Darum könntest du auch einmal aufmerksam nachvollziehen, wie es meine en: US-Quelle lieferte: in falschen Dezimalangaben, die sich nicht auf das klassische System umrechnen ließen. Wenn ich segle, weiß ich genau, dass meine Anzeige aus nachvollziehbaren Gründen beide Werte angibt - und wonach navigiere ich wohl im Zweifelsfall? --Herrick14:43, 21. Apr. 2008 (CEST)
Tja, dann hätte man heute noch nicht Amerika entdeckt Und das o.e. Dezimalsystem ist wieder einmal nur eine US-Marotte. --Herrick15:39, 21. Apr. 2008 (CEST)
Man sieht, du hast schon lange keine Position mehr gerechnet. Das Dezimalsystem ist übrigens eine napoleonische Marotte, genauso wie das Fahren auf der falschen Seite. -- visi-on17:04, 21. Apr. 2008 (CEST)
ich habs gesehen, danke. Dieses sonderbare Verhalten betrifft auch noch andere Parserfunktionen. -- visi-on12:12, 18. Apr. 2008 (CEST)
Welche Kriterien?
Letzter Kommentar: vor 16 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Nach welchen Kriterien werden denn eigentlich die Koordinaten eines Ortes bestimmt? Im Zusammenhang mit einem von mir derzeit per EN überarbeiteten Artikel finden sich die folgenden Angaben:
Das kommt mir irgendwie so vor, als wolle man die Koordinaten des Reichstages ermitteln, gäbe aber, ohne mit der Wimper zu zucken, die des Brandenburger Tores an.
Die Abweichung von etwa 250 m in Nord-Süd-Richtung und bei der Breitenlage mal grob auf einen halben Kilometer geschätzt in Ost-West-Richtung läßt sich kaum mit Ungenauigkeiten bei der Ermittlung erklären – in Minnesota kann man mit dem üblichen (Online-)Kartenmaterial nahezu in einen Vorgarten hineinzoomen. Bezogen auf den besagten Ort entspricht die Fläche, die sich aus der Abweichung errechnet, fast einem Prozent seiner Gesamtfläche. Das wiederum macht vor dem Hintergrund, wie Orte im amerikanischen Mittelwesten typischerweise aufgebaut sind, so ziemlich dem größten Teil der geschlossenen Bebauung aus – der Ort hat insgesamt eine Bevölkerungsdichte von nur 32 Wohnungen/km².
Nach welchen Kriterien geht man vor?
Koordinaten in Datenbanken (in USA etwa GNIS oder Census Bureau)
Koordinaten auf der amtlichen Website des Ortes (falls vorhanden)
Koordinaten per Google Maps (oder ähnlichem Medium) von
Rathaus
Kirche
Marktplatz oder Hauptplatz
Schnittpunktes der Haupt(durchgangs)straßen N/S und O/W (falls erkenn-/bestimmbar)
gefühlter optischer Mittelpunkt anhand des Lageplans
der gesamten Gemarkung
der geschlossenen Bebauung
kritiklose Übernahme aus anderen Quellen (etwa EN:WP)
Es handelt sich im übrigen um keinen Einzelfall, sondern, wie ich bei meinem Zug durch die Staaten beim Einbauen der Lagekarten feststellte, um hunderte von Einzelfälle.
Die Frage paßt übrigens indirekt auch zu der auf WP:FZW von gestern hinsichtlich von Brücken und Tunnel. In der dortigen Diskussion hat sich aber zumindest ein Konsens dahingehend abgezeichnet, bei Brücken die Brückenmitte abzuschätzen und bei Tunnel (wo die Mitte "optisch" in der Pampa liegt) die Koordinaten des Tunnelportals anzugeben, das die Streckenkilometrierung der Bahnstrecke oder Straße zuerst erreicht.<Achselzuck zum Gotthardtunnel/> --Matthiasb11:01, 17. Apr. 2008 (CEST)
Also ich habe manche Koordinaten hiermit ermittelt: http://www.giswiki.org/hjl_get_CoorM.htm Damit kam zumindest bei meinen Test mit Googlemaps immer die richtige Position heraus, allerdings bin ich dann in meiner Aufsicht bei Googlemaps nie so dicht an dem Gebäude drauf, wie in diesem Tool. Da scheint etwas mit dem Scale und Dim-Wert nicht zu stimmen? Ich würde nämlich in googlemaps gerne gleich die zweitgrößte Vergrößerung sehen können, um das Gebäude mit seiner Baustruktur zu erkennen, statt erst reinzoomen zu müssen. (Beispiel: Ibrahim-Pascha-Palast: 41° 0′ 22,7″ N, 28° 58′ 28,4″ O41.006328.97456 ) LG -- Lynxxx 11:43, 17. Apr. 2008 (CEST) [EDIT: Achja, noch ne Anmerkung: Ich suche mir in diesem Tool immer mit der Satellitenansicht das Gebäude, Platz, etc. raus. also nutze keine reinen Daten aus einem Reiseführer, oder ähnlichem. Vielleicht liegt es daran, dass es bei dir nicht stimmt? -- Lynxxx11:45, 17. Apr. 2008 (CEST) ]
Koordinaten in Datenbanken (in USA etwa GNIS oder Census Bureau)- Zur Not, manchmal nur Minutengenau.
Koordinaten auf der amtlichen Website des Ortes (falls vorhanden) - Auch manchmal falsch und z.T. noch grob in Gauß-Krüger-Koordinaten ermmittelt.
Koordinaten per Google Maps (oder ähnlichem Medium) von - Auf jedenfall damit prüfen, lag früher aber oft auch falsch
Rathaus -noch am ehesten
Kirche -nein
Marktplatz oder Hauptplatz - wenn dort auch das Rathaus steht, und das ganze historisch ist, ist das sicher sehr gut. Bitte keine Überschneidungen mit anderen Wikipedia-Objekten. Wenn es also über den Marktplatz einen Artikel gibt, dann bitte leicht versetzen.
Schnittpunktes der Haupt(durchgangs)straßen N/S und O/W (falls erkenn-/bestimmbar) - nein, höchsten in den USA im "Wilden Westen"
gefühlter optischer Mittelpunkt anhand des Lageplans- ja eindeutig mein Favorit, das ganze muss nicht alzu genau sein. Basis sollte das historische Zentrum sein.
der gesamten Gemarkung
der geschlossenen Bebauung
kritiklose Übernahme aus anderen Quellen (etwa EN:WP) - bitte prüfen, aber generell zulässig.
Ergänzend möchte ich noch sagen, dass manche Städte wie Berlin vom Stadtrrad ein definiertes und oftmals ausgebauten Stadtmittelpunkt haben.--Kolossos13:21, 17. Apr. 2008 (CEST)
Na was nun ? Muss man sich täglich umstellen?
Letzter Kommentar: vor 16 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, bis vor 2 Tagen funktionierte die Koordinierung in den den Insel-IBoxen einwandfrei. Jetzt hagelt es peinliche ERRORs ... Wenn das hier so weiter geht, da schreibe ich halt meine eigenen Routinen für meine Projekte. --Zollwurf17:08, 20. Apr. 2008 (CEST)
Kann man mir den Sinn dieser "Notwendigkeit" mal erläutern? Aus oben genanntem Beitrag "ausgeschnippelt":
|LAENGE=1.35|BREITE=0.25|FLAECHE=0,27 km² Soll es jetzt ein Dezimalpunkt (US-Schema) oder ein Dezimalkomma sein? --Zollwurf11:35, 21. Apr. 2008 (CEST)
Countys in den Vereinigten Staaten
Letzter Kommentar: vor 16 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
MMn wäre es sinnvoll bei den Artikeln in den Unterkategorien von Kategorie:County in den Vereinigten Staaten die Vorlage:Koordinate Artikel schon durch Vorlage:Coordinate botmäßig zu ersetzen, damit die Mitarbeiter im P:USA einen Überblick bekommen, was in ihrem Bundesstaat so los ist. Es handelt sich um ca. 3700 Artikel, die wird niemand händisch umstellen und eine Kombination mit der IB ist da nicht notwendig (keine Positionskarte). Bei der Gelegenheit sollte man die Abschnittsüberschrift Geografie auf Geographie vereinheitlichen. --Matthiasb17:48, 26. Apr. 2008 (CEST)
Ich würde ein einfügen in die IB trotzdem für sinnvoll halten, da die Vorlagenauswertung besser genutzt werden kann. Außerdem können die type und region angaben von der Infobox vorgegeben werden. Auch kann man dann noch überlegen, ob man zusätzlich die Koordinaten als Text ausgegeben haben möchte. Auch könnte ein lagewunsch direkt von der IB übernommen werden. Der Umherirrende13:38, 29. Apr. 2008 (CEST)
Letzter Kommentar: vor 16 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Die neue Koordinatenvorlage kann bei Erdbeben nicht zielführend eingebunden werden.
{{Coordinate|article=DMS|NS=31/5/2.4/N|EW=103/16/1.2/E|type=landmark|dim=250000|region=CN-51}} liefert nicht ganz China, was sinnvoll wäre, sondern nur einen Teil und gibt keine Sekunden an (was bei Epizentren durchaus sinnvoll ist)
{{Coordinate|article=DMS|NS=31/5/2.4/N|EW=103/16/1.2/E|type=country|region=CN-51}} liefert einen sinnvollen Kartenausschnitt, zeigt aber völlig unzureichende Koordinaten an
{{Coordinate|article=DMS|NS=31/5/2.4/N|EW=103/16/1.2/E|type=landmark|region=CN-51}} zeigt zwar richtigerweise die genaue Position an, liefert aber einen unbrauchbaren Kartenausschnitt (Google hat in der Gegen nicht einmal Karten im gewählten Maßstab verfügbar)
Wie kann ich die Vorlage dazu zwingen, einerseits auf einen großen Kartenausschnitt zu verlinken, andererseits Grad, Minuten und Sekunden anzuzeigen? --Matthiasb20:27, 12. Mai 2008 (CEST)
Gar nicht, aber es wäre diskutabel, bei type=landmark, was ja bereits eher auf etwas kleinräumiges hinweist, auf die Rundung zu verzichten. mal abwarten was die andern meinen. Gegenbeispiele? -- visi-on20:40, 12. Mai 2008 (CEST)
mit den fixes sind die Möglichkeiten in der WP erschöpft. Was «geohack» mit dim/scale anfängt habe ich nicht unter Kontrolle:
{{Coordinate|text=DMS|NS=31/5/2.4/N|EW=103/16/1.2/E|type=landmark|dim=250000|region=CN-51}} Parameter name fehlt in Fließtextkoordinate31° 5′ N, 103° 16′ O31.084103.267
Letzter Kommentar: vor 16 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
Als Dezimaltrenner erscheint der Punkt statt dem Komma zum Beipiel hier, muss man doch weiter wie in der alten Vorlage die Koordinate zusätzlich als Text eingeben? -- 91.7.61.23900:39, 16. Mai 2008 (CEST)
Ohje, tut mir leid, aber der Ersteller der Vorlage, ging im ehemaligen immernoch Punkt/Hochkomma-Land Schweiz in die Schule ...
...und fleissig sind die Sisyphos-Sichter. Soll ich wirklich 10tausende von gesichteten Atikeln mit wenigen Tastaturanschlägen (weniger als es für diesen Text brauchte) degradieren? -- visi-on13:04, 16. Mai 2008 (CEST)
Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Ist es gewollt, daß die Vorlage ein Leerzeichen vor Textkoordinaten einfügt? Ich habe ({{Coordinate|text=DMS…}}) eingegeben und generiert wurde ( <span…). --jailbird14:45, 1. Jun. 2008 (CEST)
Letzter Kommentar: vor 16 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
Eigentlich sollten die Leerzeichen zwischen den Grad-, Minuten- und Sekundenangaben ja schmal sein. Spricht etwas dagegen, in Vorlage:Coordinate to DMS an den beiden betroffenen Stellen durch {{\}} zu ersetzen? Die Vorlage:\ simuliert ein schmales geschütztes Leerzeichen (welches ja direkt aus Gründen der Browserkompatibilität nicht verwendet werden kann). Vergleiche:
Den Trick der Vorlage:\ kenne ich. Ich bin davon noch nicht überzeugt. Wenn, dann werde ich den Trick direkt implementieren. Die Vorlage hat schon genug Nodes. -- visi-on17:21, 7. Jun. 2008 (CEST)
Mit dem neuen Parser ist die pre-expand-size zwar kein limitierender Faktor mehr aber es ist immernoch sehr viel html-code um nur einen Leerraum darzustellen. Konkret resultiert expandiert:
Interessante Variante! Ich schlage vor, das zumindest schonmal einzubauen. Bei mir (ff3) ist 75* = 100*<small> </small> = 142*{{\}}, also = 0.316em, <small> </small> = 0.237em. Also schonmal eine deutliche Verbesserung. Leider macht eine weitere Verkleinerung bei mir keinen Unterschied. --Quilbert問16:48, 8. Jun. 2008 (CEST)
ja dem ist so, weil auch bei kleiner Schrift immer ein Leerraum erkennbar bleiben soll. Man kann es nun auch so betrachten, dass aus typographischer Sicht der Leerraum nie kleiner werden sollte. -- visi-on11:46, 10. Jun. 2008 (CEST)
Mit <span style="font-size:0.5em"> </span> erreiche ich bei mir ein geschütztes Leerzeichen, das nur halb so breit wie ein normales Leerzeichen ist:
ihr habt sicher Wikipedia:Löschkandidaten/18. Juni 2008#Vorlage:\ gelesen: dort ist jetzt ein WCAG-konfomer ansatz gewählt (class="nnbsp"), der langfristig angetragen ist, und sich von diversen hacks und ihren jeweiligen nachteilen distanziert (<small> </small> hielt ich ursprünglich auch für gut, ist aber etwa für kleine schriften und fixedfonts eine ziemlich unleidige sache.., ditto em-angaben) - mit dem editbutton ist der aufwand übrigens auf einen click reduziert (und wie gesagt, angesichts des aufwandes, der sonst für formatierungen betrieben wird, ist diese sache minimalst) - ob andere vorlagen nun diese vorlage, oder den code direkt benutzen, ist adhoc mal egal, weil es schnell geändert werden kann - nur, wenn wieder jeder sein privat-süppchen kocht, kommen wir der WCAG-konformität nicht näher --W!B:11:47, 29. Jun. 2008 (CEST)
CSS-Definition für Dezimal-Puristen
Letzter Kommentar: vor 16 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Man muss eben alles was geht auch mal ausprobiert haben ;-)
Hallo visi-on, so leid es mir auch tut, traditionellerweise funktionieren :after und :before nicht im IE (hab's grad eben für V7.0 gecheckt). lg --Herzi Pinki20:08, 1. Jul. 2008 (CEST)
Dann ist dieses goody halt nur für Feuerfuchsanwender gut. Ich finds noch praktisch, denn so sehe ich grad was in der Koordinate drin ist. -- visi-on20:39, 1. Jul. 2008 (CEST)
Rechteckige Klammer rechts oben
Letzter Kommentar: vor 16 Jahren13 Kommentare3 Personen sind an der Diskussion beteiligt
Hinter den Koordinaten rechts oben erscheint einsam und hilflos eine schließende rechteckige Klammer. --Torsten Bätge 18:40, 4. Jul. 2008 (CEST)
Habe mir das eben nochmal mit Firefox angeschaut, dort ist tatsächlich keine Klammer. Beim Internet Explorer 7 allerdings schon. --Torsten Bätge 19:00, 4. Jul. 2008 (CEST)
Datei:Klammer.pngHier ist mal ein Screenshot der betreffenden Stelle dieser Seite. --Torsten Bätge 19:20, 4. Jul. 2008 (CEST)
Das sieht aber so aus als ob hier die Koordinate etwas anderes überdeckt. Welcher Artikel ist das? und wie siehts ohne Artikelkoordinate aus?-- visi-on19:24, 4. Jul. 2008 (CEST)
Das liegt an der Nachricht: Es läuft eine erneute Testrunde der stabilen Versionen. Ab sofort wird der Sichterstatus wieder automatisch vergeben. [Verbergen]. --тнояsтеn⇔19:29, 4. Jul. 2008 (CEST)
Ja, das ist es. Passt das nur bei mir so seltsam genau? --Torsten Bätge 19:33, 4. Jul. 2008 (CEST)
Ich sehe die Klammer auch im FF3.0. Das ist der Rest von [Verbergen], der nicht ganz verborgen ist.Die gesichteten Versionen lassen sich halt nicht verbergen. Das Grundproblem ist wieder einmal, dass sich zwei absolut positionierte divs überlappen. Und das damit der [Verbergen]-Link nicht anklickbar ist. Ich dachte visi-on, du bist bei den Wassern? lg und schade dass du nicht ins Zillertal kommst. --Herzi Pinki21:46, 4. Jul. 2008 (CEST)
guter Tip! Mal sehen in welches Flusssystem ich morgen ... Ja bedaure das auch sehr dem Zillertal fern bleiben zu müssen. -- visi-on23:36, 4. Jul. 2008 (CEST)
Letzter Kommentar: vor 16 Jahren15 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo zusammen.
Wie die meisten ja schon wissen gibt es die Kategorie Parameterfehler. Dort werden Parameter der Vorlage Coordinate und Positionskarte auf Fehler überprüft. Seit einiger Zeit nun auch die Höhenangabe. Soweit ich gesehen habe sind deutsche Städte und Gemeinden aufgrund einer fehlerhaften Höhenangabe mit in der Kategorie gelistet. Wie wollen wir damit umgehen? Erst mal alles dabei lassen und nicht beachten, oder etwas der Art von HÖHEVON und HÖHEBIS für die Vorlage:Infobox Gemeinde in Deutschland/Vorlage:Infobox Ort in Deutschland ausarbeiten? MfG Monsterxxl<°))))>14:33, 7. Jul. 2008 (CEST)
ich bin natürlich wiedermal von den Socken, dass es so viele sind. Dann aber hinterfrage ich auch ernsthaft den Sinn solcher Bereichsangaben, denn würde ich dies auf die Gemeinde Zermatt übertragen ergäben sich womöglich 1523 bis 4634 Meter über Meer (Dufourspitze) mit nahezu Null Aussagekraft zum effektiven Siedlungsgebiet. Ich wäre also eher für langsames aber sicheres ausrotten. Wie auch immer, wir sollten es einfach schaffen eine sinnvolle Zahl an die Koordinatenvorlage zu übergeben. Da spricht eigentlich nichts dagegen auch bei der Höhenangabe das Prinzip des Gefühlten Zentrums anzuwenden. -- visi-on16:31, 7. Jul. 2008 (CEST)
OK, soll mir recht sein. Habe schon vor längerer Zeit mal eine Diskussion bei einer anderen Vorlage in diese Richtung geführt. Da sind wir aber zu keinem Schluss gekommen... Rein prinzipiell gäbe es ja auch noch die Möglichkeit einen ittelwert aus den Höhen VON und BIS zu bilden. Wobei das dann endgültig auch nur verwirrung stiftet, da keiner mehr bescheid weiß wo die Werte herkommen. Denke mal wir sollten uns hier einigen und dann den Vorschlag hier vorbringen. Ich spreche das so explizit an, da diese Vorlage nach und nach gewachesen ist und viele ihr Herzblut investiert haben. Will da niemanden auf den Schlips treten. MfG Monsterxxl<°))))>17:34, 7. Jul. 2008 (CEST)
Das mit auf den Schlips treten hat etwas aber hier im Elfenbeinturm theoretisieren bringts auch nicht. Eventuell müssen wir die Diskussion halt an mehreren Punkten führen, aber wir wollen ja saubere Daten, also müssen wir hin gehen. -- visi-on17:47, 7. Jul. 2008 (CEST)
Sollte man nicht den Nullpunkt des Vermessungsamtes (auch für die Koordinaten) zugrundelegen (also wo die Kilometerangaben bei Entfernungen enden, in vielen Fällen das Rathaus oder der Bahnhof. Ansonsten sollte man sich nach WP:KTF doch an den Eigenangaben der Stadtverwaltung orientieren.--Matthiasb17:55, 7. Jul. 2008 (CEST)
Da die Vermessungsämter ebenfalls dem Prinzip Gefühlter Mittelpunkt nachleben und es hier eh nur um sinnvolle bis sinnentleerte Höhenbereichsangaben geht sehe ich grad nicht worauf du hinaus willst. Wenn ich aber grad nochmals den Beitrag von Kolossos finden würde, in dem er darlegt welche Koordinate gewählt werden soll, würde ich dich gerne dorthin verweisen. -- visi-on22:10, 7. Jul. 2008 (CEST)
Von daher betrachte ich auch meine Frage, ab wann denn dies nun erwünscht sei, als legitim. Hatte nämlich auch vorher erst nachgeschaut.
Bei den türkischen Orten war ein Fehler in der Vorlage, die Stauseen müssen halt nach und nach korrigiert werden. -- visi-on23:38, 7. Jul. 2008 (CEST)
Jo, sehe ich auch so. In die Türkische Vorage hatte ich noch gar nicht reingeguckt, aber du hast da eindeutig ein gutes Auge dafür und siehst die Fehler schneller als so manch anderer. Die Artikel, die in der Vorlage Stausee stehen halte ich an und für sich sehr Bot-fähig. Hab schon gesehen, das du da angefangen hast. Das sind aber noch immer über 250 Artikel. Da könnte man dann auch gleich so ein paar Standardsachen wie Tausendertrennzeichen entfernen, Komma durch Punkt, Rechtschreibung durch den Bot machen lassen. Ich glaube das ist im Endefekt einfacher und weniger Arbeitsintensiv. MfG Monsterxxl<°))))>07:00, 8. Jul. 2008 (CEST)
Die IB See steuert übrigens auch noch ein paar bei. Weil in diesem Gewässerspektrum sowieso mal eine Überarbeitung der IBs gut tun würde, erachte ich aber so Einzel-Flick-Aktionen per Bot ebenfalls für zu wenig effizient. Ja ich habe ein paar von Hand korrigiert, weil ich mir ein Bild von der Situation machen wollte. -- visi-on12:00, 8. Jul. 2008 (CEST)
Ok, wie denkst du dann darüber? Bot, Hand, Teilautomatisiert mit dem AWB? Also ich denke, wenn die IB's umgearbeitet werden würde ein Bottdurchlauf durchaus effektiver sein als alles nur mit der Hand zu sein. Und ohne jetzt mal eigennützig zu denken...Da ich gerade Prüfungen schreibe und dann eine kurze Zeit nicht da bin ist es für mich schwierig per Hand mitzuarbeiten. MfG Monsterxxl<°))))>19:48, 8. Jul. 2008 (CEST)
Ich denke ein redesign Anlauf könnte man mal versuchen anzustupfen. Bis dahin könnte man auch die Höhenübergabe an die Koordinatenvorlage unterbinden. -- visi-on21:36, 8. Jul. 2008 (CEST)
IB Ort in Lateinamerika korrigiert
Fehler in IB See und Stausee unterdrückt
keine Höhenübergabe in IB Ort in Südtirol mehr (da unbrauchbar)
IB Ort in Polen wünschen ausdrücklich Bereichsangabe
verteilt werden. Höhenbezug ist in der Regel der ISO-3166-1 Code ausser bei Deutschland (DE-NN/DE-NHN/DE-HN bzw FX für Frankreich (europäischer Teil) → Vorlage:Höhe
Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Also ich bin ja eigentlich begeistert von der neuen Vorlage. Nur eine Sache hab ich noch nicht rausgefunden. Zum Beispiel im Artikel Deutschland (und allen anderen Ländern) wird das ja so gemacht, dass eine Koordinate angegeben wird (der Mittelpunkt der Region vermutlich), als Text aber linke und rechte bzw. obere und untere Grenze angegeben werden. Wie funktioniert das mit Coordinate? Ich habe bis jetzt noch keine Coordinate gefunden, wo ich spicken könnte. Ich finde nur immer einzel-Coordinates, deswegen hab ich schon die Vermutung, dass das evtl. noch gar nicht geht und deswegen bei Ländern immer noch die Koordinate Artikel verwendet wird. --maststef18:13, 27. Aug. 2008 (CEST)
Bereichsangabe ist in der Artikelkoordinate (noch) nicht möglich. Bisheriger Konsens war aber, dass solches in der Fliesstextkoordinate ausreicht. -- visi-on17:23, 9. Sep. 2008 (CEST)
Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Können wir die beiden nicht langsam löschen/archivieren? Sind ja jetzt schon seit einiger Zeit nicht mehr im Artikelnamensraum eingebunden. MfG Monsterxxl<°))))>13:30, 28. Aug. 2008 (CEST)
Letzter Kommentar: vor 16 Jahren23 Kommentare6 Personen sind an der Diskussion beteiligt
Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit Belegen (beispielsweise Einzelnachweisen) ausgestattet. Angaben ohne ausreichenden Beleg könnten demnächst entfernt werden. Bitte hilf Wikipedia, indem du die Angaben recherchierst und gute Belege einfügst.
Diese Vorlage ist miserabel programmiert. Sie benötigt zehn (!) andere Vorlagen mit drei Ebenen. Das stellt wegen der vielen Einbindungen eine enorme Serverlast dar. Hier ist dringend Abhilfe nötig. Sie muss auch nicht so extrem deppensicher geschrieben werden. Die Untervorlage CoordinateLAT ist z.B. ein "überladenes Monster" ein expr-Ausdruck recht m. E. völlig. Cäsium137(D.)19:09, 25. Okt. 2008 (CEST)
Der Server muss jedesmal eine Untervorlagenseite neu laden und durch den Parser schicken. Das ist generell schlecht. Es ist immer besser, wenn der Code schlank ist. Cäsium137(D.)22:06, 25. Okt. 2008 (CEST)
Erstens werden viele der hier verwendeten Untervorlagenseiten nur optional geladen, d.h. der insgesamt geladenen Code je Verwendung der Hauptvorlage ist viel schlanker als die Summe aller Untervorlagenseiten.
Zweitens gilt das vermutlich nur, wenn die Seiten bearbeitet werden, sobald sie gecachet sind, gilt das nicht, oder? Und das ist die Menge der Zugriffe.
Drittens könnte alles viel einfacher/schlanker sein, wenn die Stringfunktionen freigeschalten wären. Die Komplexität der Vorlagen resultiert aus der eingeschränkten Programmierbarkeit der Vorlagen.
Gibt es viertens konkrete Messergebnisse, wie genau diese Vorlage(n) die Server belasten? Immerhin sollte vor jeder Performance-Optimierung eine Messung stehen. Optimierung auf Verdacht find ich nicht gut, und ohne Messung könnte man den Effekt der Optimierung auch nicht bewerten. Das Prinzip make it run, make it right, make it fast, make it small ist schon ok, momentan wären die ersten beiden Schritte getan, aber daneben gibt es auch noch den Aspekt der Wartbarkeit und Lesbarkeit. Und diesem Aspekt wäre bei dem von dir eingeforderten Spagetticode eher nicht gedient. Daher sollten unbedingt konkrete Maßzahlen vorliegen, bevor ev. unschöne Optimierungen in Szene gesetzt werden.
Im übrigen bin ich der Meinung, dass visi-on diese Vorlagen hervorragend programmiert hat. Das von dir gebrauchte Wort miserabel ist fehl am Platz. lg --Herzi Pinki22:36, 25. Okt. 2008 (CEST)
Also miserabel beziehe ich auf die Zerteilung des Codes. Die wirkt ja nicht wie ein Unterprogramm bei compiliertem Code, sondern wird von einem (schlechten) Parser bearbeitet. Das mit dem Cache ist unberechenbar. Der Server wirft auch häufig genutzte Seiten heraus, wenn eine andere, aufwendige Prozedur laufen soll. Verschlanken schadet auf jeden Fall nicht. Wenn keine pauschale Ablehnung kommt, dan mache ich mir da mal noch mehr Gedanken zu. Cäsium137(D.)22:59, 25. Okt. 2008 (CEST)
Ich würde erstmal auf den Hauptersteller Benutzer:visi-on warten, dieser macht derzeit eine Wikipause. Gedanken kann man sich gerne machen, bedenke aber, das die Vorlage schon sehr oft eingebunden ist und Änderungen daher auch nicht die Server entlasten, es sollte also nicht so laufen wie bei der Vorlage:Infobox Ort in Polen. Das größte Problem wird sein, die Codeänderungen auch zu testen, bis die jetztige Vorlage entstand ist auch viel Zeit investiert worden. Nicht nur bei Programmierungen und überlegungen wie man es machen kann, sondern auch die Diskussion und Überzeugungsarbeit etc. (Möchte garnicht wissen, was alles damit zusammenhängt) Der Umherirrende23:10, 25. Okt. 2008 (CEST)
(BK) Lese ich das richtig, es gibt demnach keine Messergebnisse, die auf ein konkretes Performanceproblem mit dieser Vorlage hindeuten? Ich denke die Dinge wären einfacher mit Stringfunktionen, Schleifen und Variablen. Mehr braucht es nicht. Vielleicht ist diese Vorlage ja ein Anfangspunkt, solche Features freizuschalten. Kaum hat jemand die Taylorentwicklung für den sin(x) ausprogrammiert, schon ist sie auch freigeschaltet worden. Falls du dir darüber hinaus Gedanken machst, unter Vorlage:Coordinate/Test gibt es (leider durch verschärfte Prüfungen nicht ganz aktuelle) Regressionstestfälle (ich schau mal - fehlende Pflichtparameter ergänzt, visueller Vergleich ok, automatischer soll-ist-vergleich geht noch nicht (wegen geänderter Formate)). Solange du nur eine Alternativimplementierung erarbeitest, ist alles ok, sonst möchte ich mich dem Rat meines Vorschreibers anschließen und dich bitten, auf Benutzer:visi-on zu warten, bevor das in Breite umgesetzt wird. Der hat immerhin ein halbes Jahr Arbeit in die miserable Vorlage investiert. enjoy --Herzi Pinki23:23, 25. Okt. 2008 (CEST)
Selbstverständlich überschreibe ich nicht einfach. Ich werde für den Fall gewiss an einem Duplikat editieren. Wenn das einigermaßen läuft kann ich ja immer noch Vorschläge machen. Das die Software unzureichend ist, dass wissen wir alle. Cäsium137(D.)23:39, 25. Okt. 2008 (CEST)
wenn es einigermaßen läuft, mit Verlaub, ist zuwenig. Bei der Menge an Einbindungen braucht es mehr als eine einigermaßen laufende Vorlage. Sonst gibt es Megazoff. Und es braucht ein klare Migrationsstrategie - bedenke dabei, dass der erste Schritt der Migration auf die Vorlage:Coordinate noch länger laufen wird. Das Interface der Vorlage wirst du ja hoffentlich nicht antasten. Und, es fehlen immer noch die begründenden Messergebnisse. Immerhin wäre es doch sinnvoll, die beiden Lösungen vor einer Entscheidung in diesem Punkt zahlenmäßig vergleichen zu können. lg --Herzi Pinki00:05, 26. Okt. 2008 (CEST)
Die Einbindungen von Coordinate sollen natürlich bleiben. Es geht um den Ersatz der Untervoragen durch Code in "Coordinate". Cäsium137(D.)00:10, 26. Okt. 2008 (CEST)
en:WP:PERFORM kann man m. E. zum größten Teil vergessen. Die haben auch nicht zum Sparen von Festplattenplatz (also Edits) aufgefordert. Trotzdem waren vor ein paar Tagen die HDDs voll. Bis die sch mit Anliegen an die User wenden, muss denen die Bude abbrennen... Daher ist dieses Prinzip mit Vorsicht zu betrachten. Darüber hinaus ist es das Problem der User, wenn der Quellcode langsam ist. Den Betreiber interessiert das wenig. Ansonsten wäre die WP-SW schon länsgt viel besser und effektiver. Cäsium137(D.)22:43, 26. Okt. 2008 (CET)
Wenn die Festplatten voll gewesen wären, hätte es wohl wesentlich länger gedauert, bis die Site wieder gelaufen wäre.
Aber es trifft sich ja schön, dass Du nicht Betreiber, sondern Benutzer bist und uns nun endlich aus unserer Ungeduld mit einer Quantifizierung reißen kannst, wieviel langsamer der Quelltext (?) von Vorlage:Coordinate gegenüber einer „optimierten“ Fassung ist. Gerade bei einer momentan ja anscheinend eher schlecht programmierten Wiki-Software sollten da ja Dimensionen messbar sein.
Die Vorlage wurde noch unter dem alten Preprozessor entwickelt. Ich hatte damals extremst die pre-expand-size im Auge (heute keine Limite mehr). Das optionale Laden von nur effektiv gebrauchten Untervorlagen musste damals noch mit einem kleinen Kunstgriff erzwungen werden.
Der neue Preprozessor wertet in if-Konstrukten nur den true-Zweig aus. Alle Bool'schen Ausdrücke sind darauf optimiert.
Bei einem Interpreter (hier der Fall) ist die Länge des Programms (effektiv gelesene Bytes) entscheident. Die hierzu zugänglichen Masszahlen (NewPP limit report) sind alle relativ zum erlaubten Maximum sehr tief:
Preprocessor node count: .../1000000
Post-expand include size: .../2048000 bytes
Template argument size: .../2048000 bytes
Expensive parser function count: .../500
Der Platzbedarf im Cache kann demzufolge nicht übermässig gross sein.
Es gibt keine Compilation.
Das Fehlen von Variablen wird soweit möglich über Untervorlagen und deren Parameter kompensiert. (Man kann im weitesten Sinn die Parameterübergabe als Variablenzuweisung betrachten.)
ich bedaure sehr, dass keine Stringfunktionen zur Verfügung stehen. Im Wissen, dass sich damit eine Turingmaschine bauen liesse trage ich diese Einschränkung aber mit Fassung.
Der Code ist weit von The Art of Computer Programming entfernt, reizt aber nach bestem Wissen meinerseits die Möglichkeiten der Vorlagenprogrammierung aus. Konkrete Vorschläge zur Verbesserung nehme ich jederzeit gerne entgegen. Im weiteren Danke ich Herzi Pinki für die bereits gemachten Darlegungen. -- visi-on19:15, 29. Okt. 2008 (CET)
Allgemein sehe ich das ähnlich, die fehlenden Möglichkeiten sind ein Problem hier: Eine sinnvolle SW muss die Möglichkeit haben, in begrenztem Rahmen auch eine TM zu ermöglichen. Solange sie keine Schadfunktion generieren kann (also entsprechende Begrenzung in Funbktionalität und Zuständen). Zum konkreten Anliegen: Mein Anliegen ist nicht die Laufzeit des Interpreters. Ich sehe die Zerteilung auf viele Untervorlagen als problematisch an. Ich gehe davon aus, dass HDD-Zugriffe das größte Potential zur Verzögerung haben. Wenn der heutige PP nur true-Zweige bearbeitet, dann könnte man doch einen Teil des in Untervorlagen befindlichen Codes direkt in die Vorlage:Coordinate schreiben. Dann wäre sichergestellt, dass dieser Code zusammen mit der Vorlage im Cache ist. Nach meiner Kenntnis werden stets alle Subvorlagen, derne Name konstant ist und welche nicht im Cache stehen, von der Platte gelesen und erst mit der Auswertung werden die nicht benötigten Teile, also false-Zweige, "vergessen". Ich würde eine Zusammenfassung begrüßen. Cäsium137(D.)22:00, 30. Okt. 2008 (CET)
Ergänzung: Darüber hinaus ist auch der andere Fall ein Problem: Es werden, wenn ich das richtig gesehen habe, einige Subvorlagennamen dynamisch generiert, d.h., der in einem Parameter enthaltene String ist Bestandteil des Vorlagennamens. Das bewirkt ein Anhalten des Interpreters mitten in der Prozedur, um das Laden der Subvorlage von der Platte zu warten (wenn nicht im Cache), denn erst, wenn der Interpreter an der entsprechenden Stelle der Auswertung ist, hat er die Information, welche Datei angefordert werden muss, zur Verfügung. Cäsium137(D.)22:13, 30. Okt. 2008 (CET)
Du hast das schon richtig gesehen nur:
ein Interpreter arbeitet immer dynamisch
statisch ausprogrammiert verdoppelt mindestens die Codelänge und so oder so ist dann die Vorlage entweder im Cache oder muss geladen werden.
Wenn du der Meinung bist, dass es nichts bringt, dann lassen wir es halt. Ohne Einigkeit ist eine Änderung gewiss nicht sinnvoll. Cäsium137(D.)23:40, 3. Nov. 2008 (CET)
Serverlast und „Langsamkeit des Quelltextes“ unterliegen keiner demokratischen Entscheidung, sondern sind zwischen zwei verschiedenen Vorlagenvarianten messbar (auch wenn ich immer noch nicht weiß, was letzteres ist). Wenn Du Dich endlich einmal bequemen könntest, Deine diesbezüglichen Behauptungen mit Daten zu belegen, wird – bei entsprechendem Messergebnis – mit Sicherheit niemand Deinen Änderungen in dem Weg stehen. --Tim Landscheidt05:43, 4. Nov. 2008 (CET)
Ich interpretiere die Aussage unseres radioaktiven Freundes so, dass die Sache hier erledigt ist. Dann sollten wir sie auch so behandeln. —Quilbert問14:48, 4. Nov. 2008 (CET)
Mir wäre eigentlich lieber gewesen, ich (, wir) hätte(n) Cäsium137 vom Gegenteil überzeugen können. Trotzdem vermag ich der ganzen Sache positives Abgewinnen. Wie es Open Source mit sich bringt, wurde der Code von einigen – mehr als ich ursprünglich annahm – analysiert und getestet. Dass es dabei auch mal zu kritischen Äusserungen kommt gehört da sozusagen zum Geschäft. -- visi-on18:07, 4. Nov. 2008 (CET)
Skins und CSS-Definitionen
Letzter Kommentar: vor 16 Jahren6 Kommentare1 Person ist an der Diskussion beteiligt
Die Definitionen sind inzwischen seit Monaten aktiv. Es ist also Zeit das mal zu bereinigen, solange ich noch weiss warum diese Definitionen mal angepasst wurden.
Fett sind die derzeitigen überdeckenden CSS-Styles aus der Source von Vorlage:CoordinateMAIN hinzugefügt.
absolute Fontgrösse wegen Fliesstext-/Artikel-Koordinaten. Ermöglicht freie Formatierung im Fliesstext
die Grösse ist so gewählt, dass man an den Sichtungs-Boxen, Lemmatitel usw. einigermassen vorbeikommt
ein margin-right sollte es an Stelle des padding-right auch tun. Verzicht auf !important (WP:BIENE)
Nicht sicher bin ich mir ob die Definition margin-left:18px nicht auch mit dem Seperator a[href ^="http://"] versehen werden muss. Meine aber dies sei nicht notwendig, denn
Letzter Kommentar: vor 16 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
In dem Artikel steht (nicht von mir):
{{Coordinate|text=DM|NS=47/13/0/N|EW=1/32/0/W|type=landmark|name=Zentrum der Landhemisphäre|region=FR-E}}
und heraus kommt (jedenfalls in meinem uralt-Konqueror und in Lynx, beide ohne JavaScript und ohne Wikipedia-Anmeldung):
47° 13′ N, 1° 32′ W47.216666666667-1.5333333333333
Da stimmt doch was nicht - wo kommen die nachgestellten Zahlen mit den Sechsen und Dreien her ?
Wissende, helft ! -- Juergen 80.133.212.18610:10, 30. Dez. 2008 (CET)
ist zwar ein blöder Hinweis, aber hast du schon versucht, deinen clientseitigen Cache zu leeren? soll angebelich dageben helfen. lg --Herzi Pinki23:37, 30. Dez. 2008 (CET)
Klar. Habs ja auch extra noch mit einem anderen Browser probiert, mit gleichem Ergebnis.
Lynx (ein Text-Browser) hat gar keinen on-disk-cache. Er unterstuetzt aber auch die ganzen aktuellen CSS-Tricks nicht. Ob dies wohl die Ursache ist ? Wenn ich in Firefox CSS abstelle ("no style"), erscheinen auch dort diese Zahlen. Haben wir hier einen CSS-Experten, der das nachvollziehen kann ? Wozu sind diese Elemente ueberhaupt in der HTML-Seite drin ??
Und das o.e. Dezimalsystem ist wieder einmal nur eine US-Marotte. --Herrick 15:39, 21. Apr. 2008 (CEST)
