Wikipedia Diskussion:WikiProjekt Georeferenzierung

Archiv

Zur Archivübersicht

Wie wird ein Archiv angelegt?

Bevor du eine Frage stellst, solltest du bitte erst im passenden Archiv nachschauen, evtl. gibt es dort bereits eine Antwort.
Ältere Diskussionen bis Mai 2007 sind dort thematisch sortiert einsehbar. Seit Mai 2007 werden Beiträge automatisch archiviert.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Höhenbereiche

wakeup da steht der Entscheid immernoch aus. -- visi-on 13:30, 16. Jan. 2010 (CET)

Ja... die unendliche Geschichte. Bin auch sehr für eine schnelle Lösung, wie gehen wir es am besten an bzw. wo kann es abschließend diskutiert und bschlossen werden? WP:GEO, WP:FzW, Vorlage Diskussion:Infobox Gemeinde in Deutschland (die hat wohl die meisten Höhenbereichsangaben), ...? --тнояsтеn ⇔ 15:41, 16. Jan. 2010 (CET)

Also mir wärs am liebsten wenn wir unter den sachlich vertrauten einen Lösungsvorschlag ausarbeiten, der auch vom Laien intuitiv verstanden wird. Denn würde ich gern via MB absegnen. damit hätten wir dann auch den Feedback ob das was wir ausgedacht haben tatsächlich dem Ziel entspricht. Eine gross angelegte Umfrage wird kaum neues bringen.

Ich kann ja gleich mal Fragen, ob die grobe Unterteilung in Punkt- und Flächenobjekte verständlich ist? Wenn ja, können wir an meiner angedachten Lösung ansetzen. -- visi-on 19:24, 16. Jan. 2010 (CET)

Aufschlüsselung der verbliebenen Parameterfehler nach Infoboxen (Stand: 9. Dezember 2010, 02:23):

Vorlage	Anzahl (13.3.2010)	(9.5.2010)	(9.12.2010)	(2.1.2011)	(21.3.2011)
Infobox Gemeinde in Deutschland	532	515	360	0	0
Infobox Ort in Polen	–	–	66	66	0
Infobox Ort in den Vereinigten Staaten	8	7	5	0	0
Infobox Ort in Bulgarien	3	3	3	0	0
Infobox Gemeinde in Österreich	2	2	1	0	0
Infobox Ortsteil einer Gemeinde in Deutschland	2	0	0	0	0
Infobox Gemeinde in Südtirol	108	108	0	0	0
Infobox Fluss	3	0	0	0	1
Sonstige	2	0	0	0	1
Summe	676	652	435	66	2

Speziell bei der Vorlage:Infobox Gemeinde in Südtirol würde es sich IMHO lohnen, neue Parameter für den Höhenbereich einzuführen. Die Box ist insgesamt nur 116-mal eingebunden, da sprechen 108 Einbindungen mit Höhenbereich eine deutliche Sprache. --Entlinkt 21:48, 12. Mär. 2010 (CET)

Dort sind es wenn ich recht verstanden habe die Maximalwerte der Gemeindefläche. Das wäre ja in meinem Vorschlag enthalten. Persönlich finde ich diese Zahlen von geringem nutzen, aber wenns gewünscht wird. Man muss nicht alles teilen können. Insbesondere bei den Gemeinden Deutschlands ist die Zahl sehr hoch. denn es ist laut IB beschreibung gar nicht erwünscht. Da sind 500 auf 17000 dann doch viele. -- visi-on 00:38, 13. Mär. 2010 (CET)

Bei Südtirol sind anscheinend drei Werte eingetragen (überwiegend Minimum und Maximum im Gemeindegebiet + „Zentrum“, teilweise aber auch komplizierter, siehe Vorlagenauswertung), bei allen anderen nur zwei. Selbst ohne irgendeine Änderung an der Koordinatenvorlage würde es sich lohnen, zumindest den „mittleren“ Wert freizulegen. Dafür braucht es in der Box mindestens einen neuen Parameter für den Höhenbereich, evtl. auch zwei, falls Minimum und Maximum getrennt sein sollen. --Entlinkt 01:23, 13. Mär. 2010 (CET)

PS: Es gibt nur noch ca. 11500 Gemeinden in Deutschland. Überblick über Gemeinden in Deutschland, bei denen die Höhe nicht nur aus Ziffern besteht (Vorlagenauswertung). --Entlinkt 01:55, 13. Mär. 2010 (CET)

Hmm, sollte man bei dem ganzen nicht zuerst die Quellenlage berücksichtigen? Die Doku zur Gemeinde in Deutschland verweist beispielsweise auf das Bundesamtes für Kartographie und Geodäsie, da kommt (maximal) ein Parameter bei raus. (Ich hoffe mal, dass die Angabe der Höhe an der Stelle der Koordinaten entspricht.) Hab’ mal gehört in Frankreich soll das anders sein. Die Praxis im Moment sieht ja eher so aus, dass wild auf irgendwelchen Karten rumgestochert wird, was zu müßigen Diskussionen über den tatsächlichen Mittelpunkt (Koordinaten) und die anzugebenen Höhe führt. Mit Wikipedia:Belege hat das alles nichts zu tun. --Alex 20:55, 12. Apr. 2010 (CEST)

Nachfrage: wird das hier noch diskutiert? Eine Lösung wäre schön und vielleicht nicht erst in 5 Jahren. Oder wo könnte man noch eine Diskussion anregen? --188.174.1.72 12:25, 17. Mai 2010 (CEST)

Wie lange noch??? --93.104.172.76 15:29, 28. Jun. 2010 (CEST)

Auch ich als "Starter" dieser Diskussion würde gerne wissen, wie denn nun hier weiter verfahren wird? Wer macht ein oben angesprochenes MB und wo? --Lambdacore 22:38, 31. Aug. 2010 (CEST)

Da die Diskussion irgendwie nicht aus den Pötten kommt, mache ich jetzt mal einen definitiven Vorschlag:

• Höhenbereichsangaben sind nur dort zulässig, wo vergleichbare Quellen verfügbar sind. Ansonsten wird die Höhe an der Stelle der geografischen Koordinaten angegeben.

Vergleichbar meint dabei eine Quelle, die verschiedene Punkte einheitlich erfasst. Ich denke dabei an so etwas wie das Bundesamt für Kartographie und Geodäsie in Deutschland. Im Gegensatz zu irgendwelchen Angaben, die auf (privaten oder öffentlichen) Internetseiten zum Ort stehen oder aus Karten herausgelesen werden. Konsens? --Alex 20:39, 23. Sep. 2010 (CEST)

Das Schweigen interpretiere ich mal als Zustimmung. Habe gerade mit Erschrecken festgestellt, dass es gar keine Hilfeseite gibt, an der man meinen Vorschlag von oben platzieren könnte. Unter Vorlage:Coordinate/Doku habe ich mal ein wenig was ergänzt. Ansonsten: zentrale Stelle an der man die ganzen komischen Infoboxen überzeugen kann? --Alex 16:52, 16. Okt. 2010 (CEST)

Hallo Alex, dein Vorschlag ist ok, nur hilft er vermutlich nicht, das Problem zu lösen. Gerade für die Problemkinder DE, IT-BZ und PL sind die Daten vermutlich aus gemeinsamen amtlichen Quellen. Du musst also nur 3 Infoboxen überzeugen. Lösung a la Vorlage:Infobox Gemeinde in Frankreich sind ja überall möglich. Umsetzen kann das ein Bot. Probleme gibt es dann, wenn die Höhe an der Koordinatenstelle nicht bekannt ist (nicht aus amtlichen Werken). lg --Herzi Pinki 17:57, 16. Okt. 2010 (CEST)

Ja, mir wäre es auch ganz lieb, wenn das mal an zentraler Stelle irgendwo stehen würde. Die Vorlagen Infobox Gemeinde in Deutschland und Infobox Ort in Polen haben es in der Parameterbeschreibung ja schon drin stehen, dass Von-Bis-Angaben nicht gewollt sind. Das wird leider nur nicht umgesetzt. (Oder andersrum: zumindest mir ist keine vergleichbare Quelle für Deutschland bekannt, die Minimal- und Maximalhöhe angibt. Zum Rest kann ich leider wenig sagen.) Aus meiner Sicht dürfte im Moment die Vorlage:Infobox Ortsteil einer Gemeinde (in Deutschland) die größten Probleme bereiten, da dort der Parameter Höhe sowohl für die mittlere als auch die minimale Höhe stehen kann. Ich verspüre aber wenig Lust für jede Infobox diesen Strauß auszufechten (womöglich noch mit unterschiedlichen Ergebnissen), daher der Ruf nach einer zentralen Stelle. --Alex 18:42, 16. Okt. 2010 (CEST)

Ich hatte in der Kategorie:Parameterfehler einen Baustein, der das Abarbeiten blockiert entfernt. Er wurde wieder eingesetzt, da noch nicht entschieden sei, wie mit Höhenbereichen verfahren werden soll. Mittlerweile wird auf genau diese Diskussion verlinkt. Was muss denn noch diskutiert werden und wie und wo kann man so etwas denn mal abschließend entscheiden? --Alex 00:47, 30. Nov. 2010 (CET)

Habe für Vorlage:Infobox Gemeinde in Südtirol eine Lösung gefunden und bin dabei den Großteil der Artikel umzustellen, bei einigen müssen noch die Eckdaten ermittelt werden--Schnellbehalter ^Fragen 01:08, 1. Dez. 2010 (CET)

Ich interpretiere das Schweigen mal als „es muss nichts mehr diskutiert werden“. Ich werde den Baustein entfernen. --Alex 02:24, 9. Dez. 2010 (CET)

Ich bin auch für eine baldige Lösung (habe schon mehrfach nachgehakt hier)... Allerdings hilft es uns ja nicht weiter, wenn der Baustein entfernt wird und immer noch ein paar Hundert Artikel den Parameterfehler aufweisen. Eine Lösung über die Änderung der Infoboxen wäre hier zielführend. --91.22.217.95 08:39, 9. Dez. 2010 (CET)

Die Infoboxen sind nicht das Problem. Sowohl in der Dokumentation der deutschen wie der polnischen ist klar ausgedrückt, dass Von-Bis-Angaben nicht erwünscht sind. Bei der deutschen Infobox wurde das zuletzt hier auch noch mal auf der Diskussionsseite angesprochen. Danach habe ich mir erlaubt das für die Infobox Gemeinde in Deutschland per Hand zu ändern. Auf dieser Liste habe ich mittlerweile die Fälle 1−210 abgearbeitet. Ich befürchte aber, dass der Baustein verhindert, dass sich noch mehr Benutzer an der Abarbeitung beteiligen, insbesondere wenn der Parameterfehler eben nicht durch die Infobox Gemeinde in Deutschland ausgelöst wird. --Alex 17:26, 9. Dez. 2010 (CET)

So, abgesehen von den polnischen Ortschaften ist der Fehler abgearbeitet. (Wenn mir da einer eine vernünftige Quelle nennt, mache ich das auch noch.) Probleme bereitet nach wie vor die Vorlage:Infobox Ortsteil einer Gemeinde in Deutschland. Dort hat der Parameter Höhe die Bedeutung mittlere Höhe, wenn Höhe-bis leer ist und minimale Höhe, wenn Höhe-bis eine Angabe enthält. An die Vorlage:Coordinate wird immer der Parameter Höhe weitergegeben, sodass der Fehler in der Wartungskategorie nicht auftaucht. Im Sinne des Erfinders dürfte dieses Vorgehen trotzdem nicht sein. Wenn ich den Template-Tiger richtig bedient habe, war dies im August bei 2713 Artikeln der Fall. --Alex 22:40, 2. Jan. 2011 (CET)

Für Polen hab ich mal hier angefragt: Portal Diskussion:Polen#Geografische Daten Polen --тнояsтеn ⇔ 15:22, 16. Jan. 2011 (CET)

Mal eine kurze subjektive Zusammenfassung der Nachfragen auf Portal Diskussion:Polen#Geografische Daten Polen, Portal Diskussion:Polen#Geoportal und Vorlage Diskussion:Infobox Ort in Polen#Höhenangabe: es wurde versucht das Fass neu aufzumachen (ich will aber in meiner Infobox Höhenbereiche drin haben), die Diskussion hier wurde als nicht relevant abgetan und letztlich wurde das Problem „gelöst“ indem der Hinweis man wünsche keine Höhenbereichsangaben aus der Dokumentation gelöscht wurde. Die Vorlage:Infobox Ortsteil einer Gemeinde in Deutschland schlummert übrigens auch noch nach wie vor vor sich hin. --Alex 13:23, 22. Feb. 2011 (CET)

Das Problem mit der Polen-Infobox ist „gelöst“. --Alex 11:11, 21. Mär. 2011 (CET)

Na ja, Kategorie:Parameterfehler ist zwar leer, aber die Infobox Ortsteil einer Gemeinde in Deutschland gibt nach wie vor den minimalen Höhenwert weiter (wenn Höhe-bis ausgefüllt ist) und die Polen-Infobox „umgeht“ das Problem in dem sie gar keinen Parameter weitergibt, obwohl Informationen vorhanden sind. Auf die Gefahr hin, dass ich nerve. --Alex 09:29, 19. Jul. 2011 (CEST)

Zusatzwunsch Koordinaten für Abschnitte von Artikeln

Hier mal ein Alternativvorschlag: Könnte man nicht Abschnitte von Artikeln mit Koordinaten verlinken? Ich stelle mir das so ähnlich wie bei den normalen Koordinaten rechts oben vor, nur das die Koordinaten dann eben rechts neben der Abschnittsüberschrift stehen. Dadurch könnte man einzelne Objekte mit Koordinaten ausstatten, die zu unwichtig für einen eigenen Artikel sind. Außerdem würde ein (Welt-)Kugelhagel vermieden. Ein Problem könnten dann aber evtl. unzählige überflüssige Zwischenüberschriften sein. -- мorıтz 11:33, 31. Aug. 2010 (CEST)

<quetsch>sorry Moritz, hast du dir den Artikel Bezirk Baden (Niederösterreich)#Verwaltungsgliederung angeschaut - wie sollte das gehn? --K@rl (Verbessern ist besser als löschen) 18:24, 31. Aug. 2010 (CEST)

Okay, da geht's wirklich nicht :) -- мorıтz 18:28, 31. Aug. 2010 (CEST)

Bitte ein und dieselbe Diskussion nur an einer Stelle führen! --Spischot 13:50, 31. Aug. 2010 (CEST)

Sorry, aber die beiden Diskussionen haben nichts miteinander zu tun. --K@rl (Verbessern ist besser als löschen) 21:07, 4. Nov. 2010 (CET)

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! --Hedwig in Washington (Post?)•B 06:30, 21. Jul. 2011 (CEST)

Höhenbezug bei Flüssen in (Süd-) Albanien

Hallo, mir ist aufgefallen, das noch diverse Artikel zu albanischen Flüssen ohne Infobox existieren. In dem Zusammenhang fällt, wenn man es genau betrachtet, das Problem der Höhendarstellung ins Gewicht. Es gibt die Vorlage Höhe - da wird bspsw. die Meereshöhen-Basis in codierter Form - Basis Adriatisches Meer - nur für Länder von Ex-Jugoslavien und Italien angeboten. Albanien liegt überwiegend an der Adria - doch auch am Ionischen Meer. Zu den südalbanischen Flüssen - Bsp. Bistrica (Albanien) benötige ich noch eine Idee wohin die Nivelementgemäß gehören: Adria oder präziser wäre Ionisches Meer/Mittelmeer. --Metilsteiner 11:11, 26. Sep. 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! --Hedwig in Washington (Post?)•B 06:31, 21. Jul. 2011 (CEST)

Position der Koordinaten im Artikelkopf

Bei weitergeleiteten Seiten verschiebt sich die Position der Artikelkoordinaten vertikal. Beispiel wäre etwa Shepheard Hotel vs. Shepheard Hotel (Kairo). Da es mit Opera, Firefox und IE so ist, gehe ich mal nicht von einem Darstellungsfehler, sondern von einem "Programmierfehler" aus. --тнояsтеn ⇔ 23:56, 18. Okt. 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! --Hedwig in Washington (Post?)•B 06:32, 21. Jul. 2011 (CEST)

Geodaten im Artikel vs. OSM

Mir ist bei einigen Artikeln aufgefallen, dass die Position einiger Gebäude etc. in der Open Street Map leicht verschoben dargestellt werden. Wenn die einzelnen Fähnchen auf der richtigen Adresse sitzen würden, wäre das natürlich etwas schicker. Macht es Sinn/ist es erwünscht, die Geokoordinaten im Artikel so anzupassen, dass sie mit der OSM übereinstimmen? Oder ist das Vertrauen in die OSM zu gering bzw. die ganze Sache eher unerheblich? Gruß, Phoinix 15:52, 19. Okt. 2010 (CEST)

Zunächst mal würde ich sagen, die Koordinaten sollten mit der Wirklichkeit übereinstimmen (bzw mit dem Referenzsystem WGS84). Inwieweit das dann mit OSM oder GoogleMaps passt, das sollte nicht unser Problem sein. Das Google-Luftbild (weiß ich aus eigener Erfahrung) kann schonmal über 10m abweichen. Und bei OSM würde ich auch nicht unbedingt meine Hand ins Feuer legen.

Ich vermute mal, 99% der Artikel-Georeferenzen wurden einfach von GoogleMaps abgegriffen. Die Fehler fallen ja auch erst dann auf, wenn man das mit anderen Quellen vergleicht. Im Meter-Bereich sind aber Google, OSM, Bing, Yahoo & Co als Quelle ungeeignet. Am genausten (für Deutschland) ist sicherlich noch die amtliche Grundkarte 1:5000 (max 5m Abweichung). Oder man misst halt selbst mit einem GPS nach. --alexrk 16:39, 19. Okt. 2010 (CEST)

Danke für die ausführliche Antwort. DAU-Frage: Reicht für die eigene Messung ein internes GPS im Smart Phone aus oder ist ein Spezialgerät vorzuziehen? (Ich habe leider keine Ahnung, ob es da qualitative Unterrschiede gibt.) Gruß, Phoinix 17:15, 19. Okt. 2010 (CEST)

Uhm, das kann ich pauschal leider so nicht beantworten, da das im Einzelnen vom Receiver, Antenne, Extra-Features abhängig ist. Bei den etwas besseren GPS-Empfängern kann man zB auch noch ein spezielles Verbesserungs-Signal empfangen (Stichwort WAAS, EGNOS, DGPS). Damit erreicht man zB mit dem iQue von Garmin laut Herstellerangabe "<3 meters, 95% typical". Vlt findest Du solche ähnlichen Angaben im Handbuch zu Deinem Smartphone. --alexrk 18:06, 19. Okt. 2010 (CEST)

Ich stimme AlexRK zu, für die Daten von OSM wird niemand generell seine Hand ins Feuer legen. Ich vermute jedoch, dass die OSM-Daten oftmals genauer sind als unsere Koordinaten. OSM bittet zum Glück auch die Möglichkeit sich in den Editoren auch die Trackpoints der anderen Bearbeiter anzuschauen, falls diese auf den zentralen Server hochgeladen wurden. Wenn an einer Stelle viele Leute waren und das passend aussieht, sollte man sich die eigene Messung sparen können. Hast du konkrete Beispiele, wo es nicht paßt? Und ja ich fände es auch "chick" wenn unsere Fähnchen an der richtigen Stelle (+/- 5m) wären, da das die Nutzung verbessert, also nur zu. --Kolossos 19:48, 19. Okt. 2010 (CEST)

Wenn jemand einen Radweg in OSM selbst per GPS-Track erstellt hat, ist der vermutlich relativ genau. Ja. Wo von Yahoo "abgemalt" wurde, ist man halt wieder von der Genauigkeit der Yahoo-Luftbilder abhängig. Seen und Wälder sind zT nur ganz grob eingezeichnet. Hab auch schon diverse Punktdaten gefunden, die anscheinend nur mit einer Genauigkeit von 1 Bogenminute irgendwoher importiert wurden. Und manche Dinge sind dann auch einfach komplett falsch (genauso wie bei Wikipedia :)). Also das ist echt schwer da eine generelle Genaugkeit zu beziffern. Wie gesagt: ich finde, wir sollten uns da nicht unbedingt OSM oder Google als Referenz nehmen. Manches passt dann vlt in OSM aber dafür in Google nicht oder umgekehrt oder es ist beides falsch. --alexrk 20:09, 19. Okt. 2010 (CEST)

Beispiel: Radio_hsf Der Verein liegt natürlich nicht neben dem Gebäude, sondern befindet sich darin. Die Abweichung ist relativ gering, erscheint nur unpassend, weil der Rest so detailliert (inkl. Hausnummern) erscheint. Bei Google Maps wurde es richtig auf das Haus gepappt, stimmt dann allerdings nicht mit dem Kartenmaterial überein, weil die Satellitenbilder hier leicht verschoben sind. --Phoinix 22:16, 19. Okt. 2010 (CEST)

Im konkreten Fall ist die Abweichung (ca.5m) wirklich so gering, das ich es persönlich so lassen würde. Bei 10m Abweichung bzw. einer höheren Wikipedia-POIs-Dichte könnte man nochmal drüber sprechen.

Achso, auf meiner Karte(OSM-Gadget), liegen die Punkte leider momentan eh immer etwas daneben, weil diese in meiner Ausgangsbasis von Dispenser leider etwas stark gerundet werden. --Kolossos 22:52, 19. Okt. 2010 (CEST)

Ich möchte die Gelegenheit nutzen, um auf einige amtliche Kartendienste im Web hinzuweisen, die vermutlich recht zuverlässige geographische Koordinaten liefern:

• http://map1.naturschutz.rlp.de/mapserver%5Flanis/ (Rheinland-Pfalz)
• http://map.geo.admin.ch/ (Schweiz)
• http://www.amap.at (Österreich)
• http://www.geoportail.fr/ (Frankreich)
• http://www.ign.es/iberpix/visoriberpix/visorign.html (Spanien)
• http://getamap.ordnancesurvey.co.uk/getamap/frames.htm (Großbritannien, ohne Nordirland)
• http://www.osi.ie/ (Irland)
• http://www.topoquest.com/ (Nordamerika, man beachte unten die Liste ab einem bestimmten Maßstab)

(Hinweise auf andere Länder willkommen!)

Bei einigen wird eine Koordinatenumrechnung erforderlich, aber auch Konverter gibt es gratis im Web. Im Vergleich dazu weichen die Werte bei Google nach meiner Erfahrung um max. etwa 10 m ab (einzelne Ausreißer mit bis zu 30 m Abweichung habe ich auch schon erlebt). Wenn man auf halbe Bogensekunden, höchstens Zehntel Bogensekunden rundet, dürfte man im Bereich der möglichen Genauigkeit – also etwa 10 m – liegen. Noch genauere Angaben halte ich für Augenwischerei. Übrigens: wenn irgend möglich, sollte man die Georeferenz an zwei voneinander unabhängigen Quellen prüfen! Insofern scheint mir Optimierung für OSM suboptimal zu sein. --Telford 20:47, 19. Okt. 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! --Hedwig in Washington (Post?)•B 07:39, 21. Jul. 2011 (CEST)

Geokoordinaten kategorisieren

Meine Idee ist es den Koordinaten zusätzlich noch eine thematische Marke beizufügen. Bei der Anzeige der OSM müsste dann noch zusätzlich eine Einstellmöglichkeit hinzukommen. Es gäbe dann die Darstellung aller Einträge und je nach Artikel noch verschiedene thematische Marken. Ich könnte mir zeitabhängige Marken, raumabhängige und themenabhängige Marken vorstellen. Also, z.B. Marken zum 19. Jhr., zu einem Land oder Stadt oder zum Römischen Reich. Der Knackpunkt wäre, dass es möglich ist, beim Einlesen der Koordinaten auch die Kategorie des zugehörigen Artikels mit einzulesen. Wenn man dann feststellt, dass eine Kat in einem bestimmten Katbaum enthalten ist, wird die Koordinaten mit einer bestimmten Markierung automatisch versehen. Wäre so etwas machbar und sinnvoll? --Goldzahn 21:37, 30. Okt. 2010 (CEST)

Jeder mit den entsprechenden Programmierkenntnissen ist gerne eingeladen dich daran auf dem Toolserver zu probieren. Eine kleine thematische Karte gibt es schon über unsere "Type"-Angaben: Beispiel mit Wasserflächen. Raumabhängig sind die Karten generell und bei dem zeitlichen glaube ich nicht, dass das sinnvoll funktioniert. An den Kategoriebäumen wird man sich wohl gennerell die Zähne ausbeissen, gerade wenn man es dann noch in verschiedenen Sprachen probiert. Lasst uns lieber die Daten mit denen von OSM verknüpfen, dann haben wir dann schonmal deutlich detailierte Typangaben, statt unseren "landmarks" gäbe es dann "Museen, Rathäuser, Denkmäler...". --Kolossos 13:05, 31. Okt. 2010 (CET)

Da gibt aber Wikipedia schon noch einiges mehr an Information her als nur die Unterscheidung zwischen Museum und Rathaus. Ich könnte mir zB in der Karte sowas vorstellen wie: zeige mir alle Artikel derselben Kategorie(n) an. zB bin ich im Artikel Theben (Ägypten) und möchte nun alle weiteren antiken ägyptischen Städte sehen. Das dürfte doch eigentlich noch im Rahmen des Machbaren liegen und wäre mE ein ziemlich hilfreiches Feature, oder?

Was mich zum nächsten Problem führt: sowas wie antike Städte oder Romanschauplätze gibt es vlt hier in der Wikipedia aber nicht unbedingt in OSM. Und, so wie ich OSM verstehe, sollen solch "nicht-existierenden" oder historischen Objekte dort auch nicht aufgenommen werden. --alexrk 15:31, 31. Okt. 2010 (CET)

*quetsch* Das mit den ägyptischen Städten geht schon. Ich habe den Kartenlink rechts oben in die Kategorie eingebaut ([1]). --тнояsтеn ⇔ 17:31, 31. Okt. 2010 (CET)

Wie man hier sieht, kann man mit dem Tool auch mehrere Kategorien einbinden. Ich habe das für die Kat Afghanistan mal direkt in Google Maps gemacht (Das was in der maps-suche steht per Hand geändert) und mir gleich noch alle Unterkats mit anzeigen lassen. --Goldzahn 01:03, 2. Nov. 2010 (CET)

Die Überlegung mit der Kategorie zielte darauf ab das zu automatisieren. Bei einer individualisierten Typangabe müssten 100.000 Artikel per Hand geändert werden. Vielleicht wäre es aber auch möglich die Typangabe automatisiert zu ändern? Ein Museumsartikel bekommt dann den Typ Museum, etc. Bei schwierigen Typen könnte man das dagegen rein manuell machen. Vorteil wäre das das über Monate hinweg abgearbeitet werden könnte. Übrigens, das mit den Gewässern sind recht gut aus. Was nur fehlt wenn da viele verschiedene icons verwendet werden, ist eine Legende. --Goldzahn 17:10, 31. Okt. 2010 (CET)

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! --Hedwig in Washington (Post?)•B 06:33, 21. Jul. 2011 (CEST)

A proposal to simplify and improve geo markup in Wikipedia

Einfach mal zu Information: http://www.princexml.com/howcome/2009/wikipedia/geo/ --Kolossos 13:05, 31. Okt. 2010 (CET)

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! --Hedwig in Washington (Post?)•B 06:35, 21. Jul. 2011 (CEST)

Vorlage:Coordinate + Vorlage:Höhe

gerade in berg-artikelen haben wir zahlreich den fall, das nebenrangige landmarken neben der höhe auch mit coordinaten versehen werden (können/wollen/sollen) - da tritten dann der immer gleiche fall ein:

Nebengipfel ({{Höhe |1111|at}}&nbsp;{{Coordinate |text=ICON0|…|elevation=1111|region=AT}})

könnte man das nicht kombinieren, etwa, wenn man text=HÖHE macht, käme

{{Coordinate|text=HÖHE|…|elevation=1111|region=AT}}

Nebengipfel (1111 m.ü.A.001111)

das verlinken des m.ü.A. entfällt bei kleinangaben sowieso
verzeihung für schon wieder eine spinnerte idee (nehmt es als ausdrückliches kompliment, dass sonst sowieso alles höchst zufriedenstellend ist, wenn man auf solche gedanken kommen kann) --W!B: 14:09, 15. Nov. 2010 (CET)

Ich denke, das ist zu viel des Guten... im Sinne von "die Vorlage wird zu überladen mit Funktionen". Warum nicht einfach {{Coordinate|text=1111 m.ü.A.|…|elevation=1111|region=AT-6}}? Man muss zwar die Höhe zweimal eingeben, aber ich persönlich fände dies nicht schlimm. Übrigens: auch wenns nur ein Beispiel ist, das "at" muss groß ;-) --тнояsтеn ⇔ 17:07, 15. Nov. 2010 (CET)

gerade in berg-artikelen haben wir zahlreich den fall: Wo z.B.? So oft kommt das dann doch wieder nicht vor. Manchmal wird die Tabellenform verwendet, auch um nach Name / Höhe sortierbar zu machen, da nützt die gewünschte Kombivorlage wenig, manchmal werden ganze Sätze formuliert. Dazu kommt, dass die Region in Coordinate und in Höhe unterschiedliche Wertebereiche aufweist (AT-7/DE-BY vs AT). lg --Herzi Pinki

ja danke, ich weiß, eierlegewollmilchsäue sind immer kritisch - ein anderer aspekt waren übrigens die streckenboxen für bahn und straße, siehe Portal Diskussion:Bahn #Vorlage:BS + koordinaten - ich hab eh immer schlechtes gewissen, sowas anzusprechen, mir kamen in letzter zeit einfach genug anwendungsfälle unter (werd mal welche exemplarisch zusammensuchen) - übrigens hatte ich es fast umgekehrt gesehen, für eine koordinate muss man eh immer die höhe heraussuchen, wieviel einfacher wärs, einen schalter umzulegen, als nochmal eine eigene vorlage einzubauen - aber stimt, Deine variante tuts auch, text={{Höhe|1111}} hat sie ja leider nicht gefressen ;)

das umwandeln AT-7/DE-BY → at geht nicht? sind die string-extension noch immer nicht aktiv? --W!B: 16:57, 16. Nov. 2010 (CET)

{{Info ISO-3166-2|code={{ParmPart |1|AT-7/DE-BY}}|top}} = AT --Herzi Pinki 01:17, 17. Nov. 2010 (CET)

wow - {{lc:{{Info ISO-3166-2|code={{ParmPart |1|AT-7/DE-BY}}|top}}}} = at - oder muss höhebezug nicht klein sein? ;) - stimmt aber, viel aufwand mit wenig nutzen.. --W!B: 03:51, 18. Nov. 2010 (CET)

nein Höhenbezug sollte auch groß sein: AT. Allerdings verzeiht Vorlage:Höhe mittels uc: --Herzi Pinki 00:44, 20. Nov. 2010 (CET)

und das unlösbare Problem mit DE-NN/DE-NHN/DE-HN habe ich ganz vergessen. lg --Herzi Pinki 23:38, 24. Nov. 2010 (CET)

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! --Hedwig in Washington (Post?)•B 06:37, 21. Jul. 2011 (CEST)

«♁» für erde/kirche

zwar war die idee mit dem «♁» für erde nett, aber in finde es immer verwirrlich, weil es in den allermeisten fällen eher als kartensymbol für kirchengebäude zu verstehen ist, was etwa bei bergen befremdlich wirkt, eine aussageneutraleres zeichen irgendwie mit geobezug (gibt es eine windrose, sonst etwa ☼ 362C "sonne", kurz vor ♁, oder ※ 203B Referenz) vielleicht OMA-tauglicher - explizite angaben für astonomische angelgenheiten (etwa meteoritenkrater) kann man ja mit text=ERDE implementieren --W!B: 14:19, 15. Nov. 2010 (CET)

Schau auch mal hier und evtl. in Verbindung hier. --тнояsтеn ⇔ 17:13, 15. Nov. 2010 (CET)

ah, danke, ich seh, die diskussionen um text=bild sind weitergegangen - schade, dass es kein unicode-zeichen gibt, das den sachverhalt "geokoordinate" wirklich plausibel darstellt - ich persönlich hätte ja ㊏ "Erde" 328F favorisiert (die chinesen sind uns in der ikonologie um jahrtausende voraus- aber lesen muss man das halt können..) ;) - na, vielleicht wird für die grafik noch eine lösung gefunden, im design vielleicht analog zu {{Audio}} ^ⓘ (gedanklich seh ich da keinen großen unterschied, es handelt sich um eine art wechsel des mediums für jeweils den sachverhalt: "anhören"/"anschauen (auf karte)"): der klicklink würde also hinter dem symbol liegen, nicht drauf --W!B: 17:12, 16. Nov. 2010 (CET)

Wie wäre es statt dem bisherigen ⊙ (U+2299 CIRCLED DOT OPERATOR) als Koordinatenlink ⌖ (U+2316 POSITION INDICATOR)? Leider sind beide Symbole im normalen Fließtext bei normaler Schriftgröße sehr klein. --Fomafix 13:28, 19. Nov. 2010 (CET)

Der Internet Explorer 6 kann mit den Standardschriftarten weder ♁ noch ⌖ darstellen. Hier müsste mit Vorlage:Unicode bzw. class="unicode" von MediaWiki:Common.css nachgeholfen werden, damit die Symbole so aussehen: Vorlage:Unicode Vorlage:Unicode --Fomafix 15:06, 19. Nov. 2010 (CET)

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! --Hedwig in Washington (Post?)•B 07:39, 21. Jul. 2011 (CEST)

Datenextraktion, Georef-Datenbank

Hallo, eine Frage zum Prozedere der Datenextraktion: wodurch wird der Wert in der LANG-Spalte in der Tabelle der Georeferenzen bestimmt. Ich dachte, das wäre die Sprachversion mit dem längsten Artikel - scheint aber doch oftmals nicht zu stimmen. --alexrk 17:49, 18. Dez. 2010 (CET)

Upps, späte Antwort. Es ist aber so, dass es nach Länge geht, allerdings nach Anzahl der Bytes und da in Russisch ein Zeichen häufig ein Zeichen 3 Bytes braucht, sind diese Artikel im Vorteil. Gibt es ein konkretes Beispiel? Dann würde ich nochmal nachschauen. --Kolossos 12:45, 1. Mär. 2011 (CET)

Hallo Kolossos, danke für die Erklärung - ist recht einleuchtend. Ich war da bei meiner Georef-Statistik drüber gestolpert. Hab aber dann festgestellt, dass die LANG-Spalte ohnehin bei der Auswertung unsinnig ist. Ausschlaggebend ist ja nur, ob der Datensatz einen Eintrag in title_de hat - dann weiß ich, dass es dazu einen deutschsprachigen Artikel gibt. ..PS: dass die Ru-Artikel mehr Bytes verbrauchen, war mir nicht klar, deshalb hab ich gestutzt, dass offensichtlich in Ru kürzere Artikel trotzdem die Nase vorn haben können --alexrk 16:40, 1. Mär. 2011 (CET)

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! --Hedwig in Washington (Post?)•B 07:40, 21. Jul. 2011 (CEST)

Vorlage:Linked Coordinates findet Coordinaten nicht, die gemeinsam mit der Poskarte erzeugt werden (Datenextraktion?)

Hallo, dieser Link: http://toolserver.org/~para/cgi-bin/kmlexport?project=de&linksfrom=1&article=Myra wird über {{Linked Coordinates}}, in diesem Fall von Myra aus erzeugt. Myra (Lykien) scheint aber in der Treffermenge auf der Karte nur dann auf, wenn nicht die Kombination aus Artikelkoord. und Poskarte verwendet wird. Workaround ist die Wiedereinführung der redundanten Coordinaten/Poskarte.

{{Coordinate| article=/| und {{Coordinate| article=/| map=right| sollten wohl bezüglich GeoHack keinen Unterschied machen.

Ich vermute, dass es sich dabei nur um eine Kleinigkeit im GeoHack handelt, eigentlich sollten beide Versionen funktionieren. Wer kann helfen? danke lg --Herzi Pinki 23:56, 19. Dez. 2010 (CET)

{{Coordinate| article=/| und {{Coordinate| article=/| map=right|name=Myra/Demre| machen aber doch einen Unterschied. Ich könnte mir vorstellen (ohne es bisher ausprobiert zu haben), dass der Slash im name-Parameter "stört". --Josch28 ^Disk 01:52, 3. Jan. 2011 (CET)

guter Hinweis, danke, das Ding ist nur urrrrg zu testen. Bis die Änderungen zum Toolserver durchschlagen und wie das genaue Cachingverhalten ist, ... unklar. &usecache=0 und &usecache=1 liefern abwechselnd unterschiedliche Ergebnisse, jedenfalls invalidiert &usecache=0 den Cache nicht. Geht wohl nur mit code review. Aber der Tipp mit / ist vermutlich eine heiße Spur (üblicherweise werden Koordinaten ohne name-Parameter erzeugt) lg --Herzi Pinki 10:58, 3. Jan. 2011 (CET)

Kannst du bitte bei dem Code-Review auch noch folgenden Fehler suchen? In dieser Verwendung funktioniert {{All Coordinates}} nicht, weil sich der kmlexport an dem "ä" in der Abschnittsbenennung stört. Weder urlencode noch anchorencode haben geholfen, während http://toolserver.org/~para/cgi-bin/kmlexport?project=de&article=Zeche_von_der_Heydt&section=Lage_der_Schächte&redir=google mit Umlaut in der URL (!) bei mir funktioniert hat. Ich habe letztlich den Abschnitt umbenannt ... --Josch28 ^Disk 15:27, 3. Jan. 2011 (CET)

Koordinaten in Weiterleitungen

hierher aus Benutzer Diskussion:W!B:, ich denke, hier interessant --W!B: 05:25, 28. Dez. 2010 (CET)

Hallo W!B, ich habe gerade einen Vesuch gemacht und zwar bei redirects Koordinaten dazugegeben. Z.Bsp. Tirolerhofsiedlung. Bei All Coordinates bekommt also auch die redirects mit dazu. das heißt wenn wir die Orte mit redirects in die Gemeindekategorien reingeben, dann bekommen wir sie auch mit All Coordinates heraus. --K@rl (Verbessern ist besser als löschen) 18:39, 8. Dez. 2010 (CET)

schade dass die Koordinaten in redirects nicht angezeigt werden, ich würde es auch für sinnvoll erachten, redirects zu georeferenzieren. Abgesehen von All Coordinates. lg --Herzi Pinki 01:22, 9. Dez. 2010 (CET)

bei mir findet ihr offene ohren, ich versuche schon seit jahren, infomationen in redirects einzulagen (kategorien, präzise interwikis, auch personendaten, ..), weil ich WLs für eines unserer hochwertigsten und leistungsfähigsten werkzeuge halte

das problem ist, dass sie bei jeder verschiebung mit dem WL-schreib-skript [→Wikipedia:Helferlein/Extra-Editbuttons] verloren sind, also höchst instabil - das führt dazu, dass ich inzwischen sicherlich 1000ende WLs, die ich angelegt hab, beobachten muss - ohne es noch wo anders backup zu lagern (etwa der diskussionsseite) wird es nicht gehen --W!B: 10:44, 9. Dez. 2010 (CET)

End of hierher --W!B: 05:25, 28. Dez. 2010 (CET)

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! --Hedwig in Washington (Post?)•B 07:49, 21. Jul. 2011 (CEST)

Quellen der Geodaten in Vorlage einbinden

Wie kann man die Quellen der referenzierten Geokoordinaten in der Vorlage einbinden, bzw. einen Einzelnachweis dafür setzen, so dass die Quelle der angezeigten Koordinaten bei den Einzelnachweisen ausgewiesen wird? So etwas Ähnliches gib es in der englischen Wikipedia und in der deutschen wäre es auch sehr wünschenswert. --Bullenwächter ↑  10:40, 6. Jan. 2011 (CET)

Nein, das geht nicht. Nach meiner persönlichen Auffassung sollte das auch nicht in die Vorlage hinein, um diese ohnehin schon komplexe Vorlage nocht noch weiter aufzublähen, sondern sollte wie andere Einzelnachweise im Artikel verbleiben. --Spischot 10:57, 6. Jan. 2011 (CET)

Hallo Spischot! Ich versuche es momentan mit einem <!-- Quellenangabe --> Zusatz nach dem Vorlagenbaustein zu lösen, finde es aber nicht optimal. Bei einem <ref> Quellenangabe </ref> Einzelnachweis ist der Zusammenhang zu den Geokoordinaten in der Artikelansicht leider nicht auf anhieb erkennbar. --Bullenwächter ↑  08:21, 11. Jan. 2011 (CET)

Das gilt aber nicht für Textkoordinaten. -- visi-on 23:08, 1. Feb. 2011 (CET)

Gemeinde-Geodaten

Gibt es eigentlich irgendwo Listen von Geodaten zu Gemeindelisten, z. B. die Geodaten zu allen Gemeinden in Baden-Württemberg, in Österreich, im Kanton Appenzell-Innerrhoden usw.? Etwas in der Art von Metadaten:Einwohnerzahl. --Holder 17:54, 12. Jan. 2011 (CET)

Meinst du innerhalb oder ausserhalb der WP? Bei geonames gibt es über Oldenburg (Oldenburg) dies:

2857458 Oldenburg 53.16667 8.2 P PPL DE 06 159218 10 Europe/Berlin 2010-08-10

Download der Daten: [2], da dann die Datei DE.zip Uwe Dedering 18:29, 12. Jan. 2011 (CET)

In Österreich sind Geodaten der Hauptorte aller Gemeinden bei der Statistik Austria, siehe Vorlage:Legende AT Bezirk --K@rl (Verbessern ist besser als löschen) 18:56, 12. Jan. 2011 (CET)

Vielen Dank, genaus so etwas habe ich gesucht. --Holder 07:58, 13. Jan. 2011 (CET)

Wobei die dort angegebenen Koordinaten häufig irgendwo im Wald/auf dem Feld liegen und nur grob mit dem jeweiligen Ort in Verbindung stehen. Für Wikipedia halte ich die Genauigkeit für nicht ausreichend. --Martin Zeise ✉ 13:21, 16. Jan. 2011 (CET)

Die Daten von Geonames sind größtenteils (wenn nicht gar gänzlich) nur auf 1 Dezimalgrad genau, daher liegen einige Dörfer schonmal etwas daneben. In Openstreetmap und in den Wikipedia-Georeferenzen ist die Genauigkeit um einiges besser. Wenn Du mit Shapefiles was anfangen kannst, schau mal hier oder hier (für aufbereitete OSM-Daten). Eine CSV-Datei mit allen WP-Georeferenzen findest Du hier. Wenn es Dir nur um einzelne Georeferenzen geht, kannst Du auch den Webdienst des BKG Geographische Namen Deutschlands (GN-DE) bemühen. --alexrk 14:54, 16. Jan. 2011 (CET)

Linked Coordinates

Auf der Seite Wikipedia:WikiProjekt Ostwestfalen-Lippe/Ortsteile sollten beim Anklicken der Vorlage linked coordinates alle Ortsteilartikel auf einer Karte angezeigt werden, die dort auf der Seite stehen. Allerdings werden die Ortsteile, die einen anderes Lemma haben als dort steht, bei Google-Maps nicht angezeigt, z.B. [[Heiden (Lage)|Heiden]]. Andere Lemmata dieser Art funktioneren dagegen, wie z.B. [[Lage (Lippe)|Lage]]. Wählt man aber Bing als Kartendienst aus, wird das Ergebnis ganz falsch. Weiß da jemand weiter? Grüße, --Joe-Tomato 15:31, 17. Jan. 2011 (CET)

Zumindest bei Bing liegt es an der Menge der Koordinaten. Bei 200 ist hier Schluss. --тнояsтеn ⇔ 17:49, 17. Jan. 2011 (CET)

Gleiche Vorlage: Anderes Problem. In Liste der Gebirgsketten an der nordamerikanischen Pazifikküste passt die Vorlage perfekt, allerdings werden im Text zur Abgrenzung eine Handvoll Gebirge genannt, die nicht zu den Küsten-Ketten gewählt werden. Gibt es eine Möglichkeit, diese auszuschließen? Grüße --h-stt !? 12:45, 19. Jan. 2011 (CET)

Nein, das geht nicht. --91.22.243.115 19:40, 4. Feb. 2011 (CET)

Mist - Wie kann man denn einen vergleichbaren Effekt erreichen? Oder kann man der Vorlage "linked coordinates" das nicht evtl beibringen? Es gibt da doch sicher hunderte Fälle, in denen es sinnvoll wäre, viele oder auch fast alle verlinkte Artikel entsprechend mit Koordinaten anzuzeigen, aber eine Handvoll eben nicht? Grüße --h-stt !? 15:50, 7. Feb. 2011 (CET)

Laut http://toolserver.org/~para/cgi-bin/kmlexport sollte das mit dem Parameter "section" gehen. --тнояsтеn ⇔ 17:51, 14. Feb. 2011 (CET)

Habe jetzt mal versucht, nur die Links aus dem Abschnitt "Große Gebirgszüge" aufzurufen: [3]. Sind aber auch noch die Links aus der Einleitung dabei. --тнояsтеn ⇔ 17:58, 14. Feb. 2011 (CET)

weiterschaltbare mehrfachkarte PositionskarteX ISO

Hallo, habe eine neue Vorlage gebaut, die auf PositionskarteX (+) aufbauend und unter Auswertung des ISO-Codes einfach so eine weiterschaltbare Karte erzeugt. Dabei kommt sie ohne zentrale Definition der Karten a la Vorlage:PositionskarteX FR-29 aus. Beispiele hier und Diskussion dort (einstweilen noch alles im BNR, Feedback trotzdem willkommen.). lg --Herzi Pinki 15:54, 26. Jan. 2011 (CET)

Vorlage:Lagewunsch noch sinnvoll?

Hallo, ist die Verwendung einer separaten Vorlage:Lagewunsch überhaupt noch sinnvoll? Die gesamte Vorlage besteht ja ausschließlich aus der Einbindung der Vorlage:Coordinate und ist daher meiner Ansicht nach überflüssig. Die paar Verwendungen könnte ich mit dem Bot in ein paar Minuten substen, sodass auch hier kein Problem entstehen dürfte. Damit hätte man die Vorlage Coordinate als einzige und generelle Vorlage für Koordinaten und könnte die Vorlage Lagewunsch löschen. Grüße --Carport ^{(Disk. • ± • MP)} 15:35, 31. Jan. 2011 (CET)

Klingt für mich sinnvoll. --Spischot 16:09, 31. Jan. 2011 (CET)

Bin da neutral, allerdings finde ich es lustig, dass so viele Begriffe von englisch auf deutsch übersetzt werden, wie beim Bilder einbinden, auch wenn es doppelt so viel Schreibarbeit ist - da wär es dann umgekehrt ;-) --K@rl (Verbessern ist besser als löschen) 18:27, 31. Jan. 2011 (CET)

ach ich ging da abundzu die Einbindungen durch, ergänzte den ISO-Region-Code und substituierte ...

War auch noch ein kleines Zugeständnis an die man spricht Deutsch Fraktion. Kann man löschen tut aber auch nicht weh. -- visi-on 23:04, 1. Feb. 2011 (CET)

Verteilung georeferenzierter Artikel

Zur Info: Georeferenzierte Artikel im Kurier. --91.22.200.141 18:12, 6. Feb. 2011 (CET)

Vorlage:Infobox Erdbeben

Macht es in der Vorlage für Erdbeben Sinn, die Tiefe des Epienzentrums als Parameter elevation einzubauen? .-91.22.200.127 20:08, 16. Feb. 2011 (CET)

Nein und nein. elevation wäre der einzige englische Parametername. Und den Parameter Tiefe gibt es schon. Uwe Dedering 20:58, 16. Feb. 2011 (CET)

Sorry, falsch ausgedrückt. Der Parameter Tiefe der Erdbebenvorlage wird an die Coordinate-Vorlage weitergegeben (dort als Parameter elevation mit negativem Wert). Das meinte ich, sind dort negative Parameter gewünscht? Es kommt dann auch wieder zum allseits bekannten "von-bis-Problem", wie etwa in Iwate-Erdbeben 2008. --91.22.200.127 21:08, 16. Feb. 2011 (CET)

OSM-Implementierung und dim-Angaben

Bitte beachten und Senf abgeben: Hilfe Diskussion:OpenStreetMap#Optionen / Standardeinstellungen --91.22.198.219 20:33, 13. Mär. 2011 (CET)

Portugal: Daten konvertieren - wer kann helfen

In einer mächtig gewaltigen Datenbank (ca. 160 MB) zu Denkmalen in Portugal werden die exakten Positionsdaten mit angegeben - doch die Angabe erfolgt im Gauss-Krüger-System nach port.Standard. Für den gerade erforderlichen Eintrag zum Tanque dos Mouros wird dort: M248.0 P207.5 - Carte Milit.: 425 angegeben - nun bin ich so schlau wie zuvor. Das Geogr. Institut/ Landesvermessungsamt bietet da offenbar auch keine Hilfe an - wer kann das Konvertieren? --Metilsteiner 14:56, 8. Apr. 2011 (CEST)

Trivial ist das nicht. Man muss wohl erstmal die EPSG ID-Nummer rausbekommen. Ich vermute es ist "3763-ETRS89/Portugal TM06", man muss sich aber sicher sein. Anschließend gibt es diverse Tools (Postgis, QuantumGIS) zur Umwandlung bzw. Anzeige in WGS84. --Kolossos 10:24, 9. Apr. 2011 (CEST)

Die Koordinaten sind anscheinend in einem projiziertem Koordinatensystem names "Portuguese National Grid" angegeben (EPSG Code 20790). Die 425 ist dabei die Nummer des Kartenblattes der Serie 1:25000 - ist unwichtig. Die beiden ersten Zahlen geben die Koordinaten in Kilometer an - d.h. wenn Du die Koordinaten in einer Dezimalstelle vorliegen hast - sind die Postionen auf 100m genau. Da wirst Du also vielleicht nochmal mit Hilfe von Google Maps o.ä. etwas korrigieren müssen. Je nachdem. Wenn das Denkmal ein Gebäude in einer Stadt ist, können 100m schon viel sein. Jetzt zur Umrechnung. Es gibt hierfür eine Webseite mit einem Transformationstool - dort wählst Du aus: "Coordenadas Rectangulares" und "Militares Datum Lisboa", gibst dann den Wert in Meter ein, klickst auf TRANSFORMAR und nimmst aus der Spalte WGS84 die geografischen Koordinaten im WGS84 System (Länge/Breite).

248000, 207500 ergibt -07º 34' 49,029″ 38º 50' 01,615″

PS, für die Freunde von Kommandozeilen und PROJ.4:

cs2cs +init=epsg:20790 +towgs84=-282.1,-72.2,120.0,-1.529,0.145,-0.890,-4.46 +to +proj=longlat +ellps=GRS80 +towgs84=0,0,0

248000.00 207500.00

7d34'49.05"W 38d50'1.615"N 51.579

Viel Spass beim Knobeln, --alexrk 12:54, 9. Apr. 2011 (CEST)

Vielen Dank für die rasche Hilfe. Ich habe nochmal alle Fakten abgewogen und einen hochwahrscheinlichen Ort an der Nationalstr. gefunden, auf den (fast) alle Angaben zutreffen. Ideal wäre natürlich eine TK25 der Region, doch in PT scheint Online-Kartographie noch immer ein Staatsgeheimnis zu sein. Viele Grüße --Metilsteiner 19:46, 9. Apr. 2011 (CEST)

Eigentlich nicht. Klick mal auf der Startseite auf "IGeoE-SIG - Sistema de Informação Geográfica Online" da kommst Du in einen Online-Viewer für die TK's. Funktioniert allerdings nur mit IE (>6) (wassn sch***). --alexrk 20:45, 9. Apr. 2011 (CEST)

Oh prima - Danke! Damit wird die Suche bei künftigen Artikeln immens erleichtert.--Metilsteiner 20:12, 10. Apr. 2011 (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! --Hedwig in Washington (Post?)•B 07:33, 21. Jul. 2011 (CEST)

"Add-Tags":ein neues Werkzeug zur Verbindung Wikipedia-OpenStreetMap

Unter folgender Adresse gibt es ein neues Tool um verstärkt Wikipedia-Tags in die OpenStreetMap Datenbank einzupflegen und so die Verbindung beider Projekte voranzutreiben:

http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl/Add-tags

Später können wir dann wieder auf diese Einträge zugreifen und so auch Linien- und Flächenobjekte auf unserer OSM-Karte darstellen die in die Artikel integriert ist. Ganz nebenbei werden auch die als Interwikilinks hinterlegten Daten als Übersetzungen des Name-Tags übernommen. Startpunkt ist eine Catscan-Abfrage und eine Abfrage von OpenStreetMap-Objekten. Die Objekte werden dann versucht zu verknüpfen. Kontrolle ist dann in JOSM möglich. Dieser muss momentan scheinbar in der latest Version anstatt der stable Version laufen. Für Fragen, insbesondere zur Erstellung der passenden Abfragekriterien, stehe ich gerne zur Verfügung. --Kolossos 10:44, 9. Apr. 2011 (CEST)

ISO-Code-Updates

Grüß euch!

Ist beim Updaten der ISO-3166-2-Codes sonst noch was zu tun oder wünschenswert, außer

• dem Aktualisieren der Seiten wie zB ISO 3166-2:CL
• dem Anlegen neuer Code-Seiten wie zB Vorlage:Info_ISO-3166-2:CL-AP?

Lässt sich das Einsetzen der aktuellsten Codes in Geovorlagen irgendwie botgestützt machen oder sonst irgendwie erleichtern? Danke für Hilfe, … «« Man77 »» 14:46, 10. Apr. 2011 (CEST)

Noch was: Lässt sich irgendwie eine Liste an Artikeln erstellen, die einen gewissen Code verwenden (zB "CL" allein oder "CL-TA", was ja aufgeteilt wurde)? … «« Man77 »» 14:06, 11. Apr. 2011 (CEST)

Einbindungen von CL-TA: [4] ([5]); alle mit CL: [6] ([7]). --тнояsтеn ⇔ 17:41, 11. Apr. 2011 (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! --Hedwig in Washington (Post?)•B 07:34, 21. Jul. 2011 (CEST)

Asiatischer Teil Ägyptens

Mir missfällt, dass zB bei Dahab die Positionskarteneinbindung per {{Coordinate}} die Asienkarte ausspuckt, nicht die Ägyptenkarte, auch trotz maplevel=national:

28.49305555555634.504722222222

Dahab​

Muss das sein? Könnte das wer ausbessern?… «« Man77 »» 23:33, 11. Apr. 2011 (CEST)

Kenn mich zu wenig aus, um es zu reparieren, aber es liegt an region=EG-JS. Allein mit region=EG geht es auch standardmäßig (ohne maplevel):

28.49305555555634.504722222222

Dahab​

--тнояsтеn ⇔ 19:06, 12. Apr. 2011 (CEST)

"Schuld" ist wahrscheinlich, dass EG als Afrika definiert ist, obwohl Teile nicht afrikanisch sind. Die Vorlage ist mir zu komplex, um da irgendwas rumzuschrauben, aber in meinen Augen ist das ein Manko, das in Richtung Bug geht. … «« Man77 »» 08:02, 13. Apr. 2011 (CEST)

ISO 3166-2:CV

Wahrscheinlich sind wir machtlos, aber ich hab da Mitteilungsbedüfnis: ISO war nicht intelligent genug, um zu sehen, dass sie jetzt CV-SL für zwei verschiedene Entitäten in Verwendung haben. Wie gehen wir damit um? … «« Man77 »» 23:33, 11. Apr. 2011 (CEST)

Zwei Möglichkeiten:

• Vorlage:Info ISO-3166-2:CV-SL um São Lourenço dos Órgão erweitern. Vorteil: Vorlagen-System = ISO-System. Sollte irgendwann jedes Gebiet einen eigenen Code bekommen, ist das schnell zu trennen. Im Moment verweisen nur fünf Artikel auf die Vorlage. Da es kleine Gebiete auf den Kapverdischen Inseln sind, ist mit einem größeren Anwachsen der Artikelzahl nicht zu rechnen. Nachteil: Eine Abfrage nach Artikeln zu den einzelnen Gebieten ist nicht möglich.
• Für São Lourenço dos Órgão wird ein WP-internes Kürzel eingefügt, analog zu den Kürzeln für die Ozeane. Vorteil: Hier ist eine getrennte Abfrage möglich. Nachteil: Bei der Vergabe des Kürzels im ANR muss aufgepasst werden, dass nicht das „amtliche“ Kürzel vergeben wird. ISO 3166-2:CV steht im ANR und kann daher keinen Hinweis auf einen abgeänderten WP-internen Code aufnehmen, das ist nur bei Vorlage:Info ISO-3166-2:CV-SL möglich. NNW 10:29, 13. Apr. 2011 (CEST)

Sal und São Lourenço dos Órgãos liegen ja nicht gerade nebeneinander. Ein Bot sollte in der Lage sein, bei Koordinaten nördlich/südlich einer gewissen Linie das CV-SL zu belassen oder zu ändern, wäre meine laienhafte Vermutung. Ich wär eher für Lösung zwei, wir müssen nicht jeden Fahler nachmachen. … «« Man77 »» 17:27, 13. Apr. 2011 (CEST)

Dann schauen wir mal, ob sich noch wer meldet. Ansonsten nehmen wir Lösung zwei, denn mir ist es egal, also zählt dein Votum. Wir wäre es mit CV-LO? NNW 10:53, 14. Apr. 2011 (CEST)

Ich bekam eine Antwort von "Technical Programme Manager/Editor/Secretary of ISO 3166/MA". In dem Mail kommt das Wort "experts" ziemlich oft vor; zwar nicht sicher aber mit "high probability" wird der Code für den hl. Lorenz im nächsten Newsletter CV-SO lauten.

Schön finde ich auch die doppelte Verwendung von ID-MA (als geographische Einheit und für eine der zwei dazugehörenden Provinzen) … «« Man77 »» 14:43, 23. Apr. 2011 (CEST)

Am weitesten von einem georeferenzierten Punkt entfernter Punkt

Gibt es eigentlich ein Tool, welches den Punkt ermittelt (sei es nun in D-A-Ch oder weltweit), der am weitesten von einem georeferenzierten Punkt entfernt ist? So eine Art WP-interner-Pol der Unzugänglichkeit.--Olaf2 15:43, 26. Apr. 2011 (CEST)

Das Problem sollte sich mit PostGIS-Mitteln lösen lassen. Ich denke da an die Funktion ST_Buffer, wird aber auch nicht ganz leicht. Wofür brauchst du es? Willst du Urlaub dort machen? ;-) Wenn ich auf Datei:Imageworld-artphp3.png schaue ist der südliche Pazifik ein ganz guter Kandidat für einen Seeurlaub und Sibirien für einen Festlandsurlaub. --Kolossos 11:04, 13. Mai 2011 (CEST)

Oh ja, mal Wikipedia-Urlaub möglichst weit weg von jeglichem Artikel ;). Es ist mehr bloße Neugier und vielleicht die Idee, durch Schreiben eines Artikels für die jeweils recht abgelegene Gegend, den Pol dann auch kräftig zu bewegen. (Innerhalb von D-A-Ch würden auch Artikel entstehen können, die sich nicht mit Tiefseegräben befassen.;) - Könnte auch ein WP-internes "Spiel" sein: Wem gelingt es den Abstand im Laufen eines Zeitraums um wieviele Meter/Km zu verkürzen?)--Olaf2 12:13, 13. Mai 2011 (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! --Hedwig in Washington (Post?)•B 07:35, 21. Jul. 2011 (CEST)

Bilder mit identischen Koordinaten

Das Tool von Kolossos ist beeindruckend, alle Commons-Bilder auf einer Karte anzuzeigen! Ich versuche, Tags nachzutragen, wobei ich Positionsfehler von eigen 100m in Kauf nehme. Frage: Wenn ich mehreren Bildern dieselbe Koordinate zuordne, lassen sie sich alle auf toolserver.org/~kolossos/openlayers/commons-on-osm.php abrufen, oder nur das erste? Vermip 13:01, 15. Mai 2011 (CEST)

Leider immer nur eines. Beim Einbinden in Google Maps ist über die Karte auch immer nur ein Bild an der selben Koordinate aufrufbar, über die Spalte links sind allerdings alle sichtbar ([8]). --тнояsтеn ⇔ 13:30, 15. Mai 2011 (CEST)

Danke für die Antwort (beim Nach-Taggen werde ich mich auf das schönste Foto geschränken...). Den Weg über Google kannte ich noch nicht. Vermip 15:16, 15. Mai 2011 (CEST)

Nun ja, vielleicht gibt es noch einen anderen Weg. Prinzipiell sollten alle Fotos georeferenziert werden können ohne Rücksicht auf die Auswertung der Daten. --тнояsтеn ⇔ 15:33, 15. Mai 2011 (CEST)

Ähm, der erwähnte Dienst.. zeigt der nicht die Bilder zu georeferenzierten Artikeln? Da haben die Geo-Tags auf Commons doch gar keinen Einfluss. --alexrk 18:15, 15. Mai 2011 (CEST)

Nee, Bilder von Commons: http://toolserver.org/~kolossos/openlayers/commons-on-osm.php --тнояsтеn ⇔ 19:57, 15. Mai 2011 (CEST)

Vorlage:All Coordinates für OSM

Zur Info: Wikipedia:WikiProjekt Vorlagen/Werkstatt#Testversion von Vorlage:All_Coordinates. --тнояsтеn ⇔ 22:31, 19. Mai 2011 (CEST)

Bzw. jetzt: Benutzer:Plenz/OSM for Wiki. --тнояsтеn ⇔ 09:23, 20. Mai 2011 (CEST)

Gerade wollte ich danach fragen: warum zeigt die Vorlage {Linked Coordinates} nur Artikel bei Google an? -- und entdecke hier den Hinweis.
Wird diese Vorlage nun auf OSM umgestellt?
Mit der linken Auflistung der Quellen ließen sich auch Bilder mit identischen Koordinaten darstellen (s.a. Wikipedia_Diskussion:WikiProjekt_Georeferenzierung#Bilder_mit_identischen_Koordinaten). Vermip 22:04, 23. Mai 2011 (CEST)

Manche Artikel erscheinen nicht auf Google-Maps

Siehe hier. --Klaron 17:52, 7. Jun. 2011 (CEST)

Freeware-Viewer für referenzierte Karten?

Hibt es ein Freewaretool, mit dem man eine oder mehrere georeferenzierte Bilder einfach nur ansehen kann? Ich will einem anderen Benutzer das Bild und die dazughörige Worlddatei schicken, ohne das er sich eine entsprechende Profisoftware wie ACAD oder so besorgen muß. Hab schon mal herumgegugelt, allerdings ohne Erfolg. Glückauf! Markscheider Disk 11:11, 17. Jun. 2011 (CEST)

uDig, ArcGIS Explorer ..oder, wenn Du aus der WLD-Datei KML machst, auch Google Earth. --alexrk 11:40, 17. Jun. 2011 (CEST)

Danke, werd ich mal downloaden und ausprobieren. Mit dem Umwandeln in kml habe ich mich noch nie befasst (bisher wußte ich gar nicht, daß das möglich ist) - gibts da irgendwo eine Anleitung bzw. ein Konvertierungstool? Glückauf! Markscheider Disk 12:00, 17. Jun. 2011 (CEST)

Konvertierungstool wüsst ich nicht, wenn das Bild in WGS84 vorliegt, kannst Du die KML aber auch mit ein bisschen Umrechnen per Hand erstellen. Schau mal zB bei Commons für ein Beispiel ..File:Schmettau Plan de la ville de Berlin (georeferenced).jpg --alexrk 12:45, 17. Jun. 2011 (CEST)

Ich arbeite i.d.R. mit GK. :( Glückauf! Markscheider Disk 13:01, 17. Jun. 2011 (CEST)

Dann müsstest Du das natürlich für Google Esrth erst in WGS84 transformieren (zB mit GDAL) - das würde hier aber etwas zuweit führen, da dann vrmtl auch noch solch Probleme wie Datumsübergang für GK zu beachten sind. --alexrk 13:29, 17. Jun. 2011 (CEST)

Genauso siehts aus. Wie gesagt, es ging nur ums Visualisieren, ggf. mehrere Dateien in einer Ansicht, und das auf einfachstem Wege. Da bin ich natürlich bei GE hellhörig geworden, denn dann müßte er keine zusätzliche, evtl. englischsprachige und kompliziert zu bedienende Software installieren. Glückauf! Markscheider Disk 13:35, 17. Jun. 2011 (CEST)

In kml umwandeln geht mit dem toolserver. Am Beispiel Kölner Dom den Link zum deutschen Toolserver klicken, auf den englischen Toolserver (auf der linken Seite unter Languages) wechseln, dann oben unter Contens auf Export. Da gibt es dann den fertigen Export in KML und GPX --Knochen 11:13, 18. Jun. 2011 (CEST)

Das geht für eine Einzelkoordinate, Knochen. Aber mir geht es um Landkarten, die dann in GE lagerichtig eingeblendet werden sollen. Glückauf! Markscheider Disk 09:16, 19. Jun. 2011 (CEST)

Serverprobleme bei ~kolossos?

Seit einiger Zeit zeigt Kolossos keine Bilder mehr an. Weiß jemand die Ursache? Vermip 16:25, 23. Jun. 2011 (CEST)

Und sie sind wieder da (lokales Cache Problem). Vermip 16:27, 23. Jun. 2011 (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! --Hedwig in Washington (Post?)•B 07:35, 21. Jul. 2011 (CEST)

all coordinates | section

Unter Drehfunkfeuer habe ich in die Abschnitte Deutschland, Österreicht und Schweiz die Vorlage:All Coordinates mit:

All Coordinates|pos=right|section=Liste der VORs in DE/AT/CH|text=ssdf

eingefügt. Ich hätte erwartet, dass nur die Koordinaten in DE, im zweiten nur die von AT und im dritten von CH angezeigt werden. Statt dessen erhalte ich in allen drei Abschnitten ausschließlich Koordinaten von DE + AT, ohne CH. Was übersehe ich? Vermip 10:39, 25. Jun. 2011 (CEST)

Hi, danke für den Hinweis:

• Das Problem war keines für Bing
• Wohl aber für google maps, da habe ich es behoben.
• für OSM funktioniert es auch nicht, aber das konnte ich nicht fixen, habs weitergeleitet.
• für die Schweiz ist es klar, warum keine Koordinaten angezeigt werden, das liegt einfach daran, dass keine da sind (stehen als Text in der Tabelle und nicht als Koordinaten, die Positionskarte daneben trägt nichts bei)

--Herzi Pinki 07:19, 2. Jul. 2011 (CEST)

Danke! Was war der Fehler bei Google? Habe die Koordinaten für CH umgeschrieben, aber es funktioniert noch nicht (fehlene Sichtung?). Vermip 19:39, 2. Jul. 2011 (CEST)

nach der Sichtung hat es auch für CH funktioniert. Der Fehler bei google war ein falsches url encoding. lg --Herzi Pinki 00:03, 3. Jul. 2011 (CEST)

Danke für die Meldung. Ich habe mein Programm entsprechend ergänzt. Es kennt jetzt die Parameter

• project
• linksfrom
• article
• section
• l

Fehlt noch was? --Plenz 21:07, 6. Jul. 2011 (CEST)

in Drehfunkfeuer (und FF 4) funktioniert section jetzt wie erwartet. Danke. lg --23:04, 6. Jul. 2011 (CEST)

Klasse, danke! Vermip

Frage zu Fluessen, Kantonen, Gemeinden

Moin! Wie sollen Fluesse und Verwaltungseinheiten (Kantone, Gemeinden, Naturschutzgebiete, usw,) referenziert werden? Beim Rhein ist die z.B. die Muendung mit dem kleinen Marker versehen. Bei Gemeinden die Verwaltung? Wie aber z.B. Naturschutzgebiete? Einfach per Augenmass in die Mitte zwirbeln? Klingt irgendwie nicht richtig. :)) Danke! --Hedwig in Washington (Post?)•B 06:40, 27. Jun. 2011 (CEST)

Huhu! Jemand da? :) --Hedwig in Washington (Post?)•B 00:52, 1. Jul. 2011 (CEST)

Aber wer sagt's denn, doch wer zu Hause, Grüße nach Washington. ME sollte man sich immer den Zweck der Aktion vor Augen halten, es geht darum, das Objekt auf Karten zu finden. Und dann reicht eine in die Mitte gezwirbelte Koordinate allemal (v.a. in Kombination mit einer Größenangabe (Par dim)), zumindest bei flächigen Objekten wie Naturschutzgebieten, Gebirgen, ... Schwieriger und weniger unmittelbar benutzerfreundlich ist die Markierung von im Wesentlichen linearen Objekten, wie Flüssen, Straßen, Eisenbahnlinien. Dort gibt es dann objekttypspezifische Festlegungen (etwa über die Quell- und Mündungskoordinaten bei Flüssen). --Herzi Pinki 01:08, 1. Jul. 2011 (CEST)

Ok, danke! Wo findet man diese objektspezifischen Festlegungen? Nur in der Infobox? Oder gibt es irgendwo ein HowTo? --Hedwig in Washington (Post?)•B 04:50, 2. Jul. 2011 (CEST)

Die jeweilige Infobox (so sie die Koordinaten verarbeitet) und Artikel aus der gleichen Objektkategorie sind sicher gute Anhaltspunkte, HowTo kenne ich keines, hätte aber durchaus Sinn. Was es gibt, ist bloß ein HowTo, mit welchen Parametern Koordinaten an Infoboxen übergeben werden sollen, aber das betrifft das Design von Infoboxen. lg --Herzi Pinki 06:10, 2. Jul. 2011 (CEST)

Danke, dieses HowTo hab ich gefunden. Naja, bastel ich mich dann eben durch. :) --Hedwig in Washington (Post?)•B 06:30, 2. Jul. 2011 (CEST)

Wenn großflächige Objekte einen "Schwerpunkt" oder "Kern" haben, referenziere ich auf diesen und nicht auf die geometrische Mitte. Bei ausgedehnten Gemeinden mit eingemeindeten Ortsteilen ist das der Hauptort, auch wenn er nicht in der Mitte der Gemeindefläche liegt. Innerhalb einer geschlossenen Siedungsfläche ist es das Zentrum; in Karte oder Luftbild kann man oft klar erkennen, wo sich der ursprüngliche Siedlungkern befindet, andernfalls sind z.B. Marktplatz oder Rathaus Anhaltspunkte. Innerhalb dieses Kerns dann per Augenmaß in die Mitte. In Städte-Artikeln nicht exakt z.B. auf das Rathaus georeferenzieren, weil dies prinzipiell lemmafähig ist und dann 2 Artikel an der gleichen Koordinate lägen. Diese letzte Regel ist wohl Konsens, das davor meine persönliche Auffassung einer sinnvollen Georeferenz. --Telford 09:48, 2. Jul. 2011 (CEST)

Ja, so versuche ich das auch zu machen. Also weniger Regeln und mehr gesunden Menschenverstand. :) --Hedwig in Washington (Post?)•B 19:07, 2. Jul. 2011 (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! --Hedwig in Washington (Post?)•B 07:37, 21. Jul. 2011 (CEST)

[GeoHack] USGS - The National Map 2.0

Hallo, bitte um freundliche Beachtung der Diskussion: Wikipedia_Diskussion:Kartenwerkstatt#PDF-Karten_der_USA ...es geht um die Einbindung von USGS-Karten in die Wikipedia. mE sollte das über den GeoHack laufen - es gibt neuerdings auch einen Webmap-Viewer für die neue National Map. Wäre wohl gut, den auf der GeoHack-Seite mit einzubinden (Beispiel-Link). --alexrk 16:10, 1. Jul. 2011 (CEST)

Hilfe benötigt

Ich binde gerade in dem Artikel Liste der Kulturdenkmäler in Frankfurt-Höchst Koordinaten ein – aus unerfindlichen Gründen landet oben rechts am Artikelanfang alles in der Ecke, obwohl sie im weiteren Text auch korrekt angezeigt werden. Bin zugegeben aber Anfänger in der Georef-Syntax. Was mache ich falsch? Herzlichsten Dank im Voraus --Roland.M 20:28, 5. Jul. 2011 (CEST)

Innerhalb von {{Coordinate|article=/|text=/|....}} bedeutet der Parameter "article", daß die Koordinate rechts oben angezeigt wird, der Parameter "text", daß die Koordinate im Text (also dort, wo sie angegeben ist) angezeigt wird. Man kann grundsätzlich auch beide Parameter (oder keinen) angeben, aber rechts oben darf natürlich nur maximal eine Koordinate stehen. Im vorliegenden Fall gehören also die ganzen "article=/|" raus. Dann hat der Artikel als ganzer keine Koordinate, was richtig ist. --Telford 20:54, 5. Jul. 2011 (CEST)

Außerdem musst du noch jeder Koordinate einen sinnvollen Namen, z.b. name=Zuckschwerdtstraße 058|… hinzufügen. Dann müsste es gehen. --Spischot 20:57, 5. Jul. 2011 (CEST)

Ja, das hatte ich vergessen. Was mir auch noch aufgefallen ist: man sollte die Bogensekunden auf maximal 1 Nachkommastelle runden. Dies entspricht etwa 2 bis 3 m Genauigkeit, jede "genauere" Georeferenz ist Augenwischerei. --Telford 21:04, 5. Jul. 2011 (CEST)

Sollte da nicht anstatt text=/ besser text=DMS stehen? Ich dachte text=/ sollte nicht verwendet werden? --Hedwig in Washington (Post?)•B 21:06, 5. Jul. 2011 (CEST)

logisch ist DMS und / meist identisch (soll heißen, erzeugt dieselbe Zeichenkette), allerdings ist DMS etwas performanter, da / in Abhängigkeit von region auf das Koordinatensystem gemappt wird, und dies bei Direktangabe von DMS entfällt. Bei langen Listen mit vielen Koordinaten ist daher DMS vorzuziehen, bei einzelnen Koordinaten oder in der Schweiz (!) eher /. (siehe auch Vorlage:Coordinate#Artikel-_und_Fließtextkoordinate) --Herzi Pinki 21:57, 5. Jul. 2011 (CEST)

Also grundsaetzlich in NICHT-CH Artikeln DMS im Fliesstext und in Listen einsetzen. DMS wird doch genau wie / in der Karte dargestellt. Oder bezieht sich das eher auf externe Anwendungen (Google Maps, GeoHack)?? --Hedwig in Washington (Post?)•B 23:46, 5. Jul. 2011 (CEST)

Habe die bestehenden Coordinaten wie folgt geandert: article=/ entfernt; text=/ mit text=DMS ersetzt; name="" vor region eingefuegt. Die Namen muessen noch nachgetragen werden. Roland.M informiert.--Hedwig in Washington (Post?)•B 23:59, 5. Jul. 2011 (CEST)

Verstehe zwar nur die Hälfte von den letzten zwei Absätzen, aber herzlichen Dank für eure Bemühungen und das Fixen! --Roland.M 00:16, 6. Jul. 2011 (CEST)

Noch nicht ganz erledigt: Roland, bitte trage überall bei name="" einen Sinnvollen Namen des jeweiligen Objekts ein. Positionen ohne sinnvollen Namen machen sich in der Geo-Datenbank (und in Google) schlecht. --Spischot 20:16, 7. Jul. 2011 (CEST)

Man sollte, ich habe es schon auf der Vorlagendiskussion angemerkt, die Eingabemöglichkeite article=/ und text=/ vollständig entfernen. Zum einen verwirrt das nur die Benutzer, zum anderen ist darin Code involviert, der andernfalls nicht notwendig ist. Inwieweit das auf das allgemeinen Performanceproblem bei Listen Auswirkungen hat, weiß ich jedoch nicht. --Matthiasb ^{(CallMyCenter)} 20:05, 12. Jul. 2011 (CEST)

Vorlage:Lage

Allgemeine Diskussion

Habt ihr das mitbekommen? --Matthiasb ^{(CallMyCenter)} 22:13, 5. Jul. 2011 (CEST)

jetzt schon, danke. Siehe auch {{Koordinate Weltkugel}}. Die Performance in großen Listen ist halt ein Problem und user sind erfinderisch. Solange die Performance so ist, bleibt das Kämpfen für eine einheitliche Koordintenvorlage ein Kampf gegen Windmühlen. Resignierend --Herzi Pinki 22:27, 7. Jul. 2011 (CEST)

hier der Link zu einem Tool für die Umwandlung von allen Koordinate-Einbindungen aus einem Artikel nach Vorlage:Lage. Es wandelt auch DMS nach Dezimalgrad um. Man sollte aber, bevor man den Artikelinhalt ersetzt, nochmal die Änderungen checken; die Umwandlung ist recht schlicht und deckt bestimmt nicht alle Spezialitäten der Koordinate-Vorlage ab (Schweizer Landeskoordinaten o.ä.) --alexrk 14:39, 8. Jul. 2011 (CEST)

also automatische Konvertierung finde ich aber doch etwa frech. Es handelt sich um eine redundante Vorlage, gegen die ein LA gestellt werden sollte, ... lg --Herzi Pinki 19:21, 10. Jul. 2011 (CEST)

Tja, die Proliferation nimmt ihren Lauf :) In Anbetracht der Performance ist das ja eigentlich auch ein schlüssiger Workaround. Ich habe es mal an einer Straßenliste verglichen: 47sec vs. 6sec für einen Seitenaufruf. Ich versteh nicht, was das Vorlagen-Geraffel an sich hat, dass so eine simple Koordinaten-Vorlage sooo langsam sein kann. Ich hoffe, die führen da irgendwann mal eine vernünftige Template-Engine ein. --alexrk 12:02, 11. Jul. 2011 (CEST)

Angesichts der weitreichenden Auswirkungen halte ich es für absolut problematisch, irgendwelche Hau-Ruck-Lösungen ohne Abstimmung flächendeckend einzuführen. Besser wäre, das erst mal vorher hier zu diskutieren und eine wirklich saubere Lösung zu suchen. Für mein Gefühl ist diese neue Vorlage weniger kiss als quick&dirty, und so was rächt sich bei komplexen Systemen erfahrungsgemäß irgendwann. --Telford 14:55, 11. Jul. 2011 (CEST)

Volle Zustimmung. --тнояsтеn ⇔ 15:05, 11. Jul. 2011 (CEST)

Nichts gegen Diskussionen, nur die Seiten, die jetzt auf die schlanke Vorlage umgestellt wurden, waren definitiv nicht mit der Koordinaten-Vorlage machbar, wenn ein Aufruf über 40 Sekunden dauert. Ich möchte auch nochmal darauf hinweisen, dass das Problem mit der Performance schon seit Ewigkeiten ohne Besserung herumgärte. So wundert es wenig, wenn jetzt eine für Listenartikel brauchbare Alternative auf fruchtbaren Boden fällt. --alexrk 16:04, 11. Jul. 2011 (CEST)

Hey, das hier ist ein Wiki. {{Coordinate}} wurde sicher auch nicht von einem Gremium entworfen sondern begann quick'n'dirty, oder? Man probiert etwas aus, und wenn es gut ist setzt es sich durch, und wenn nicht verschwindet es wieder. So sind übrigens auch das Internet, das WWW und die Wikipedia entstanden. --PM3 23:25, 11. Jul. 2011 (CEST)

Hallo PM3, Hier kannst du die Geschichte der Vorlage Coordinate nachlesen, immerhin währte die Diskussion bis zur finalen und flächendeckenden Umsetzung von Nov. 2007 bis Juni 2009, inklusive einer breiten Diskussion und einem notwendigen Meinungsbild. Die wesentliche Verbesserung, die mit der flächendeckenden Einführung der {{Coordinate}} verbunden war, war die deutliche Verbesserung der Datenqualität der Altdaten (snapshot), aber auch massive Unterstützung bei der Aufrechterhaltung der Datenqualität bei neuen Koordinaten (gemessen im Vergleich zur WP:en), etwa durch kontinuierliche Abarbeitung der Kategorien Parameterfehler und Geographische Lage gewünscht. Ausgangspunkt für die Arbeiten damals war übrigens auch eine Vielzahl von unterschiedlichen Vorlagen für denselben Zweck. lg --Herzi Pinki 05:42, 12. Jul. 2011 (CEST)

Ok, verstehe. Die fehlende Parameterprüfung halte ich auch für ein großes Problem der neuen Vorlage, bzw. für das einzige wirklich ernsthafte. Aber bei Seitenladezeiten über 30 Sekunden hört halt auch der Spaß auf - wenn der Server mal höher belastet ist, kann sich das Vervielfachen (beim Bearbeiten im BNR kommt nochmal Faktor 2 drauf, wegen geringerer Prio auf dem Server), und dann kriegt man Timeouts beim Speichern.

Lösungsmöglichkeiten:

• Eine möglichst weit abgespecke Version von Vorlage:Coordinate, die wenigstens Faktor 3-4 schneller ist
• Ein neuer Parameter geprüft für die Vorlage:Lage, der erst nach Prüfung durch einen Dritten (manuell oder durch einen Bot) gesetzt werden darf. Hilft natürlich nichts bei nachträglichen Änderungen.
• Ein Bot, der regelmäßig alle (geänderten) Artikel mit Vorlage:Lage durchgeht und die Parameter prüft.

Macht alles eine Menge Arbeit. --PM3 06:39, 12. Jul. 2011 (CEST)

• Stelle Löschantrag. --Matthiasb ^{(CallMyCenter)} 07:42, 12. Jul. 2011 (CEST)

Vielleicht bekommen wir aus der angeheizten Diskussion genügend Energie, um eine deutliche Performance.Verbeserung der {{Coordinate}} zu erzeugen. Zwei Denkansätze dazu: Ich habe (erst vor wenigen Tagen) irgendwo in den Diskussionsarchiven eine Diskussion zwischen Visi-on und einem anderen Benutzer gefunden: Der andere bot an, eine Erweiterung {{#coordinate:…}} für die Media-Wiki-Syntax zu schreiben, sofern Visi-on die Spezifikation dazu schriebe, was dieser zusagte. Leider finde ich die Stelle nun nicht mehr (vielleicht findet noch jemand den Link). Diese Lösung wäre aus meiner Sicht sehr sinnvoll. Eine alternativer Ansatz: Ich vermute, dass die Performance vor allem für die Parameterprüfung und die Fehlerbehandlung drauf geht - das müsste man man zunächst mal genau untersuchen. Falls dem so wäre, zahlten wir in der täglichen Anwendung einen aus meiner Sicht unangemessen hohen Preis um wenigen Unterstützern in gelegentlichen Fällen die Qualitätssicherung zu erleichtern. Ein Ansatz könnte daher sein, die Fehlerbehandlung auszukommentieren und nur für wenige Tage im Jahr im Rahmen einer jeweils konzertierten Aktion für kurze Zeit zu aktivieren, um Listen für die Pflege abzufragen. Im Alltag könnte der teue Code auskommentiert bleiben. --Spischot 09:25, 12. Jul. 2011 (CEST)

Halte ich für keine gute Idee, aber wenn, dann umgekehrt: Man ersetze den Inhalt von Vorlage:Lage hin und wieder durch einen Aufruf von Vorlage:Coordinate! Dann hat man (a) optimale Performance da, wo es nötig ist und (b) mehr Fehlersicherheit als bei deinem Vorschlag, weil die allermeisten Artikel weiter Coordinate verwenden und permanent geprüft werden. --PM3 09:45, 12. Jul. 2011 (CEST)

Matthiasb hat in der Löschdiskussion den Vorschlag gemacht, die Unterstützung für "text=/" und "article=/" aus der Vorlage herauszunehmen und alle ensprechenden Vorkommen durch "=DMS" zu ersetzen. Würde das wirklich soviel helfen?

Generell muss man m.E. aber auch nicht an einer einheitlichen Vorlage festhalten, sondern man kann auch eine abgespeckte Version für Tabellen bereitstellen, wo nur die notwendigsten Parameter enthalten sind (NS, EW, type, region, text, name) und nicht z.B. article, map und die ganzen Folgeparameter, dim, globe usw.

Eine schneller arbeitende Vorlage ist jedenfalls unbedingt erforderlich, aus meiner Liste Münchner Brücken habe ich die Koordinaten alle wieder rausgeschmissen. Ist zwar schade (v.a. wegen der jetzt mit der Vorlage:All Coordinates gegebenen Möglichkeiten, aber die Ladezeit war für die Leser einfach unzumutbar. -- Bjs M S 14:42, 12. Jul. 2011 (CEST)

Den Vorschlag, die Option "article=/" aus der Vorlage zu entfernen halte ich im Rahmen der Qualitässicherung und Vereinheitlichung für sinnvoll – ich erwarte daraus allerdings kaum Beschleunigungen bei Aufrufen, die heute schon "article=DMS", denn die "teuren Parserfunktionen" werden in diesem Fall auch nicht mehr aufgerufen.

Der Vorschlag, nur die notwendigsten Parameter in eine schnelle Vorlage aufzunehmen, ist dagegen nicht sinnvoll. Die Anzahl der übergebenen Parameter spielt für die Geschwindigkeit weder bei der {{Lage}} noch bei {{Coordinate}} eine wesentliche Rolle – vielmehr kommt es darauf an, was die Vorlage mit den übergebenen Informationen so alles veranstaltet. Falls wir also eine Vorlage wie {{Lage}} aus Performance-Gründen behielten, spräche alles dafür, möglichst vollständige Informationen zu übergeben damit eine spätere Nachpflege nicht unter dem Informationsverlust zu leiden hätte und damit die Argumente der Gegner bezüglich des Informationsverlustes vom Tisch wären (selbst wenn diese Zusatzinformationen zunächst mal gar nicht verwendet würden). Die lästige Arbeit, diese Parameter beim Aufruf zu bestimmen möchte weiterhin noch erledigt wissen, denn nur der Artikelschreiber kann sagen, welches Objekt er da eigentlich georeferenziert. Nach wie vor bin ich aber eher gegen die zweite Vorlage und statt dessen für eine Beschleunigung der {{Coordinate}}. --Spischot 15:07, 12. Jul. 2011 (CEST)

So Leute, die Vorlage:Lage hat jetzt eine vollständige Plausibilitätsprüfung sämtlicher Parameter, inlusive Einordung in in Kategorie:Parameterfehler und ohne erkennbaren Performanceverlust. Hat mich exakt zwei Stunden Zeit gekostet, den Code dafür ... --PM3 15:33, 12. Jul. 2011 (CEST) (belanglosen Rest gelöscht)

(Quetsch) Danke für die Mühe, schon mal seeeehr interessant! Zum Ersten zeigt es, dass die von vielen für wesentlich erachteten Informationsmengen und auch einige Prüfungen tatsächlich fix gehen könnten, d.h. innerhalb der {{Coordinate}} besteht latentes Optimierungspotential (zumindest das gefühlt Wichtige wird scheinbar erledigt), auch wenn noch nicht klar ist wo und wie dieses Potential gehoben werden kann. Weiterhin ist es spannend, dass die Parameterprüfung nicht pauschal teuer sein muss, wie ich dies noch oben vermutet hatte. Jetzt werde ich wirklich neugierig, wohin die Performance denn verschwindet. Die von mir oben geforderte Performance-Analyse wird jetzt richtig spannend. Ich hoffe, dass ich in den kommenden Tagen ’was rausbekomme. Um Missverständnisse zu vermeiden: Bis auf weitere nehme ich an, dass die {{Coordinate}} schon jetzt recht clever programmiert ist die Performance vor allem an der angebotenen Funktionalität zusammen hängt. Und weiterhin gehe ich davon aus, dass alle Funktionnen irgendwo auch ihre Daseinsberechtigung haben. Im Zweifel bin ich aber, ob der zu zahlende Performance-Preis bei jedem Aufruf dem Nutzen angemessen ist und ob dieser Zusammenhang im Rahmen einer einheitlichen Vorlage unumgänglich ist. --Spischot 16:41, 12. Jul. 2011 (CEST)

Scheint doch langsamer geworden zu sein. Ich bastel mal weiter. --PM3 16:28, 12. Jul. 2011 (CEST)

Meine Parameterprüfung ist - obwohl sie recht kompakt aussieht, doch langsamer als erwartet. Es braucht wohl viel Erfahrung mit Vorlagenprogrammierung, ob sowas gut zu optimieren. Bei gecachten Kopien von Liste der Kulturdenkmäler in Worms ist meine Lösung nicht schneller als Vorlage:Coordinate, aber um 20% langsamer als Vorlage:Lage. Bei ungecachten Daten konnte ich bislang nur Coordinate und Lage vergleichen, und da war letztere um Faktor 4 schneller.

Der Codeablauf von Vorlage:Coordinate scheint schon verdammt gut optimiert zu sein; ich denke, da kann man nicht mehr viel rausholen. Was die viele Zeit kostet, ist anscheinend das Expandieren der Vorlagen, wenn der Artikel nicht im Cache ist (d.h ne Viertelstunde oder so nicht mehr abgerufen wurde). Hier könnte eventuell ein Aufteilen von Vorlage:Coordinate & Untervorlagen in kleinere Teilstücke helfen. Also die seltener benötigten Features in Untervorlagen auslagern.

In die Vorlage:Lage habe ich inzwischen auch die Parameter type und dim eingebaut; das hat wirklich keine messbare Performance gekostet. --PM3 17:36, 12. Jul. 2011 (CEST)

Bei gecachten Artikeln komme ich auf ähnlich gute Zeiten wie mit der Vorlage:Lage ohne Parameterprüfung. Wenn ich jetzt noch ein paar Sekunden beim Expandieren der Vorlage einsparen kann, wäre es ein toller Kompromiss: NS, EW, region, type und dim (evtl. weitere) mit 100%iger Prüfung und automatischer Einordnung in Kategorie:Parameterfehler, aber mindestens dreimal so schnell wie Vorlage:Coordinate bei nichtgecachten Artikelversionen. --PM3 18:19, 12. Jul. 2011 (CEST)

Weiterentwicklung

Da ich nicht weiß, ob hier jemand Vorlage Diskussion:Lage liest, schreibe ichs lieber auch nochmal hier hin. Ich versuche im Moment, das Ding um wichtige Features zu erweitern, ohne dabei den Performancevorteil aufzugeben. Also Vorlage:Lage in Richtung Vorlage:Coordinate zu entwickeln, weil mir das 10mal einfacher erscheint, als aus Vorlage:Coordinate die nötige Performance rauszuquetschen.

Bereits eingebaut:

• Parameterprüfung
• type
• dim
• Mikroformat

Geplant:

• text
• sortkey
• globe
• elevation

--PM3 18:40, 13. Jul. 2011 (CEST)

Performance-Verbesserung Vorlage:Coordinate

Da es offensichtlich ein Problem gibt und unterschiedliche Ansichten der Lösung, versuche ich mal hier so neutral wie möglich zusammenzufassen und den Anfang für einen gemeinsamen Arbeitsraum für eine Lösung zu machen. Alle die sich an der Diskussion beteiligen wollen, sollen es in sachlicher Art hier an dieser Stelle tun. Es geht um Verbesserung, nicht um pro oder contra.

Problemdefinition

Die Vorlage {{Coordinate}} ist bei vielfacher Verwendung zu langsam.
Dies betrifft hauptsächlich Listen von georeferenzierten Objekten, aktuell gerade massiv die Denkmallisten. Zweite betroffene Stelle sind Positionskarten mit vielen eingetragenen Positionen, die über idente Mechanismen erzeugt werden. Um dieses Problem in Listen zu lösen wurde eine neue Vorlage {{Lage}} mit stark reduzierter Funktionalität aber deutlich besserer Performance geschaffen (it's a wiki), gegen die aktuell ein LA läuft.

Abgrenzung des Problems

Wie schon oben in der Problemdefinition angeführt, tritt das Problem bei (langen) Listen auf. In anderen Fällen einzelner Verwendungen von {{Coordinate}} gibt es aktuell keinen erkennbaren Handlungsbedarf, die Performance zu verbessern. Listen haben aber einige zusätzliche Eigenschaften, die uns Ansätze für Optimierungen bieten.

Optimierungsansätze bei der Verwendung in Listen

(bitte ergänzen und kommentieren)

• globe=earth kann vorausgesetzt werden. Bis wir die Denkmäler auf dem Mond listen (und mehrere hundert Einträge zusammenbekommen), wird es noch dauern.
• In Listen / Tabellen werden keine Artikelkoordinaten (aus den einzelnen Einträgen) erzeugt.
• In Listen / Tabellen werden keine maps aus den Koordinaten generiert
• eine abgespeckte Version von {{Coordinate}} kann da also durchaus Sinn machen und ich denke, dagegen kann man sich nicht verwehren. (Dies könnte aber auch durch einen zusätzlichen Schalter in der {{Coordinate}} erreicht werden.)

Randbedingungen

(bitte ergänzen und kommentieren)

• sinngemäß Wikipedia:WikiProjekt_Georeferenzierung/Neue_Koordinatenvorlage, inklusive MB. Außer es wird hier anders entschieden.
• Jede alternative Lösung sollte den kompletten Parametersatz an der Schnittstelle anbieten und auch einfordern (zumindest in Form von Doku), damit jederzeit auf Coordinate oder andere gemeinsame Alternativlösungen redirectet werden kann. Eine Auswertung kann dabei natürlich tw. unterbleiben.
• Eine gesonderte Implementierung für Listen ist ausdrücklich als Lösung erlaubt, nur sollte sie in ihrer Funktionalität nicht gegen die Vorlage:Coordinate zurückfallen, was
  • Parameterprüfung (inklusive region)
  • identische Schnittstelle zum Geohack (type, dim, region, …)
  • identische Schnittstelle zu den Kartendiensten bing, google maps und OSM.
  • Verwendung von Mikroformaten
  • Printverhalten
  • Schweizbezogenheit (CH1903 statt DMS)
  • Mobile Endgeräte (Bsp, könnten auch von Coordinate besser unterstützt werden),

anbetrifft.

• Jede alternative Lösung ist, abgesehen von ihren Einschränkungen, sinngemäß gegen Vorlage:Coordinate/Test zu testen.

Tja, da ist die Vorlage:Coordinate dann schon durchgefallen, die produziert dort jede Menge Fehler von verschiedener Art. --PM3 22:48, 12. Jul. 2011 (CEST)

• Auch wenn für Listen eine eigene Vorlage / eine Variante von Coordinate geschaffen würde, sollte die im MB geforderte Einheitlichkeit nicht durch weitere Vorlagevarianten aufgeweicht werden.

Das Wegfallen einer dieser Randbedingungen wäre gut zu begründen.

Anmerkungen

• Bing zeigt über {{All Coordinates}} (und auch sonst) nur max. 200 Koordinaten an, insoferne machen mehr als 200 in einer Liste ev. aus diesem Grund wenig Sinn.
  • Eine externe technische Beschränkung bei genau einem Anbieter darf kein Grund dafür sein, alle betroffenen Inhalte an die Möglichkeiten diesen Anbieters anzupassen. --jergen ? 22:16, 12. Jul. 2011 (CEST)
• Eine Einschränkung es Formats auf nur Dezimalgrade halte ich für ungünstig aus Gründen der Benutzerfreundlichkeit. Man sollte generell eine Umrechnung von 60er System auf Dezimalsystem von Benutzern nicht verlangen, viele der mir untergekommenen Fehler resultieren genau daraus. Und die GIS Systeme werfen mal das eine, dann das andere aus, nicht jeder weiß das in google maps etwa umzustellen.
• Es scheint allerdings auch bei vielen Koordinaten ein schnellerer Seitenaufbau zu erfolgen, wenn die Koordinaten tatsächlich dezimal vorliegen. (in etwa vergleichbare Beispiele 89 mal DMS vs. 80 mal dezimal) --Matthiasb ^{(CallMyCenter)}

Abschätzung

{{Lage}} inklusive aller Prüfungen wurde von PM3 vermessen und im Falle, dass die Seite sich nicht schon expandiert im Cache befindet, um einen Faktor 3 gegenüber Coordinate beschleunigt. Es gibt Leute, die bereits 30 Coordinaten in einer Seite von der Performance für schwer erträglich halten, mit einem Faktor 3 käme man daher auf 100 Listenelemente und damit an die Grenze, bei geduldigeren Personen bei etwa 300-400 Koordinaten. Dies würde also immer noch nicht ausreichen, um die denkmalintensivsten Städte Deutschlands in einer Liste unterzubringen. Aber natürlich in den meisten Fällen Erleichterung schaffen.

Liste der Straßen und Plätze in Berlin-Mitte hat aktuell 237 Koordinaten und kommt non-cached mit Vorlage:Coordinate auf ca. 55 Sekunden Ladezeit, mit der überarbeiteten Vorlage:Lage auf ca. 20 Sekunden, wozu sicher die gigantische Tabelle einiges beiträgt. Die Schmerzgrenze bei solchen Artikeln würde ich bei 60 Sekunden ansetzen, also bei diesen Daten ca. 700 Koordinaten mit den vorhandenen Mitteln. Bei mehr als 60 Sekunden läuft in Hochlastzeiten, oder wenn man eine Kopie im BNR editiert (geringere Serverprio!) leicht in einen Timeout. --PM3 22:06, 12. Jul. 2011 (CEST)

Serverseitige Lösung

Eine bereits einmal angedachte, leider nicht weiter verfolgte, aber sicher zielführende Lösung wäre eine serverseitige. Etwa durch ein plugin, das ein tag <coordinate> (mit gleichen Parametern und bot-Umsetzung) entsprechend umsetzt. Die Lösung hier über Vorlagen ist immer ein Krampf. Rein von der Performance her, abgesehen von der Performance. Ein solches Tag sollte natürlich international verwendbar sein. Probleme dabei dürften sein:

• Lokalisierung (Formatierung der Koordinaten, Namen der Himmelsrichtungen, Koordinatensystem (z.B. CH), Fehlermeldungen)
• Neutrale, serverseitige Modellierung des ISO Regionsbaums (derzeit hier über lokale Vorlagen)
• Integration mit den Positionskarten / map Erzeugung
• Abstimmung mit und Durchsetzung bei der Foundation

--Herzi Pinki 20:51, 12. Jul. 2011 (CEST)

Das dauert vorraussichtlich ewig... . --Kolossos 19:03, 13. Jul. 2011 (CEST)

... und es ist fraglich, ob es dann wirklich kompatibel zu {{Coordinate}} sein wird. Wird ja auch die Koordinatenbedürfnisse aller anderen Sprachversionen berücksichtigen müssen; die haben dafür ihre eigenen Vorlagen. --PM3 19:08, 13. Jul. 2011 (CEST)

Weitere Diskussion

Ist denn bekannt, warum {{Coordinate}} so langsam ist? Wenn nicht, wäre das wohl der erste Schritt zur Lösung, oder? --Alex 21:34, 12. Jul. 2011 (CEST)

Ich persönlich bin der Meinung, daß die Performance bei den fraglichen Listen vor allem durch das Zusammenwirkung von Tabellensyntax und Koordinatenvorlage erzeugt wird. Es wird ja praktisch eine Tabellenzeile geschriebenm dann der Link zum Geohack und die Koordinatenbeschriftung erzeugt, dann wird die n§achste Tabellenzeile geschrieben usw.

Ich glaube, daß das Problem nicht primär in der Vorlage liegt. Man mußte vermutlich mal analysieren, in welcher Reihenfolge der Krempel jeweils geladen wird. Da läuft vermutlich einiges nicht optimal, vor allem zwischen den ganzen Skripten, die sonst noch geladen werden.

Es ist auffällig, daß bis 30 oder 40 Koordinaten kein Zeitverlust offentsichtlich ist, ab so etwa 150 Einbindungen dauert es wirklich lang. --Matthiasb ^{(CallMyCenter)} 21:59, 12. Jul. 2011 (CEST)

Habe keine guten Tools (Profiler) oder Hinweise zum Aufspüren des Performance-Leaks gefunden, nur etwa [9]. Jedenfalls sollte man vor einer Änderung der Funktionalität doch nochmals versuchen, den Vorlagen-Code zu optimieren. Aufgrund eines kurzen Code-Reviews würde ich Folgendes ausprobieren:

• Zu CoordinateLAT und CoordinateLONG je ein privates Subtemplate bauen mit 4 unbenannten Argumenten für Grad, Minuten, Sekunden, Himmelsrichtung; den CoordinateLAT/LONG-Code dorthin übertragen (ohne ParmPart, {{#if:{{{4}}}{{{3}}}{{{2}}}...); diese nur aus CoordinateLAT/LONG mit 1 (Dezimalgrad) oder 4 Argumenten aufrufen, spart je ein gutes Dutzend ParmPart-Aufrufe pro Vorlagenaufruf, dafür zwei Template-Aufrufe mehr. Oder mit Variable-Extensions arbeiten, falls das geht.
• Falls möglich analoge Subtemplates für region/map/caption-Teil, da dort ebenfalls Variablen anstelle der mehrfachen ParmPart-Aufrufen hilfreich wären.
• Bereichsprüfung à la -90 <= x <= 90 mit abs impl.
• Himmelsrichtungen nur als Grossbuchstaben 'N', 'S', 'E', 'W' akzeptieren (spart wenige uc:-Aufrufe)

Macht wohl alles nur ein paar Prozent aus, aber vielleicht gibt's noch mehr davon? Hinweis: Habe noch nie Vorlagen programmiert, nur anderes Zeugs. Vielleicht liege ich also mit den Vorschlägen daneben… --Meleager 22:10, 12. Jul. 2011 (CEST)

zu Matthias: Mit Vorlage:Lage erreicht man im identischen Artikel mit gleicher Tabelle ein Drittel der non-cached-Ladezeit (siehe #Abschätzung); mit der alten Variante war es sogar in Viertel. Also liegt es definitiv im Wesentlichen an der Vorlage. Und da die Vorlage:Coordinate aus dem Cache ausgesprochen fix ist - 10% schneller als meine Variante - kann es nicht an den Codelaufzeiten liegen, sondern eigentlich nur am zu expandierenden Codeumfang. Das Ding ist inklusive aller eingebundenen Untervorlagen einfach verdammt groß, und wenn man das dann 200mal expandiert, dauert das halt so lange.

Bei 30 Koordinaten-Einbindungen hat man kaum eine Chance etwas zu messen, da dürften die Unterschiede innerhalb der natürlichen Schwankungen der Serverlast/-antwortzeiten liegen.

@Meleager: Vergleich mit/ohne abs() war eins der Dinge, die ich heute mit Vorlage:Lage durchtetestet habe. Auch bei großen Artikel kein messbarer Unterschied. --PM3 22:16, 12. Jul. 2011 (CEST)

Danke. Auch das uc: wird nicht teuer sein. Vermutlich muss man wirklich die Anzahl Aufrufe bzw. die zur Laufzeit entstehende Datenmenge (Parse Tree) minimieren. --Meleager 22:37, 12. Jul. 2011 (CEST)

Ich glaube ich hab eben einen Denkfehler gemacht: Das Expandieren und Parsen dürfte ein zusammenhängender Vorgang ein; die Daten aus dem Cache werden nachher bestimmt nur noch en bloc kopiert. Aber das passt ja trotzdem zu dem parse tree. Untervorlagen werden anscheinend nur expandiert, wenn wirklich darauf zugegriffen wird - vielleicht kann man die Datenmenge auf diese Weise minimieren. --PM3 00:38, 13. Jul. 2011 (CEST)

Schalter in Vorlage

Also ich bin auch für das Testen des oben gewähnten Schalters in der Vorlage Coordinate, ich könnte mir dafür sowas wie "list=yes" oder "simple=yes" vorstellen. Man hätte also an der Spitze eine einzige if-Abfrage und würde dann entweder in das springen, was Vorlage:Lage so macht oder halt in die komplexen Ausführung von Vorlage:Coordinate (samt aller Untervorlagen) springen.

Ich denke das könnte funktionieren. Falls nicht, so hätte aus meiner Sicht eine zweite Vorlage für Listen Ihre Berechtigung. Diese Vorlage sollte dann so schlicht wie möglich gehalten werden, also kein Plausibilitätsprüfung und vorallem keine Koordinatenumwandlungen.

Könnte das mit dem Schalter bitte mal jemand ausprobieren? --Kolossos 19:21, 13. Jul. 2011 (CEST)

Noch einfacher: Angabe von simple ohne Parameter, um es einzuschalten. Ich probiere es mal aus. --PM3 19:50, 13. Jul. 2011 (CEST)

Hab eine Testreihe gemacht, mehrmals abwechselnd zwischen verschiedenen Versionen. Ergebnis:

• simple-Variante: kein erkennbarer Unterschied zu Vorlage:Lage
• normal-Variante: ca. 15 ms Performance-Verlust pro Einbindung gegenüber der bisherigen Vorlage:Coordinate → vernachlässigbar

Also: Testergebnis positiv!

Das sähe dann so aus:

1. Der Codeteil von {{Coordinate}} wird nach {{CoordinateFull}} kopiert
2. Hilfsvorlage {{Lage/Fehler}} wird nach {{Coordinate/SimpleError}} kopiert
3. Der Codeteil von {{Coordinate}} wird ersetzt durch den Codeteil aus {{Lage}} (mit Anpassung an die umbenannte Fehler-Vorlage) plus einen Aufruf von {{CoordinateFull}}, falls nicht simple=y gesetzt ist

Parameterprüfung & Einordnung in Kategorie:Parameterfehler würde ich auch bei simple=y drin lassen; das kostet auch nur so um die 15 5-10 ms pro Einbindung. --PM3 21:56, 13. Jul. 2011 (CEST) Parameterprüfung beschleunigt --PM3 21:35, 14. Jul. 2011 (CEST)

Ich wäre bereit mich um alles zu kümmern und die simple-Option in {{Coordinate}} einzubauen, unter der Voraussetzung dass ich bis auf Weiteres Schreibzugriff auf {{Coordinate}} behalte, um weiter Optimierungen und Verbesserungen an der simple-Variante vornehmen zu können. Vor allem möchte ich noch text und sortkey einbauen, sofern es keine nennenswerte Performance kostet. Also Vollsperrung für {{CoordinateFull}} und nur Halbsperrung für die neue {{Coordinate}}. Morgen bin ich weg; ab übermorgen hätte ich Zeit dafür. --PM3 22:18, 13. Jul. 2011 (CEST)

Schön, das schein ja ein Fortschritt zu sein. Ich hätte folgende Anliegen:

• in den österreichischen Denkmallisten wird nicht der Text Lage, sondern der Text Standort verwendet, manchmal Karte (Liste der Brücken in Berlin). Könnte man sicher vereinheitlichen, aber vielleicht könnte Lage den Parameter text auswerten. Default kann ja Lage sein.
• in vielen langen Listen stehen Koordinaten im Format DMS, um allgemein nützlich zu sein, sollte also auch der Wert text=DMS unterstützt werden. etwa Liste von Vulkanen in Bolivien
• es gibt auch rein textuelle Koordinaten, die auf die Vorlage umgestellt werden können sollten. etwa Liste der Segelfluggelände in Deutschland (da hat schon jemand vor der Performance resigniert).
• Tabellen hatten bisher die Möglichkeit der Sortierung nach Koordinaten (entweder von O nach W oder von N nach S). Parameter sortkey.
• Prüfung auf EW scheint nicht stattzufinden. {{Lage|NS=-30|EW=70/10/10/E|type=landmark|region=AT}}: {{Lage|NS=-30|EW=70/10/10/E|type=landmark|region=AT}}

--Herzi Pinki 22:30, 13. Jul. 2011 (CEST)

zu deinem Angebot, das alles umzusetzen. Gerne. Aber die Vorlage wird mehrere 100000mal verwendet. Es ist nicht gut, auf so einer Vorlage etwas auszuprobieren. Kannst du die fertige Implementierung unter einem temporären Namen bereitstellen, damit damit ausführlich getestet werden kann. Es denken im Moment andere auch noch über (Teil-)Lösungen nach. die sollten dann zusammen aktiviert werden. lg --Herzi Pinki 22:38, 13. Jul. 2011 (CEST)

Bitte sehr, hier ist die fertige Vorlage zum Testen:

{{Benutzer:PM3/Coordinate}}

Zusammen aktivieren mit anderen Lösungen ist nicht nötig, weil beides unabhängig voneinander ist und an verschiedener Stelle eingebaut würde: Die in der Vorlagenwerkstatt diskutierte Lösung wäre eine Optimierung der non-simple-Variante und fände dann komplett in {{CoordinateFull}} (s.o.) & Untervorlagen statt.

NS und EW werden vollständig geprüft mit Ausnahme des Zeichens /, aus Performancegründen. Ich werde versuchen, dafür noch eine Lösung zu finden. Die übrigen Wünsche von dir werden alle funktionieren, sobald die Parameter text und sortkey eingebunden sind; das habe ich für die nächsten Tage vor. --PM3 22:58, 13. Jul. 2011 (CEST)

/ in EW und NS wird jetzt auch als Fehler erkannt, damit sollte die Prüfung nun vollständig sein. --PM3 23:10, 13. Jul. 2011 (CEST)

Danke für eure Arbeit, seh ich das richtig, dass die Angabe simple=y die Angabe der Koordinaten in Dezimaldarstellung erwarten wird? Danke --Richtest 10:36, 15. Jul. 2011 (CEST)

Ja. Zusätzlich können wir eine Vorlage bereitstellen, die die Formate ineinander umrechnet, vgl. Vorlage:LageDMS. Also man gibt dort Grad/Minuten/Sekunden ein, und das Ding schreibt dann ein {{Coordinate|simple=y|...}} mit Dezimalbrüchen in den Artikel. --PM3 15:12, 15. Jul. 2011 (CEST)

Ok, mir gehts um die Koordinateneinbindung in Bahnstreckenboxen, da ist die simple-Form wegen der zu erwartenden Menge nötig, es ist andererseits praktisch, auch °'" formatierte Koordinaten zum Beispiel aus Bahnhofsartikeln kopieren zu können. NS und EW werden dabei als Parameter angegeben und nicht direkt die Vorlage im Quelltext angegeben. Eventuell kann man aber in die Streckenvorlage noch eine Abfrage einbauen, die jeweils die passende Koordinatenvorlage einbindet.. --Richtest 15:21, 15. Jul. 2011 (CEST)

Ich nehme an, ihr habt dazu zwei Parameter für Breitengrad und Längengrad in eurer Vorlage. Dass kann genauso gelöst werden, wie ich oben geschrieben habe, zum Beispiel:

  {{Infobox Bahn-XYZ
  | ...
  | Breitengrad = {{subst:CoordinateDMS|NS=50/48/39/N}}
  | Längengrad = {{subst:CoordinateDMS|EW=6/28/57/E}}
  | ...
  }}

Folgendes würde dann in den Artikel geschrieben:

  | Breitengrad = 50.810833
  | Längengrad = 6.4825

--PM3 16:24, 15. Jul. 2011 (CEST)

Stimmt, danke. --Richtest 16:31, 15. Jul. 2011 (CEST)

Die neue Vorlage dafür heißt nun {{XDMS}}, anwendbar so:

  {{Infobox Bahn-XYZ
  | ...
  | Breitengrad = {{subst:XDMS|50/48/39/N}}
  | Längengrad = {{subst:XDMS|6/28/57/E}}
  | ...
  }}

--PM3 16:56, 19. Jul. 2011 (CEST)

Testergebnisse

• Ich habe mal die Performance nachgemessen.
• Probleme mit Bing konnte ich nicht nachvollziehen.

lg --Herzi Pinki 22:07, 14. Jul. 2011 (CEST)

Danke. Die Daten sind noch etwas verzerrt, weil Lage und PM3/Coordinate auch den Inhalt von region prüfen. Coordinate prüft nur, ob region vorhanden ist, das spart Zeit. Ich teste das gleich nochmal mit mehr Koordinaten und unter gleichen Bedingungen, d.h. ich baue d←en region-Syntaxtest aus. --PM3 22:51, 14. Jul. 2011 (CEST)

Es braucht mE nicht mehr Koordinaten, das Verhalten dürfte linear sein, bis an die Parserlimits gestoßen wird. Du kannst aber gerne meine Messflles modifizieren und eigene Messwerte eintragen (neue spalte). --Herzi Pinki 23:08, 14. Jul. 2011 (CEST)

Danke, Herzi Pinki, endlich mal Fakten! Ich habe die Präprozessor-Daten hinzugefügt und die Formatierung aufgehübscht. Hat schon jemand eine Tendenz von Bergis Zwischenstand? --Spischot 23:13, 14. Jul. 2011 (CEST)

Hab jetzt mal mit timeit wget auf der Kommandozeile gemessen und komme auf etwas andere Zeiten. Die region-Prüfung in Lage und PM3/Coordinate hatte ich vorher abgeschaltet, zur besseren Vergleichbarkeit (bleibt b.a.w. auch abgeschaltet). --PM3 01:03, 15. Jul. 2011 (CEST)

Umsetzung

Entwurf für die neue Vorlagenstruktur (Einbindungshierarchie):

• {{Coordinate}} ← Code aus Benutzer:PM3/Coordinate + VNR-Anpassungen
  • {{CoordinateFull}} ← {{Coordinate}}
    • bestehende Untervorlagen CoordinateXXX
  • {{CoordinateSimple}} ← {{Lage}}
    • {{CoordinateParamError}} {{CoordinateError}} ← {{Lage/Fehler}}
    • ggf. weitere Untervorlagen für weitere Features, insbes. text und sortkey

Das Ganze wäre in umgekehrter Reihenfolge anzulegen und stufenweise zu testen, bevor als Letztes die Vorlage:Coordinate ausgetauscht wird. --PM3 17:14, 15. Jul. 2011 (CEST)

Außerdem, sehr wichtig:

• {{CoordinateSimpleDMS}} ← {{LageDMS}}

Das Ding muss aber noch verbessert werden, da kümmere ich mich in den nächsten Tagen drum. --PM3 19:46, 15. Jul. 2011 (CEST)

• move bei Coordinate müsste doch reichen, danach gibt es einen redirect und der wird bald mit deinem wrapper gefüllt?
• was meinst du mit importupload?
• Vorlage:Coordinate/Doku muss angepasst werden, aber das ist nicht kritisch.
• was hältst du davon statt {{CoordinateParamError}} oder {{Lage/Fehler}} die vorhandene {{CoordinateMSG}} zu verwenden. Fehler treten nicht in der Menge auf, dass die Ausgabe von Fehlermeldungen ein Performanceproblem darstellen würde. Wäre eine Vorlage und eine Redundanz weniger.

--Herzi Pinki 21:10, 15. Jul. 2011 (CEST)

Wikipedia:Importwünsche/Importupload, bei copy notwendig um die Bearbeitungshistorie zu übernehmen. Beim move überflüssig. Move ist im .o.g Fall aber ungut, weil dann bis {{Coordinate}} ← Code aus Benutzer:PM3/Coordinate + VNR-Anpassungen erst mal nix mehr geht. --Spischot 21:34, 15. Jul. 2011 (CEST)

habe gerade eine Testvorlage verschoben, der Aufruf über WL hat klaglos funktioniert. Wo siehst du die Probleme? Coordinate leitet weiter und der wrapper kann gestestet werden (solange er nicht Coordinate heißt). --Herzi Pinki 23:02, 15. Jul. 2011 (CEST)

Hast ja recht. Ich habe nur versucht, mich in PM3s Ideen hineinzuversetzen, aber mit redirect sehe ich (entgegen meiner etwas unüberlegten Behauptung) keine Probleme. --Spischot 23:12, 15. Jul. 2011 (CEST)

Dass Vorlageneinbindung per Redirect geht, wusste ich noch nicht. Und ihr zwei garantiert mir, dass das 100%ig safe ist? Wie oft die Vorlage eingebunden ist, wisst ihr ja. Und dass auch keine unvorhergesehenen Probleme beim Austausch von {{Coordinate}} auftreten und nachher nicht irgendein Admin vor den Problem steht, nicht auf "zurücksetzen" drücken zu können?

Wass passiert denn mit dem Link auf die Vorlagen-Doku bei einer Verschiebung? Der geht ja relativ zum Seitenname. Muss man die dann auch verschieben? Möglichst zeitgleich? Und nachher wieder zurückverschieben, möglichst zeitgleich mit dem Überschreiben des Redirect? --PM3 23:58, 15. Jul. 2011 (CEST)

die doku gar nicht verschieben, redirect von Vorlage:CoordinateFull/Doku auf Vorlage:Coordinate/Doku einrichten (für die anderen subfiles detto), erst danach die Vorlage verschieben. Damit findet CoordinateFull auch seine Doku, die dort bleiben kann, wo sie immer war. Man muss zwar vorsichtig sein, ja bitte!, aber ich denke, das aufwändige importupload kannst du dir sparen. (Die doku ist auch relativ wurst, tut keinem weh, wenn die mal falsch verlinkt sein sollte.) --Herzi Pinki 00:10, 16. Jul. 2011 (CEST)

Ok, auf deine Verantwortung. Dann mache ich das bei den anderen beiden Vorlagen auch per Verschieben. Das gibt dann vorübergehend Chaos mit der Doku, bis {{Lage}} überall ausgetauscht ist, aber egal. --PM3 00:52, 16. Jul. 2011 (CEST)

Vor dem finalen Austauschen von {{Coordinate}} würde ich gerne alles noch einmal durchtesten. Wenn wir das mit Move machen, wäre {{Coordinate}} eine zeitlang inexistent; das geht nicht.

{{CoordinateMSG}} passt nicht, weil ich andere Fehlermeldungen brauche, teils aus Performancegründen (zusammengefasste Fehlerklassen) und teils wegen eingeschränktem Funktionsumfang (kein DMS, unerlaubte Parameter). Davon abgesehen hat {{CoordinateMSG}} so viel interne Redundanzen, dass die eine zusätzliche nicht mehr ins Gewicht fällt.

Meine Liste oben zeigt nur die neue Vorlagenstruktur, weil ich die nicht alleine entscheiden möchte. Meine Todo-Liste für die Umstellung ist wesentlich umfangreicher. --PM3 22:00, 15. Jul. 2011 (CEST)

darum auch die Anmerkung mit {{CoordinateParamError}}, {{Lage/Fehler}}, {{CoordinateMSG}}: du hast vielleicht Angst, deine superschnelle simple=y Vorlage über so eine Vorlage wieder auszubremsen. Aber ich kenne noch keine Messung, die diese Vorlage als Performanceleak herausgefunden hat. --Herzi Pinki 23:02, 15. Jul. 2011 (CEST)

Die Performance der Fehlervorlage spielt keine Rolle, weil sie im Normalfall nicht expandiert wird. --PM3 23:53, 15. Jul. 2011 (CEST)

Ich verkürze {{CoordinateParamError}} zu {{CoordinatePE}}, das sollte 42 Bytes pro Einbindung einsparen. Was {{CoordinateMSG}} angeht: Machbar wäre, der Vorlage einen zusätzlichen Parameter simple=y zu spendieren, sodass sie sich bei bestimmten Fehlercodes anders verhält. Dann könnte ich die Fehlerbehandlung dort zumindest an einer Stelle zusammenfassen. {{CoordinateParamError}} würde aber trotzdem bleiben, um Übergabeparameter zu übersetzen. Damit kann ich auch nochmal ca. 50 Bytes pro Einbindung einsparen (wertvoller Präprozessor-Speicher). --PM3 06:14, 16. Jul. 2011 (CEST) bringt netto alles keinen Vorteil --PM3 17:59, 16. Jul. 2011 (CEST)

 Ok eledigt:

• simple-Parameter in {{Coordinate}} eingebaut und dokumentiert
• {{Lage}} überall durch {{Coordinate|simple=y}} ersetzt
• neue Vorlagen {{DMS2Grad}} {{XDMS}} und {{CoordinateSimpleDMS}} zur Übersetzung von DMS-Koordinaten
• LA auf Vorlage:LageDMS

Vielen Dank auch an Herzi Pinki für die konstruktiven Verbesserungsvorschläge. Das mit dem Zusammenführen von {{CoordinateMSG}} kam leider nicht in Frage, weil es in jedem Fall Performance gekostet hätte. --PM3 01:35, 18. Jul. 2011 (CEST)

Gerne, und alle Achtung für die schnelle und saubere Umsetzung

allerdings widersprichst du dir (Die Performance der Fehlervorlage spielt keine Rolle, weil sie im Normalfall nicht expandiert wird.).

obiges waren keine Vorschläge, sondern Anforderungen:

• in vielen langen Listen stehen Koordinaten im Format DMS, um allgemein nützlich zu sein, sollte also auch der Wert text=DMS unterstützt werden. etwa Liste von Vulkanen in Bolivien
• es gibt auch rein textuelle Koordinaten, die auf die Vorlage umgestellt werden können sollten. etwa Liste der Segelfluggelände in Deutschland (da hat schon jemand vor der Performance resigniert).

Es ist schade (weil es weiterer Sonderlösungen bedarf), dass text=DMS von simple nicht unterstützt wird. Die Konvertierung der Dezimalwerte auf DMS kostet Performance, aber das mag doch jede Liste selbst entscheiden. Im Fall, dass nur Text ausgegeben wird, schlägt dieser Performancepenalty ja nicht zu.

• {{Coordinate|text=DMS|simple=y|NS=47|EW=16|region=AT|type=landmark|name=irgendwo}} erzeugt 47° 0′ 0″ N, 16° 0′ 0″ O und das ist eine Katastrophe, da
  • alle Stellen mit text=DMS dahingehend überarbeitet werden müssen.
  • der sich anbietende Workaround {{Coordinate|text=47° N 15°|simple=y|NS=47|EW=16|region=AT|type=landmark|name=irgendwo}} erzeugt 47° N 15° O (der Fehler ist Absicht),
  • genau jene Redundanzen zurückbringt, die als eines der ganz wesentlichen Ziele der Umstellung der ehemaligen Vorlage:Koordinate Text auf Coordinate entfernt worden sind
  • damit wieder eine Latte uneinheitlicher Formatierungen hervorbringt (welches Zeichen für Minuten? ', ´ oder ′).
• nach der gleichen Logik ist natürlich auch text=/ zu unterstützen. Zumindest darf im text nicht / als Ausgabetext stehen bleiben, sondern sollte als DMS interpretiert werden.
• gleiches gilt für text=DM

Und dann gibt es noch jede Menge direkt links auf den geohack, die sollten auch durch Coordinate ersetzt werden. (http://toolserver.org/~geohack/geohack.php, z.B. Wikipedia:WikiProjekt Bremen/WLM2011/Liste Bremen/Östliche Vorstadt, leider sind da alle über Coordinate indirekt eingebundenen auch dabei. - aber vielleicht gibt es ja eine zielgenauere Abfrage).

lg --Herzi Pinki 09:07, 18. Jul. 2011 (CEST)

Lieber Advocatus Diaboli,

• Anforderugen in Sachen Funktionsumfang legen wir nach meinem Verständnis von Wikipedia-Arbeit gemeinsam fest, im Konsens und vor allem auf Grundlage der Wünsche von den Listenautoren, die das Ding einsetzen. Einzelne Leute können dazu Vorschläge und Meinungen und Hinweise beisteuern. (Jetzt bitte nicht mit dem alten Meinungsbild drohen: das hatte das Problem mit der Performance nicht berücksichtigt.)
• Deinen Seitenhieb von wegen: ich widerspäche mir selbst - und das als Einschränkung der Anerkennung meiner Arbeit - finde ich schade. Ist sowas nötig? Oben ging es um die Performance der {{CoordinateMSG}} selbst - also wie effizient diese implementiert ist - und die spielt in der Tat keine Rolle. Allerdings müssten für deren Einbindung, wie ich inzwischen festgestellt habe, zusätzliche Parameter angegeben werden, und das kostet ebenfalls etwas Performance - auch wenn sie nicht aufgerufen wird.
• Solche Fälle wie die Segelplätze würde ich individuell mit nem Macro-Recorder-Editor erschlagen. Ist eine Sache von 10-15 Minuten, sowas per Editormakro umzustellen.
• text=DMS kann man mit einem einfachen search-and-replace durch text=Lage ersetzen. Man muss eh mit search-and-replace drübergehen, um das simple=y einzubauen bzw. die Vorlage {{CoordinateSimpleDMS}} einzusetzen; da tut ein zweiter Durchlauf auch nicht weh.

Die DMS-Option würde ich auch gerne einbauen, aber ich überblicke noch nicht, was das an Performance und Speicherplatz kostet. Auch wenn es nicht aufgerufen wird, kostet es etwas für die reine Einbindung, siehe oben.

Mit text=DMS und DM alleine ist es ja nicht getan, sonder da kommt noch CH1903 und / und sortkey hinzu, und dann möchtest du als nächstes die Weltkugel haben, und wenn ICON2 drin ist sollte konsistenterweise auch ICON0 und ICON1 gehen. Ich schätze mal, dass das alles zusammengenommen die Performance und den Speicherbedarf (d.h. maximale Koordinatenzahl pro Liste) bereits um 5-10% verschlechtert, wenn es nicht verwendet wird. Wenn wir die Icons weglassen, eher 5 als 10%. Müssen wir uns nun überlegen, ob es das wert ist. Quarz sagt nein; ich denke: ja. --PM3 16:12, 18. Jul. 2011 (CEST)

Woher weißt du? :-) Im Ernst: Es geht den Leuten mit den fetten Listen (die nicht mehr sachgerecht geteilt werden können) um Performance, Performance, Performance. Wenn ich sehe, dass eine Liste mit GeoHack-Link (oder der Urform der {{Lage}} rund 8 Sekunden braucht, bis der Benutzer eine Reaktion am Bildschirm sieht (nicht bis zum Ende des Ladens), unter Verwendung des simple=y-Zweigs von {{Coordinate}} bereits 18 Sekunden, wachsen mir angesichts der Erweiterungswünsche Dackelfalten. Das befeuert meine Neigung, bei den Links zu bleiben. Auf den von mir betreuten Listen kann ich darauf achten, dass die valide sind. --Quarz 16:50, 18. Jul. 2011 (CEST)

8 vs. 18 (vs. 60) Sekunden in der drittgrößten Liste einer der größten Listen der gesamten de.WP, mit 600 Koordinaten. Mit der text=DMS-Erweiterung dürften daraus ca. 18,5 bis 19 Sekunden werden. Schlimm? --PM3 18:16, 18. Jul. 2011 (CEST)

... wobei mir auch nicht klar ist, wo die 4 Sekunden bei der Umstellung von Benutzer:PM3/Coordinate auf die nun identische Vorlage:Coordinate verlorengangen sind. Ich mache mich mal auf die Suche. --PM3 18:29, 18. Jul. 2011 (CEST)

60 s? Damit hatten wir dort nichts zu tun - die Listen, die wegen Totalblockade per Adminanfrage gelöscht werden mussten, waren viel kleiner. Ich bin ja froh um die 18 Sekunden statt ich weiß nicht was. Und wenn DMS tatsächlich einen Effekt im Bereich des Rauschens hat, kann ich dem leicht zustimmen. Nur machen mir die Begehrlichkeiten Sorgen. Es muss klar sein, dass Geschwindigkeit einen Preis hat. Man muss im Zweifel auf Features verzichten. --Quarz 18:46, 18. Jul. 2011 (CEST)

Ich hatte es eben nachgemessen: 62 Sekunden sind es mit {{CoordinateFull}} (der ex-{{Coordinate}}). Nur mal so zum Vergleich.

PM3/Coordinate und Coordinate hab ich auch gerade nochmal verglichen; sind identisch. Der Unterschied zwischen 16-20 Sekunden Ladezeit heute und 14-15 Sekunden vor ein paar Tagen kommt wohl durch aktuell höhere Serverlast. --PM3 18:53, 18. Jul. 2011 (CEST)

So, text-Option ist eingebaut. Wie erwartet liegt der Performance-Verlust in der Größenordnung von ca. 1 ms pro Einbindung, also ca. 0,5 Sekunden für Wikipedia:WikiProjekt Bremen/WLM2011/Liste_Bremen/Mitte. Preprozessor-Speicher kostet es erstaunlicherweise gar keinen.

Alle text-Optionen werden unterstützt, von DMS bis zum Weltkugel-ICON2, mit Ausnahme von /, von dim-abhängigem D(M(S))-Format und von allen weiteren Spezialfeatures, die ich evtl. übersehen habe. sortkey habe ich erst mal außen vor gelassen; das würde auch wieder in ähnlicher Größenordnung Performance kosten.

Das Ganze baut auf den bestehenden Funktionen wie {{Coordinate to DMS}} etc. auf, und die sind elend langsam; text=DMS kostet z.B. 20-25 ms pro Einbindung, d.h. der Zeitbedarf der Vorlage verdoppelt sich damit. Hier dürfte allerdings die neue Bergi-Optimierung eine Verbesserung bringen.

@Herzi Pinki: Kannst du noch die neue Vorlage:CoordinateSimpleText halbsperren? Die übrigen neuen Vorlagen habe ich schon halbsperren lassen. --PM3 04:05, 19. Jul. 2011 (CEST)

sortkey ist jetzt auch drin; Performanceverlust bei Nichtverwendung ist vernachlässigbar, nur ca. 0,5 ms pro Einbindung. Hab auch mal eine Performanceübersicht bei Verwendung der einzelnen Optionen erstellt: Vorlage:Coordinate#Vorlage zu langsam? / eine Seite runterscrollen. --PM3 18:39, 19. Jul. 2011 (CEST)

Habe text=DM(S) nun um Faktor 4 optimiert (nur in Verbindung mit simple=y). Damit ist diese Option nun auch in großen Listen wieder interessant. --PM3 07:02, 20. Jul. 2011 (CEST)

Hallo PM3, danke. Die eine Vorlage habe ich halbgesperrt (und ICON0/1 ergänzt.). --Herzi Pinki 01:02, 21. Jul. 2011 (CEST)

Mainroutine schlank und modularer Aufbau

ausserdem möchte ich bei einem ausgewachsenen programm wie dieser vorlage (die in wikisystax programmieren zu müssen, ist ja wirklich eine leistung, die wäre selbst in COBOL noch effektiver: mein respekt) nochmal an einen grundsatz des objektorientierten programmierens erinnern:

die routine main besteht ausschliesslich aus unterroutinenaufrufen

sie tut also nichts anderes, als die eingabeparameter in weitergegebene parametersätze zusammenzustellen. eine if-anfrage hat in einer hauptroutine eigentlich nichts verloren: imho gehört sowohl die ausgabeerstellung (article output) als auch etwa die sortkey-subroutine und ImDruckVerbergen ausgelagert
dann kann man nämlich

1. ganz speziell nur das aufrufen, was man braucht
   • so braucht die artikelkoordinate und die in einer IB definiv kein nach-geolage-sortieren, der ist für listen
   • auch muss bei einer definition von text explizit kein sort erzeugt werden, weil die tabelle nach dem angegeben text sortieren muss, nicht nach geo-breite oder -länge (die einleitende phrase {{#if:{{{text|}}}|{{#if:{{{sortkey|}}}|{{CoordinateSORT|… ist imho ein denkfehler) - und ist text im fliesstext definiert, brauchts sowieso kein CoordinateSORT
2. viel leichter sowohl fehlersuchen (also prüfwerkzeuge bauen), als auch nur module austauschen, ohne die coordinate selbst neu laden zu müssen

imho ist also CoordinateSimple und CoordinateFull nicht der rechte weg: viel mehr brauchen wir mehr schalter-variablen, die einen schlankeren, angepassteren aufruf ermöglichen (statt der eierlegenden wollmilchsau), etwa:

• mode=IB nur für infobox-implementierungen, dort DMS zu verwenden, sollte sowieso standard sein, also kann man sich alle anderen output-abfragen sparen - oder haben wir eine IB, die das nicht so macht
• oder eben mode=LIST, und dann erfolgt standardmässig ein verschlankter aufruf/ausgabe für listenelemente, was auch mehr einheitlichkeit in die listen bringen würde, gerne auch mode=CELL, wenn die koordinate allein in einer zellenspalte zu stehen kommt (dann und nur dann brauchts ein sortier-feature)
• umgekehrt sollte sich der autor aussuchen dürfen, ob er W-O oder N-S in seiner tabelle sortieren will, wenn er dieses feature nutzen will: dann wäre es aber auch explizit anzugeben, dass CoordinateSORT gewünscht wird (was jetzt, solange es die Vorl:Lage in Listenartikeln gibt, noch aufwärtskompatibel möglich ist)

für jedes neue feature sollten aber mindestens drei andere features, die dann unnötig sind, abgeschalten werden: dazu unterscheidet man zwischen datenvariablen, und schaltervariablen: die routine main kümmert sich ausschlisslich um zweitere (daten sind ihr egal), die subroutinen ausschlisslich um ihren datensatz und die sie betreffenden schalter, egal, ob sie der WP-autor oder main erzeugt - denkt nur daran, wie schnelle komandozeile funtioniert: ein befehl, 3 eingabedaten (wie einen dateipfad, einen text), aber 50 schalter, was jetzt genau getan werden soll damit --W!B: 20:10, 16. Jul. 2011 (CEST)

OOP in Wikiepdia-Vorlagen? Das werden wir beide nicht mehr erleben. :)

Die Vorlage wird gerade optimiert → bitte hier weiterlesen: WP:WVW#Vorlage:Coordinate --PM3 01:55, 17. Jul. 2011 (CEST)

ah, ich sehe, genau das meinte ich, gute sache.. ;) --W!B: 09:06, 17. Jul. 2011 (CEST)

Fehlende region-Prüfung in Vorlage:Coordinate

Die Vorlage prüft bislang nur, ob region vorhanden ist, aber nicht, was drinsteht. Vermutlich haben wir jede Menge Artikel mit unerkannten Region-Fehlern.

Ich schlage vor, eine (vorerst) stille Prüfung in Vorlage:Coordinate einzubauen, die diese Fehler in Kategorie:Parameterfehler unter Buchstabe R einsortiert:

 {{#if: {{NAMESPACE}} 
   ||{{#if: {{Info ISO-3166-2:{{{region|}}}}} 
     |[[Kategorie:Parameterfehler|R{{FULLPAGENAME}}]]}} 
 }}

Kostet grob gepeilt 10 ms Performance, ich denke das ist verkraftbar. Vielleicht auch erst mal nur testweise, um zu schauen was es an Fehlern gibt, und um die einmalig abzuarbeiten. --PM3 01:20, 15. Jul. 2011 (CEST)

Damit wirst du laut meiner Glaskugel 647 Fehlermeldungen in 374 Artikeln erhalten. Du willst vermutlich gerne solche Fehler, wie in Liste europäischer Leuchttürme finden, wo BU statt BG für Bulgarien benutzt wurde oder Dampier-Archipel mit AZ-WA. Diese Art von Fehler entdeckte ich aber auf den ersten Blick kaum. Etwas häufiger kommt ein angehängter Bindestrich wie bei FR- in Schlacht bei Montmirail vor. Bei ein paar weiteren ist der region-Paramter mit einem Leerstring versehen.

Der weitaus überwiegende Teil enthält aber mehrere aneinandergereihte Regioncodes, die aber natürlich so als Vorlagenname nicht existieren, wie in Liste der Pässe in der Schweiz (CH-UR/CH-VS), CERN, Neuengland (US-CT/US-NH/US-ME/US-MA/US-RI/US-VT) oder Südamerika (AR/BO/BR/CL/CO/EC/PE/GF/GY/PY/SR/UY/VE).

Die ersten drei Fehlervarianten aus dem ersten Absatz habe ich in einer Liste zusammengestellt (jeder falsche Region-Code wird pro Artikel nur einmal aufgeführt). Vorlagendaten stammen aus dem templatetiger-Scan von 21.6. und die iso-Vorlagennamen von heute:

1. A.S. Création ()
2. Agennix ()
3. Andikythira (GR-A4)
4. Úpa (CZ-HK)
5. Barra do Garças (BRA-MT)
6. Bartlett Lake ()
7. Božena Němcová (CZ-KH)
8. Borgdorfer See ()
9. Dampier-Archipel (AZ-WA)
10. Duke-of-York-Inseln (PG-)
11. Emil Nolde (DK-)
12. Europaradwanderweg R1 (BE-)
13. Europaradwanderweg R1 (DE-)
14. Europaradwanderweg R1 (EE-)
15. Europaradwanderweg R1 (FR-)
16. Europaradwanderweg R1 (NL-)
17. Europaradwanderweg R1 (PL-)
18. Europaradwanderweg R1 (RU-)
19. Goodwin Sands (UK)
20. Guatemala-Stadt (GT-)
21. Isar (AT-TI)
22. Juan de Nova (TF-05)
23. Kythira (GR-A4)
24. Liste der Einschlagkrater der Erde (TD-BET)
25. Liste der Einschlagkrater der Erde (ZA-GT)
26. Liste der Tuamotu-Inseln (PF-TG)
27. Liste europäischer Leuchttürme (BU)
28. Liwa-Oase (AE-ZA)
29. Mangyŏngdae (KP-PYO)
30. Marklo (NL-OI)
31. Martim Vaz (BR-)
32. Nördlichste Orte der Erde (GL-01)
33. Ostseewelle ()
34. Pferdebahn Prag–Lana (CZ-SR)
35. Philadelphia Naval Shipyard ()
36. Primacom ()
37. Prutz (AT-TI)
38. PSI AG ()
39. Rücker AG ()
40. Rjukan (NO-TE)
41. Schlacht bei Montmirail (FR-)
42. Schloss Ratibořice (CZ-KH)
43. Sinan (BA-MO)
44. Solo Kleinmotoren ()
45. Stóragjá (IS-)
46. Storey County (US-)
47. Turracher Höhe (AT-K)
48. Tuvalu (TV-NIU)

Merlissimo 02:43, 15. Jul. 2011 (CEST)

Interessant, danke.

Verstehe ich Deine Antwort richtig: Es gibt Tools, mit denen man bestimmte Fehler bereits raussuchen kann, wenn man weiß, wonach man suchen muss? Oder gibt es bereits ein Tool, das alle Fehler auswirft, und das man irgendwie unter WP:GEO#To-do-Liste bereitstellen könnte? --PM3 03:30, 15. Jul. 2011 (CEST)

Ich bin der Meinung, dass man Fehler auch anders suchen kann, z. B. mit der Vorlagenauswertung (leider keine Life-Daten). Und die Leute können auch einfall auf die Koordinaten klicken und merken ja dann, ob Sie an der richtigen Stelle der Karte raus kommen. Die Performance sollte jedenfalls nicht damit übermäßig belastet werden. --Kolossos 16:32, 15. Jul. 2011 (CEST)

Wie gesagt: 10 Millisekunden pro Einbindung der vollständigen Vorlage:Coordinate. Auf die Kartenposition hat region allerdings keinen Einfluss. Geohack zeigt es nur an, ohne weitere Verwendung; von daher ist es die 10 ms wohl nicht wert. --PM3 17:26, 15. Jul. 2011 (CEST)

@Kolossos Die Liste basiert wie oben beschrieben auf den Daten deiner Vorlagenauswertung.

@PM3 Ich habe einfach mit mysql auf dem TS rumgespielt. Mein bash-Script für die Ausgabe oben:

MYTEMPFILE=`mktemp -t Coordinate.XXXX`
mysql -wBN -hdewiki-p.rrdb -e "SELECT SUBSTRING_INDEX(page_title,':',-1) FROM page WHERE page_namespace=10 AND page_title LIKE 'Info_ISO-3166-2:%'" dewiki_p > ${MYTEMPFILE}
SQL="
CREATE DATABASE IF NOT EXISTS u_%USER%;
USE u_%USER%;

CREATE TEMPORARY TABLE codes (codes VARCHAR(10) PRIMARY KEY);
LOAD DATA LOCAL INFILE '%TEMPFILE%' INTO TABLE codes; 

SELECT CONCAT('# [[',name,']] (',Value,')')
 FROM u_kolossos_tt_p.dewiki
 WHERE tp_name = 'Coordinate' AND entry_name='region'
  AND Value not in (SELECT codes FROM u_merl.codes) AND Value NOT LIKE '%/%'
 GROUP BY name, Value
"
SQL=`echo "$SQL" | sed "s/%USER%/$USER/g"`
SQL=`echo "$SQL" | sed "s|%TEMPFILE%|${MYTEMPFILE}|g"`
mysql -wBN -hsql -e "$SQL"

Merlissimo 20:27, 15. Jul. 2011 (CEST)

Aber hallo, ganz neue Fehler

• Fehler in der region von Artikelkoordinaten werden über http://de.wikipedia.org/wiki/Spezial:Linkliste/Vorlage:Info_ISO-3166-2:%3F%3F gefunden, für text koordinaten ist diese Prüfung nicht eingeschaltet worden, aber wie man an der obigen Liste sieht, macht Prüfung Sinn. Gibt es keine Prüfung, addieren sich die Fehler. Mit folgender Artikel/Text-Koordinate Beispiel 47° 0′ 0″ N, 16° 0′ 0″ O4716 sollte hier aufscheinen.
• Also braucht es hier offensichtlich weitere Prüfungen. Wie kann man die obige Prüfung, am einfachsten zentral unter Kategorie:Parameterfehler einbinden (ohne manuelle Aufbereitung)?
• Fehlerprüfung oben ist zu einfach,
  • region kann auch durch / getrennt mehrere Werte annehmen und dann funktioniert obiger algorithmus nicht. DE-BY/DE-BW ist ein gültiger Wert für region.
  • region kann auch auf eine nicht existente Region verweisen, entweder weil die ISO Codes im Land neu organisiert worden sind und alte Codes entfallen oder weil für neue ISO Codes noch kein neues Info_ISO-3166-2: angelegt wurde (beides kommt öfter vor als man denkt). Daher sollten solche Unstimmigkeiten nicht zu einer roten Fehlermeldung im Artikel führen. Sondern über irgendwelche Nebenschauplätze abgehandelt werden. Geht maximal im BNR, aber die meisten User sind wohl überfordert, wenn sie für das Wegkriegen einer Fehlermeldung die entsprechende ISO-3166-2 erstellen müssten. Zum Glück gibt es aber inzwischen die meisten codes (Stand aber vor einem Jahr, danach sind mir keine Aktivitäten des Nachziehens von offiziellen ISO-Code Änderungen untergekommen)
• der obige Code ruft {{Info ISO-3166-2:AT}} auf, auch wenn dabei kein Code erzeugt wird, da kein Parameter übergeben wird, erhöht der Aufruf oben den Preprocessor node count um den Wert 19. Ist vermutlich verkraftbar. #ifexist ist wohl auch keine Lösung, da teuer.
• die obige Prüfung wird nicht im ANR wirksam. Meinst du das mit still? Wenn schon Prüfung, dann würde ich mir wünschen, dass auch im ANR geprüft wird, aber existierende Artikel nicht gerötet werden. Rote Fehlermeldungen in Artikel helfen nicht einmal bei der Neuanlage immer, aber bevor man was rot macht, muss man die Gründe für den Fehler in Altartikeln bereinigen.

@Merlissimo u. Fehlermeldungen

• eine leere Coordinate ohne region sollte nicht als Fehler betrachtet werden, Borgdorfer See ist aber aus anderen Gründen durchaus wertvoll gefunden zu werden. Spätestens beim Einhängen eines Bildes hätte man dort seine Wunder erlebt.
• bei den Unternehmen oben habe ich lange gesucht, aber keinen Grund für eine Beschwerde gefunden. Ev. falsch positiv?

lg --Herzi Pinki 20:34, 15. Jul. 2011 (CEST)

Ich hatte oben geschrieben Vorlagendaten stammen aus dem templatetiger-Scan von 21.6. Dieser Edit war erst danach. Ich hatte das hier ja nur durch Zufall gesehen. Die paar Scriptzeilen für die Query waren in zwei Minuten geschrieben (die Erstversion war natürlich für andere etwas unleserlicher als die oben gepostete). Ansonsten habt ihr mit Kolossos den Experten für diese Vorlagenauswertung schlechthin. Er kennt sich sowohl mit der Koordinatenvorlage und natürlich auch mit seinem eigenen templatetiger-DB aus. AND Value != '' würde die Leerwert ignorieren. Merlissimo 20:52, 15. Jul. 2011 (CEST)

Ach, entschuldige, wo war ich schon wieder, ich dachte, der 21. 6. war doch gerade eben. --Herzi Pinki 20:58, 15. Jul. 2011 (CEST)

Die obige Prüfung wird nur im ANR wirksam (doppelter || nach dem #if). Die ISO-3166-2-Vorlage wird aufgerufen, das kostet die erwähnten 10 ms.

Mit still meine ich, dass keine Fehlermeldung im Artikel erscheint, sodass wir erst mal die Lage peilen könnten und die Leute nicht zu sehr überfallen. Aber da diese Region-Angabe in Vorlage:Coordinate bislang wohl nirgendwo ausgewertet wird, ist das vielleicht alles nicht so wichtig. --PM3 22:06, 15. Jul. 2011 (CEST)

Hier ist ein weiterer Grund, die region-Prüfung einzubauen: Wikipedia:WikiProjekt Kategorien/Diskussionen/2011/Juli/16#Kategorie:Geographische Lage gewünscht (nach Region-Name) --PM3 22:23, 16. Jul. 2011 (CEST)

Das Problem mit meheren, /-getrennten ISO-Codes ließe sich lösen, indem wir nur den ersten davon prüfen - besser als nichts. Also so:

 {{#if: {{NAMESPACE}} 
   ||{{#if: {{Info ISO-3166-2:{{#titleparts:{{{region|}}}|1|1}}}} 
     |[[Kategorie:Parameterfehler|R{{FULLPAGENAME}}]]}} 
 }}

--PM3 02:07, 17. Jul. 2011 (CEST)

Koordinate Weltkugel: noch ein wunsch als erinnerung, wenn wir dabei sind

anlass hinter der Koordinate Weltkugel war übrigens:

1. dass in spalten das icon möglichst klein ist
2. die fehlermeldung (lagewunsch) dann aber die spalten enorm aufbläht

erschünscht wären also eine "stille" fehlermeldung, weil in listen fehlende koordinaten nicht für alle sichtbar sein brauchen: bringt sicher auch performance, den lagewunsch nicht erzeugen zu müssen (und der tabellenparser des browsers muss dann NACH erzeugen aller koordinaten die spalte erst recht wieder anpassen, und massig hidden-text herausrechnen: involviert ist also nicht nur die WP-serverleistung und die internet-datenrate, sondern auch die örtliche CPU & Grafikprozessor beim leser) vielleicht geht das dann gleich in einem, beim code-update, damit wir den zweiten fork auch noch gleich loswerden --W!B: 19:08, 16. Jul. 2011 (CEST)

Klingt sinnvoll; Einbau ist trivial. Zum Beispiel: neuer Parameter quiet=yes, dann in Vorlage:Coordinate an passender Stelle einfügen:

|quiet={{{quiet|}}}

und am Anfang von Vorlage:CoordinateNO:

{{#if:{{{text|}}} |{{#ifeq:{{{quiet|}}}|yes||<span id="{{#if:{{{name|}}}|{{anchorencode:{{{name}}}}}|text_coordinates}}" class="coordinates" style="background:#FFC" >Koordinaten fehlen! [[Wikipedia:WikiProjekt Georeferenzierung|Hilf mit.]]</span>}}}}

--PM3 22:59, 16. Jul. 2011 (CEST)

wow, ja! volltreffer - was ist eigentlich schneller, #ifeq oder #switch (also {{#switch:|yes=|default=…) - jedenfalls ist switch besser ausbaubar, falls noch andere werte kommen könnten

bei dieser vorlage gehts sicherlich um promille in der performance, wenn wir mit um die 500 einbindungen kalkulieren (und wie ich die wikifanten kenn, wenn 500 gut klappen, kommt bald einer mit 1500 ;) --W!B: 09:14, 17. Jul. 2011 (CEST)

Der Unterschied zwischen #if und #switch dürfte auch bei 500 Einbindungen noch unterhalb der Nachweisgrenze liegen. --PM3 15:02, 17. Jul. 2011 (CEST)

Andererseits: Wenn Koordinateneinträge gewünscht werden, dann sollte das m.E. auch an den entsprechenden Stellen im Artikel erkennbar sein. Das nur nach Kategorie:Geographische Lage gewünscht anzuwälzen und auf Artikelseite zu verstecken, finde ich kontraproduktiv. --PM3 00:55, 19. Jul. 2011 (CEST)

+1, Full ACK, PM3 --Herzi Pinki 00:45, 21. Jul. 2011 (CEST)

Kategorie:Geographische Lage gewünscht (nach Region-Name)

Zur Info: Diese Kategorie, die ausschließlich ansonsten unerwünschte Kat-Weiterleitungen enthält, wurde zur Löschung vorgeschlagen. Bitte dort mal die Argumente vortragen, ob diese Weiterleitungen grundsätzlich sinnvoll sind. Gibt es z.B. einen Bot, der darin einsortierte Artikel automatisch in die jeweilige Zielkat umsortiert, da solche Artikel ja nicht in der Zielkat angezeigt werden? Werden die Kategorien regelmäßig genutzt und kann man das irgendwo sehen, z.B. Botbeiträge, wo ein Bot die umsortiert hat? Wenn das nicht geschähe, wäre es ja grundsätzlich evtl. sinnvoller, Artikel mit falschem Parameter einfach in einer Wartungskat zur Umsortierung zu listen. Vielleicht kann jemand, der eine eventuelle Diskussion zur Einführung der Katweiterleitungen kennt, mal was in der LD dazu sagen. Außerhalb dieser Katweiterleitungen existieren übrigens keine weiteren, die werden nämlich sonst alle nach SLA automatisch gelöscht. Deshalb wäre mal eine gute Begründung hierfür sinnvoll. Ich hatte bereits selber mal überlegt, auf diese Kat einen LA zu stellen, hab es aber dann erst mal so gelassen, da ich davon ausgehe, dass ihr euch die Sache bei deren Einführung im Dezember 2008 gut überlegt habt. --Geitost 19:56, 16. Jul. 2011 (CEST)

Ich bilde mir ein, die Implementierung einigermaßen verstanden zu haben, aber deine Vermutungen (Weiterleitung, Bot, umsortieren, Zielkat, ...) ergeben für mich keinen Sinn. (Der Löschantrag übrigens ebensowenig). --Spischot 20:21, 16. Jul. 2011 (CEST)

Wenn man Artikel in Kat-WL einsortiert, werden diese nicht in der Zielkat angezeigt. Das ist einfach so. Das heißt, dass sie dort niemand finden kann. Und wer auf der WL landet, landet in der Zielkat und sieht auch nicht die Artikel in der WL. Dazu müsste man dann die WL erst mal zurückverfolgen. Oder halt irgendwie anschließend immer die Artikel in die Zielkat umsortieren, ob nun per Hand oder per Bot, spielt dabei erst mal keine Rolle. Und die Oberkat ist die einzige sinnvolle Möglichkeit, die Artikel einigermaßen komfortabel finden zu können, um sie dann umzusortieren. Man kann natürlich auch gleich die Artikel geodatieren stattdessen, dann bräuchten sie nicht mehr in die Zielkat. ;-)

Die Frage ist ja nun: Was passiert denn nun mit den Artikeln in den Kat-WL? Gibt es einen Bot, der darauf angesetzt wird oder wie werden die Artikel in diesen Kat-WL gefunden, um sie dann geodatieren zu können? Solange unklar bleibt, was mit solchen Artikeln passiert, macht natürlich auch ein solcher LA Sinn. --Geitost 02:29, 17. Jul. 2011 (CEST)

Danke für deine Erklärung, ich verstehe nun was du willst. Es gibt keine Artikel in den WL-KAts und es gibt keinen Bot. Für alles weitere sind ja jetzt genügend Spezialisten in der LD versammelt. --Spischot 10:44, 17. Jul. 2011 (CEST)

eigener ISO-Code, aber keine Wartungskategorie

Die folgenden Gebiete haben einen eigenen ISO-3166-1-Code, der teils auch mit {{Coordinate}} verwendet wird, aber es existieren keine Wartungskategorien unter Kategorie:Geographische Lage gewünscht (nach Region-Code):

• Åland Inseln
• Amerikanisch Samoa
• Anguilla
• Bouvetinsel
• Britische Jungferninseln
• Britische Territorien im Indischen Ozean
• Cookinseln
• Französisch Guiana
• Französisch Polynesien
• Französische Südgebiete
• Guadeloupe
• Guam
• Heard Insel und McDonald Inseln
• Kaimaninseln
• Kokosinseln
• Marshallinseln
• Martinique
• Mayotte
• Montserrat
• Nauru
• Niederländische Antillen
• Niue
• Nördliche Marianen
• Norfolk Insel
• Pitcairn
• Puerto Rico
• Réunion
• Saint Pierre und Miquelon
• Samoa
• Seychellen
• St. Lucia
• Südgeorgien und die Südlichen Sandwichinseln
• Svalbard und Jan Mayen
• Swasiland
• Tokelau
• United States Minor Outlying Islands
• Wallis und Futuna
• Weihnachtsinsel

Ist das Absicht? --PM3 01:50, 17. Jul. 2011 (CEST)

Viele davon dürften Unterkats sein und bei Verwendung einfach in die Landesoberkat einsortiert werden, wie das immer ist, wenn die Unterkat fehlt. Das sollte also kein Problem sein. So z.B. bei den Gebieten von Frankreich, die sich irgendwo in Übersee befinden, die dann in der französischen Kat landen; auch die Niederlande und Großbritannien dürfte das betreffen bzw. die USA. Siehe auch deren länderspezifische ISO-Übersichten, wo es zu den wenigsten Überseegebieten Unterkats gibt. Die haben dann im Normalfall 2 mögliche ISO-Codes, mit und ohne das Länderkürzel davor. Svalbard gehört wohl zu Norwegen usw. Recht viele Inselgebiete deswegen. Wenn man die abzieht, was bleibt dann noch übrig von der Liste? --Geitost 02:20, 17. Jul. 2011 (CEST)

Was du beschreibst, ist die Ausnahme; die allermeisten dieser ISO-Codes sind in Verwendung. Zum Beispiel in Amerikanisch-Samoa, Anguilla, Bouvetinsel, Britische Jungferninseln, Britisches Territorium im Indischen Ozean, Cookinseln, Guadeloupe, Guam, Heard und McDonaldinseln. Das ist jetzt nur Buchstabe A-H, weiter habe ich nicht geschaut. --PM3 02:31, 17. Jul. 2011 (CEST)

Koordinatenimport von anderen Wikis

Wird sowas eigentlich schon gemacht? Ich habe gerade mal aus Spaß geschaut, wieviele plwiki Artikel die Koordynaty-Vorlage enthalten, der dewiki aber nicht (sind knapp 1200). Ist jemand an solchen Listen interessiert? Merlissimo 01:06, 19. Jul. 2011 (CEST)

Direktimport geht? Ich suche bisher alles selber raus und trage dann haendisch ein. Ich versuche alle Koordinaten selber zu finden, falls ich nicht fuendig werde, suche ich in anderen wikis. Tja, wenn das automatisiert werden koennte, ich bin dabei! Solange AWB mitmacht. :) --Hedwig in Washington (Post?)•B 08:18, 19. Jul. 2011 (CEST)

Hoffentlich werden die Koordinaten, bevor sie hier eingesetzt werden, noch einmal geprüft und nicht einfach nur übernommen. Die Angaben liegen manchmal katastrophal daneben, z.B. bei pl:Chartum über 100 km, immerhin eine eigentlich gut zu lokalisierende Hauptstadt. Das betrifft natürlich nicht nur die polnische WP. NNW 09:21, 19. Jul. 2011 (CEST)

Dispenser stellt doch so eine Liste wöchentlich bereit (WP:GEO#Artikel ohne Koordinaten, [10])? --Meleager 10:40, 19. Jul. 2011 (CEST)

Das Tool von Dispenser deckt aber nur die Fälle ab, wo bereits ein Lagewunsch auf dewiki gesetzt ist. Ich meinte vorhandene Artikelkoordinaten, aber überhaupt keine Koordinatenvorlage auf dewiki. Außerdem sprach ich von Listen und nicht von einer automatischen Übernahme in die Artikel. Merlissimo 11:36, 19. Jul. 2011 (CEST)

Das hatte ich auch so verstanden. Nur zeigt die Erfahrung, dass Koordinaten, soweit irgendwo vorhanden, gerne ungesehen übernommen werden. Mein Hinweis richtete sich also nicht an dich, sondern an diejenigen, die mit dieser Liste arbeiten wollen. NNW 11:44, 19. Jul. 2011 (CEST)

Deswegen würde ich das ja gerne erst einmal hier im Projekt ausprobieren wollen, bevor ich mir überlege, ob ich das später auch an die Portale verteilen kann. Merlissimo 12:01, 19. Jul. 2011 (CEST)

Ich habe Wikipedia:WikiProjekt Georeferenzierung/Referenzierte Objekte in anderen Wikipedias erstellt. Falls das angenommen wird müsse natürlich noch Erklärungstexte usw ergänzt werden. Aber auf die schnelle als Diskussionsgrundlage reicht das imo aus.

Also das sind fremdsprachige Artikel mit Artikelkoordinaten (also nicht im Fließtext) und auf dewiki ganz ohne Koordinaten (also weder Artikel noch Fließtext).

Um also einen Artikel langfristig aus der Liste zu entfernen muss man entwerder auf dewiki eine Koordinate einfügen (Fließtext reicht aus) oder die falschen Interwiki korrigieren.

Als Dritten bleibt noch der Fall, dass aufgrund anderer Anforderungen der dewiki-Artikel nicht für eine Koordinate geeignet ist. Solche Artikel müsste man irgendwo vermerken, damit es bei der nächsten Aktualisierung nicht wieder auftaucht. Dazu könnte man z.B. eine Unterseite analog zu Wikipedia:WikiProjekt_Interwikilinks/Commonslinks/Ignorieren erstellen auf denen man zu ignorierende Artikel verlinken kann. Aber vielleicht schaut ihr erst einmal, ob überhaupt jemand so eine Liste nutzen möchte. Merlissimo 13:40, 19. Jul. 2011 (CEST)

Wie wäre es mit einer Kennzeichnung automatisch importierter Koordinaten als "noch zu prüfen"?

{{Coordinate|NS=34.5657|EW=12.345|...|status=unchecked}}

→ Einordnung in Kategorie:Parameterfehler unter Nr. 0 (oder in eine neue Wartungskategorie), und nach Prüfung löscht man das status=unchecked raus. --PM3 14:31, 19. Jul. 2011 (CEST)

FYI: Ich bin auch nicht von stumpfem kopieren der Daten ausgegangen. Aber eine Liste, die die Arbeit vereinfacht ist schon nicht uebel. Z. Zt. erstelle ich mit CatScan eine Liste, die ich in Excel "reinige" und dann von Hand(!) mit AWB nach div. Regeln abarbeite. Bin gerade bei Unternehmen in DE-NI. :) Soweit dazu. Ich finde den Vorschlag von PM3 extrem praktisch. Die Parameterfehler werden ja eh mehrmals taeglich geprueft und bereinigt. --Hedwig in Washington (Post?)•B 16:55, 19. Jul. 2011 (CEST)

Wo Georef?

Kollege Platte hat mich gebeten, in Artikeln ueber

„Bahnstrecken (wo mehr als ein Punkt nötig wäre), Unternehmen oder sonstigen abstrakten Gebilden, die zur besseren Auffindbarkeit in den Ortskategorien untergetaucht sind.“

– Platte in Benutzer Diskussion:Hedwig in Washington#Lagewünsche

keine Koordinaten, bzw. den Lagewunsch einzutragen. Haben wir hier eigentlich eine Art Arbeitsgrundlage, sprich Liste, ueber Lemmata die referenziert werden soll, bzw. keine Koordinate haben sollen? M.E. sollten moeglichst alle Artikel, soweit nicht beweglich :), referenziert werden. Bahnstrecken koennten z.B. Start- und Endziel, sowie besondere Merkmale der Strecke, im Text verlinken. Was denkt Ihr? --Hedwig in Washington (Post?)•B 17:08, 19. Jul. 2011 (CEST)

Wir haben durchaus schon georeferenzierte Bahnstrecken, bei denen der Artikel auf den Start- bzw. Endpunkt verlinkt ist.

Für Unternehmensartikel mit mehreren Standorten haben wir eine eindeutige Zuordnung, nämlich Einordnung nach dem Sitz der Muttergesellschaft (des Konzerns). Nur nach diesem Kriterium wird in Kategorien eingeordnet, und danach lässt sich auch georeferenzieren. Hin und wieder kann man Ausnahmen machen, wenn der Sitz nur ein kleines Büro mit Briefkasten irgendwo ist, aber der bekannte Unternehmensort eine große Fabrik woanders. So einen Fall hatte ich letztens; da hab es der Fabrik zugeordnet.

Etwas gestolpert bin ich über die HiW-Bot-Lagewünsche für verteilte Objekte wie Stadtbefestigung Koblenz. Wo soll man das zuordnen? Die Festung Mainz hab ich auf die Zitadelle als fortbestehendes Hauptbauwerk verlinkt - aber was macht man bei Koblenz? Auf irgendein kleineres Relikt setzen? --PM3 18:58, 19. Jul. 2011 (CEST)

Also bei Bahnstrecken können die einzelnen Betriebsstellen (in der Streckenbox) georeferenziert werden und dann wird die Vorlage All Coordinates eingebunden (Beispiel_ Benutzer:Richtest/Aartalbahn. So ähnlich würde ich das bei der Stadtbefestigung auch machen, damit hat man dann direkt Zugriff auf eine Lagekarte mit allen wichtigen Objekten.. --Richtest 19:11, 19. Jul. 2011 (CEST)

Klar, nur ist das keim Job für das WP:GEO-Projekt, das die Lagewünsche abarbeitet, sondern für die jeweiligen Artikelautoren. Da muss ja überhaupt erst mal eine systematische Liste mit den Einzelteilen erstellt werden. Wenn das direkte Eintragen von Koordinaten nicht möglich ist, sollte sowas m.E. nicht in Kategorie:Geographische Lage gewünscht auftauchen.

Kann man den Lagewunsch-Baustein in so einem Artikel durch einen Vermerk ersetzen, der weitere Bot-Einträge verhindert? Oder genügt es, dein einfach auszukommentieren und mit einem kleinen Kommentar zu versehen? --PM3 19:36, 19. Jul. 2011 (CEST)

Die Eisenbahner diskutieren gerade ueber die Koordinaten in der Streckenbox. Ja, bei solchen Dingen wie der Stadtbefestigung bin ich auch am gruebeln. Schoen waere natuerlich eine Art Datenreihe auf der Karte zu haben, die den Verlauf (in etwa) nachzeichnet.

Auskommentieren reicht aus (solange {{Coord drinne bleibt) Der Bot sucht nach Lagewunsch und Coord, wenn vorhanden, dann SKIP. Kein Problem. Sollte fuer solche Zwecke wie Stadtmauern -ich denke grad an die Chin. Mauer- eine andere Form des Lagewunsches erstellt werden? KatzeinSchwanzbeiss, da sind wir dann wieder bei All Coordinates. Oder?

Ich baue mal eine How-To-Liste mit div. Objekten. --Hedwig in Washington (Post?)•B 03:43, 20. Jul. 2011 (CEST)

Erster Abriss der Liste hier

Ich darf an folgende Diskussionen (2008) erinnern:

• WP:GEO Disku "Koordinaten für Artikel mit "gestreuten" Objekten"
• und insbesondere Disku zu Hochschulen und Unternehmens

Aus diesem Grund haben wir noch manche nicht georeferenzierte Hochschul-Artikel. Gruß, --emha d|b 11:44, 20. Jul. 2011 (CEST)

Liste ergänzt. Soll ich die Liste in die Doku verschieben? Oder sollten wir eine extra Seite einrichten?? --Hedwig in Washington (Post?)•B 22:57, 20. Jul. 2011 (CEST)

Ich denke, die Liste muss noch etwas reifen, bevor sie auf die Userschaft losgelassen werden kann:

• "Gebäude" -> "Bauwerke"
• Artikel punktförmigen oder flächig-zusammenhängenden Einzelobjekten (Haus, Stadion, Kaserne, Kirche, Flughafen, See etc.) sind trivial, ich denke das braucht man nicht einzeln zu erläutern
• Unternehmen und Organisationen kann man schlecht unter "Gebäude" subsummieren; das ist eine eigene Klasse von Objekten, die man Gebäuden zuordnen kann. Das mit den Briefkasten hast du jetzt sehr wörtlich genommen :-)
• dito Veranstaltungen
• wir haben jede Menge Infoboxen mit Koordinatenangabe: Kategorie:Vorlage:mit Koordinate - da gilt natürlich generell, dass die Koordinaten in die Infobox kommen
• "Stadtmauer, Wall - Besondere Punkte können referenziert werden." Nur, wenn man den Artikel entsprechend umschreibt. Oder ist ein besonderer Punkt pro Objekt gemeint?
• Kanäle kann man teilweise via Infobox Fluss erschlagen
• zentrale Punkte / Mittelpunkte müssen nicht die besten Punkte sein. Genau an den zentralen Punkten stehen z.B. oft die Beschriftungen bei OSM, Google etc., daher setze ich meine Links gerne etwas exzentrisch, damit man sich nicht gegenseitig stört, besonders bei kleinen Objekten wie z.B. Dörfern.
• Eisenbahnstrecken werden derzeit - wie gesagt - teils auch via einem der beiden Endpunkte referenziert. Nicht alle haben Streckenboxen.
• Warum bei einem Stausee nicht einen Punkt im See verlinken, der sich in dem der Staumauer zugewandten Teil befindet? Dann hat man beides mit einem Link erschlagen.

Es gibt viele, viele Details, nach denen man sich richten kann, aber da wird auch jeder wieder seinen persönlichen Stil haben. Bei Gebäuden setze ich die Links z.B. selten in die Mitte, sondern meist etwas in Richtung der Zugangsseite; damit hat man gleiche eine zusätzliche Information untergebracht. Oder gestern hatte ich einen Fußballverein, da gab es als Hauptort das lokale Stadion, aber auch noch Nebengebäude und ein paar hundert Meter ein Vereinslokal. Da habe ich den Link ins Stadion, aber nahe des Eingangsbereichs = in Richtung der anderen relevanten Objekte platziert.

Vielleicht erst mal mit einem einfachen Grundregelsatz anfangen, und uns dann Gedanken um die Problemfälle machen?

1. Wenn Infobox verfügbar: per Infobox einbinden.
2. Wenn es eine zusammenhängende Fläche ist: an sinnvoller Stelle innerhalb der Fläche verlinken. Das kann in der Mitte sein, oder auch in einem besonders markanten / relevanten Bereich.
3. Wenn es eine linienartige bzw. langgestreckte Struktur ist: Wenn möglich an einem besonders markanten / relevanten Punkt, z.B. Startpunkt oder einem der beiden Endpunkte eines Wegs, herausragendes Bauwerk einer Stadtmauer etc. Wenn es keinen besonderen Punkt gibt: irgendwo in der Mitte der Strecke verlinken. Wenn sie geschlossen ist: irgendwo auf der Strecke.
4. Objekte, die sich über verschiedene Orte verteilen: Wenn möglich, das Hauptobjekt verlinken, zum Beispiel
   • den Hauptsitz eines Unternehmens oder einer Organisation
   • den bekanntesten/relevantesten Einzelort
   • das Hauptbauwerk von mehreren

   Wenn dies nicht möglich ist, nur die Einzelteile im Text verlinken, nicht den Gesamtartikel.

Damit hätten wir auch einen Anhaltspunkt für Verkehrswege ohne passende Infobox: Die fallen unter Nr. 3. Für Bundesautobahnen und Bundesstraßen gibt es Strecken-Infoboxen, aber wohl noch ohne Koordinaten.

Vielleicht wäre es auch das Beste, bei den Infoboxen anzufangen, die noch keine Koordinatenfelder haben, z.B. {{Infobox Unternehmen}}. Und dann ggf. in Zusammenarbeit mit den Fachbereichen in der jeweiligen Infobox-Doku erklären, wie verlinkt wird. --PM3 01:43, 21. Jul. 2011 (CEST)

Insbesondere Briefkaesten nehme ich sehr woertlich! ;) Ist auch OMA-safe verstaendlich. Ich werde die Liste entspr. deiner Liste oben erweitern / anpassen. Den Einbau in eine Infobox kannst Du doch sicher hier in einem Satz erklaeren? :))) Ich habe mich die letzten Wochen mit der InfoboxNRHP kraeftig verhoben. Das haette ich in einem Jahr nicht geschafft.

Die Liste wollte ich erstmal hier in die Disku verschieben, btw.

OK, werde stricken gehen..... --Hedwig in Washington (Post?)•B 05:53, 21. Jul. 2011 (CEST)

Besser so? --Hedwig in Washington (Post?)•B 07:29, 21. Jul. 2011 (CEST)

ja --PM3 20:44, 22. Jul. 2011 (CEST)

Verschoben. Danke fuer Deine Hilfe! --Hedwig in Washington (Post?)•B 19:12, 24. Jul. 2011 (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! --Hedwig in Washington (Post?)•B 19:12, 24. Jul. 2011 (CEST)

⊙

Das ICON0 von {{Coordinate}} erscheint bei mir nur als ein kleiner, windschiefer Knubbel: ⊙ Formatiere ich es dagegen mit <tt> als monospaced, wird es recht ansehnlich: ⊙. Dass das Ganze system- und CSS-abhängig ist ist mir klar. Trotzdem mal die Frage: Ist das bei euch auch so, dass „⊙“ besser aussieht als „⊙“? Vielleicht wäre es ja einen Versuch wert, das Ding generell mit <tt> zu formatieren. --PM3 03:47, 21. Jul. 2011 (CEST) PS: Screenshot

Kann ich nich betätigen: Unter Win7+FF5 und Win7+IE9 sind beide schön. Unter XP+IE8 und XP+FF5 sind beide kleiner und eckiger, die <tt>-Version schlechter. Bei anderen Browsern und Systemen gibt's bestimmt wieder andere Resultate. Besser Finger weg von solchen "Unterstützungen", die Browser- oder Font-Schwächen übertünchen wollen. --Spischot 06:11, 21. Jul. 2011 (CEST)

Sehen beide nicht so toll aus. Irgendwie unrund. Google Chrome (akt.), auf Vista und auf XP probiert. --Hedwig in Washington (Post?)•B 06:40, 21. Jul. 2011 (CEST)

Auf Win7 mit Opera, Firefox und IE kein Unterschied und beide schön rund. --тнояsтеn ⇔ 17:49, 21. Jul. 2011 (CEST)

Das dürfte von der Schriftgröße (die bei <tt> ein wenig anders sein mag) und lokalen Antialiasing-Fähigkeiten abhängen. Auf meinem Laptop ohne ClearType ist das Pixel in der Mitte eines geradzahlig-pixel-breiten Kreises immer verschoben, mal links oben, mal rechts unten. Dazu kommen noch Probleme, weil das Schriftzeichen aus keinem Standardfont stammt. Ich wäre für rausnehmen :-)

Das Rendering dürfte verschieden genug sein, dass es sich nicht lohnt ein semantisch falsches, den Parser zusätzlich belastendes Tag einzubauen. --✓ ^Bergi 18:36, 21. Jul. 2011 (CEST)

ok, schade --PM3 18:43, 21. Jul. 2011 (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! ----PM3 18:43, 21. Jul. 2011 (CEST)

Keine Koordinate - Störung?

Im Artikel Klauser (Unternehmen) wird keine Koordinate (oben rechts) angezeigt, liegt eine Störung vor? Vor ein paar Tagen ging es noch. --Atamari 10:48, 21. Jul. 2011 (CEST)

Das ist doch der Artikel mit der Zuerich-Koordinate gewesen? Oh, schlechte Erinnerungen..... :) Heftiges Replication lag auf S3 lt Toolserver Koennte das Problem sein. Kolossos?? --Hedwig in Washington (Post?)•B 11:13, 21. Jul. 2011 (CEST)

War ein Backslash zuviel bei den Einzelnachweisen. Habs repariert. --тнояsтеn ⇔ 11:23, 21. Jul. 2011 (CEST)

Danke. (Kleiner Fehler - große Auswirkung). --Atamari 11:28, 21. Jul. 2011 (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! --Atamari 11:28, 21. Jul. 2011 (CEST)

Fehlermeldungen bei fehlenden Parametern

Hallo, im Kontext meiner Überarbeitung der Vorlage:CoordinateFull und der Diskussion zur region-Prüfung: Derzeit werden in der Vorlage:CoordinateMAIN durch die Syntax {{#if:{{IstZahl|0{{{PARAM}}}|R|2}}||{{MSG}} }} mit der vorangestellten 0 keine fehlenden Parameter (pop und elevation) erkannt. CoordinateMSG sieht dafür aber (noch?) Wartungslinks vor. Wurde das mit Absicht rausgenommen, um den Parser von der ineffizienten MSG-Vorlage zu entlasten? Wie soll damit umgegangen werden? --✓ ^Bergi 18:44, 21. Jul. 2011 (CEST)

pop und elevation sind optional; Eintrag in die Wartungskategorie sind nur für falsche Zahlenformate vorgesehen. Also das sieht ok aus. --PM3 19:54, 21. Jul. 2011 (CEST)

Ach, in Vorlage:CoordinateMSG ist ja tatsäch auch Code für fehlendes elevation oder pop drin. Beide waren von Anfang an optional, wurden aber bis zum 29. Juni 2009 als Parameterfehler einsortiert: [11] Wenig sinnvoll - wenn überhaupt, dann hätte man es vom Typ abhängig machen müssen. In der Kat. Parameterfehler wars auch von Anfang an nur als "Fehler in der Höhenangabe / Einwohnerzahl" dokumentiert. [12]

Also das passt schon so, und der Code für fehlendes elevation und pop aus Vorlage:CoordinateMSG kann raus. --PM3 04:29, 22. Jul. 2011 (CEST)

Danke, das werde ich in die neue Vorlage (und die neue Fehlervorlage) einfließen lassen. --✓ ^Bergi 20:43, 23. Jul. 2011 (CEST)

Kategorie:Parameterfehler

Mal eine ganz andere Baustelle: Im Sinne der Neuordnung von Wartungskategorien würde ich gerne die Kategorie:Parameterfehler nach Kategorie:Parameterfehler Koordinateneinbindung (o.ä., sehr gerne mit WP-Präfix auf Kategorie:Wikipedia:Parameterfehler Koordinateneinbindung) verschieben. Das hätte ich auch schon längst getan, wenn Merlissimo nicht gemeint hätte dass davon evtl. Geo-Tools beeinträchtigt werden könnten. Sein Bot käme damit klar. Daher möchte ich noch um Eure Meinung bitten. Zudem suche ich einen Admin, der das in den geschütztzen Vorlagen umsetzen sowie die Kategorieseite mit ihrer beträchtlichen Versionsgeschichte verschieben (reimportieren) kann. --✓ ^Bergi 18:54, 21. Jul. 2011 (CEST)

Wie wäre es mit einem kürzeren Name? z.B. Kategorie:Wikipedia:Coordinate-Parameterfehler. --PM3 23:51, 28. Jul. 2011 (CEST)

Vorlage:Positionskarte

 Info: Ich habe mit Vorlage Diskussion:Positionskarte#Textebene auf Positionskarte hinzufügen einen Vorschlag zur erweiterten/veränderten Verwendung der Positionskarten gemacht. Ich würde mich dort über Feedback aus dem Projekt Georeferenzierung freuen. --Spischot 11:14, 22. Jul. 2011 (CEST)

Weiterer Hinweis: Vorlage Diskussion:Positionskarte#Alternativkarte. --✓ ^Bergi 21:11, 28. Jul. 2011 (CEST)

Default-Koordinatenformat

So, bevor die neue Version von Vorlage:Coordinate in Betrieb gehen wird habe ich noch ein paar Fragen an euch:

• Die Vorlage:Coordinate/Test/Default (wie Vorlage:CoordinateRR DEFAULT, nur effizienter) erzeugt Werte für das Standardausgabeformat (anzuwählen per /) nach Regionscodes. Zurzeit wird nur zwischen Schweiz/Liechtenstein, alles andere und beides gleichzeitig unterschieden. Nachdem aber mittlerweile UTM zur Verfügung steht (und wahrscheinlich auch OSGB36 nicht mehr lange warten muss) möchte ich von euch gerne wissen wann denn mal was ausgegeben werden soll. Wo wird denn was angewandt? Gilt OSGB36 auch in Überseegebieten (mit GB-Isocode)?
• Die andere Frage beträfe die Bezeichnung. Bisher wurde das so gelöst, dass wenn in der Artikelkoordinate ein zweites Format (also CH1903) ausgegeben wurde davor das Kürzel des Formats - mit ausführlichem Tooltip - kam. Derartiges wird vermutlich häufiger nötig werden wenn mehr eher unbekannte Formate zur Verfügung stehen. Wie soll das gelöst werden, sollen wir dafür am besten einen neuen Parameter einführen? Oder gibt es eine bessere Lösung?
  1. Vorlage:Coordinate/Test/Neu
  2. Vorlage:Coordinate/Test/Neu
  3. Vorlage:Coordinate/Test/Neu
  4. Vorlage:Coordinate/Test/Neu
  5. articleVorlage:Coordinate/Test/Neu
  6. articleVorlage:Coordinate/Test/Neu
  7. articleVorlage:Coordinate/Test/Neu

Wie soll also vor allem die automatische Lösung für article aussehen?

• Und noch eins: Gibt man CH1903 immer mit Klammern an, ich habe dies mittlerweile entfernt (2. Beispiel)?
• Sowie: wie findet ihr die UTM-Umsetzung vom Format her, fehlt da ein „m“ für Meter, ein „Nord“ bzw. „Süd“? --✓ ^Bergi 21:51, 28. Jul. 2011 (CEST)