Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/Neue Koordinatenvorlage/2010

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

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

[[Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/Neue Koordinatenvorlage/2010#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:WikiProjekt_Georeferenzierung/Archiv/Neue_Koordinatenvorlage/2010#Thema_1

O für Ost bitte abschaffen

Fortsetzung des archivierten Abschnitts Wikipedia Diskussion:WikiProjekt Georeferenzierung/Neue Koordinatenvorlage/Archiv/2009#NS, EW:

In allen romanischen Sprachen steht O für West (französisch ouest, italienisch ovest, spanisch und portugiesisch oeste). Mit der IMHO nicht sinnvollen Begründung, dies hier sei die „DEUTSCHE“ Wikipedia und die zusätzliche Option „störe niemanden“, steht es bei uns (und nur bei uns) für Ost. Nur stört sie aber leider doch, denn Koordinaten hören nicht an der Sprachgrenze auf. Als das O in der Koordinatenvorlage mal für kurze Zeit verboten war, habe ich so um die 250 Artikel über französische Gemeinden korrigiert, in denen meistens wirklich Ost, aber auch ein paarmal West gemeint war. Heute gab es mal wieder eine spanische Gemeinde mit demselben Fehler, und wer weiß, wie viele es noch gibt.

Können wir diese völlig unnötige zusätzliche Fehlerquelle bitte mal abschaffen und dabei bleiben? Wer E für Ost nicht „deutsch“ genug findet, der muss es ja nicht schreiben, sondern kann es einfach weglassen. Die Himmelsrichtung darf auch leer sein und bedeutet dann Ost bzw. Nord. --Entlinkt 18:32, 27. Jan. 2010 (CET)

stimme zu, macht in den romanischen Ländern Verwirrung. (ich muss selbst jedesmal nachdenken, wenn ich auf z.B. geoportail O lese). Aber irgendwo hatte ich eine Vorlage im Hinterkopf, die wollte partout O und nicht E: Vorlage:Infobox Flughafen, jetzt nur noch Altlasten. lg --Herzi Pinki 22:53, 27. Jan. 2010 (CET)

Die Warum-Frage

Entschuldigt die dumme Rückfrage, aber aus aktuellem Anlass des Problems mit der Einbindung vieler Koordinatenvorlagen, stellt sich mir eine grundsätzliche Frage:

Warum muss die Vorlage einige kb Template-Programmierung enthalten? Dafür, was auf der Wikipedia-Seite angezeigt wird, ist doch der Großteil des Codes irrelevant. Warum läuft der z.Zt. durch das Template-Programm implementierte Algorithmus nicht stattdessen nach dem Aufruf des Links auf dem Toolserver?

--Pjacobi 17:36, 10. Jan. 2010 (CET)

Der Frage würde ich mich anschließen. Ich weiss das wir zur Zeit der Umsetzung alles in eine Vorlage pressen wollten, um die Auswertung durch eine einzige Vorlage zu vereinfachen, mittlerweile läuft die Auswertung aber sowieso über die Datenbank-Einträge durch die Links auf den Geohack. Wir sollten also vielleicht für lange Listen eine Vorlage haben, die so einfach ist wie die alte Vorlage:Koordinate_Text mit nur einem Parameter. --Kolossos 19:04, 10. Jan. 2010 (CET)

Teil einer Antwort: Koordinatenfehler auf :en (4520) vs. Koordinatenfehler auf :de (577), insbesondere Nr. 1. Von den auf :de auftretenden Koordinatenfehlern sind praktisch alle auf Höhenbereiche zurückzuführen. Die Umstellung der Vorlage hat die Qualität der Daten ziemlich verbessert. Ein zweiter Teil der Antwort: weil die Stringroutinen in der Templateprogrammierung nicht freigeschalten sind. lg --Herzi Pinki 00:12, 21. Jan. 2010 (CET)

Danke Herzi Pinki. -- visi-on 16:24, 22. Jan. 2010 (CET)

→ Kategorie:Parameterfehler (bei einer Toolserverlösung gäbe es in der WP keinen Fehlerhinweis. Die Zahl der Bearbeiter würde sich auf sehr wenige beschränken)

→ Kategorie:Wikipedia:Lagewunsch (man müsste wieder zurück zu den generierten Listen)

-- visi-on 09:48, 23. Jan. 2010 (CET)

Man sollte das Problem mit den Höhenbereichen mal endgültig lösen: die Höhe eines Ortes ist zumindest in entwickelteren Gebieten der Erde amtlich bestimmt, meist nimmt man das Rathaus, seltener den Bahnhof falls vorhanden. Höhenbereichsangaben sind in den meisten Fällen original research und Theoriefindung, da mir keine Norm bekannt ist, ob zum Höhenbereich eines Ortes jeder Punkt der Gemarkung gehört oder nur jeder Punkt des besiedelten Bereiches. Leider wählt aber jeder Bearbeiter die Geokoordinaten nach eigenem Ermessen – viele nehmen den optischen Mittelpunkt auf der Karte oder zumindest den Punkt, den sie für den Mittelpunkt halten. Auch ist da oft die Grenze zwischen Gemarkung und Bebauung nicht erkennbar, sodaß ein so bestimmter "Mittelpunkt" im Prinzip mit Neutraler Standpunkt unvereinbar ist. Daran muß gearbeitet werden: 90 % der Geokoordinaten in der DE:WP sind Schüsse in die Landschaft. Dann gibt es noch ein anderes Problem: die Daten von Google stimmen nicht mit den amtlichen Daten überein: in den USA sind es je nach Gegend bis zu 15 Bogensekunden in Nord-Süd-Richtung und bis zu 5 in Ost-West-Richtung (oder umgekehrt, ich erinnere mich jetzt nimmer genau, wo ich das gelesen habe, irgendwo auf der USGS-Website, nehme ich an), da die amtlichen Daten auf dem Datum von 1929 beruhen. In anderen Staaten wird das nicht anders sein. --Matthiasb 10:03, 23. Jan. 2010 (CET)

Das mit den Höhenangaben ist ein heisses Eisen. Ich habe hier versucht die Diskussion neu anzustossen. Bezüglich NPOV: Eine Begrenzung auf den besiedelten Raum ist nicht möglich, weil das jeder Staat – wenn überhaupt – anders definiert. Aber ich kann Minimum und Maximum von flächigen Objekten angeben. Das ist eindeutig und vergleichbar. Über den zweifelhaften Wert lässt sich trefflich streiten. Zum Mittelpunkt: Wir neigen allgemein zu übertriebener Genauigkeit. Wenn der Schuss in die Landschaft eine Ortschaft auf 500m genau trifft ist das genau genug. -- visi-on 02:25, 24. Jan. 2010 (CET)

Inzwischen gab es auch eine Diskussion in EN über die Ladegeschwindigkeit. Dort glaubt man, das WikiAtlas Javascript als Schuldigen identifiziert zu haben, wenn ich die Diskussion richtig verstehe. --Matthiasb 13:57, 1. Feb. 2010 (CET)

Positionierung des Schriftzugs in der Coordinate-Vorlage

Warum lässt sich in da, im Gegensatz zur Positionskarten-Vorlage, der Ortsname nicht je nach Bedarf links vom Punkt positionieren, wie das z.B. bei Ali Adde und Holhol sinnvoller wäre? Gruß, Amphibium 14:58, 19. Jan. 2010 (CET)

Bei Naturschutzgebiet Borgwallsee und Pütter See ragt die Beschriftung sogar über die Positionskarte hinaus. --тнояsтеn ⇔ 10:07, 21. Jan. 2010 (CET)

54.59053333333313.102166666667

Schwedenhagener Ufer​

Wurde jetzt elegant umgangen, aber eine Dauerlösung ist das auch nicht. Ich füg rechts nochmal ein Beispiel an. --тнояsтеn ⇔ 20:02, 21. Jan. 2010 (CET)

weil das eigentlich nicht gebraucht wird. Aber man könnte den Default für rechts links auf die Mitte nehmen. Ich schau es mir mal an. Ist irgend wo in ganz grässlichem Code versteckt. -- visi-on 16:21, 22. Jan. 2010 (CET)

done -- visi-on 17:07, 17. Feb. 2010 (CET)

Super, danke. --тнояsтеn ⇔ 17:33, 17. Feb. 2010 (CET)

Bitte gern geschehen und gewusst wo war es sogar ganz einfach. -- visi-on 18:14, 17. Feb. 2010 (CET)

Parameter für Quelle

Es scheint mir ein Paramter für eine Quellenangabe zu fehlen (die muss nicht angezeigt werden, aber ohne den Parameter geb ich spezielle Quellen nicht an obwohl ich sie greifbar hätte, bestenfalls mal im ZQ oder einen Kommentar, aber viel Freude kommt dabei nicht auf). --94.223.204.87 00:02, 17. Feb. 2010 (CET).

Das nicht aber mit Verweis auf Google auch nicht. Dann weiss ich nur dass es ein Schuss in die Landschaft war. -- visi-on 14:12, 17. Feb. 2010 (CET)

Das verstehe ich (sprachlich) nicht. Der Punkt der Anfrage ist wohl, dass es Orte gibt, die sich nicht über Satellitenbilder verifizieren lassen, zum Beispiel weil es den Ort nicht mehr gibt, und rein sprachliche Angaben sind oft unpräzise. Wenn du meinst, dass Leute dort dann "eigene Recherche in Google Earth" oder so was angeben, dem könnte man mit einer passenden Benennung des Parameters entgegentreten (auf deutsch wohl sowas wie ÜbernommenVon). In jedem Fall ist es wünschenswert, wenn Quellen vorhanden sind, dass diese auch angegeben werden --94.222.128.143 16:32, 17. Feb. 2010 (CET).

Aber grad für die von dir genannten Fälle ist der Belegapparat wie wir in bereits haben besser geeignet. Nur schon weil es dann meist mehrere und auch Widersprechende Quellen gibt. Das kann man nur im Fliesstext ausarbeiten und ist dort auch der Quellenkritik (und Überprüfung) ausgesetzt. Ich habe mir allerdings schon Gedanken zu Ereignissen gemacht (type=event), die man auch noch mit einem Datum austatten müsste. Dies wäre wiederum auf Begründung (Begin/Start) und Untergang (Ende) einer Sache (Objekt) ausdehnbar. Aber ich zweifle an der OMA-Tauglichkeit. -- visi-on 17:00, 17. Feb. 2010 (CET)

Bevormundung der User

Hallo,

ich finde es unschön und nervig, daß die Vorlage den Anwender häufig bevormundet. Ich möchte nicht immer gezwungen sein, region oder type eingeben zu MÜSSEN. Eine gute Vorlage hat bei fehlenden Parametern sinnvolle Fallback - Defaults. Was mich gerade auch genervt hat, ist, daß ich nicht einfach eine Koordinate in einen Fließtext mit text=DMS einfügen kann, sondern daß ich gezwungen bin, auch noch einen name= parameter mir auszudenken. Warum? Je höher man die Hürden legt, desto weniger wird eine Vorlage benutzt... --92.201.67.229 16:17, 17. Mär. 2010 (CET)

hast du Vorschläge für sinnvolle Defaultwerte für type und region? Deine Frage nach dem Warum von name habe ich versucht, durch den link rechts oben in Öffentlicher Bücherschrank zu beantworten. lg --Herzi Pinki 00:43, 18. Mär. 2010 (CET)

Schade dass du dich durch unsere hohen Qualitätsanforderungen an Koordinaten bevormundet füllst. Ich versuchs daher mal so: Du sollst region und type angeben. Nur bei Textkoordinaten musst du name angeben. Einzig bei Artikelkoordinaten ist dieser per default das Lemma. Das mit der Hürde stimmt zwar, ist aber erträglich da es genügend Mitarbeiter in unserem Projekt gibt die diese Parameterfehler abarbeiten. Würden wir diese nicht in versteckten Wartungskategorien einsortieren wäre das Auffinden äusserst mühsam. -- visi-on 07:50, 18. Mär. 2010 (CET)

Abgleich mit Google Earth

Sehr geehrte Damen und Herren der Wikipedia, wehrte Administratoren, ich habe eine einfache Frage zum Abgleich mit Google Earth. In Google Earth kann man in den Ebenen ja einstellen, dass man Wikipediaeinträge (wenn vorhanden) anzeigen lassen kann. Dazu habe ich auch folgenden Artikel gefunden, siehe hier. Ich wollte jetzt wissen, wie dieser Abgleich funktioniert und warum nicht alle Orte und Städte damit geladen werden! Danke für eine Antwort. Hochachtungsvoll K. Baumeister

Wir wissen nicht, was Google da genau macht, jedenfalls haben wir in der deutschen WP auf die Vorlage:Coordinate un nicht auf Vorlage:Coord umgestellt. Auch wertet Google auch nicht die Koordinaten aus wenn wir mehrere Koords. in einem Artkel, z.B. einer Liste, haben.

Alternativ kannst du ja den Layer unter Wikipedia:WikiProjekt_Georeferenzierung/Wikipedia-World#Google-Earth-Wikipedia-Einblendung probieren. --Kolossos 21:30, 20. Mär. 2010 (CET)

Coordinate template support in GeoLocator tool

Hello everyone, I've added {{Coordinate}} template support into GeoLocator tool under "More wikipedia templates" section in current maintenance release 0.27 (ChangeLog) upon request from Kolossos. Check it out... Regards, --Teslaton 17:44, 20. Mär. 2010 (CET)

region=XO

Wikipedia:WikiProjekt Georeferenzierung/Neue Koordinatenvorlage#Ozeane definiert XO für geostationäre Objekte im Orbit. Aktuelle Verwendung: Olympus Mons (Berg auf dem Mars). Ganz offensichtlich ist Olympus Mons kein geostationäres Objekte auf einer Umlaufbahn. Wenn bestimme Artikel aus anderen Sprachen (fr:Spécial:Pages_liées/Modèle:Géolocalisation/Mars, da:Speciel:Hvad_linker_hertil/Fil:Moonmap from clementine data.png) in die deutschsprachige Wikipedia übernommen werden, entsteht grundsätzlich der gleiche Sachverhalt. Was also tun?

1. Bedeutung von XO aus sämtliche extraterrestrischen Positionen sämlicher Himmelskörper (einschließlich der Erde) ausweiten?
2. Weitere Codes aus dem Bereich für private Nutzung aneignen?
3. ISO-Code in solchen Fällen einfach weglassen und Eintrag in der Wartungskategorie hinnehmen?

--Spischot 09:29, 21. Mär. 2010 (CET)

Dafür wäre mal der Parameter globe gedacht gewesen. region macht nur auf der Erde Sinn. -- visi-on 18:25, 22. Mär. 2010 (CET)

Ich habe die unsinnige Region aus Olympus Mons entfernt - der Artikel scheint darunter nicht gelitten zu haben. --Spischot 08:58, 25. Mär. 2010 (CET)

ad 1. nein, ist unsauber, stimme dir zu, das nicht zu tun. ad 2. macht in diesem Kontext keinen Sinn, da sich die ISO codes auf die Erde beziehen. Stimme dir zu, das nicht zu tun. ad 3. bin mir nicht so sicher.

ich hab's nach region=mars (damit die Wartungskategorie wegfällt) auf globe=mars geändert. Dies erzeugt aber wieder einen Eintrag in der Wartungskategorie. Eigentlich sollte, falls globe, kein Fehler bez. region angezeigt werden. Analoge Probleme sollten alle Artikel von Mondkratern und dergleichen (etwa Kategorie:Außerirdischer Berg) haben, dort stehen die Koord allerdings nur als Text. Zumindest Google Mond und Google Mars sind verfügbar, da könnte ein noch zu schaffender nonGeo-hack die Artikelkoord ebenfalls anzeigen. lg --Herzi Pinki 22:53, 25. Mär. 2010 (CET)

globe war eben nur mal angedacht. Müsste man noch in Kraft setzen. -- visi-on 23:40, 25. Mär. 2010 (CET)

Großartig, globe= ist offenbar ganau das Richtige! Ich habe mir das mal genauer angesehen: Es fehlt nicht mehr viel. Nachdem ich die GeoTemplates für Mond und Mars angelegt habe, funktioniert der Geo-Hack einschließ den Links zu Google Mars, Google Moon und NASA World Wind. Zum Beispiel für Olympus Mons 18° 24′ N, 134° 0′ WMars18.4-134 und in Mons La Hire 27° 48′ N, 25° 30′ WMoon27.8-25.5. (Naja, bis auf den Schönheitsfehler, dass man plötzlich erkennt, dass die Koordinaten noch zu ungenau sind. :-))

Für Google Earth fehlen nur noch die php-Skripte moon.php und mars.php. Diese sind fast identisch zu earth.php, nur dass eine Zeile ergänzt werden muss: Ergänze

<kml xmlns="http://earth.google.com/kml/2.0">

mit

<kml xmlns="http://earth.google.com/kml/2.0" hint="target=moon">

bzw.

<kml xmlns="http://earth.google.com/kml/2.0" hint="target=mars">

– das müsste schon genügen.

Um die Wartungskategorie und auch den Parameter map= in Vorlage:Coordinate vernüftig zu unterstützen, will ich als nächstes noch was analoges zu Vorlage:Info ISO-3166-2 bauen. Ich melde mich dann wieder hier. --Spischot 14:06, 27. Mär. 2010 (CET)

Habs als zusätzlichen globe-Parameter in das earth.php Skript eingebaut, damit muß ich nicht jedesmal ein neues Skript anlegen, wenn Google einen neuen Planeten einspielt.
Bitte denkt daran, dass es Leute wie mich gibt, die aus dem Link auf den Geohack, Geokoordinaten für eine Datenbank generieren. Bei Olympus_Mons wird Vorlage:Positionskarte genutzt, ohne dass diese den Parameter "globe" unterstützt. Aus der Datenbank werden Karten für die Erde generiert und da ist es dann nicht allzu lustig mitten im Ozean einen Mondkrater zu haben. --Kolossos 21:23, 27. Mär. 2010 (CET)

globe wird jetzt durch die Positionskarten durchgeschleift. Bei Olympus Mons jetzt in Ordnung. --Herzi Pinki 03:02, 28. Mär. 2010 (CEST)

18° 24′ N, 134° 0′ WMars18.4-13425000

Olympus Mons​

{{Coordinate|NS=18.4|EW=-134|globe=mars|map=right|article=/|type=mountain|elevation=25000}} erzeugt allerdings die falsche Karte, aber die richtige Koordinate rechts oben. --Herzi Pinki 03:09, 28. Mär. 2010 (CEST)

So, die Vorlage:Info globe ist jetzt fertig. Mit {{Info globe|globe={{{globe}}}|map}} kann man die Positionskarte zu einem Himmelkörper ermitteln. Die dortigen Wartungkategorien werten unbekannte Ausprägungen für globe, fehlende Positionskartenangaben und nicht vorhandene Positionskarten aus. Mit dieser Vorlage kann jetzt der Parameter map= umgesetzt werden.Für globe ungleich earth sollte region nicht mehr überprüft werden. Außerdem könnte man aus globe auch noch die erweiterte Version des Geo-Microformats unterstützen. --Spischot 00:47, 29. Mär. 2010 (CEST)

Das führt jetzt zu einer komischen Überschneidung zwischen Vorlage:Coordinate und Vorlage:CoordinateSky - vor allem in der Wartungskats. Kann man vorher überlegen die Wartungskats anzupassen? In welche Richtung ist mir egal. Merlissimo 22:15, 29. Mär. 2010 (CEST)

Überschneidung soll natürlich nicht sein. Bitte gib das Problem genauer an. Aus meiner Sicht kümmert sich Vorlage:Coordinate um eine Position aus Breiten- und Längengrad auf der Erde oder (nach der Erweiterung) auf einem anderen Himmerskörper wie dem Mond oder dem Mars. Als Himmelskörper kommen dazu insbesondere astronomische Objekte innerhalb unseres Sonnensystems in Frage. Vorlage:CoordinateSky kümmert sich dagegen um einen Ort eines Fixsterns am Firmament. --Spischot 22:26, 29. Mär. 2010 (CEST)

In Geographie steht "Die Geographie (auch Geografie, griechisch γεωγραφία geographia) oder Erdkunde ist die Wissenschaft, die sich mit der räumlichen Struktur und Entwicklung der Erdoberfläche befasst". Derzeit werden Wartungssfälle in Coordinate alle unterhalb von Kategorie:Wikipedia:Lagewunsch einsortiert, was dann IMO nicht passt. Coordinate Sky sortiert Wartungsfälle unterhalb von Kategorie:Astronomisches_Objekt_mit_fehlenden_Koordinaten ein. Ich will nur, dass die Katbenennung mit angepasst wird. Das würde für den Mond Selenografie heißen - da bräuchte man aber ein generelleres Benennungskonzept. Merlissimo 22:52, 29. Mär. 2010 (CEST)

Stimmt, jegliche Vewendung von Geo-Begriffen in Zusammenhang mit Himmelsobjekten (außer der Erde) ist von der Bezeichnung nicht ganz korrekt. Diese etwas schlampige Bezeichnung ist an anderen Stellen schon lange üblich (1, 2, 3, 4), worduch es freilich auch nicht korrekter wird. Um dieses Problem konsequent zu umgehen, müsste man wohl entweder die Geo-Begriffe in allen Vorlagen rund um Vorlage:Positionskarte, Vorlage:Coordinate, usf. durch allgemeinere Begriffe ersetzen, oder anstelle des Parameters globe=... die vorgenannten Vorlagensysteme für sonstige Himmelskörper separat erstellen. Ersteres gefällt mir nicht, weil die überwiegende Nutzung für Positionen auf der Erde unnötig schwer verständlich und hölzern wird. Zweiteres gefällt mir aber auch nicht, weil es die Wartung sehr erschwert und die Änlichkeit der verschiedenen Sprachversionen herabsetzt. Bei der Abwägung würde ich persönlich die sprachliche Unsauberkeit viel eher in Kauf nehmen.

Wenn es dagegen nur um Kategorie:Wikipedia:Lagewunsch geht, lässt sich das bestimmt lösen: Sollte jemand {{Coordinate |NS= |EW= |type= |region= |globe=moon}} für einen Lagewunsch auf dem Mond eintragen, kann man dies in eine separate Wartungkategorie wie z.B. Kategorie:Lage auf Himmelskörper gewünscht oder Kategorie:Position auf Himmelskörper mit fehlenden Koordinaten eintragen. Die anderen Wartungsprobleme werden übrigens in Kategorie:Parameterfehler gesammelt, und dort werden keine Geo-Begriffe verwendet.

Den Zusammenhang mit Kategorie:Astronomisches_Objekt_mit_fehlenden_Koordinaten kann ich aber immer noch nicht erkennen (eine Galaxie befindet sich nicht auf dem Mond, ein Marsvulkan befindet sich nicht am Firmament) Wo sollen die beiden Bereiche sich denn überschneiden?

Würde eine Änderung am Lagewunsch ausreichen, um deine Bedenken zu zerstreuen? --Spischot 00:13, 30. Mär. 2010 (CEST)

Vorlage für dich entsperrt. Ich habe aber selber auch keine gute Idee, wie man das mit Geo am Besten löst. Merlissimo 00:29, 30. Mär. 2010 (CEST)

Die Option map mit globe=... zeigt jetzt die korrekte Positionskarte an. --Spischot 00:53, 30. Mär. 2010 (CEST)

Es gibt den Spruch "Teile und Herrsche". Also eine Aufteilung einer großen Aufgabe in kleine Probleme kann durchaus sinnvoll sein. Insbesondere wenn die Anwendungshäufigkeit so unterschiedlich ist (>200.000 Koords auf der Erde, gegen ein paar Tausend auf Mond/Mars). Aber wenn Ihr die terrestrischen und die extraterrestrischen Anwendungen sauber unter einen Hut bekommt, soll es mir auch recht sein. --Kolossos 22:59, 30. Mär. 2010 (CEST)

title / tooltip

Hallo, könnte man bitte einen Parameter Tooltip hinzufügen? Er wäre bei den Inline-Links sehr hilfreich. Um Missbrauch zu vermeiden, könnte man ihn auch auf diesen Fall beschränken. Bisher erscheint bloß der Name, der meist im Artikel eh schon steht. Auch eine Ergänzung "Koordinaten zu {{{name}}}" für den Normalfall ist hilfreich. Leider kann das bloß ein Admin. Oder habt ihr grundlegende Einsprüche?
meint -- ✓ ^Bergi 18:44, 21. Apr. 2010 (CEST)

also wozu der tooltip anpassbar sein soll seh ich jetzt garnicht... -- visi-on 23:06, 2. Mai 2010 (CEST)

Ich verstehe das Problem auch nicht, gibt es vielleicht ein Beispiel? --Kolossos 07:17, 3. Mai 2010 (CEST)

Das Bahnportal hätte gerne eine Möglichkeit, die Betriebsstellen geozureferenzieren. Dazu soll in der Vorlage:BS in die km-Zahl ein (optionaler) Geohacklink eingebaut werden, sinnvollerweise als {{Coordinate|…}}. Der Tooltip mit dem Namen (was wohl eine Zusammensetzung aus dem Betriebstellentyp und der Bezeichnung sein wird) ist nicht aussagekräftig, wohin der Link eigentlich führt. Vorgestellt hätte ich mir "Koordinaten zu {{{Typ}}} {{{Name}}}: {{{NS}}}/{{{EW}}}" oder so ähnlich. Auch in normalen Artikeln wäre das vielleicht nicht schlecht, gerade wenn nur ein Icon gesetzt wurde dessen Zweck sich nicht jedem sofort erschließt. Ein Versuch, dem text-Parameter ein span-tag (mit title) zu übergeben endet mit der Ausgabe als DMS. Dieser Bug liegt vermutlich an einer fehlerhaften Weiterreichung innerhalb der Vorlage (wg. des = im Parameter), ich hab mich allerdings auch noch nciht genug in den Quellltext vertieft um die genaue Stelle angeben zu können.
meint -- ✓ ^Bergi 17:31, 3. Mai 2010 (CEST)

in normalen Artikeln [...] wenn nur ein Icon gesetzt wurde dessen Zweck sich nicht jedem sofort erschließt ist doch in jedem Artikel der gleiche Sachverhalt. Wenn das tatsächlich ein Problem darstellt, sollte es m.E. zentral in der Vorlage und nicht individuell in jedem Artikel gelöst werden. --Spischot 18:42, 3. Mai 2010 (CEST)

Ja, der Tooltip sollte eben nicht nur den Namen des Objekts (der sowie direkt daneben steht), sondern auch dass es sich um Koordinaten handelt oder noch besser gleich diese selbst beinhalten. Ob das nun intern oder in den BS-, Infox- oder anderen Vorlagen gelöst wird, ist mir egal. Für Spezialfälle sollte man den Tooltip jedoch auch extern beeinflussen können. Möglich wäre auch ein Format-switch (z.b. zwischen „Koordinaten zu {{{Name}}}: {{{NS}}}/{{{EW}}}“, „{{{Name}}} ({{{NS}}}, {{{EW}}})“ etc.), ähnlich wie es derzeit beim Text-Paramter gelöst ist.
meint -- ✓ ^Bergi 12:13, 4. Mai 2010 (CEST)

ICON0 und ICON1

Beide Icons sind superscheußlich, was soll ich sonst sagen. ICON0 ist noch nichtmal symetrisch, ICON1 zu fett und weist deutliche Zacken auf. --WolfgangRieger 15:12, 4. Apr. 2010 (CEST)

sind keine ICONs, nur einfache unicode-Zeichen. Hier stark vergrößert: ICON0=⊙, ICON1=^▼ lg --Herzi Pinki 16:22, 4. Apr. 2010 (CEST)

Das bedeutet, dass es am superscheußlichen Zeichen in der von deinem Browser genutzten Schrift liegt. ÅñŧóñŜûŝî (Ð) 20:35, 13. Mai 2010 (CEST)

Renderfehler bei name-Parameter mit spitzen Klammern

Wenn der Parameter name= HTML enthält, führt das zu Renderfehlern. Das ist mir nie aufgefallen, es scheint erst seit wenigen Tagen so zu sein. Siehe z.B. Plotzen oder hier: 58° 0′ N, 14° 0′ O5814 --TMg 23:11, 14. Mai 2010 (CEST)

Wozu soll das HTML denn bei einem Parameter gut sein ? Niemand benötigt das HTML dabei wirklich, denn die Boxen sollen ja gerade einheitlich formatiert sein. ÅñŧóñŜûŝî (Ð) 23:41, 14. Mai 2010 (CEST)

Das Problem existiert schon immer. Vermutlich ist es keinem aufgefallen. Das Problem lässt sich hier nur mit einem weiteren Parameter lösen, der dann nicht an den Koordinatenlink weitergegeben wird. Der Umherirrende 09:59, 15. Mai 2010 (CEST)

Das Problem scheint aber rel. groß zu sein, etwa Kategorie:Ort im sorbischen Siedlungsgebiet mit 300 Einträgen. Der Zusatzparameter sollte spendiert werden, oder der sorbische Alternativname aus der Box entfernt werden, oder eine alternative Trennung etwa mit / statt Zeilenumbruch gemacht werden. --Herzi Pinki 19:43, 15. Mai 2010 (CEST)

Es liegt an {{#if:{{{name|}}}|<span title="{{{name}}}">}} in Vorlage:CoordinateLINK. Man könnte dort {{#tag:nowiki|{{{name}}}}} einsetzen. Dann würde zwar auch Wikisyntax nicht funktionieren, aber das tut sie sowieso nicht.

PS: Das Problem ist zwar allgemeiner und lange bekannt, in Plotzen tritt es aber wirklich erst seit kurzem auf. Wer möchte, kann in der Vorlage:Infobox Ortsteil einer Gemeinde |name={{#if: {{{Ortsteil|}}} | {{{Ortsteil}}} | {{SUBPAGENAME}} }} gern wieder herausnehmen, dann aber bitte auch unten bei der Positionskarte. Die Vorlagen Coordinate und Positionskarte müssen gleich parametriert sein, andernfalls landet die Koordinate doppelt in der Auswertung. --Entlinkt 20:36, 15. Mai 2010 (CEST)

Ich habe den nowiki-Workaround eingebaut. Dies ist ein Workaround und keine „Einladung“, HTML einzubauen.

In der Vorlage:Positionskarte~ findet sich eine interessante abweichende Implementierung für dasselbe Problem, nämlich {{#ifeq:{{LOCALURL:{{{label}}}}}|/wiki/{{ucfirst:{{{label}}}}}|{{{label}}}}}. Sie hat den Vorteil, dass Eingaben mit HTML ganz unterdrückt werden, aber den Nachteil, dass auch Eingaben mit Leerzeichen und sonstigen Sonderzeichen unterdrückt werden, weil LOCALURL auch URL-Encoding macht.

Nun ist mir eine dritte, viel einfachere Möglichkeit eingefallen: Mit {{FULLPAGENAME:{{{name}}}}} kann man prüfen, ob etwas ein gültiger Seitentitel ist. Da spitze und eckige Klammern in Seitentiteln nicht erlaubt sind, ließen sich HTML und Wikilinks auf diesem Wege ausfiltern. Ich würde gern an beiden Stellen dieselbe Lösung umsetzen. Wäre die FULLPAGENAME-Variante dafür geeignet? --Entlinkt 02:00, 16. Mai 2010 (CEST)

mir fällt grad nichts ein wo dagegen spricht-- visi-on 15:58, 16. Mai 2010 (CEST)

Nichts spricht gegen was? ;-) FULLPAGENAME an beiden Stellen, also sinngemäß {{#if:{{FULLPAGENAME:{{{name|}}}}}|<span title="{{{name}}}">}} (bei HTML und Wikilinks ganz auf Titel verzichten) oder nowiki an beiden Stellen (aus HTML und Wikilinks das relativ „bestmögliche“ machen)?

Sollte es dann bei HTML und Wikilinks einen Parameterfehler geben (muss nicht gleich sein)?

Noch eine Notiz für später: Die Imagemap in Vorlage:Positionskarte~ ist vermeidbar. Von der Bildbeschreibungsseite abweichende Linkziele können auch extern sein, dann aber analog zu internen Links ohne eckige Klammern drumherum, d. h. Vorlage:CoordinateLINK müsste umgeschrieben werden, den Link für Positionskarten ohne die Klammern auszugeben. --Entlinkt 17:43, 16. Mai 2010 (CEST)

Puh jetzt steh ich grad neben dem Schuh ... -- visi-on 21:28, 19. Mai 2010 (CEST)

PS sehr heikel dort was zu ändern. aus irgend einem Grund rendert auch Liste_der_Verkehrs-_und_Sonderlandeplätze_in_Deutschland nicht mehr. -- visi-on 21:32, 19. Mai 2010 (CEST)

Ja, Post-expand include size, super. Pro Zeile ist die Koordinatenvorlage einmal eingebunden, die Vorlage:Flugplatztabelle dreimal. Ich frage mich, ob man bei der noch was rausholen kann. Kann man da nicht die {{!-}} durch |- ersetzen? Wird in Infoboxen doch auch gemacht. Braucht das überhaupt eine Tabelle zu sein oder täten ein paar <hr /> es nicht auch? --Entlinkt 22:51, 19. Mai 2010 (CEST)

Konnte man: Post-expand include size: 1978104/2048000 bytes. Was für ein Akt für ein paar horizontale Linien. --Entlinkt 01:11, 20. Mai 2010 (CEST)

Jetzt Post-expand include size: 1884174/2048000 bytes. Seltsam. Ich nahm an, die Entfernung so vieler Vorlagen (bei allen Flughäfen mit nur einer Landebahn) würde mehr bringen. Kann das jemand erklären? --TMg 10:21, 20. Mai 2010 (CEST)

Das dürfte an der in diesem Fall (nur der erste Parameter war gesetzt) geringen Komplexität der Vorlage:Flugplatztabelle liegen. Sie gibt dann ja nur align=center|{{{1}}} aus. Da die 6 anderen Parameter leer sind und nur in einer Bedingung, die nicht erfüllt ist, geprüft werden, tragen sie zur Post-expand include size nichts bei. Unerreichbarer Code wird mit dem neuen Parser nicht mehr expandiert.

Hier mal ein paar Testergebnisse:

• Das Einfügen des nowiki-Tags in der Vorlage:CoordinateLINK hat auf der Seite Liste der Verkehrs- und Sonderlandeplätze in Deutschland 78644 Bytes gekostet. Nicht empfehlenswert.
  das war meine Vermutung, wollte es aber nicht einfach behaupten.-- visi-on 22:57, 23. Mai 2010 (CEST)
• Der Test auf FULLPAGENAME in der Vorlage:CoordinateLINK kostet demgegenüber 13718 Bytes, bzw. der Unterschied spart 64926 Bytes.
• 2388 Bytes ließen sich durch Entfernen des Unterstrichs in dem Konstrukt {{#if:{{{label|}}}|_&title={{{label}}}}} in der Vorlage:CoordinateLINK einsparen. Ist der Unterstrich wirklich notwendig? Genügt der Ampersand nicht als Trennzeichen?
  doch müsste genügen, ist einfach nur so weil es früher auch so war. evtl muss der eine oder andere dann halt seine Linkauswertung anpassen. -- visi-on 22:57, 23. Mai 2010 (CEST)
• 2223 Bytes ließen sich durch Auslagern von align=center| aus der Vorlage:Flugplatztabelle in den Artikel einsparen. Das wäre vielleicht sowieso sinnvoll, dann wäre die Vorlage nämlich flexibler und auch außerhalb von Tabellen einsetzbar.
• Mit dem jetzt aktiven Test auf FULLPAGENAME in der Vorlage:CoordinateLINK haben Links, die den Test nicht bestehen, gar kein title-Attribut. Wenn und nur wenn es gewünscht wäre, dass sie stattdessen den Seitennamen als title-Attribut erhalten, könnte man den Test nach Vorlage:CoordinateMAIN verlagern und weitere 6859 Bytes sparen, indem man dort {{#if:{{{name|}}}|{{{name|}}}|{{FULLPAGENAME}}}} durch {{#if:{{FULLPAGENAME:{{{name|}}}}}|{{{name}}}|{{FULLPAGENAME}}}} ersetzt. Würde man dort aber zum Beispiel {{#if:{{{name|}}}|{{#if:{{FULLPAGENAME:{{{name}}}}}|{{{name}}}}}|{{FULLPAGENAME}}}} einsetzen, um das jetzige Verhalten zu imitieren, dann wäre die Post-expand include size genau gleich wie jetzt, aber die anderen Größen näher am Limit.

Gruß --Entlinkt 23:04, 20. Mai 2010 (CEST)

Coordinaten-Funktion

Hat nicht jemand mal Lust und Zeit endlich eine Extension zu schreiben und das einfach in eine Funktion zu packen anstatt immer mehr und teurere Vorlagen zu erstellen? Einige Ladezeiten von Listen sind echt übel. Merlissimo 23:25, 20. Mai 2010 (CEST)

Ich weiß nicht, ob ich richtig verstehe, ob mit immer mehr Vorlagen die Verschachtelung gemeint ist, aber die kann durchaus ihren Sinn haben, solange sie das Verhalten des Parsers richtig ausnutzt. Beobachtung: Jedes einzelne Zeichen in der Vorlage:CoordinateLINK kostet genau 6 Bytes Post-expand include size je Einbindung (getestet mit dem besagten Unterstrich und den Anführungszeichen des title-Attributs), die 13718 Bytes des FULLPAGENAME-Hacks kosten bei 398 Einbindungen auf der Seite so viel wie 5,74 Zeichen (demgegenüber nowiki: 32,93 Zeichen, warum auch immer). Stünde alles in einer Vorlage, wäre es statt 6 Bytes pro Zeichen nur noch eines, dafür wären aber die anderen Limits früher erreicht. Die Konsequenz ist natürlich richtig: In Wikitext kann man keine Vorlage bauen, die jede Menge Konsistenzprüfungen vornehmen und jede Menge HTML-Elemente und -Attribute und einen ellenlangen Weblink erzeugen und mehrere hundert mal auf einer Seite funktionieren und dabei auch noch schnell sein soll. Gruß --Entlinkt 00:19, 21. Mai 2010 (CEST)

Das hast du richtig erfasst die Verschachtelung habe ich wirklich so gewählt um einigermassen ausgewogen alle Limits gleichzeitig zu erreichen. -- visi-on 22:57, 23. Mai 2010 (CEST)

Mit einer Funktion hätte man genau diese Probleme nicht und man kann auch beliebige Stringfunktionen benutzen.

Das eigentliche Schreiben dieser Extension ist auch nicht das Problem - das ist schnell gemacht. Entscheidend ist mal eine ordentliche Konzeptbeschreibung. Also wie sieht die Eingabe aus, was für eine Ausgabe in Wikitext soll erzeugt werden mit allen Eventualitäten (muss natürlich global passend sein).

Wenn jemand das Konzept erstellt, könnte ich das programmieren. Nur habe ich mich selbst nie mit der Koordinatenvorlage befasst. Merlissimo 18:13, 21. Mai 2010 (CEST)

Bin ich grundsätzlich bereit dazu. Die Vorlagen haben ja einige Zwecke nun gut erfüllt und wir wissen besser worauf es ankommt. Die Datenqualität konnte verbessert werden aber es gibt auch noch ein paar redundanzprobleme die noch nicht gelöst sind und durch eine Funktion bzw durch einen Tag <georef>nicht automatisch bewältigt sind. Ich bin also auch noch nicht ganz mit der Erfassung der Georeferenzen an sich zufrieden. Ich stampf das aber nicht innert drei Tagen aus dem Boden. Könnte man sich evtl. mal zu einem Workshop treffen? -- visi-on 22:57, 23. Mai 2010 (CEST)

Wenn sich da ein paar Leute zusammenfinden wäre das gut. Von meiner Seite aus nicht, aber ich muss ja dann nicht mitmachen. Das ganze muss sollte ja auch mit den drei Geohack-Autoren abgesprochen werden.

Aber wir können doch einfach mal sammeln was es braucht. Ich stelle mir das gerade so vor:

{{#coordinate:earth|Breite|Länge}} erzeugt [/geohack.....{breite} ...{länge} Koordinaten Formatiert]

• Die URL wird einfach mit Variablen über eine Systemnachricht definiert.
• Bei falschen/fehlenden Parametern wird ein Error erzeugt, den mit mit iferror abfangen kann.
• Der ganze Positionierungskram (Fließtext, Artikelkoordinate) bleibt in der Vorlage.

Damit wäre doch der rechenaufwändige Teil der Vorlage erledigt. Die Frage ist, welche Parameter man sonst noch als extra Parameter rein packt oder was man einfach durch einen url-Append-Parameter macht. Wenn man nur letzteres macht, wäre die Erweiterung sehr universell einsetzbar (z.B. direkt mit einem anderen Kartendiensten).

Desweiteren müsste man klären welche Eingabe-Formate/Systeme bei den Koordinaten sinnvoll sind. Da muss man schauen, was es international alles so gibt, wie man umrechnet und wie man der Funktion sagt, welche Eingabe man gerade angegeben hat. Gleiches gilt für's Ausgabe-Format - dort vielleicht über die Benutzereinstellugnen?

Bei earth hatte ich mir gedacht, damit könnte man auch CoordinateSky usw. abdecken in dem man dort auch Sky oder Mars angeben kann. Bei Sky wäre es natürlich Rektaszension/Deklination statt Länge/Breite.

Soweit meine spontanen Ideen. Ansonsten müssten die Fachleute mal was sagen, die die Probleme kennen. Merlissimo 01:57, 24. Mai 2010 (CEST)

Wer findet den Fehler?

http://toolserver.org/%7Edispenser/view/File_viewer#log:coord-dewiki.log meldet bei Artà und Oppenheim nicht nachvollziehbare Koordinatenfehler. Ich habe mir schon mehrmals die Augen wundgesehen, aber den Fehler nicht gefunden. Kann da wer helfen? Danke --Herzi Pinki 20:31, 21. Mai 2010 (CEST)

Bei Oppenheim steckt der Fehler hier, gefunden habe ich das über Special:Linksearch. Bei Artà komme ich mit der Spezialseite auch nicht weiter. Jemand mit Zugriff auf die Datenbank könnte das sicher leicht finden. Gruß --Entlinkt 23:09, 21. Mai 2010 (CEST)

Danke, da hätte ich ja ganz Oppenheim auf den Kopf stellen können und hätte nichts gefunden. Da erzeugt wohl das Skript von Dispenser ungünstige Links. --Herzi Pinki 00:02, 22. Mai 2010 (CEST)

jetzt wo ich wusste, dass ich ganz woanders suchen muss, habe ich den zweiten auch gefunden. --Herzi Pinki 10:54, 22. Mai 2010 (CEST)

Projekt Georeferenzierung Der Setzer dieses Bausteins ist der Ansicht, diese Diskussion sei erledigt. Sie wird daher automatisch in das Archiv verschoben. Bist Du der Ansicht, diese Diskussion sei noch nicht erledigt, so scheue Dich nicht, diesen Baustein durch Deinen Diskussionsbeitrag zu ersetzen! --Herzi Pinki 10:54, 22. Mai 2010 (CEST)

Welcher Types?

Hallo Allerseits

Wenn man den neusten Koordinaten-Dump von Kolossos anschaut, findet man unter dem Parameter "type" nicht nur einiges an Tippfehlern. Es gibt auch einige "types", wie building (583x), church (472x), lake (507x) oder watermark (503x), die eigentlich landmark resp. waterbody sein sollten. (Im Vergleich dazu gibt es gerade mal 22 satellite.) Ist das sinnvoll, diese Unterteilung so zu belassen? --Tobias dahinden 13:31, 31. Mai 2010 (CEST)

nein. building, church -> landmark; lake, watermark -> waterbody; lg --Herzi Pinki 00:51, 1. Jun. 2010 (CEST)

Fehler bei region=RU-PRI und map=right

Um überhaupt eine Karte zu bekommen, habe ich in Pawlowski-Bucht erst mal „region=RU“ gesetzt, das muss sich aber ändern. -- Olaf Studt 21:45, 13. Jun. 2010 (CEST)

Hab nur ein Teil herausgefunden: Vorlage:Info ISO-3166-2:RU-PRI verweist auf Kontinent Asien. Irgendwie (vermutlich die Level-Logik) führt dies zur Einbindung der Vorlage:Positionskarte, Asien, die es allerdings nicht gibt. Dadurch dann der Fehler. --Spischot 22:19, 13. Jun. 2010 (CEST)

habe mal einen Workaround reingebaut. --Herzi Pinki 22:22, 13. Jun. 2010 (CEST)

Der Regionscode RU führt immer noch zu Problemen. Standardmäßig sucht die Vorlage entweder die Europa-Karte oder die nicht vorhandene Asien-Karte, wenn auch der ISO-3166-2-Code angegeben wird. Die Russland-Karte erscheint nur ohne ISO-3166-2-Code. Über maplevel=adm1st lässt sich mit ISO-3166-2-Code zumindest die entsprechende Regionskarte anzeigen, maplevel=country hingegen bringt nichts. NNW 14:53, 4. Aug. 2010 (CEST)

Das Problem ist innerhalb der Vorlage:Coordinate. Hier wird geprüft, ob der continent des aktuellen Codes und des top-Codes identisch ist. Wenn nicht, wird sich für die Kontinenenkarte entschieden. Bei RU-PRI sind die eingetragenen Kontinente nicht identisch (Eurasien vs. Asien), daher wird sich für Positionskarte Asien entschieden, die Karte ist aber nicht vorhanden, daher gibt es Darstellungsprobleme. Kann jemand den Grund erläutern, warum es dort die Abfrage gibt? Der Umherirrende 20:37, 18. Sep. 2010 (CEST)

...und bspw. bei RU-KGD (Kaliningrad) sind die Kontinente auch nicht identisch (Eurasien vs. Europa), also wird die Positionskarte Europa genommen, die es gibt. Was zwar OK wäre, wenn man den Kontinent haben will, aber nicht, wenn mann das Land (also "national", hier: Russland) haben will. In letzterem Fall kommt nämlich auch Europa. Kann das daran liegen, dass eine Positionskarte Eurasien auch nicht existiert? (Sehe zwar keinen logischen Zusammenhang, aber vielleicht tut's die Vorlagenlogik?) -- SibFreak 22:29, 18. Sep. 2010 (CEST)

puh, ich denk mich da wieder rein ok. -- visi-on 04:57, 21. Sep. 2010 (CEST)

also wenn top eurasien und current = europa oder Asien dann toplevelkarte nehmen noch einfügen. Sorry habe keine Zeit das durchzutesten aber ich denk NordnordWest versteht was ich meine. Ändern kann er es allemal. Sorry -- visi-on 15:57, 23. Sep. 2010 (CEST)

Dein Vertrauen in alle Ehren, ich stehe gerade auf dem Schlauch. *ratlos, NNW 20:48, 23. Sep. 2010 (CEST)

Die verschiedenen Möglichkeiten kann man sich auf Benutzer:NordNordWest/test ansehen. NNW 10:53, 21. Sep. 2010 (CEST)

article=DM

(von Vorlage Diskussion:Coordinate hierher verschoben --Herzi Pinki)

Warum werden bei Kikuzuki trotz article=DM die Sekunden angezeigt, bei text=DM jedoch korrekterweise nicht? --Mps 23:59, 16. Jun. 2010 (CEST)

Der Grund, wenn ich mich recht entsinne, waren die Erdbeben, die ein punktförmiges Epizentrum haben, aber einen oft hunderte km großen Zerstörungsradius (dim). Und so wird bei type=landmark die Angabe von article=DM ignoriert, egal ob Gebäude, Erdbeben oder eben bei Koordinatenungenauigkeit. Ist nicht ganz logisch, ist aber so. Mit type /= landmark wird article=DM honoriert, aber das ist natürlich hier keine Lösung, da Schiffe schon als landmark zu geokodieren sind und das außerdem die Infobox für alle gleich macht. --Herzi Pinki 01:25, 17. Jun. 2010 (CEST)

Wäre es dann nicht logischer gewesen bei Erdbeben einfach immer DMS anzugeben? --Mps 01:30, 17. Jun. 2010 (CEST)

Originaldisk zu landmark und Erdbeben --Herzi Pinki 02:03, 17. Jun. 2010 (CEST)

Erweiterungsvorschlag Type=Place

Derzeit ist Type=City für Städte und Stadtteile sowie Orte und Ortsteile gedacht. Dh. "Berlin" und "Kreuzberg" landen in der selben Schublade - nicht sehr sinnvoll. Anwendungsbeispiel: Konkret würden wir gerne auf der großen Österreichkarte der Österreich Werbung alle Städte über 10.000 Einwohner anzeigen, verlinkt mit WP. Statdteile dieser Größe aber natürlich nicht. Das ist derzeit nicht möglich. Vorschlag: Erweiterung um Type=Cityquarter (alternativ Quarter, Citydistrict, District). Was denkt ihr? --Helge 13:34, 17. Jun. 2010 (CEST)

Ohne den Vorschlag be- oder gar abwerten zu wollen, denke ich, es wäre effizienter, dafür die Wikipedia-Kategorien (hier Kategorie:Gemeinde in Österreich) auszuwerten. Wie das genau zu implementieren wäre, weiß ich nicht, aber machbar wäre es sicher, und es müsste nicht das Kategoriesystem im Parameter type dupliziert werden. Es ist nämlich für jeden Wert des Parameters type eine Anwendung denkbar, die eine feinere Auflösung erfordert. Gruß --Entlinkt 03:17, 13. Jul. 2010 (CEST)

Das Konzept der Gemeinden wie in D-A-CH ist in anderen Staaten oft unbekannt. Oder umgekehrt: eine Stadt oder Gemeinde ist in Südamerika häufig ein Gebilde, daß man in Deutschland als Landkreis bezeichnen würde.Im übrigen war Kreuzberg bis zur Verabschiedung des Groß-Berlin-Gesetzes Anfang der 1920er Jahre eine eigenständige Stadt, Berlin im heutigen Sinne gab es rechtlich noch nicht. Eine Aufteilung des Parameters könnte somit nur Chaos bringen, weil nach Eingemeindungen man auch noch den Typ der Koordinate ändern müßte. Geographisch gilt übrigens ein Ort ist ein Ort, das Konzept Ortsteil interessiert in der physischen Geographie nicht. Viel wichtiger würde ich einen Typ building halten, weil derzeit unter landmark sowohl natürliche als auch von Menschenhand geschaffene Gebilde zusammengefaßt sind. Und ein besonderer Baum oder sonstwelche Geoobjekte, die kein Gewässer oder Berg sind, ist schon thematisch etwas anderes als ein Bauwerk. --Matthiasb (CallMeCenter) 09:12, 13. Jul. 2010 (CEST)

Gut, wenn Ortsteile in der Geographie nicht interessieren, dann dürften Ortsteile auch nicht mit "Type=City" markiert sein. Nur lässt sich das nicht entfernen, da "Type" eine Pflichtangabe ist und es keinen Typ gibt, der passt. Absolut suboptimal. --Helge 15:55, 4. Aug. 2010 (CEST)

Vorlage:Coordinate#type: „für Städte und Stadtteile, Orte und Orts-Gemeinden“ --Mps 16:01, 4. Aug. 2010 (CEST)

Genau das ist ja das Problem, liebe/r Mps! Die Kategorisierung unterscheidet NICHT zwischen Orten und Ortsteilen unterscheidet, womit (nicht nur) die oben beschriebene Nutzungsform unmöglich wird. Stadtteile sind nun mal keine Städte und umgekehrt. --Helge 15:57, 23. Sep. 2010 (CEST)

Neuer Vorschlag: Erweiterung um "Type=Place" für alle Orte, die keine "City" sind. Darunter fielen dann Stadtteile genauso wie irgendwelche anderen Punkte, die sind nicht durch andere Kategorien kategorisieren lassen. (Abschnittsüberschrift entsprechend aktualisiert.) --Helge 16:00, 23. Sep. 2010 (CEST)

region-Parameter scheint nicht optional zu sein

Bei Kolchis wird die Fehlermeldung „region-Parameter fehlt“ ausgegeben, obwohl region laut Dokumentation optional sein sollte (und sich bei Kolchis auch nicht zügig benennen lässt, vgl. Diskussion ebendort). Unter „Fehlerbehandlung“ in der Dokumentation ist der Parameter dann aber wieder verpflichtend. Kurzum: Er sollte es nicht sein. --Tim Landscheidt 13:13, 9. Jul. 2010 (CEST)

Man kann immer eine Region angeben, im Zweifelsfall eben mehr als eine. --Mps 13:17, 9. Jul. 2010 (CEST)

Ja, und das ist, was die Fehlermeldung fördert: Es wird eine Region angegeben, um das hässliche Rot wegzubekommen, statt die richtige(n) Region(en). --Tim Landscheidt 14:22, 9. Jul. 2010 (CEST)

Um es noch etwas zu vertiefen: Wenn ich beispielsweise die Eifel koordinieren möchte, reicht es aus, als region BE/DE/LU anzugeben, ohne auf BE-x/BE-y/DE-NW/DE-RP/LU-z verfeinern zu müssen. Da sollte auch in anderen Fällen der Mut zu Lücken seinen Platz finden. --Tim Landscheidt 15:52, 9. Jul. 2010 (CEST)

Nicht oder nur annähernd lokalisierbare Objekte

Ich gehe gelegentlich Kategorie:Antike griechische Stadt und ähnliches mittels Catscan nach Artikeln durch, die noch nicht lokalisiert sind. Dabei gibt es hauptsächlich vier Fälle:

1. Die Koordinaten lassen sich leicht und einwandfrei ermitteln (→ Koordinaten einfügen),
2. das Objekt existierte und ist lokalisierbar, aber nicht sofort (→ Lagewunsch einfügen),
3. das Objekt existierte, ist aber nicht präzise, sondern nur ungefähr lokalisierbar („an dem Nordrand des X-Gebirges“, „an der Ostküste der Y-Insel“, etc.) und
4. das Objekt existierte, ist aber überhaupt nicht lokalisierbar (wobei das natürlich fast ein Sonderfall von 3. wäre mit „radius=20000000“).

(Alle Aussagen jeweils auf gute Quellenbasis bezogen; also nicht Atlantis & Co.)

Problem bei 3. und 4. ist natürlich, dass in der „nächsten Catscan-Runde“ die Artikel wieder auftauchen. Daher wäre es schön, wenn man für diese „ca.“- und „gar nicht“-Koordinaten eine Notation finden könnte. Die Vorlage könnte dann einen „radius“-Parameter ähnlich wie „dim“ interpretieren, so dass der gesamte Bereich, in dem sich das Objekt befunden haben könnte, angezeigt wird. --Tim Landscheidt 02:29, 13. Jul. 2010 (CEST)

Diese Disk könnte dazu von Interesse sein – ohne jedoch für dein Anliegen eine Lösung zu bieten. -- Meleager 21:27, 13. Jul. 2010 (CEST)

Es bestärkt zumindest darin, dass man mit den eigenen Gedanken nicht völlig daneben liegt :-). --Tim Landscheidt 00:43, 14. Jul. 2010 (CEST)

Ich denke mal quer. Ist es wirklich notwendig, nicht lokalisierbare Objekte so ungenau zu lokalisieren, dass sie erst recht nicht lokalisierbar sind (radius=20000000)? So Angaben wie am Nordrand des X-Gebirges sind doch perfekt (im Text). Wenn das Gebirge verlinkt und geolokalisiert ist, dann ist es über einen Klick mehr auch aufzufinden. Wem ist gedient, wenn ich irgendwohin auf google maps geschickt werden, dort das Objekt aber auch nicht finde? Wo ist das Zentrum des Gebiets (am Nordrand des Gebirges kann ganz im Westen oder aber ganz im Osten sein)? Eigentlich geht es dir doch darum, Artikel, die potentiell geolokalisiert werden könnten, aber für die nach Überprüfung aus Quellenmangel keine Koordinaten bestimmbar sind, von weiteren CatScan Treffern auszunehmen; im Gegensatz zu sinnvollen Koordinaten, die einen Mehrwert für den Leser darstellen, also um Informationen, die bloß einen Mehrwert für den Autor im Zuge einer so gearteten Durchsicht bieten. Das Autorenproblem könnte mittels einer zusätzlichen Wartungskategorie mit der Semantik es gibt keine sinnvollen Koordinaten gelöst werden, die in alle Artikel der Fälle 3 und 4 eingebaut werden könnte, und die verwendet werden könnte, um sie entweder beim nächsten CatScan Lauf auszufiltern (Tims Requirement) oder auch um gezielt danach zu suchen. Ein Anfang wäre {{Nicht lokalisierbares Objekt|region=|radius=}}, mittels CatScan2 lässt sich auch sinnvoll danach filtern. lg --Herzi Pinki

Nun, der Wiki-Aspekt ist ja nur eine Seite der Medaille, die andere beispielsweise eine Karte/Geo-Suchmaschine, auf der man vielleicht auch die an dem Nordrand des Gebirges gelegenen Objekte nicht unter den Tisch fallen lassen möchte. Oder, wenn ich einmal hier in dem Flachland bleibe, die Hammaburg, wo man sich ziemlich sicher ist (und die Koordinaten in dem Artikel sogar ganz sicher :-)), wo sie sich befunden hat, aber man eben immer noch nicht den letzten Beweis gefunden hat. (Das radius=20000000 war nur geistiges Reckturnen; von mir aus können wir „nur ungefähr lokalisierbar“ und „nicht lokalisierbar“ auch gerne in der Notation vollkommen trennen.) --Tim Landscheidt 12:49, 14. Jul. 2010 (CEST)

Hinweis Erweiterungsvorschlag text=ICON2 (graphische Weltkugel)

siehe WP:GEO lg --Herzi Pinki 22:56, 7. Aug. 2010 (CEST)

Fehler bei Region=PR

Hier sollte das Arecibo-Observatorium auf Puerto Rico markiert sein:

18.344166666667-66.752777777778

WikiProjekt Georeferenzierung/Archiv/Neue Koordinatenvorlage/2010​

Wenn man die Region auf DomRep verfälscht, kommt man auch nicht ganz ran: 18.344166666667-66.752777777778

--Hagman 23:08, 7. Okt. 2010 (CEST)

Du must noch |maplevel=adm1st einfügen, um Puerto Rico anzuwählen. NNW 23:27, 7. Okt. 2010 (CEST)

Coordinate wird nicht angezeigt

Hallo, ich habe diesen Artikel angelegt und wunder mich warum die Coordinate nicht angezeigt wird, wenn die wenn die Vorlage unterhalb der Einzelnachweise eingebunden wird. [1] Hat jemand eine Erklaerung? mfg --Lofor 00:15, 24. Okt. 2010 (CEST)