Zum Inhalt springen

Wikipedia Diskussion:WikiProjekt Georeferenzierung

Seiteninhalte werden in anderen Sprachen nicht unterstützt.
aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 11. August 2006 um 16:57 Uhr durch Monsterxxl (Diskussion | Beiträge) (→ISO-Code bei Italien und Frankreich). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Letzter Kommentar: vor 18 Jahren von Arcy in Abschnitt Anfordern von Daten der Landesvermessungsämter

Bevor du eine Frage stellst, solltest du bitte erst im passenden Archiv nachschauen, evtl. gibt es dort bereits eine Antwort.
Die älteren Diskussionen sind dort thematisch sortiert einsehbar.
Bitte hols wieder hervor, wenn was nochmal aufgerollt werden soll.
(Wenns hier zu voll wird, versuche ich das thematisch zu archivieren. Kann auch gern jemand anders machen, aber bitte den Sinn dahinter beibehalten.)

Archiv

Archiv 1: Technisches bezüglich der Paramter und der Ausgabe:

Archiv 2:

Archiv 3:

Archiv 4:




scale

Eine vernünftige automatische Maßstabssteuerung ist bei Vermischung von punkt-, linen- und flächenförmigen Objekten nicht möglich. Ob man ein Berg oder ein Gebirge, Einen Teich, eine Fluss, oder ein Meer angibt ist aus den Attributen nicht erkennbar. Die Darstellung, dass das Scale-Attribut eigentlich nicht gebraucht wird ist nicht richtig. --Langläufer 23:00, 29. Jan 2006 (CET)

it's a wiki. --BLueFiSH ? 03:32, 30. Jan 2006 (CET)
in den projekten will ich aber nicht mal schnell rumfuschen. die diskussion kann man ja nicht mehr nachvollziehen bei der Länge. --Langläufer 08:51, 30. Jan 2006 (CET)
@Langläufer: Wenn ich dich richtig verstehe, meinst du, wir sollten mehr das scale-Attribut einsetzten. Oder meinst du dass das scale-Attribut generell unbrauchbar ist. Bei erstem Fall kann ich nur raten, warte noch ein wenig, z.B. das Attribut type und region wurden auch am Anfang sehr selten benutzt, bis es dann doch jemand eingefügt hat. Bei zweitem Fall, welche andere Lösung schlägst du vor? -- sk 09:25, 30. Jan 2006 (CET)
ich meinte es wird zu selten benutzt. Die Anleitung klang ja auch so, als ob es überflüssig sei. Eine Richtlinie für die passende Maßstabswahl wäre noch gut: Wieviel Umland sollte sichtbar sein? Ich Orientiere mich derzeit an Google-Maps. Bei anderen Anbietern führen die Maßstabsangaben allerding leider zu ganz anderen Ergebnissen. --Langläufer 09:50, 30. Jan 2006 (CET)
Eine Scale-Angabe macht imho nur dann Sinn, wenn sie einen Bezug zur realen welt hat. Dies kann z.B. der Maßstab sein, bei dem ein Objekt bei einer 10 x 10 cm großen Darstellung optimal sichtbar ist. Wahllos undefinierte "massstabslose" Zahlen von 1-10 machen da wenig Sinn. Auch kann man sich dabei nicht grundsätzlich an einem Anbieter orientieren. Arcy 18:10, 30. Jan 2006 (CET)
? Das ist ja wohl keine Frage, sinnlos sollte die Wahl nicht sein! Nehmen wir mal z.B: an wir haben ein Land. Soll der in den Ausschnitt bei Google-Maps passen (so dass man die Stadtteile besser erkennt) oder lieber nur z.B. 1/9 der Bildfläche einnehmen, damit man auch das Umland sieht. Wie ist es dann bei einem Briefkasten (z.B.) ? Da interessiert mich doch wahrscheinlich die Umgebung viel mehr? --Langläufer 19:29, 30. Jan 2006 (CET)
"Die Google Map" gibt es nicht. Eine Google-Map bzw. jede Karte hat eine Größe, z.B. 400x400 Pixel oder 10x10 cm. Nehmen wir mal an, ein Objekt muß innerhalb eines Kartenrahmens von 400x400 Pixel darstellbar sein. Der Maßstab (scale) bei dem dieses Objekt noch vollständig sichtbar ist ergibt sich +/- automatisch daraus. Dazu packt man noch eine Portion gesunden Menschenverstand und eine Prise Geschmack und fertig ist die Massstabsangabe bzw. die Scaleangabe. Dann klappts auch mit dem Briefkasten. Arcy 16:14, 31. Jan 2006 (CET)
Und da sind die Probleme! 1. Wie groß (wie viele Pixel) ist die Karte wirklich? (Google, Map...) 2. Wie groß ist ein Pixel? - das hängt von der Auflösung des Monitors ab meist 96dpi). Meine ursprüngliche Frage war ja, ob man den guten Geschmack gesunden Menschenverstand ein wenig eingrenzen kann. Davon nehme ich erstmal Abstand - solange die technischen Fragen noch nicht geklärt sind.
Es ist imho weniger eine technische Frage (Dreisatz) sondern Frage der Normsetzung und der Praktikabilität. Ansonsten ist eine 10x10 cm große Karte über Google-Maps genauso groß wie eine 10x10 cm große Karte im Atlas auf Papier bei gleichem Maßßstab und gleichem Ausschnitt "gleich" groß. Arcy 17:14, 31. Jan 2006 (CET)
Der gleiche Maßstab ist nur gewährleistest, wenn immer schön die Bildauflösung mitgeführt und angepasst wird. Dazu muss der Browser die Bildschirmauflösung (dpi) kennen (kann man bei Mozilla einstellen, bei IE nicht). Ist aber auch egal, für den Ausschnitt ist die Größe (pixel) und nicht der Auflösung (dpi) entscheidend. --Langläufer 17:30, 31. Jan 2006 (CET)
Ohne scale-Angabe kommt man nicht aus, weil in der type-Angabe eben nur ein typischer Maßstab definiert ist. Ich prüfe einen scale-Wert mit Google Maps und Mapquest, damit habe ich die besten Erfahrungen gemacht. Ich kenne aus früheren Diskussionen die Meinung Einzelner, dass man scale nicht benötigt, aber eine vernünftige Alternative haben die nicht nennen können. -- Godewind 19:59, 30. Jan 2006 (CET)
Die Scale-Angabe ist nicht nachnutzbar: Sie ist immer nur für einen einzigen Dienst richtig und auch das nur, wenn dieser den Bildausschnitt beibehält. Der bevorzugte Dienst scheint zurzeit Google Maps zu sein. Ich zitiere gerne meinen Alternativvorschlag aus Archiv1: "Artikel werden mit Ausdehnung als Kreisradius oder als Nord-Süd und West-Ost-Ausdehnung 'angereichert' (in Km).". Am sinnvollsten wäre hier also so etwas wie eine 'Bounding Box'. Wer mehr über den Zusammenhang von "Massstab", "Bild-/Kartenausschnitt" und "dargestellte Fläche in der Realität" wissen will, verweise ich auf das Rostocker GIS-Lexikon sowie auf die einschlägige Literatur der digitalen Kartographie, bzw. der graphischen Bildverarbeitung. --Geonick 22:25, 30. Jan 2006 (CET)
Sehe ich auch so, ein Radius wäre besser! Aber sollte er das Objekt minimal einkreisen oder lieber etwas größer gewählt werden? Das hängt evtl. von der Art des Objektes ab. Aber vielleicht sollte man das lieber nicht festschreiben, sondern dem Editor überlassen.--Langläufer 23:02, 30. Jan 2006 (CET)
Wichtig ist doch nicht, wie das Kind heißt, sondern was es bewirkt. Ich gebe jetzt bei scale einen (Erfahrungs-)Wert ein und schaue was Goggle-maps, mapquest oder map24 darstellen. Wenn google für ein landmark keine Darstellung hat, nehme ich einen größeren scale-Wert. Ich denke dem Betrachter ist es egal wie Bild/Kartenauschnitt zustande kommen, es ist aber lästig, wenn Google-maps nur leere Kästchen zeigt, oder ein See (z.B. Titicaca) nur als schwarze Fläche dargestellt wird, weil er nun mal größer als der Bodensee ist und Orte sind mal kreisförmig, mal langgezogen, das Bildseitenverhältnis der Darstellung bleibt aber. Mit anderen Worten: Nennt den Parameter wie ihr wollt, ums probieren wird man doch nicht rumkommen und an die vielen bereits vorhandenen scale-Werte muß man auch denken, die kann ein Bot zwar umbenennen, aber mit umrechnen wird das nicht funktionieren. Und ob man den zitierten Briefkasten pur oder mit 10m Umkreis definiert wird an der Darstellung nichts ändern. -- Godewind 10:21, 31. Jan 2006 (CET)
Ich gebe dir dar insofern recht, dass das für den Benutzer egal ist. Man will doch eigentlich gewährleisten, dass das Objket vollständig, aber nicht zu klein dargestellt wird. Um das zu erreichen, muss ich zwei Dinge kennen: die Ausdehnung des Objektes (r) und die Ausdehnung des Bildes (r'). daraus kann man dann den passenden Maßstab (M) bestimmen (M=r'/r). Ein Radius wäre somit zunächst mal die sauberste Lösung, wenn die Bildfläche variiert. Aber auch mit einem Maßstab könnte man arbeiten. Dazu müsste man eine Ausdehnung für das Bild festlegen. Damit unterschiedliche Systeme hinterher trotz abweichender Ausdehnung des Bildes das komplette Bild anzeigen, muss das Skript, welches den Maßstab weitergibt, diesen für das entsprechende System anpassen (wenn es dort nur ein kleineres Bild gibt, halt kleinerer Maßstab u. andersrum). Problematisch ist allerdings, wenn die Bildgröße des Ausgabesystems nicht bekannt ist, z.B. je nach Fenstergröße variiert. Hiefür gibt es keine Lösung. --Langläufer 10:43, 31. Jan 2006 (CET)
Wie du selbst dargelegt hast, sind unser jetziger Massstab und ein Radius äqvivalent, man muss also nur mit einer Formel M errechnen und alles kann beim alten bleiben. Ich komme bei einem Maßstab von 1:15000 auf ein Objekt vom ungefähr 1 km. Also ist unser scale X=15000*r [r in km]. Für andere Programme als GoogleMaps sollte sich dieser Wert auf Kvalenberg entsprechend umrechnen lassen. Kolossos 11:27, 31. Jan 2006 (CET)
Zur Erläuterung warum Skale (zumindest begrifflich) nicht geeignet ist um den Bildausschnitt einzustellen. --Langläufer 14:10, 31. Jan 2006 (CET)
Aquivalent, wenn man die Ausgabebildgröße fest definiert ist. Diese variiert aber in Realität je nach Kartenanbieter, Monitorauflösung, etc. Was ich erreiche will ist der gleiche Ausschnit, bzw. den gleichen Radius sehen, was ich angebe heißt aber Maßstab. Einfache, aber begrifflich nicht ganz saubere Lösung ist: Man könnte z.B. Google-Maps einfach als Standard annehmen. Für alle anderen Systeme sollte "Kvalenberg" den Maßstab so anpassen, dass etwa der gleiche Bildausschnitt wie in Google-Maps gezeigt wird. --Langläufer 12:29, 31. Jan 2006 (CET)
Die Google-Map-Scale-Angabe ist nicht portierbar. Die Scaleangabe bezieht sich auf eine durchschnittliche Ausdehnung in Meter pro Pixel. Zu den Polen und zum Äquator hin wird bei gleicher Scale-Angabe eine unterschiedlich großes Objekt dargestellt. Bei einer Scale-Angabe von "10": Am Äquator 100 km = 2,5 cm, Nordgrönland: 10 km = 1,5 cm. (auf meinem Bildschirm). Man überzeuge sich hier. Die Google-Map-Scale-Angabe ist somit auch nur für Google-Maps brauchbar und nur mit Angabe der Längen- und Breitengerade auch portierbar. Arcy 16:51, 31. Jan 2006 (CET)
Das scheint mir ein Problem der Kartenprojektion. Der Maßstab gilt nur an den Berührstellen (bzw. -kreisen). Damit muss sich "Kvalenberg" rumärgern. Breitenangabe ist aber bei der Koordinate immer dabei, sollte also eine automatische Korrektur möglich sein. Dein Vorschlag ist 400px, 10cm als Normgröße ist o.k. Lösung ist ein guter Kompromiss. Das begrifflicher Problem sollte aber langfristig berücksichtigt werden. --Langläufer 17:20, 31. Jan 2006 (CET)

Vorschläge

A

Als Ausgangspunkt der Scale-Angabe dient ein Kartenfenster von 10 cm (ca. 400 x 400 Pixel).

  • Dieses Kartenfenster ist auf einem DINA4-Blatt darstellbar
  • Nahezu jeder Bildschirm stellt solch ein Fenster (ca. 400x400 Pixel) vollständig sichtbar dar.
  • 10 cm sind eine runde Zahl um damit zu rechnen.
  • Die Scaleangabe erfogt in klassischer Weise als Maßstab im 1 : XXXX Modus.
Diese Variante hat den Nachteil, das man den Wert XXXX erst errechnen muss oder mit einem bestimmten Tool bestimmen muss.

B

  • Es wird nur die reale maximale Ausdehnung eines Objektes genannt (Länge und Breite oder Radius eines Umkreises). Um alles weitere kümmert sich "die Software". Vorteil dieser Lösung ist, dass dem einfachen Nutzer gleichzeitig Informationen zur Objektausdehnung mitgeliefert werden.
Bin nach wie vor eindeutig für B. Begründung: Daten mit Raumbezug - um die es hier geht - sind 'massstabslos' (vgl. Rostocker Glossar)! Das Attribut könnte extension, circumcircle oder diameter heissen, falls wir uns auf den Radius des Umkreises einigen. Vergesst dabei nicht die Einheit und Nachkommastellen anzugeben; ich schlage vor Kilometer mit Meter-Auflösung. Das ergibt einen Wertebereich von 0.001 km bis maximal 99'999.999 km. -- Geonick 08:48, 1. Feb 2006 (CET)
Ist doch ganz einfach. Die Lösung heisst "size". Vielleicht würde sogar der Exponent auf der Basis von Metern reichen, 0 = 1 m, 1 = 10, 2 = 100 m, 3 = 1 km, 4 = 10 km, 5 = 100 km usw. oder die Grösse des Objekts in Metern eben.
Ich würde jedenfalls mit solchen Werten arbeiten, die sich auf das Objekt beziehen, und nicht auf irgendeine Software. -- Simplicius 15:45, 3. Feb 2006 (CET)
Dies bedeutet allerding auch zusäzliche Rechnerei für den einzelnen. Und bei 50m habe ich schon Entscheidungsschwierigkeiten. Arcy 18:39, 9. Feb 2006 (CET)
keinen Exponenten - so einfach wie möglich, alse radius in m bwz. km! --Langläufer 17:08, 22. Feb 2006 (CET)

C

verschoben nach E.II

D

Dezimale Angabe von Länge und Breite in Kilometern

Die Angabe von Länge und Breite begegnet optimal allen Fragen der Darstellung eines Objektes. Arcy 18:44, 9. Feb 2006 (CET)

was ist bei dir Höhe? meinst du vielleicht Länge und Breite? dezimal ist ok - ist aber teil von vorschlag B. --Langläufer 17:10, 22. Feb 2006 (CET)
Stimmt, danke. Arcy 17:58, 22. Feb 2006 (CET)

E

Google-Maps like Scaleangaben

Die Daten sollten schon auf die Objekte bezogen sein ("Datenebene", "Primärdaten") und nicht auf irgendein Programm ("Präsentationsebene"), von dem man unter anderem auch nicht weiss, ob es nicht mal später Geld kosten wird.
Ich wäre daher dafür, eine Ergänzung mit dem Durchmesser oder Radius zu machen, wenn es überhaupt erforderlich ist, da was zu machen.
Zum Bleistift gibt es bei Google Earth ja auch verschiedene Auflösungen, und die könnte man formelmässig bei der Umrechnung berücksichtigen, so dass man am Ende gar nur mit einer diskreten Anzahl von Scale-Angaben fahren könnte. -- Simplicius 23:53, 8. Feb 2006 (CET)
Es ist aus fachlicher Sicht vielleicht richtig die Objekte auf "Datenebene" (wie ich es verstehe also in realen Abmessungen) zu bewerten, als Laie kann ich aber nur über die "Präsentationsebene" der angebotenen Programme (Google maps, mapquest, usw.) einen Wert ermitteln und nur diese Darstellungen werden wohl für die meisten Nutzer der WP interessant sein. @Kolossos: Wenn Du die scale-Angabe noch nie benutzt (und vermißt) hast, dann lag das entweder an den ausgewählten Objekten, die günstig in das Raster der Type-Angabe fielen, oder Du hast auf der "Präsentationsebene" ein unbefriedigendes Ergebnis hinterlassen. Beispiele für erforderliche scale-Angaben (wie immer man das Kind auch nennen will) habe ich in der Diskussion schon genannt, bringe sie aber bei Bedarf gerne noch mal. Mein Fazit: Die Koordinatenangabe ist für die "Präsentationsebene" interessant und da wird eine Angabe zum "Kartenauschnitt" benötigt. Präzise Angaben auf "Datenebene" können ergänzend rein oder in den Artikel einfließen. -- Godewind 10:16, 9. Feb 2006 (CET)
Ich hab meine Aussage oben etwas ergänzt. Um es noch mal anders zu formulieren: angenommen ein Objekt ist 500 m groß, dann sind das 500. Damit kann jeder was anfangen.
Um daraus irgendeine andere Zahl zu machen, dafür gibts Formeln, also soll das doch die Formel machen. Das muss nicht immer heissen, dass ein Scale "berechnet" wird, sondern kann auch bedeuten, dass pro Objekt in einer Fallunterscheidung geprüft wird, welcher scale "am zweckmässigsten" ist - auch in Abhängigkeit der Anwendung Google Earth, NASA World Wind und was in Zukunft kommt. -- Simplicius 12:40, 9. Feb 2006 (CET)
Den Ansatz verstehe ich ja und finde ihn auch vernünftig, weil die hohen scale-Werte ja auch keinen Sinn machen es sei denn ich könnte auf der "Präsentationsebene" etwas mit einem Wert "1" anfangen. Kann ich aber nicht, werde ich auch nicht mit einer Objektgröße von 1m können, aber das spricht ja nicht gegen Deine Dimensionierung. Nun die Praxis, Beispiel 1: Schulschiff Deutschland, das Teil ist rund 100m lang, liegt diagonal im Bild und Google maps bringt bei scale:2000 ein gutes Bild. Beispiel 2: Ein (flächenmäßig) kleineres Objekt der Leuchtturm (Travemünde), da ist schon ein scale:20000 erforderlich, weil Google in dem Bereich keine höher auflösenden Bilder anbietet. Spricht ja auch nicht gegen Deine Skalierung, das Schiff hätte vielleicht den Wert 200, der Leuchtturm müßte aber schon 2000 bekommen und das nur wegen Google. Deshalb erlaube mir einen Vorschlag: Einen Parameter für die Objektgröße, die dann auf den Straßenkarten auch etwa so dargestellt wird und einen Parameter für Google maps, der mit der dortigen Skala korrespondiert (~ 1..20). Klingt redundant, die Fachleute werden vielleicht die Stirn runzeln, aber ich sehe keine andere Möglichkeit die "Datenebene" und die "Präsentationsebene" mit einem Parameter adäquat darzustellen. -- Godewind 15:56, 9. Feb 2006 (CET)
Das sind interessante Fragen, ein Schiff könnte auch hochkant im Bild stehen (ich meine jetzt nicht sinkend), das Objekt könnte aber auch in einem Bildbereich liegen, der hochauflösend gezeigt wird oder im Meer, das samt Inseln meist sehr schlecht gezeigt wird.
Grundsätzlich wäre es aber gut, in die Artikel nur die Primärdaten reinzutun, und kvaleberg.org erzeugt dann per Formel einen optimierten Ausschnitt für den klickenden Benutzer.
Auch so erschiene im Ausschnitt dann ganz Spanien, ganz Madrid, oder gegebenenfalls ein kleineres Fenster, das vor dem Hintergrund der Auflösungsstufen nicht zu klein gewählt sein sollte. Für die Koordinatensammlungen sollte äquivalent auch eine Fallunterscheidung möglich sein (in bestimmten Bereichen per Formel, in bestimmten Bereichen Festangabe eines scales).
Habe ich aber schon irgendwelche festen Zahlen in den Artikeln nur auf die Google-Ansicht bezogen, sind diese Betrachtungen für produktabhängige Differenzierungen in einem anderen Produkt sozusagen für'n Popo. -- Simplicius 17:13, 9. Feb 2006 (CET)
  • zu: "weil Google in dem Bereich keine höher auflösenden Bilder anbietet": Fürn popo ist es auch den gerade in deutschland angebotenen googlemaps hinterherzulaufen und dann scale neuen un detailierteren karten anzupasseen.
  • zu: "einen Parameter für Google maps, der mit der dortigen Skala korrespondiert (~ 1..20).": korrespondiert heisst Google-Scale heißt festlegung auf google-maps
    Die Google-Map-Scale-Angabe korrespondiert nicht mit der Größe eines Objektes sondern ist zusätzlich abhängig vom Längen- und Breitengerade. Die Scaleangabe bezieht sich auf eine durchschnittliche Ausdehnung in Meter pro Pixel. Zu den Polen und zum Äquator hin wird bei gleicher Scale-Angabe eine unterschiedlich großes Objekt dargestellt. Bei einer Scale-Angabe von "10": Am Äquator 100 km = 2,5 cm, Nordgrönland: 10 km = 1,5 cm. (auf meinem Bildschirm). Man überzeuge sich hier. Die Google-Map-Scale-Angabe ist somit auch nur für Google-Maps brauchbar und nur mit Angabe der Längen- und Breitengerade auch portierbar.In entsprechender Weise sind komplizierte Umrechnungen erforderlich um mittels Höhe, Breite sowie Breiten- und Längengrad einen Google-Map-Scale zu berechnen, der zusätzlich für ein definiertes Bildschirmfensterchen gelten muss. 18:27, 9. Feb 2006 (CET)-- Arcy 18:29, 9. Feb 2006 (CET)
Ist mir aus den unendlichen Diskussionen ja schon bekannt, aber gibt es eine Alternative zu Google maps? Wenn nicht wäre mir ein eigener Parameter dafür lieber als eine irgendwie berechnete aber unbefriedigende Bildansicht. Und für die Primärdaten kann man einen neuen Parameter wählen. Vielleicht ist das der Preis, den man in einer proprietären Phase zahlen muß, aber er wäre mir nicht zu hoch. -- Godewind 19:17, 9. Feb 2006 (CET)
Gute Satellitenbilder präsentiert auch NASA World Wind, wobei ich nicht zu denen gehöre, die sich mit der speziellen Ansteuerung des Programms auskennen. Aber es macht beim Programmieren sicher keinen Spaß mehr, Google-Earth-Scale-Werte in Nasa-World-Wind-Scale-Werte umzurechnen.
Deswegen sagt man heutzutage vor allem im GIS-Bereich: lass Daten mal Daten sein und Programme mal Programme. Es sind unterschiedliche Schichten.
Scale-Angaben in einer KML-Datei sind sicher sinnvoll, weil für Google Earth gedacht, aber diese komische Mathematik eines kommerziellen Programms sollte kein Standard für Einträge in der Wikipedia als GNU/FDL-Projekt werden. Ich persönlich ziehe den Durchmesser vor. Für den Rest kann man Formeln entwickeln (EVA = Eingabe=Durchmesser, Verarbeitung per case-Anweisung, Ausgabe=scale für kml). -- Simplicius 19:40, 9. Feb 2006 (CET)

F

Nehmt nach meiner obigen Formel die reale Ausdehnung in Metern mal den Faktor 10 (15) und nennt das ganze, weil es egal ist wie es heißt, scale. Damit kommt man der Variante B sehr nahe jedoch können die Formatvorlage, die Tools wie hjl_get_Coor und die bereits getätigten Eingaben erhalten bleiben. Kolossos 21:33, 3. Feb 2006 (CET)

Weist Du, wieviele Eingaben es bisher bei "Scale" gibt ? Arcy 18:03, 9. Feb 2006 (CET)
Frag bitte sk, er ist meines Wissens nach der einzigste der das im Moment halbwegs genau beantworten könnte. Kolossos 21:44, 9. Feb 2006 (CET)
Zu deinen Anmerkungen zur Variante B und hjl_get_Coor. Im tool hjl_get_Coor wird mom. die Scale-Angabe immer noch als Google-Map-Scale angegeben bzw. von der Google-Map ausgelesen. Die Angabe hat aber mit der realen Ausdehnung der Karte erstmal nichts zu tun (man beobachte die Veränderungen in der Massstabsleiste bei Verschiebung des Kartenausschnittes bei gleicher Scale-Angabe zu den Polen oder zum Äquator hin). Dein Faktor 10 (wieso erwähnst du 15) hilft da auch nicht weiter. Arcy 22:09, 9. Feb 2006 (CET)
Ok ich habs gemerkt, die scale Angaben von hjl_getCoor mit GoogleMaps taugen nicht viel. Wenn man danach die Kvaleberg-Testseite aufruft und darin GoogleMaps dann stimmt schon nix mehr. Den Faktor 15 hatte ich für Deutschland oben schonmal ermittelt, mit Faktor 10 ließe sich einfacher rechnen. Die Abweichung hin zum Aquator halte ich für vertretbar und an den Polen haben wir nur sehr wenige Einträge. Kolossos 23:24, 9. Feb 2006 (CET)
Es sind die original Scaleangaben von Google. Der Grund warum die Scaleangabe nicht funktionieren sind die unterschiedlichen Größen der Kartenfensters. Arcy 00:08, 10. Feb 2006 (CET)
Auf welche Kartengröße beziehst Du dich? Arcy 23:52, 9. Feb 2006 (CET)
Dein System geht imho auch von realen Größen aus (sein es nun cm, m oder km). Mal 10 genommen wird ja eigentlich nur ne "andere Maßeinheit" daraus, weshalb es keinen Sinn macht die Originalmaßeinheit nicht zu verwenden. Das x 10 nehmen kriegt die Kvaleberg schon hin.Arcy 00:08, 10. Feb 2006 (CET)
Mein System basiert auf der Abmessung in Metern mal 10. Was ist daran so schwierig zu verstehen? Wenn man Google-Maps über den Kvaleberg-server damit aufruft ist das bei mir Auflösungsunabhängig, ein halbwegs quadratisches Fenster mal vorrausgesetzt. Da ich persönlich eine Abweichung von +/- 40% für vertretbar halte, gilt mein Vorschlag für den ganzen Erdball. Hast du schon mal versucht mit Egil Kvaleberg in Kontakt zutreten, ob er seine Software ändert. Es ist nähmlich schwer da eine Antwort, geschweige denn eine Programmänderung, zu bekommen. Deshalb ist mein Vorschlag zwar ungenau aber er funktioniert. Ist euch eigentlich schon aufgefallen, dass Kvaleberg mit der Type-Angabe arbeitet so werden Städte im brauchbaren Maßstab 1:100.000 angezeigt, Landmarks jedoch im Maßstab 1:10.000. Es geht also auch so. Kolossos 20:30, 10. Feb 2006 (CET)
Ich stimme Kolossos zu. "Scale" ist laut Handbuch Google Earth die "Entfernung" zur Erdoberfläche, sprich zum Beispiel 10.000 m. Letztendlich heisst das ohne definierten Winkel nicht viel. Aber es geht hier ja um zwei Sachen a) Aufruf über kvaleberg b) Aufruf über die kml-Dateien. Der Typ "city" kann ja grösser gewählt werden, der Typ "landmark" feiner. In der Regel wird man damit schon hinkommen. Alles Weitere ist auf lange Sicht möglicherweise nur Datenmüll. -- Simplicius 21:30, 10. Feb 2006 (CET)

Weiteres Verfahren

Wie soll - um zu einer Entscheidung zu kommen - bezüglich der Scale-Angabe weiter Verfahren werden?

  • besteht weiterer Diskussionsbedarf ?
  • Wollen wir hier drüber abstimmen?
  • Soll diesbezüglich ein Wikipedia:Meinungsbild initiert werden?

-- Arcy 17:50, 3. Feb 2006 (CET)

Um ehrlich zu sein hab ich auf ein Meinungsbild dazu keine Lust, weil ich die Scale-Angabe noch nie benutzt habe, sorry. Kolossos 21:35, 3. Feb 2006 (CET)
hier abstimmen! --Langläufer 23:42, 9. Mär 2006 (CET)

Redundanz und In-/Konsistenz bei vielen Schwesterwikis

Edgar F. Codd lehrt uns, Information an nur einem Platz zu hinterlegen, wenn es dieselbe ist. Das Chaos von Benutzernamen und die Single-Login-Diskussion, die nicht weiter kommt, sowie das Problem bei Bildern auf den lokalen Wikis statt auf Commons kennen wir ja schon.
Ich möchte hiermit mal kurz darauf hinweisen, dass wir irgendwo einen gemeinsamen commons-ähnlichen edit-Raum brauchen, auf dem man a) interwikilinks und b) die Geookoordinate hinterlegen könnten, um Redundanz und Inkonsistenzen von vorneherein zu vermeiden.
Das ist Arbeit für die Entwickler. Wo und wie kann man die am besten erreichen? -- Simplicius 15:52, 3. Feb 2006 (CET)

Ich halte die Überlegung, Geokoordinaten auf Commons abzulegen für Unsinn. Eine Georeferenz dient zum referenzieren! Ihr wollt eine Referenz referenzieren! Wie will man denn die "richtige" Geokoordinaten in der Datenbank finden? Wenn das einfach gehen würde bräuchte man auch keine Datenbank - weil dann ließen sich identische Georeferenzen automatisch ermitteln - geht aber sicher nicht einfach. --Langläufer 16:36, 3. Feb 2006 (CET)
Ich meine eher "commonsähnlich" als commons und habe das mal geändert. Ansonsten meine ich es genauso und stehe auch dazu.
Um noch mal ein konkretes Beispiel zu bringen: wenn der Artikel Big Ben auf 100 Sprachen exisiert, gibt es irgendwann 9.990 interwiki-links (in unterschiedlicher Reihenfolge) und 100 Geokoordinaten (mit ggf. unterschiedlichen Werten).
Gäbe es ein gemeinsames Fenster, stünden dort 1 Geokoordinate und 100 interwiki-links. -- Simplicius 16:41, 3. Feb 2006 (CET)
Das ist mir schon klar du möchtest eine Liste mit Geokoordinaten. Was ist denn die korekte Geokoordinate? Insbesondere bei großflächigen Objekten ist das schwierig. Wie findet man den Eintrag in der Datenbank? Woher weiß man in welcher Sprache er da abgelegt ist? Ich sehe die Koordinate nur als Georeferenz. Georeferenzen speichert man nicht in extra Datenbanken. Sinn der Georeferenz ist es, einen räumlichen Bezug herzustellen, das tut sie, sofern sie nur innerhalb des Objekts liegt. Das tut sie auch, wenn jede Sprachversion eine leicht verschiedene Koordinate bietet. --Langläufer 16:56, 3. Feb 2006 (CET)
Es gab bei der letzten Zählung 22.000 Geokoordinaten in der deutschsprachigen Wikipedia, 34.000 Geokoordinaten in der englischsprachigen Wikipedia. Gibt es hier umgewandelt für Google Earth. Orte werden in der Regel auf die Minute genau, andere Objekte bis zur Hunderstel-Sekunde (plus minus 15 cm) genau angegeben.
Mir würde für Great Yarmouth das irgendwo in East Anglia liegt, ein [[inter:Great Yarmouth, Great Britain]] reichen, ob das dann eine Extra-Seite gibt, per iframe eingebettet werden könnte oder was anderes, würde ich die Entwickler mal gerne fragen. Ich hielte es am besten, für interwiki-links und Geokoordinaten eine solche Lösung gemeinsam zu basteln. -- Simplicius 18:12, 3. Feb 2006 (CET)
Das ist eine spezielle Anwendung die mit Georeferenzierung nichts zu tun hat. Dann hat man letztendlich eine Art Adresskodierung + Geokodierte Adressen. Das mag für Städe und Wahrzeichen ganz gut funktionieren, aber was ist mit dem Rest? Was ist mit Flächen? --Langläufer 21:52, 3. Feb 2006 (CET)
Derzeit fehlt ein Feature, um Flächenumrisse zu beschreiben. Man könnte ja auch mal eine Linie nehmen, zum Beispiel die B 51 von Bremen nach Trier.
Solche Daten lassen sich an die anderen Kartendienste, die man über kvaleberg.org nutzen kann, nicht weiterleiten.
Aber angenommen, wir würden eine solche Beschreibungsmöglichkeit einführen. An einer zentralen Stelle (sozusagen das Katasteramt) sind diese Daten (gern auch mit Versionshistorie) besser aufgehoben, als einhundert Mal neu versucht oder abkopiert. -- Simplicius 22:18, 3. Feb 2006 (CET)

An den 9.990 Interwikilinks stört sich doch auch keiner, alle verlinken einmal zur englischen WP und den Rest machen die Bots. Das hat auch den Vorteil, dass das Seitenrendering schneller geht als wenn man immer noch eine zweite Datenbank abfragen muß. Man muß noch nicht mal die deutsche und die englische Version der Geodaten untereinander abstimmen, man muß nur jeweils einzeln visuell (Google Earth läßt grüßen) die jeweiligen Koordinate nachschauen ob sie passen. Wenn wir dann einen guten Stand erreicht haben können wir einen Bot anwerfen der die Franzosen, Spanier .... in den Genuss der Georef. kommen läßt. Der Unterschied zwischen den Commons und den Georefs. liegt darin, dass ein Bild ca. 100.000 Byte braucht, ein Geotag jedoch nur 90 Byte. Ein Verweis auf eine Datenbank wird auch ein paar Byte benötigen. Kolossos 22:10, 3. Feb 2006 (CET)

Ich sehe hier auch nicht ein Problem der Bytes, sondern der Konsistenz. Die geht bei mehr oder weniger willkürlichen Duplikaten für dieselbe Sache eben schnell verloren. Und ich meine eben nicht nur die Situation, dass nur die englische und deutsche Wikipedia Geodaten enthält, sondern eines Tages auch die Wikipedias in anderen Sprachen.
Es ist ja der Witz eines relationalen Datenbankmodells, Daten, die es nur einmal gibt, auch nur an 1 Stelle zu verwahren und bei den Stellen, wo diese verwendet werden, nur noch auf diese Stelle zu verweisen. Das würde so manchem Bot die Arbeit sparen. -- Simplicius 22:18, 3. Feb 2006 (CET)
Da ich noch nichts von Orten auf Wanderschaft gehört habe, gilt einmal richtig immer richtig. Falls wir jedoch irgendwann mal in der Lage sind Pfade und Umrisse aufzuzeichnen, dann geb ich dir recht, brauchen wir auch ein gemeinschaftlich verbundenes System. Kolossos 23:19, 3. Feb 2006 (CET)

Dann frag doch: Wikipedia:MediaWiki#Kontakt_zu_den_Entwicklern. Die eventuelle Entwicklung wird sich aber erst lohnen wenn man neben Geotags auch Personendaten und sonstiges verbinden kann, und da ist man wohl wiedermal bei wikidata was nicht aus der Hüfte kommt. Kolossos 22:14, 3. Feb 2006 (CET)

Mein Stichwort: Nachdem es die Personendaten mittlerweile auch in der englischen, japanischen und alemannischen Wikipedia gibt, wäre eine Arti Wikidata wirklich sinnvoll. Aber meta:Wikidata und Unterseiten sehen nicht sooo vielversprechend aus. Grüße, ElRaki ?! 22:24, 3. Feb 2006 (CET)
Diesen Vorschlag nehme ich gerne mit auf. Die Lösung wäre dann vielleicht ein [[Wikidata:Big Ben]] und eine Lösung, dass sich der Inhalt wie eine Vorlage in den Artikel einbringt. Ich werde die morgen alle mal anspammen. -- Simplicius 23:13, 3. Feb 2006 (CET)
Hier meine Gedanken dazu: Für die Idee, Koordinaten nur an einem Ort zu pflegen und abzulegen spricht tatsächlich einiges. Dabei sind aber doch noch einige Fragen offen: Soll diese Ablage nun in der englischen Wikipedia geschehen (und alle 999 Sprachen verweisen mit interwiki-Links darauf?)? Oder soll die Ablage auf einem dritten (externen) Server sein (typischerweise ein WFS)?
Wikidata scheint z.Zt. nicht bereit. Der Toolserver hingegen läuft (wenn auch mit eingeschränkten Ressourcen pro Projekt). Die zweite Variante würde eine gänzlich uninterpretierbare (DB-)Referenz auf eine (Koordinaten-)Referenz sein, was ich problematisch finde, da es das Prinzip der Einfachheit, der Kontrolle und der Sichtbarkeit verletzt. Andererseits ist genau dies wohl bei Linienzügen und Flächen eine valable Lösung, weil dann die (genormte) Codierung klar ist (d.h. gemäss OGC).
Bleibt die erste Variante. Diese scheint mir aus folgenden Gründen nicht realisierbar: 1. Sind die Datenmengen, die ein Roboter nur schon mit einer Sprach-Instanz wie dem deutschen Wikipedia enorm und mit den Mitteln der Wikipedia inklusive des Toolservers nicht realisierbar. 2. Stellen sich hier einige weitere nicht ganz triviale Fragen: Was geschieht, wenn der englische Artikel oder dessen Koordinaten gelöscht wird? Was, wenn dessen Name geändert wird? Was passiert mit Artikel, zu denen kein englisches Pendant vorhanden ist? Wer übersetzt engliche Artikel ins deutsche, um ein interwiki-Link vom deutschen ins englische zu setzen?
Fazit: Meiner aktuellen Einschätzung nach bleibt nichts anderes übrig, als mit der aktuellen oder verbesserten Koordinaten-Vorlage möglichst viele Artikel in der deutschen Wikipedia zu verorten mit Schwerpunkt deutschsprachiger Raum; und nicht zwingend bei der deutschen und der englischen Wikipedia gleichzeitig. --Geonick 01:03, 12. Mär 2006 (CET)

Neue Daten für Google Earth

Hallo Leute, die neue KML-Datei für die deutschprachige Wikipedia ist da. Hier gehts zum Download. Viel Spaß! -- sk 23:25, 4. Feb 2006 (CET)

Stefan, wie immer danke! fragwürdig ?! 13:04, 5. Feb 2006 (CET)

Erstmal auch danke. Die dynamische Version ist jetzt auch verfügbar. Da die Datenbank auf den Toolserver umgezogen ist, ist ein erneuter Download der KMZ-Datei unter http://www.alder-digital.de/wiki/index.php/Wikipedia_in_GoogleEarth#Die_deutschsprachige_Wikipedia (22 kB) notwendig. Viel Spaß damit. Kolossos 18:04, 5. Feb 2006 (CET)

Super Arbeit, Kolossos. Ich liebe es mit der dynamischen Variante auf Endeckungsreise zu gehen! -- sk 20:13, 5. Feb 2006 (CET)
Ich schliesse mich Fragwürdig und sk an: Super! -- Simplicius 23:49, 8. Feb 2006 (CET)

Hier noch ein Hinweis auf ein interessantes Seminar zum Thema 'Google Earth': 

  Google Earth auf dem Fortbildungsseminar 2006 des Vereins Runder Tisch GIS e.V.
  vom 1. bis 3. März 2006 an der TU München

Weitere Informationen dazu siehe Verein Runder Tisch GIS e.V.

Nur zur Info: Ich habe heute die deutsche Datenbank heute auf den Stand vom 20.04.2006 gebracht. Ein erneuter Download ist nicht erforderlich. Kolossos 17:18, 30. Apr 2006 (CEST)

Formatierungen des Koordinatentextes

Ich hoffe, ich habe es nicht bei dieser Diskussion überlesen, aber gibt es eigentlich eine einheitliche Formatierung für den Textteil der Koordinatenangaben? Mir fällt immer wieder auf, dass es mehrere Arten der Angabe gibt. Zum Beispiel ein Konstrukt wie

  • 51° 27' 33" n. Br., 6° 37' 11" ö. L. (z.B. bei Moers), oder
  • 48° 47' N, 09° 11' O (wie z.B. bei Stuttgart)

und auch andere Varianten habe ich schon gesehen - z.B. nördliche Breite... also nicht abgekürzt, oder aber auch die wissenschaftlich korrektere Form, die dann statt O ein E benutzt. Ich fände es schön, sich auf etwas Einheitliches zu einigen und würde 51° 27' 33" N, 6° 37' 11" E vorschlagen. - Gruß Gesus 19:52, 10. Feb 2006 (CET)

Was ist denn an E „wissenschaftlich korrekter“ als an O? Das ist nur englischer.
Ansonsten sollten natürlich die „korrekten“ Minuten- und Sekundenzeichen ( ' ? ) verwendet werden. Ich persönlich benutze auch sehr gerne führende Nullen bei den Zahlenwerten (00° 00' 00? N, 000° 00' 00? O), dann werden zum Beispiel Zahlenfehler leichter zu erkennen. --::Slomox:: >< 21:11, 10. Feb 2006 (CET)
Das mit den führenden Nullen und den korrekten Zeichen ( ' ? ) unterstütze ich. Um auf deine Frage mit der wissenschaftlichen Korrektheit zurückzukommen: In zeitgemäßer, deutschsprachiger Fachliteratur zu Themen bzgl. physischer Geographie, Kartographie oder Geodäsie gibt es kein O bei dieser Art der Angabe von geogr. Koordinaten. Da wird halt die internationale Schreibweise verwendet. - Gruß gesus 21:43, 10. Feb 2006 (CET)
Ich bevorzuge auch die Kurzform also N/O. Ich glaube auch das versteht jeder. Kolossos 23:58, 11. Feb 2006 (CET)

Ich fände eine Vorlage wie bei den Personendaten besser. Mir würde es reichen, wenn man die Zahlen nur einmal eingeben muss und pro Zeile.
Also {{Koordinate|
BREITE = 40 23 22,00 N
LAENGE = 12 33 33,00 O
TYPE = ...
REGION = ...
}} und fertig. -- Simplicius 22:19, 10. Feb 2006 (CET)

Wie unterscheidest du dabei {{Koordinate Text... }}, {{Koordinate Artikel..}} und {{Koordinate Text Artikel...}}? Ich finde die drei Varianten sehr wichtig. Bei der Erzeugung der letzten KML hab ich auch die Vorlage:Ort Schweiz genutzt um Koordinaten der Schweizer Ortschaften zu generieren. Da ich der Meinung bin, das über kurz oder lang die Infoboxen auch bei deutschen Ortschaften genutzt werden wird (wegen der besseren Lesbarkeit), sollten wir das bei einer Neuformatierung mit bedenken. Ich habe keine Lust für jedes Land eine neue Diskussion anzufangen, dann lieber gleich richtig machen, eine globale tragbare Variante finden und die 25000 bestehenden Koordinaten gleich per Bot umwandeln. Es müsste also sichergestellt werden, dass die neue Vorlage in einer Infobox-Vorlage voll unterstützt wird. Bei den Schweizern fehlt z.B. die Region nach ISO 3166-2 (insbesondere die Kantonabkürzung). Weiterhin sollte überlegt werden, wie mit Objekten, die zwei Regionen zugeordnet werden können verfahren wird. Ich habe für Gipfel, Bergpässe schon "region:AT/IT" gesehen, aber das sollte auf jeden fall geklärt werden. Bei den "type"-Angaben, bin ich der Meinung sollten wir alles so belassen wie es ist, denn da haben sich die Kategorien zur Verfeinerung bestens bewährt und man vermeidet Doppelarbeiten.--sk 10:20, 11. Feb 2006 (CET)
Mein Vorschlag zielt vor allem auf eines ab:
  • die Koordinaten nicht doppelt eingeben zu müssen (doppelte Arbeit für das Gleiche ist vom IT-Standpunkt aus unnütze doppelte Arbeit, und ggf. widersprüchlich, weil man ja doch was anderes eintragen kann),
  • Umbrüche einzusetzen, um nicht mehr mit den Zeichen für "Leerschritt" rummachen zu müssen, damit einige Browser den Bandwurmcode aus Versehen zerlegen
Was Koordinaten in der Box oder überhaupt angeht, kann man auch eine Lösung finden, die nach vier Parametern pro Zeile Ausschau hält und die sie korrekt formatiert in der Anzeige präsentiert.
Auf Koordinaten im Text würde ich ganz verzichten, weil Sätze, die Koordinaten angeben, letztendlich doch uninformativ sind, weil sich unter 33° Ost 23° Nord ja doch niemand was vorstellen kann, auch wenn da ein Frachter gesunken sein mag.
Kurzum, mir geht es um eine Vorlage, die übersichtlich ist, statt bei Daueranwendung zur Erblindung führt. -- Simplicius 23:07, 11. Feb 2006 (CET)
Simplicius, versuch doch mal eine Vorlage zu schreiben, die mit deiner Idee klar kommt, damit kann man Leute vielleicht eher überzeugen als mit theoretischen Anstellungen. Aber ich glaube dein Vorhaben scheitert schon an der Umformatierung von "BREITE = 40 23 22,00 N" zu "BREITE = 40° 23´ 22,00´´ N". Die Dopplungen haben auch ihr gutes, so kann man am Beispiel Mosambik bei der Nutzung der von/bis Werte sehen.
Mein eigentlicher Grund warum ich schreibe ist meine Idee, dass es bei den {KoordinatenText|....} äußerst sinnvoll wäre da noch einen zusätzlichen Namen mit angeben zu können. So wäre es endlich möglich einen Artikel mit mehr als einem Punkt wie TU Chemnitz halbwegs zu gereferenzieren, was bis jetzt immer daran scheiterte, dass die TU mehrere Standorte in der Stadt hat. Man hätte also {KoordinatenText|....Name=Standort A} und {KoordinatenText|....Name=Standort B}. Auf einer Karte gäbe es dann die Ansicht "TU Chemnitz#Standort A", somit würde auch die Links weiterhin funktionieren. Bei einem Fluß könnte ich mir dann die Quelle und die Mündung vorstellen.... Kolossos 23:58, 11. Feb 2006 (CET)
Ich vermute da kein Problem, bei einer Anzeige Text1 + Variable1 + Text 2 + Variable 2 usw. zusammenzubauen, und per Bedingung falls leer, eine 0 dazuzutun.
Wenn es irgendwo eine Seite gibt "Wie kreiere ich eine Vorlage?", würde ich es gerne mal lesen.
Alternativ kann man auch einfach nur noch schreiben "Geolink" statt den Koordinaten. Wen stört es, dass die Koordinaten fehlen? Hauptsache, man kann draufklicken, oder nicht?
Bezüglich des Vorschlags "Name" wäre das über ein "Name=" jedenfalls übersichtlicher zu ergänzen, wenn die Vorlage vertikal aufgebaut wäre. -- Simplicius 14:32, 12. Feb 2006 (CET)
Zum Vorlagenbau schau mal auf Hilfe:Vorlagen, ist wirklich es interessante und leistungsstarke Fähigkeit des Mediawikis. Kolossos 19:22, 12. Feb 2006 (CET)

Mein Vorschlag wäre:
{{Koordinate|
BEZUG = Text/Artikel/Text Artikel
BREITENGRAD = 40
BREITENMINUTE = 40
BREITENSEKUNDE = 22,00
BREITE = N
LAENGEGRAD = 12
LAENGEMINUTE = 33
LAENGESEKUNDE = 33,00
LAENGE = E
TYPE = city/landmark/waterbody/mountain/country/adm1st/adm2nd
EINWOHNER = 100.000 (Wichtig für die Übergabe aus der allgemeinen Stadt-Infobox
HOEHE = 4500 (Höhe für Pässe und Berge, aber auch für Puntdaten (Profil einer Route) etc.)
REGION = DE-BY,AT (mit Komma getrennt für mehrere Regionen )
SCALE = 25000
NAME = Wrack der Titanic
}}
Ich denke damit müssten wir alles abdecken. -- sk 15:59, 12. Feb 2006 (CET)

Mit einer integrierten Vorlage:If können wir dann wohl auch das E in ein O umwandeln und auch die Sekundenzeichen "´´" nur dann ausgeben wenn bei der Variable LAENGESEKUNDE ein Wert eingetragen wurde. Nur eine statt drei Vorlagen wäre natürlich elegant. Soll ich da mal was in die Richtung bauen? Grad/Min/Sek würde ich allerdings immer auf einer Zeile zusammenfassen, nicht dass bei einem kurzen Artikel der Geotag länger wird als der Rest. Kolossos 19:22, 12. Feb 2006 (CET)
Mit dieser Vorlage wäre ich vorsichtig. Ich habe die Diskussion um diese Vorlage nicht groß verfolgt. Die Vorlage wurde aber in der en:wp schon mal zur Löschung vorgeschlagen. Ansonsten sind die logischen Templates sicherlich eine interessante Angelegenheit
Weitere Infos unter en:Wikipedia:Avoid using meta-templates, en:Wikipedia:High-risk_templates
--Arcy 08:29, 13. Feb 2006 (CET)

Hallo,
Ich habe oben schon bei "Dringender_Bedarf_zur_Revision_der_Vorlage" einen entsprechenden Vorschlag gemacht. Zu diesem stehe ich immer noch mit folgendem Zusatz: In letzter Zeit hat eine weltweite Normierung im Bereich der Koordinaten-Codierung (geotagging) eingesetzt. Diese wird von ISO, W3C, dem Open Geospatial Consortium und weiteren Organisationen unterstützt. Neuerdings ist dort auch Google vertreten. Dabei sind Vertretungen verschiedener Organisationen oft mit denselben Personen besetzt.

Speziell zu erwähnen ist aber eine Homepage einer "virtuelle Gruppe", namens Georss.org, die sich speziell dem Geotagging widmet.Dort steht klar zur Codierung: "WGS84, latitude, longitude (in that order), using decimal degrees". Aufgrund dieses Trends und zusammen mit Euren Vorarbeiten schlage ich daher folgende Syntax vor. Diese sollte den Anforderungen sowohl der Wiki-Autoren als auch einigen Informatik-Prinzipien genügen.

Syntax:

{{Koordinate|
BEZUG = enum (oblig.; Wertebereich: enum= Text/Artikel/Text Artikel)
LATITUDE = +DD.SSSS (oblig.; Wertebereich: -90.000 .. +90.0000)
LONGITUDE = +DDD.SSSS (oblig.; Wertebereich: -180.0000 .. +180.000)
ELEVATION = mmmmm (opt.; Wertebereich: -99999..+99999 in Meter über Meer, bzw. Normalnull)
EXTENSION = mmmmm (opt.; Wertebereich: 1 .. 99999 in Meter)
TYPE = enum (Wertebereich: enum= city/landmark/waterbody/mountain/country/adm1st/adm2nd/other)
REGION = cc-rr (opt.; Wertebereich: enum= siehe ISO-Norm)
POPULATION = pppppp (opt.; Wertebereich: 0 .. 99.999.999)
}}

Beispiel 'Wrack der Titanic':

{{Koordinate|
BEZUG = Text
LATITUDE = 41.76666
LONGITUDE = -50.23333
ELEVATION = -3821
EXTENSION = 2
TYPE = other
}}

Diskussion: Gegen eine 'Eindeutschung' der Schlüsselwörter habe ich grundsätzlich nichts (dann aber kein Mischmasch); eine Verdoppelung der Koordinaten wäre nach wie vor fehlerbehaftet, dessen Format in Dezimalangabe ist mit GeoRSS genormt; die EXTENSION ist ein vollwertiger Ersatz von SCALE (nur mehrfachverwendbarer) und TYPE habe ich mit other ergänzt und weise nochmals auf die (vorläufig nicht vermeidbare) Redundanz zu Kategorien hin.

Name ist mir unklar: Der Artikel hat ja schon einen? Das bringt mich sowieso auf ein Problem: Der Bezug bei 'Koordinate Text' ist unklar: Auf welchen Textabschnitt oder auf welches Wort bezieht sich dieser Datebnanklink wirklich?? -- Geonick 00:18, 13. Feb 2006 (CET)

Also die Eindeutschung scheint mir sehr wichtig, da sonst viele Leute das ganze falsch schreiben oder falsch ausfüllen. Wozu der Type "other" gut sein soll verstehe ich noch nicht ganz. Ich glaube "landmark" und "other" wird nie klar zu trennen sein. Der Eintrag Name ist dafür, wenn z.B. Im Artikel Universität Trier zwei Koordinaten auftauchen einmal für Campus I und dann für Campus II. Wie lösst du das Berg/Pass Problem, die nicht eindeutig einer Region zugeordnet werden können, weil sie auf der Grenze liegen? Ansonsten könnte ich mit deinem Vorschlag leben. -- sk 16:23, 13. Feb 2006 (CET)
Was wir statt einen Typ "other" wirklich brauchen ist ein Typ "district" also Stadtteil, da diese in einer Karte wirklich schlecht aussehen wenn ist genauso dargestellt werden wie die eigentliche Stadt. Die Vorteil einer dezimalen Schreibweise mit +/- kann ich aus programmiertechnischer Sicht wirklich nachvollziehen, aber aus Sicht einer ordentlichen Koordinatendarstellung über eine Vorlage würde ich das für einen echten Rückschritt halten. Besonders die N/S O/W- Angabe sollte schon sein. Wenn es um eine einheitliche (automatisierte) internationale Verwendung diese Vorlage geht, sollten wir vielleicht doch dem englischen den Vorzug geben. Die Vorlage von sk funktioniert jedenfalls auch mit dezimalen Gradangaben wenn man die Min und Sek wegläßt, somit würde ich ihr den Vorzug geben. Kolossos 19:13, 13. Feb 2006 (CET)

Ich habe mal als Diskussionsgrundlage eine relativ "kranke" Vorlage geschrieben mit der es möglich ist :

{{Geokoordinaten|lat-deg = 10|lat-min = 20|lat-sec = 30|lat = N|lon-deg = 40|lon-min = 50|lon-sec = 59|lon = W}}

in Vorlage:Geokoordinaten umzuwandeln.

Die ausgeschriebenen Nord West sind nur um zu zeigen, das eine Internationalisierung mit der Vorlage möglich ist. Ebenso kommt die Vorlage mit dezimalen Grad angaben klar:

{{Geokoordinaten|lat-deg = 10.12345|lat = N|lon-deg = 40.234234|lon = W}}

ergibt: Vorlage:Geokoordinaten.

Diese Vorlage wollte ich dann noch in eine zweite Vorlage stecken um die Fälle Text/Artikel/Text Artikel über if-Abfragen abzudecken das sollte nicht das Problem sein. Vorher sollte man aber abklären, ob wir unserem Servern die Vorlage wirklich zumuten wollen (Performance, Zuverläßigkeit,...). Kolossos 21:24, 14. Feb 2006 (CET)

Ich bin GEGEN eine dezimale Schreibweise von Koordinaten. Ja ich weiß, dezimale Werte können leichter verarbeitet werden. Aber man sieht diesen Koordinaten nicht mehr an, wie genau sie georeferenziert wurden! Gerade Daten aus Ortsdatenbanken sind oft nur auf Grad und Minute genau. Das führt besonders bei kleinen Orten zu (bis zu 2km) weit "verschobenen" Markierungen. Beispiel: Aus 51°13' wird dezimal 51,216667 mit (beliebig) vielen Nachkommastellen. Mit der Angabe 51° 13' 32" bzw. 51,225556 wäre der Punkt aber besser positioniert. Das macht uns die Arbeit zum Nachpflegen genauerer Koordinaten leichter. --Glg 13:13, 16. Feb 2006 (CET)

Das bedeutet dann aber auch, wenn man auf das Risiko der 20 If-Templates in meinem Vorlage-Vorschlag nicht eingehen möchte, dass es bei der Redundanz der Koordinaten bleibt. Ich könnte damit leben, weil sich die Koordinaten nachträglich nicht mahr ändern und wir in der Zwischenzeit auch Werkzeuge zur einfachen Eingabe haben. Kurzes Meinungsbild dazu? Oder sagt einfach so jeder seine Meinung dazu? Kolossos 13:30, 16. Feb 2006 (CET)
Ich finde den Einwand von Glg sehr gut. Die Genauigkeitsprüfung wird durch die dezmiale Schreibweise nicht unterstützt. Was mir gerade noch einfällt: Wegen der Stadtinfoboxen! Wenn wie bei der Schweiz die Koordinaten eingebaut werden, dann wird die eigentliche Koordinatenvorlage erst bei Generierung der HTML-Seite vom Server erzeugt. Das heißt, dass ich bei einer Suche nach der Vorlage in der Datenbank in diesem Artikel keine Koordinatenvorlage finde. Wichtig wäre also eine Umsetzung, die direkt in die Stadtinfoboxen integriert werden kann, da wir sonst die Datenbank nach den verschiedenen Typen von Stadtinfoboxen durchsuchen müssten. -- sk 13:38, 16. Feb 2006 (CET)
Siehe auch GISWiki:Datenqualität von Geodaten
@sk: *g* Dann sollten wir doch alle "ungenauen" dezimalen Angaben schnell wieder rausschmeissen . *g* Arcy 11:38, 28. Feb 2006 (CET)

Also ich wäre sehr dafür, wenn man sich langsam auf eine Verbesserung der Vorlage einstellen könnte - sowohl für Autoren (= keine doppelten Eingaben) als auch für die Verarbeitung (= klarere Formattierung ohne Schnickschnak, wie Spaces, oder Spezialzeichen wie -, ', " oder °).
Der Einwand, dass man Koordinaten in reiner Dezimalnotation (ddd.dddd) nicht mehr ansieht, wie genau sie erfasst wurden, ist nicht ganz korrekt: Es gibt natürlich auch in der anderen Richtung Beispiele mit nicht-abbrechenden Zahlenreihen... Und genauso wie bei der Altgrad-Notation ist es auch bei Dezimalnotation nützlich - wenn auch nicht hinreichend - sich auf die Anzahl Stellen zu einigen. Ich habe die entsprechenden Nachkommastellen-Bereiche nicht genau im Kopf; ich vermute, dass vier (allenfalls mit Nullen aufgefüllte) Nachkommastellen für unsere Zwecke genügen. Wenn eine Aussage über die Genauigkeit (bzw. Qualität?) der Koordinatenangaben wichtig würde, dann geht es nicht ohne zwei weitere Attribute, wie z.B. Lage- und Hoehengenauigkeit. Das wären aber Angaben, die ich im Rahmen dieses Projektes vorläufig als unrealistisch betrachte.<br\> In Anlehnung an Kolossos' Vorschlag komme ich damit auf folgende Vorlagen: 

 
Variante englisch:
  {{Geocoordinates|context=text|lat = 10.1234|lon = 40.2342|extension = 2|type = landmark}}
Variante deutsch:
  {{Geokoordinaten|kontext=Text|ostwert = 10.1234|nordwert = 40.2342|ausdehnung = 2|typ = Landmarke}}

In Ergänzung zu meinem Vorschlag oben sind dabei die in Datenbanklinks üblichen Trenner '|' und bei der eingedeutschten Variante die konsequente Deutschschreibung (Bsp. "landmark => Landmarke") zu beachten. -- Geonick 01:09, 28. Feb 2006 (CET)

  • Eine vertikale Variante der Koordinatenvorlage würde ich jedenfalls vorziehen. Die Vorschläge oben finde ich alle ganz gut.
  • Die Scale-Angabe würde ich rauslassen und stattdessen eine Angabe über die Grösse des Objekts vorsehen, die dann für viele Applikationen eine Umrechnung für einen Betrachtungsabstand/winkel/ausschnitt zulässt. Der Parameter ausdehnung ist eine gute Lösung. -- Simplicius 13:45, 28. Feb 2006 (CET)
Nur damit wir uns nicht falsch verstehen ich bin nach meinen Experimenten mit der Vorlage eher zur Überzeugung gekommen, dass im Moment kein Weg an den redundanten Koordinateneingaben vorbeiführt. Kolossos 20:40, 1. Mär 2006 (CET)
Warum müssen die Koordinaten doppelt eingeben werden? Damit wird nicht nur das Prinzip der Konsistenzhaltung sondern auch dasjenige der 'Sichtkontrolle' verletzt, denn es wird nicht das dargestellt, was maschinell weiterverarbeitet wird. --Geonick 00:22, 12. Mär 2006 (CET)

Nochmals zu Dezimalnotation:
"Der Einwand, dass man Koordinaten in reiner Dezimalnotation (ddd.dddd) nicht mehr ansieht, wie genau sie erfasst wurden, ist nicht ganz korrekt: Es gibt natürlich auch in der anderen Richtung Beispiele mit nicht-abbrechenden Zahlenreihen... Und genauso wie bei der Altgrad-Notation ist es auch bei Dezimalnotation nützlich - wenn auch nicht hinreichend - sich auf die Anzahl Stellen zu einigen."
Mir geht es nicht im die reine Anzahl der Nachkommastellen. Natürlich kommt es bei einer (Rück-)Umwandlung von Dezimalen Koordinatenwerten in die Grad-Minuten-Sekunden-Schreibweise auch wieder zu Rundungsfehlern und nichtabbrechenden Zahlenreihen. Aber man kann an einer Dezimalschreibweise nicht mehr erkennen, ob die Koordinaten aus einer "kastrierten" Datenbank kommt (d.h. der Sekundenwert wird nicht bekanntegeben) oder nicht. Die Werte aus der GeoDB Ortsdatenbank finde ich unzureichend, auch viele Internet-Kartenanbieter unterdrücken absichtlich die genauen Koordinaten (Sekundenwerte). Leider. Die Schreibweise in der Vorlage kann ruhig einfach gehalten werden, ohne die Trenn- und Sonderzeichen ° ' " , also schlicht 23 45 67 N 12 34 56 W in einer oder zwei Zeilen.
Bei der Gelegenheit: Woher wollt ihr die Höhenangabe beziehen? Sag bitte nicht GTOPO30 oder SRTM oder gar GoogleEarth... Das Höhenmodell dort ist nur für Orte im Flachland geeignet. Für Gebirge sind die horizontalen Raster (ca. 1km bei GTOPO30 bis 90m bei SRTM) und die somit interpolierten Werte dazwischen nicht das Gelbe vom Ei. Da verschwindet so mancher Berg im Raster ;-) --Glg 17:48, 2. Mär 2006 (CET)

Die Höhe ist bei der hier diskutierten Vorlage, bzw. deren Verbesserung noch nicht gross angesprochen worden. Sie kann m.E. bis auf weiteres weggelassen werden, denn sie kann 'jederzeit' aus einem (natürlich möglichst genauen) Geländemodell hergeleitet werden unter der Annahme, es werde alles auf die Erdoberfläche projiziert. Was die Dezimalangabe betrifft: Hier verstehe ich das Argument nicht "Aber man kann an einer Dezimalschreibweise nicht mehr erkennen, ob die Koordinaten aus einer "kastrierten" Datenbank kommt (d.h. der Sekundenwert wird nicht bekanntegeben) oder nicht": Niemand kann eine Herkunft an einer Zahl erkennen, oder? Auch wenn die Sekundenangabe noch da wäre, dann wären dies reine Vermutungen.
. Ich gebe zu, dies war unpräzise ausgedrückt. Lass es mich ausführlicher umschreiben: Die meisten Koordinaten, die zu Wikiartikeln erfasst wurden, stammen aus Datenbanken wie z.B. OpenGeoDb, geonames.org oder anderen frei zugänglichen Kartendiensten. Diese liefern leider nur Koordinaten mit Grad- und gerundeten Minutenangeaben (ddd°mm'). Genauere referenzierte Daten mit Sekundenwerten oder Minutenwerte mit Nachkommastellen sind dort (nicht mehr!?) frei zugänglich. In einigen wenigen Wikiartikeln haben sich Autoren bereits die Mühe gemacht, Orte auf Bogensekunde genau zu georeferenzieren. Beide lassen sich bisher prima an der Schreibweise der Koordinaten unterscheiden: 51°13'N <-> 51°13'32"N . Soweit, sogut. Werden die Koordinaten aber in der Dezimalschreibweise erfasst, sieht man der Koordinate deren "Genauigkeit" nicht mehr an: 51,216667 N <-> 51,225556 . D.h. man müsste jeden Punkt in einer Karte nochmals genau betrachten und dann entscheiden, ob er zur Verbesserung der Georeferenzierung korrigiert werden sollte oder nicht (sprich den Wert der Bogensekunde nachpflegen). Siehe auch Stichwort: "bei kleineren Orten liegen weisen sie häufig auf Punkte außerhalb des Ortsgebiets, manchmal sogar auf Machbarorte". - hab ich mich nun verständlicher ausgedrückt? --Glg 17:03, 16. Mär 2006 (CET)


Ich - und alle Roboter - wäre(n) froh, wenn die Meinungen auf die oben erläuterte Verbesserung der Vorlage Koordinate 'konvergieren' könnten. Dabei möchte ich abermals betonen, dass man mit der aktuellen zwar leben kann, wenn es auch schmerzt, da Redundant und entgegen dem 'Sichtbarkeitsprinzip' (vgl. oben). Noch 'schlimmer' als die aktuelle Koordinate zu verwenden ist nur noch, eine ganz andere zu nehmen, wie das offenbar bei verschiedenen Vorlagen (wie z.B. unten bei "Ein ' sind wieviel m?" diskutiert) immer noch der Fall zu sein scheint. --Geonick 00:22, 12. Mär 2006 (CET)

Artikel ohne Koordinate

Hi Leute, ich hab hier mal eine Textdatei erstellt, die ausgibt welche Artikel derzeit noch keine Koordinate haben, aber eine "Kategorie:Ort...". Die Textdatei beinhaltet zeilenweise den deutschen Artikelnamen, evt. englischen Artikelname, Artikelgröße und Kategorien. Durch die englischen Namen kann man auch sehr schnell ausländische Ortschaften mit Google Earth finden. Mein Vorschlag wäre, wenn wir statt der Überschrift "Projektstand" diese Liste verlinken, mit noch zu georeferenzierenden Ortschaften. -- sk 15:47, 12. Feb 2006 (CET)

Da Georeferenzierung immer Ortskenntnis voraussetzt und ich mir somit eine Verortung von Orten in Rumänien z.B. nicht zutrauen würde finde ich die regionalspezifische Anzeige von CatScan besser, zumal diese immer aktuell ist. In deiner Datei stehen 19.273 Orte es gibt also viel zu tuen. Schön wäre auf jeden Fall eine Tabelle im Datum und Anzahl der unverorteten Orte. Ich hoffe die Zahl nimmt dann im Laufe der Zeit ab und nicht zu. Kolossos 19:41, 12. Feb 2006 (CET)
Georeferenzierung erfordert IMHO keinerelei Ortskenntnis. Die Erfordernis von Ortskenntnissen würde bedeuten, dass die bisherige Arbeit von vielen am Projekt hier fehlerbehaftet ist. Viele haben ganze Landstriche georeferenziert. Arcy 22:18, 12. Feb 2006 (CET)
Ich denke auch, dass bei Städten ab 5000 Einwohner sich problemlos in Google Earth die Ortsmitte/Marktplatz/Bahnhof ermitteln lassen. Zumindest hab ich so schon zahlreiche Orte georeferenziert. -- sk 09:28, 13. Feb 2006 (CET)

Kategorie für "Ortsteil"

Ich schlage vor, mal über eine Kategorie "Ortsteil" nachzudenken, damit man sie später mal mit einem eigenen Symbol im Satellitenbild darstellen kann.

Es ist inkonsistent, irgendwo im Hochsauerlandkreis einer Stadt 50.000 Einwohner zuzuordnen, dem Stadtteil auf der anderen Flußseite dann noch mal 25.000 Einwohner.

Dann hat man 75.000 Einwohner, obwohl es nur 50.000 sind.

Hier sollte ein Symbol für "Stadtteil" reichen.

Simplicius 14:19, 16. Feb 2006 (CET)

Koordinatenübernahme vorhandener Daten per BOT

hat schon mal jemand hier Bots programmiert? ich frage mich schon länger wieso immer noch koordinaten per hand eingepflegt werden und nicht einfach aus vorhandenen Datenbanken ausgelesen und per bot eingepflegt werden. Arcy 10:24, 13. Feb 2006 (CET)

hallo? Arcy 00:50, 15. Feb 2006 (CET)

P.S. Man kann übrigens auch anhand solcher vorhandenen Datenbanken Links zur WP generieren. Mit etwas Glück werden dann bei nicht vorhandenem Artikel neue Artikel geschrieben. Ein Bot könnte aber ja schon mal die vorhandenen Datenbanken aussaugen (muss gerade dabei an mars-attacks denken) und die Daten in die WP eintragen. Arcy 00:56, 15. Feb 2006 (CET)

Hallo Arcy, automatisierte Zuordnungen von Koordinaten und Artikeln halte ich für problematisch. Zum einen sind die Daten aus den GeoDB nur auf Grad und Minute genau (bis zu 2km Abweichungen), zum anderen gibt es doppelte Namenseinträge für verschiedene Orte (z.B. Freiburg im Breisgau, Freiburg an der Elbe, Freiburg in der Schweiz). Ok, war ein "einfaches" Beispiel. Aber versuche mal einen Ortsnamen "Grefrath" richtig zuzuordnen :-( Fazit: Idee gut, Umsetzung zu fehlerträchtig. Gruss --Glg 13:29, 16. Feb 2006 (CET)

So vollautomatisch läßt sich das sicherlich nicht machen, aber vielleicht immerhin halbautomatisch, also mit händischer Überprüfung. Arcy 13:48, 16. Feb 2006 (CET)
Datenbanktechnisch ist eine automatisierte Übernahme nur dann sinnvoll, wenn die Ortsnamen 1:1 entsprechen.
Beispiel: Hagen / Hagen, Westfalen / Hagen in Westfalen / Hagen, Westf. / Hagen (Westfalen) / Stadt Hagen / nicht zu verwechseln mit anderen gleichnamigen Orten und Ortsteilen.
Und auch das Vorhandensein ist nicht selbstverständlich. Selbst auf der Kreisebene gibt es noch ständig Kreisreformen (Kreise und kreisfreie Städte verschwinden oder entstehen neu).
Bleibt also die Methode "Schmökern und Prüfen" nach meiner augenblicklichen Meinung. -- Simplicius 14:06, 16. Feb 2006 (CET)
Eine Zuordnung Wikipedia/OpenGeoDB kriegt man ganz gut hin, wenn man nicht nur die Ortsnamen, sondern auch die Kreise berücksichtigt. Ich hatte schon mal eine Liste erstellt, die den allermeisten Wikipedia-Ortsartikeln für Deutschland den passenden OpenGeoDB-Key zuordnet. Wenn jemand einen Bot programmiert, der die Daten dann übernimmt, kann ich die Liste gerne noch mal aktualisieren und hier zur Verfügung stellen. -- 84.153.247.168 01:18, 2. Mär 2006 (CET)

siehe auch: Hilfe_Diskussion:Vorlagen#If-Vorlage_für_Georeferenzierung. Arcy 18:05, 1. Mär 2006 (CET)

Auch hier ein bißchen Spam für eine gute Sache

http://petition.publicgeodata.org/ --Historiograf 03:15, 18. Feb 2006 (CET)

Super! Danke für den Hinweis auf diese Petition. -- sk 16:32, 19. Feb 2006 (CET)

Hinweis

http://wiki.genealogy.net/wiki/Computergenealogie/2006/02#Koordinateneingabe_im_GOV --Historiograf 04:29, 18. Feb 2006 (CET)

Vorgehensweise bei Artikel ohne Koordinaten

Die vor kurzem hier verlinkte Webseite von http://www.geonames.org ist auch Seitens des angebotenen DB-Download Angebotes und der verwendeten Type-Angaben recht interessant.

Daraufhin habe ich heute mal die Liste der fehlenden Einträge von Stefan Kühn mit den 6.2 Mio Einträgen der Geonames.org zusammen gewurfen und daraus Geotags erzeugt, heraus kam dabei folgende gepackte HTML-Datei, mit der man weiterarbeiten könnte. Durch die Suchfunktion im Browser kann man trotz der alphabetischen Ordnung der Ortsnamen auch systematisch bestimmte Länder abarbeiten. Die Geotags müssen nur mit Srtg-C Strg-V umkopiert werden. Natürlich sollte die Arbeit unter mehreren Benutzern noch etwas aufgeteilt werden. Bei der Prüfung der Einträge sollte der Einwohnerzahl und dem richtigen Land besondere Aufmerksamkeit geschenkt werden. Für einen Bot sind die Daten meines Erachtens nach nicht zuverlässig genug zumal sich die Namesdopplungen nur schwer trennen lassen. Es handelt sich dabei um knapp 9.000 Orte. Kolossos 20:33, 27. Feb 2006 (CET)

Ich habe die Datei heute durch das Weglassen der Klammern im Artikelname nochmal auf ca. 11.000 Einträge erweitert, siehe Artikel-ohne-Koord2.zip. Und ich habe die Datei durch die Eingrenzung auf Orte mit Einwohnerzahl nochmal auf ca. 6.300 Einträge verkleinert, siehe Artikel-ohne-Koord2pop.zipKolossos 10:55, 28. Feb 2006 (CET)
Die Seite "geonames" ist immer noch hier verlinkt.
Tolle Sache, aber leider sind die Koordinaten von der Qualität sehr schlecht. Liegen besonders bei kleinen Ortschaften meist total daneben. Vielleicht könntest du jeweils noch einen Link einbauen, der zu den Online-Map-Resourcen führt. So kann man fix überprüfen, wei genau die Koordinate den Ortsmittelpunkt trifft. -- sk 15:44, 28. Feb 2006 (CET)
Ein Link ist natürlich kein Problem. Das Ergebnis mit Links zu Kvaleberg und GoogleEarth: Artikel-ohne-Koord3pop.zip. Kolossos 17:00, 28. Feb 2006 (CET)
Hilfreich wäre auch mal eine Statistik, bei der zu jedem Land die tatsächliche Einwohneranzahl mit der Einwohneranzahl verglichen wird, die sich aus der Summe der Einwohner der georeferenzierten Orte des Landes ergeben. So würde man sehr schnell sehen in welchen Ländern der die größten Städte noch fehlen und wo wir noch viel aufholen müssen (z.B. China, Indien, USA). --sk 17:57, 2. Mär 2006 (CET)
Ich hab zZ keine Zeit sonst würde ich mich da mal aktiv beteiligen, aber ich stelle mir immer noch tool vergleichbar meines IWLC vor um die Daten abzuarbeiten oder zu bearbeiten .. Nur hab ich zZ keine Zeit für programmieren .. wir sollten aber mal einen Termin im IRC oder für Skype ausmachen ? Flacus
Fr, Sa oder Sonntag so gegen 19:00 Uhr im IRC? Cool wäre auch ein Treffen im RL. -- sk 18:58, 1. Mär 2006 (CET)
Hab zwar an den Tagen mit dem Wikipedia:Chemnitzer_Linuxtag_2006 zu tuen, aber gerne (Fr oder So). Vielleicht auch "fingerschonend" parallel über Skype. Kolossos 20:37, 1. Mär 2006 (CET)

Wikipedia Handheld GPS

Ich habe zum ersten mail google Earth mit dem Wikipedia Skin getestet und fand es nur genial. In die gleiche Richtung habe ich auch eine Idee gehabt, die ein wenig über die Google Earth Anwendung hinausgeht. Leider habe ich nicht die nötigen Programmierkenntnisse, um diese Idee umzusetzen und nun suche ich Mitstreiter, die an der Lösung dieser Idee interessiert sind.

Hier die Idee:

Wikipedia GPS

Seit Mitte 2004 bin ich großer Fan, Leser und Autor der Online Enzyklopädie Wikipedia. Was so klein als interessante Seite im Web gefunden wurde ist nun wirklich eine gute Adresse, wenn man mal wieder was nicht weiss oder doch mal nachguckt, bevor man Blödsinn redet.

Vor ein paar Wochen hat die Wikipedia in einer Offline-Version nun auch den Weg auf meinen Palm gefunden (wie es geht, steht hier), sodass bei jeder Frage, die einem in der freien Natur über den Weg läuft, schnell per Palm eine Antwort gefunden wird. Tolle Sache.

Doch es geht immer noch ein wenig besser, so glaube ich zumindest. Denn warum sollte man die Wikipedia in dieser Offline-Version nicht mit dem Navigationssystem in einem Pocket PC verknüpfen?

Wie meinen???

Nun, für ca 300 Euro wird heute in jedem besseren Elektronikladen (und auch bei Aldi ;-) ein Pocket PC Handheld (Bild 1) mit eingebautem GPS Empfänger und Navigationssoftware verkauft. Damit ist man dann per Auto, Fahrrad oder zu Fuß immer auf dem richtigen Weg.

Auf der anderen Seite kann man heute kostengünstig eine entsprechende Betrachtungssoftware (z.B. Tomeraider) auf einem Pocket PC mit Windows mobile Betriebssystem installieren und über diese Software eine Offline Version der Wikipedia (gespeichert auf einer eingesteckten Speicherkarte) durchstöbern.

Hinzu kommt nun die Tatsache, dass die überwiegende Zahl der deutschen Wikipedia-Artikel, die sich um Orte oder um Dinge drehen, die an bestimmten Orten festgemacht werden können (Denkmäler, Brücken, einzelne Gebäude), mit den Angaben der Längen- und Breitengrade versehen sind (meist oben rechts im jeweiligen Artikel). Diese Wikipedia-Artikel enthalten also exakten katographischen Daten.

Wäre es jetzt nicht klasse, wenn man diese Längen- und Breitengrade der Artikel mit der Kartendarstellung der Navigationssoftware verknüpfen würde!

Was bedeutet das? Oder was hat das für einen Sinn?

Nun, wenn ich die Kartendarstellung meines Navigationssystems aufrufen würden, sollte ich dann zwei Dinge auf dem Display sehen:

1.) Die Karte würde mir den Punkt anzeigen, an dem ich in diesem Moment gerade befinden würde.

2.) Weiterhin würden in dem Kartenbild etliche Punkte auftachen, die durch die Koordinatenpunkte der Wikipedia-Artikel entstehen würden (Siehe Bild 2). Für jeden dieser Punkte gibt es jeweils einen Artikel in der Wikipedia.

Das Geniale dieser Darstellung ist, dass man nicht erst selbst darauf kommen muss, ob es einen Eintrag für Dies oder jenes in der Gegend gibt, in der man sich gerade befindet. Nein, man sieht einen Punkt auf der Karte, klickt drauf und landet sofort beim dementsprechenden Eintrag in der Wikipedia. (Siehe Bild 3).

Natürlich müßte man bei sehr vielen Einträgen an einem Ort eine Differenzierung machen, wieviele oder welche Punkte eingetragen werden, aber das ließe sich sicher lich in irgendeiner Weise regeln.

Technisch gesehen bedeutet diese Idee, dass man irgendwie die aus der Wikipedia ausgelesenen Koordinaten auf der Karte des im Pocket PC installierten Navigationssoftware darstellen müßte. Da kenne ich mich einfach zu schlecht aus, wie die Schnittstellen eines solchen Programmes aussehen. Alternativ könnte man natürlich auch die jeweils aktuellen GPS Daten des Gerätes auslesen und die Wikipedia Koordinaten auf einer eigenen karte darstellen und den aktuellen Standort immer zentral in der Mitte des Kartenausschnittes abbilden.

Kurz gesagt, eigentlich sind alle Komponenten eines solchen Systems schon da, aber noch nicht vernetzt. Ich weiss einfach nicht, wie das geht, also wer kann diese Idee technisch umsetzen??

Den Text und die Abbildungen finden Sie auch auf meiner Webseite www.sigsig.de

Wer würde bei dieser Idee mithelfen, um sie umzusetzen? Joho345

...

Meine Umkreis.php-Kartenanzeige ist eine relativ einfache CSS-Geschichte wenn man, PHP und MySQL zur Verfügung hat. Wenn man also mit einem Laptop unterwegs wäre könnte man zumindestens über einen Xampp recht einfach eine Offline Version betreiben. Wenn das ganze unter einem Palm und mit einer einfachen Installation laufen soll, ist wohl eine komplette Neuprogrammierung notwendig. Ich kenne keine GPS-Programme mit Straßenkarteneinblendung wo man auch noch die Wikipedia-Daten als Links einblenden könnte. Zum Auslesen der GPS-Daten kann ich wenig sagen, die Frage ist ob die GPS-Koordinaten in irgendeine Datei geschrieben werden? Wenn ja dann könnte PHP diese mit Sicherheit auslesen. So viel dazu, zu mehr werde ich wohl in nächster Zeit auch nicht kommen. Aber natürlich kann ich den Quelltext und die DB zur Verfügungg stellen. Kolossos 21:47, 6. Mär 2006 (CET)
Der Quelltext würde mich mal interessieren. Wo kann man den downloaden? Arcy 22:22, 6. Mär 2006 (CET)
Hier. Nicht schön aber selten. Kolossos 22:42, 6. Mär 2006 (CET)
Hallo, vielleicht sehe ich das zu einfach, aber eigentlich müsste man das doch auch so machen können:

1.) Also eine Offline Variante für Pocket PCs kann man ja hier runterladen und auf eine ausreichend große SD Karte speichern. Wenn mann nun ein entsprechendes Betrachtungsprogramm (z.B. Tomeraider) auf dem Pocket PC installiert, kann man diese Offline Variante durchsuchen.

2.) Eine Darstellung in einem Navigationsprogramm direkt ist möglicherweise gar nicht notwendig. Mann könnte doch auch selbst ein Programm schreiben, dass auf einer bestehenden zoombaren Kartengrafik (möglichst mit Landesgrenzen und den wichtigsten Strassen) die aktuelle Position anzeigt. Dazu ist es natürlich notwendig, dass man die Daten des GPS Modul immer alktuell auslesen kann. Dann bräuchte man gar keine Schnittstelle zum bestehenden Navigationssystems.

3.) Jetzt müßte man noch ein Mapping der Koordinate auf diese Kartendarstellung hinbekommen. Klickt man nun auf einen der Punkte, müßte man zum jeweiligen Artikel innerhalb des Betrachtungsprogramms gelinkt werden.

Vielleicht sehe ich das zu simpel, aber eigentlich müßte das doch gehen? Joho345 09:28, 7. Mär 2006 (CET)

Möglicherweise gibt es auf PlaceLab.org ein Projekt, welches für diesen Zweck angepasst werden könnte. Ich habe mal dort mit JavaWPS eine kleine Applikation beigesteuert, welche eine Positionierung rein mittels WLAN Access Points ermöglicht; müsste evtl. nochmals an PDA angepasst werden (ist etwas, das in Placelab schon vorgesehen ist). WPS bedeutet u.a., dass kein GPS nötig ist. Ein WLAN-Empfänger genügt, vorausgesetzt es hat schon jemand in der Gegend WLAN Access Points mittels GPS gesammelt und auf PlaceLab.org hochgeladen (und falls nicht, kann man selber Hand anlegen...). -- Geonick 13:47, 7. Mär 2006 (CET)
Wie genau ist denn die Messung des Placelab Projekts? Kann man das so in Metern sagen? Und offensichtlich werden auch Sendemastem von Handys benutzt. Man bräuchte also, wenn ich das richtig verstehe, nicht unbedingt einen Wifi-Empfang. Die PDA Anpassung ist nicht unbeding notwendig, da ich als Handheld Plattform eh eher die Geräte mit Pocket PC Betriebssystem gesehen habe und diese Software ist ja für Pocket PC geschrieben worden. Somit sollte die ja mit wenig Aufwand umstellbar sein, oder? Joho345 14:22, 7. Mär 2006 (CET)
Ca. 10m in Gebäuden ab zwei bekannten und verorteten Access Points und z.T. mit WLAN-Karten-bedingter Verzögerung (siehe JavaWPS > Wiki > FAQ). Ansätze, bei denen zusätzlich die Acccess Point-Empfangsstärke-Verteilung registriert wird, erzielen Ergebnisse im Meterbereich. Das ist aber mit (noch) grösserem Erfassungsaufwand verbunden (vgl. erwähntes FAQ und die aktuellen heise-News zu MagicMap). JavaWPS ist ein auf das Wesentliche abgespecktes und funktional erweitertes Programm aus der grossen Menge der PlaceLab-Klassen. Viele Komponenten sind da, müssen aber ebenfalls noch richtig 'zusammengesetzt' werden (inkl. WLAN-Treiber). Nur schon die Tests werden einige Zeit beanspruchen. Und: ja, andere Positionierungs-Arten, wie z.B. über GSM (Sendemastem von Handys) sind denkbar. Dies scheitert zur Zeit am Unwillen der Provider. WLAN-Positionierung ist m.E. zurzeit die vielversprechendste Alternative, bzw. Ergänzung zu GPS - aber eben: nur wenn möglichst viele mithelfen, Access Points zu sammeln. --Geonick 19:22, 7. Mär 2006 (CET)
P.S. Ich schlage vor, diese "Wikipedia GPS"-Software-Projekt-Idee woanders hin zu verlegen. Ich hätte da noch einige Fragen betreffend dem (Daten-orientierten) Projekt Georeferenzierung... --Geonick 19:22, 7. Mär 2006 (CET)
Danke für die Antwort. Klar können wir das Projekt gerne verlegen, ich weiss nur nicht wohin. Hast Du einen Vorschlag? Joho345 20:13, 7. Mär 2006 (CET)
Man könnte einen Wiki-kompatiblen Projekt-Namen vergeben, z.B. unter 'WikiProjekt Georeferenzierung' einen Unter-Artikel erzeugen und dann die Diskussion rund um diese Projektidee inkl. diesen ganzen Abschnitt dorthin verschieben. --Geonick 00:31, 12. Mär 2006 (CET)
OK, warum nicht, ich weiss aber nicht wie das geht. Kann mir da einer einfach helfen und das machen --Joho345 22:50, 12. Mär 2006 (CET)
Es gibt bereits Tools, die sich in PDA-Navigationssoftware gängiger Hersteller einklinken und POIs in der Karte anzeigen und zusätzliche Infos (Links, HTML-Seiten) darstellen. Siehe
* http://www.pocketnavigation.de/ucontent/start__6/5.6.0.html unter "POI-Warner". Insbesondere die (teils kostenpflichtigen) Portugal-Reiseführer und Burgenführer haben dies umgesetzt.
* http://www.navifriends.com/phpbbForum/viewforum.php?f=45 der POI:Observer ist eine kostenfreie Alternative dazu.
Beide bieten die Möglichkeit, zur aktuellen Position die Point-of-Interest im nahen Umkreis auf der Karte anzuzeigen oder das Routing zu einem gewünschten Punkt zu starten. Eingebunden werden diese über ein sogenanntes Overlay. Es besteht aus einer simplen Textdatei mit Koordinaten und einen Beschreibungstext. Der Text könnte einen Link auf de.wikipedia.org zum passenden Artikel enthalten oder auf eine lokal auf dem PDA gespeicherte HTML-Seite verweisen (für Offline-Betrieb). --Glg 17:25, 16. Mär 2006 (CET)

Ein ' sind wieviel m?

haie ihrs, wieviel Meter sind ein ' ... sagen wir mal in Berlin ;) oder München oder so .. würde es gern wissen um einen Vorstellung davon zu bekommen ...Sicherlich Post 22:47, 9. Mär 2006 (CET)

Rechne doch mal den Umfang des Breitengrads anhand des Abstands von der Erdachse aus, also Erdradius bzw. 6.370 km * sinus (90 - Breitengrad) * 2 PI, und teile das dann durch 360 * 60, dann hast du den Abstand einer Minute in km. -- Simplicius 23:23, 9. Mär 2006 (CET)
für die Breite gilt übrigens 1 Minute entspicht einer Seemeile = 1852m. Für die Länge kannst due es wie von Simpicius beschrieben mit 1852m *cos(Breite) berechnen. --Langläufer 23:36, 9. Mär 2006 (CET)
und siehe Seemeile, da stehts weiter unten in Beispielen. GuidoD 23:38, 9. Mär 2006 (CET)
hmm okay bei seemeile hatte ich natürlich nicht geguckt ;O) .. danke euch auf jeden fall; ich bin zum einen wieder ein stück klüger und zum anderen weiß ich, dass ich Vorlage:Infobox (Polen) wohl doch noch um sekunden erweitern muss ;) ...Sicherlich Post 23:42, 9. Mär 2006 (CET)
Bitte bei der Infobox wirklich die Vorlage Koordinaten Text einbinden, wir haben sonst beim auslesen aus dem DB-Dump immer das Problem wenn wir für jedes Land ein anderes Skript brauchen. Weiß jemand wo die Disk. zur Schweizer Infobox archiviert wurde? Kolossos 09:04, 10. Mär 2006 (CET)
@Sicherlich schau mal bei Abweitung! -- sk 09:56, 10. Mär 2006 (CET)
@Kolossos: die Vorlage wird verwendet: {{Koordinate Text Artikel ...}} steht drin ...Sicherlich Post 10:14, 10. Mär 2006 (CET)
@Sicherlich. Nein ich meine die direkte Verwendung der Vorlage so wie es beim Artikel Berlin gemacht ist, dass ist für sk wesentlich einfacher auslesbar, da er im Moment direkt auf die DB zugreift. Kolossos 10:25, 10. Mär 2006 (CET)
nun die tabelle bei Berlin ist aber wesentlich schwerer für einen Nutzer zu bearbeiten. Und das bearbeiten von tabelleninhalten mittels bot ist bei der polnischen tabelle auch weitaus einfacher; ich würde eher vorschlagen alle Infoboxen nach "polnische vorbild" umzubauen...Sicherlich Post 10:55, 10. Mär 2006 (CET)
@sk: aha wir haben sogar einen Artikel dazu .., sehr cool ;) .. leider nicht in Breitengrad oder Längengrad verwikit :( ... vielleicht kann jmd. von euch einen klugen satz schreiben und es verlinken?! ...Sicherlich Post 10:16, 10. Mär 2006 (CET)
Eine Angabe mit Sekunden und Hunderstelsekunden ist auf etwa +- 15 cm genau, entspricht also etwa einem Eingang oder der Fußmatte. -- Simplicius 10:43, 10. Mär 2006 (CET)
naja sekunden; wenn ich da oben lese ist eine Minute mal fast 2km; das kann bei kleinen Städten ja schon was ausmachen wenn man auf der google-Karte sucht ;) ...Sicherlich Post 10:55, 10. Mär 2006 (CET) wobei gerade bei kleinen Orten die Sekundenangaben eh meist fehlen ;) .. aber seien wir für die zukunft gerüstet
Unsere Vorlage Koordinaten ist auf jeden Fall flexibler, da sowohl Minuten- als auch Sekundenangaben darin verarbeitet werden können. Ich gebe auch zu bedenken, dass es für unsere Vorlagen verschiedene Hilfsmittel gibt. Auch für die geplannte Verwendung von Bots z.B. zum Abgleich der engl. und der deut. WP oder zum auslesen aus geonames.org sind einheitliche Vorlagen zu bevorzugen. Kolossos 11:18, 10. Mär 2006 (CET)
schön, aber die bots sollen unterstützen; also richten sich die Bots vorzugsweise nach dem Nutzer und nicht umgekehrt. Die tabelle ist wohl recht unstrittig viel leichter zu bedienen. Die Daten für polnische Städte habe ich bisher noch immer in der "nicht-dezimalen" (wie auch immer das heißt, also mit ° und ') gefunden, wenn es ein problem wäre könnte man die vorlage auch für optionale dezimalschreibweise anpassen. Für polnische Städte bietet sich eher ein abgleich mit der polnischen WP an; selbige verwenden die tabellen in der übersichtlichen, und auch botfreundlichen, Form ...Sicherlich Post 11:31, 10. Mär 2006 (CET)

Und nicht vergessen: die Kartenquellen können bis zu 50 km ungenau sein *g*. Arcy 11:52, 10. Mär 2006 (CET)

@Sicherlich: Wir sind z.Zt. daran - aufbauend auf der Arbeit von sk und kolossos - die Koordinaten aus den Wikiartikeln auszulesen. Die Vorlage 'Koordinaten' ist zwar nicht optimal, genügt aber fürs Erste. Es macht die Arbeit zum Auslesen nicht gerade einfacher bis unmöglich, wenn andere Vorlagen andere Codierung von Längen- und Breitengrad verwenden. Daher meine dringende Empfehlung: Verwendet bitte die Vorlage Koordinate und verwendet sie bitte auch in anderen Vorlagen --Geonick 23:51, 11. Mär 2006 (CET)

Geonick ich kann deine argumente durchaus bedingt verstehen. aber die bisherigen townbox ist für newies absolut undurchsichtig. die neue variante ist da deutlich leichter verständlich, leichter zu bedienen und bspw. müssen keine redundanzen wie die anpassung der Ew-Zahlen gepflegt werden. Mein vorschlag; nehmt die methode von pl in die abfrage auf und so auch andere länder (z.b. schweiz) dieselben namen für die sachen nehmen sollte es kein größeren problem darstellen. und es passt. perspektivisch (und auch ziemlich nahe perspektive) kann die nutzung der townbox wie in pl auch zur abstimmung weiterer daten mit pl genutzt werden; per bot; hier zu nennen sind die beispielsweise die einwohnerzahlen oder die bürgermeister u.ä.) ...Sicherlich Post 01:10, 12. Mär 2006 (CET)
Ich habe mir schon seit längerem gedacht, dass irgendwann mal diese Optimierung der Stadttabelle kommt. Ich glaube es wäre für die unbedarften Benutzer ein großer Vorteil und der Mensch sollte immer im Vordergrund stehen. Wichtig wäre vor allem aus meiner Sicht, dass man sich einen Standard für alle kommenden Länder ausdenkt (von mir aus so wie in Polen). Also insbesondere das die Benennung der Felder überall gleich ist. Unmöglich wäre die Arbeit mit x verschiedenen Formaten. In der polnischen Formatvorlage sehe ich derzeit alles was wir brauchen vertretten (ISO 3166-2, Gradzahlen, ..., Einwohner). Wenn dieser Standard beibehalten wird, dann wäre das super. Einzigstes Problem ist noch die Gradangabe! Dort sollte irgendwie noch Nord und Süd bzw. Ost west. Ok Polen liegt nur N,E aber bei Frankreich oder England gibt es dann schon Probleme. Zusätzlich sollte wie im englischen jede Vorlage, die Geokoordinaten besitzt, in einer Kategorie gesammelt werden (Siehe w:en:Category:Coordinates templates). Sonst verliert man schnell den Überblick. Die Programm dafür anzupassen wird Mühe kosten, aber ich wäre trotzdem für eine Vereinheitlichung der Städtetabelle. Größter Vorteil ist ja dann die zentrale Optimierungsmöglichkeit bei zig-tausend Artikeln über nur eine Vorlage. Alle anderen Sehenswürdigkeiten etc. können wir ja weiter nach der jetzigen Form georeferenzieren. -- sk 08:38, 12. Mär 2006 (CET)
Siehe auch Kategorie:Vorlage mit Koordinate, die müssten alle unter einen Hut gebracht werden. Das würde uns das Leben erleichtern. -- sk 09:10, 12. Mär 2006 (CET)
hmm die Nord/Süd/West/Ost-Sache könnte man ja über das Ende löschen; also ein GradO ist Osten, GradW Westen? ...Sicherlich Post 11:30, 12. Mär 2006 (CET)
Ich bin auch dafür, eine Infobox á la Polen einzuführen und dies möglischst Wikipedia-weit einheitlich. Das würde das Eintragen der Daten und insbesondere der Geokoordinaten wirklich erleichtern. Und wenn Stefan sich schon bereit erklärt, seine Programme anzupassen, sollten wir das Ganze tatsächlich nun mal angehen. Bezüglich der N/O/S/W-Ergänzung der Koordinaten müsste man sich aber schon nochmal Gedanken bezüglicher der Verständlichkeit für den unbedarften Nutzer machen. Die von Sicherlich vorgeschlagene Variante halte ich dabei nicht für die Ideallösung, da das dann eine nur in Wikipedia anzutreffende Schreibweise wäre. --Mazbln 11:48, 12. Mär 2006 (CET)
Ich bin einer Meinung, dass Menschenlesbarkeit und Einfachheit wichtige Kriterien sind. Damit lassen sich mehr aktive Benutzer ansprechen. Die Gefahr ist nun, dass die Vorlagen einerseits (unnötig) uneinheitlich werden und andererseits, dass die Codierung umständlich bis fehleranfällig ist. Ich habe nun gesehen, dass Vorlagen in Vorlagen (wie ich es oben vorgeschlagen habe) problematisch sind, was wieder für (vereinheitlichte) Infoboxen a la Polen spricht. Diese ist immerhin redundanzfrei - ausser die Leute fügen dann unten doch wieder zusätzlich die Vorlage Koordinate an (...?)
Was die Codierung betrifft, ist die aktuelle Lösung in der Vorlage Polen mit "GradN=40 |MinutenN=40 |SekundenN=22,00 |GradO=12 |MinutenO=33 |SekundenO=33,00" noch verbesserungswürdig. Oben hat sk schon einen diskutierten Vorschlag dazu gemacht, den ich hier leicht angepasst zitiere: "Breitengrad=40 |Breitenminute=40 |Breitensekunde=22,00 |Breite=N |Laengegrad=12 |Laengeminute=33 |Laengesekunde=33,00 |Laenge=E". Vergleicht nun bitte diesen mit diesem: "Ostwert=10.1234|Nordwert=-40.2342" (man beachte das Minuszeichen). Beide Varianten sind vom Informationsgehalt her gleichwertig; sie unterscheiden sich allenfalls in der Benutzerfreundlichkeit, Lesbarkeit und der Punktnotation. --Geonick 14:26, 12. Mär 2006 (CET)
wäre der vorteil der nutzung von extraerfassung von "Breite=N" groß? für den nutzer einer stadtbox wäre das eine zusätzliche variable (und jede zusätzliche variable birgt ja fehlerpotential ;) ) ... ich behaupte mal die wenigstens Stadtboxen dürften sowohl N als auch S brauchen oder? ...Sicherlich Post 15:40, 12. Mär 2006 (CET)
Hallo, eine Ortsvorlage die für Frankreich und England (Ost/West) nicht anwendbar ist, ist einfach nicht diskutabel. Manchmal muss etwas Einfachheit für einen ordentlichen Standard geopfert werden. Kolossos 17:02, 12. Mär 2006 (CET)

(mal anmerk) da tippt man sich ja zu tode, hey, mit ein ein paar nbsp ist man im moment ja schneller, und im uebrigen, was macht man mit GPS-notation? Ist ja schoen, dass wir derzeit quellen mit DMS gebrochenen zahlen nutzen, aber die frage, ob das nicht mal irgendwann alles auf dezimalnotation umgestellt wird, die ist ja auch nicht wirklich diskutiert worden. right? GuidoD 15:43, 12. Mär 2006 (CET)

@ Guido; kann dir zwar nicht völlig folgen (was immer nbsp ist ;) ) .. aber eine umstellung ist bei der verwendung von maschinenlesbaren vorlagen über "maschinen" sprich bots IMO kein großes problem ...Sicherlich Post 15:48, 12. Mär 2006 (CET)
Also die vorgeschlagenen (Plus-Minus)-Dezimalangaben halte ich für den Leser einfach nicht für normgerecht. Desweiteren gebe ich zu bedenken, dass wir mit dem Abrücken von einer einheitlichen Koordinaten-Vorlage viele effiziente Möglichkeiten aufgeben. Ich hätte da z.B. Geonames-Search-page.php und Geonames_in_GoogleEarth anzubieten, welche fertigen Geotags produziert. Strg+C Strg+V einfacher geht es nicht. Bis wir die 142.000 Orte in der Wikipedia haben wird wohl dann auch einige Zeit vergehen. Die Koordinaten stammen aus profesionellen Quellen [1]. Kolossos 17:02, 12. Mär 2006 (CET)
Die Geokoordinaten sind dort aber trotz aller Professionalität immer noch ungenau und teilweise fehlerbehaftet (bei kleineren Orten liegen weisen sie häufig auf Punkte außerhalb des Ortsgebiets, manchmal sogar auf Machbarorte). Ungebprüft würde ich die nicht übernehmen wollen. Ich bin jedenfalls schon lange dazu übergegangen, mir die Geokoordinaten der von mir beschriebenen Artikel selbst zu bestimmen statt mich auf geonames.org zu verlassen. --Mazbln 19:59, 12. Mär 2006 (CET)
@sicherlich, umstellung auf standardisiertes format wohl nicht, aber im moment haben wir ja keinen standard vorgegeben. Da muesste man wenigstens zwei vorlagenvarianten pflegen, "coord dms", "coord gps". Und am ende will gar jemand noch die nautische notation haben (mit hauptwert bogenminute gleich seemeile und davon dann kommawert falls genauer). Egal, wollt mal dran erinnern *g*
@kolossos, das erste tool produziert kein "O"st fuer die deutsche vorlage, nix copypaste. GuidoD 17:44, 12. Mär 2006 (CET)
Danke für die Fehlermeldung, der Bug ist behoben. Kolossos 19:39, 12. Mär 2006 (CET)

Verbesserte Vorlage Geokoordinate und Umgang mit Infoboxen

Zwei Fragen

Bevor ich auf die zwei essentiellen Fragen zurückkomme, möchte ich darauf hinweisen, dass wir (Stefan und unser Roboter/Parser) zurzeit _nur_ die Vorlage Koordinate beim Auslesen berücksichtigen und wir nun nahe daran sind, diese zu verbessern. Zur Erinnerung: Der erstmalige Crawl-Vorgang der deutschen Wikipedia dauert zurzeit auf einem typischen Intel-Rechner ca. 10 Stunden.

  1. Bei der ersten essentiellen Frage geht es um die Verbesserung der Vorlage Koordinate zur Vorlage Geokoordinate. Zur Hilfe für diejenigen, die sich nicht die Mühe nehmen wollen, den Text oben zu lesen: Es geht um die Dezimalnotation (= GPS?) auf der einen und DMS.DD mit N/O-Angabe auf der anderen Seite sowie um selbstdokumentierende, mit '|' getrennte Attributnamen-Werte-Paare (Breitengrad=40 |Breitenminute=40, etc. ). Beides wäre ein klarer Fortschritt gegenüber der jetzigen Notation. Bei der Dezimalnotation kann man noch darüber reden, ob anstelle Minuszeichen eine Angabe zu N/S und W/O gemacht werden soll. Zu dieser Frage gebe ich zu bedenken, dass zurzeit ein Standard namens GeoRSS rasch Verbreitung findet und der verwendet die Dezimalnotation mit Minus-Zeichen.
  2. Wenn wir die erste Frage geklärt haben (Dezimal oder DMS.DD), kommen wir zur zweiten essentiellen Frage: Ich möchte Kolossos beipflichten und nachdoppeln, dass wir mit dem "Abrücken von einer einheitlichen Koordinaten-Vorlage viele effiziente Möglichkeiten aufgeben". Natürlich gibt es Crawler und natürlich könnten 'zig Varianten programmiert werden. Das bedeutet aber nicht, das nun bei jeder neuen Infobox oder Vorlage mit Ortsbezug die Codierungs-Diskussion hier losgeht, bzw. wieder ein Crawler oder eine Programm-Anpassung geschrieben werden müsste - sonst diskutieren wir am Ende noch das Alphabet...! Also: Die Frage hier ist, wie gehen wir mit Infoboxen-Vorlagen um? Dort ist für mich nur noch die Frage, ob die Vorlage (Geo-)Koordinaten tel-quel eingebettet werden soll, oder ob deren Attribute (ohne geschweifte Klammer) eingebettet werden sollen. --Geonick 20:56, 12. Mär 2006 (CET)
Darf ich nochmals nachdoppeln? Ich habe festgestellt, dass tatsächlich die meisten Artikel der Kategorie "Ort in der Schweiz", "Ort in ..." sowohl in der Infobox, als auch unten Koordinatenangaben enthalten. Gegeben die aktuelle suboptimale Vorlage Koordinate bedeutet das, dass z.Zt. dieselben Koordinaten dreimal(!) eingegeben werden müssen: Einmal in der Infobox und zweimal in der Vorlage Koordinate. Da gibt es Handlungsbedarf.
Ab ca. Ende nächster Woche wird unser Projekt Wikipoint zur Bereitstellung von Artikeln mit Koordinaten freigeschaltet. Ohne weitere Anpassungen (z.B. aufgrund Feedback von euch) werden Koordinaten in Infoboxen ignoriert. Zudem könnte eine zusätzliche Vorlage Geokoordinate berücksichtigt werden, wie es dem letzten Stand unserer Diskussion (vgl. Artikel_ohne_Koordinate) entspricht. --Geonick 00:02, 16. Mär 2006 (CET)
ich weiß nicht recht was der geowebdienst so tun soll, aber was meinst du mit koordinaten in infoboxen werden ignoriert ...Sicherlich Post 09:52, 16. Mär 2006 (CET)

Der Dienst ist auf meiner Benutzerseite beschrieben. Wichtig für Benutzer und Computer ist, dass Koordinaten nur mit *einer* einzigen Syntax eingetragen werden und die ist bis auf Weiteres die "Vorlage Koordinate", und deren Syntax beginnt zurzeit so: {{Koordinate Artikel|47_20_58_N_8_43...}}. In den letzten Tagen wurden Infoboxen (z.B. Polen) und Vorlagen entworfen (z.B. Bergtabelle), die Koordinatenvorlagen enthalten, die davon abweichen (vgl. Kategorie:Vorlage_mit_Koordinate). Diese Koordinaten werden Crawlern wie unseren ignoriert.

Wie die Koordinatenvorlage in Vorlagen eingebettet wird, ist eine offene Frage (vgl. oben). Wenn aber immer wieder weitere Variationen von Vorlagen-Namen entstehen, die für sich beanspruchen, Koordinaten zu enthalten, dann bricht das Chaos aus!! Dann müssten Crawler ständig testen, ob wieder jemand Lust bekommen hat, eine neue Vorlagenvariante mit Koordinaten zu entwerfen (was dann wieder einen 10-stündigen Prozess zur Folge hätte). Bitte erzeugt also keine neuen Vorlagen Koordinaten bis das nicht geklärt ist... --Geonick 17:25, 16. Mär 2006 (CET)

ahja .. naja Polen gibt es nun schon ;) und ist auch schon in reichlich artikeln drin; müsste also angpasst werden oder Polen bleibt weiß ;) ... eine vereinheitlichung der vorlage nach polnischem Prinzip gern; mir egal ob die Variablen GradN oder GradNord oder wie auch immer heißen ;) ...Sicherlich Post 21:26, 16. Mär 2006 (CET)

Nochmals: Sprache und Zweck dieser Vorschläge

Allgemeine Frage: Wo gab es überhaupt jemals Probleme mit der Namensgebung? Englisch ist doch bezüglich Koordinaten Standard hier. Oder habe ich mich da verTyped. Shouldte ich da my landamrk qannders setze ? oder irre ich mich? Arcy 01:24, 17. Mär 2006 (CET)

Also: Das Wiki-Projekt Georeferenzierung hat doch zum Ziel, Artikel/Seiten oder Textabschnitte zu georeferenzieren, indem 'Tags' mit Koordinaten in den Wikitext eingefügt werden. Damit ist es nicht nur möglich zu Online-Karten (kvaleberg-Service) zu verlinken, sondern man kann die Daten herausziehen (crawlen und parsen), um eine Geonamen- bzw. Orte-von-Interesse-Datenbank zu erhalten. Diese DB ist das Ziel meines Services auf dem Toolserver. Aus dieser können wiederum Dienste, wie z.B. ein KML für Google Earth, aufsetzen. Es geht nun in beiden Fragen oben primär um den Vorlagen-Namen, der z.Zt. ({{Koordinate Text|...}}) heisst (sekundär dann um die Attribut-Werte-Paare). Ein Crawler/Roboter sucht nun regelmässig alle (geänderten oder neuen) Artikel nach diesem Schlüsselwort (beginnend mit doppeltgeschweiften Klammern) ab. Wenn dieses Schlüsselwort ändert, dann findet der Roboter nichts, auch wenn es eine (allenfalls Koordinaten-ähnliche) Vorlage ist und auch wenn GradN dort steht. Oben versuchte ich auch zu erläutern, dass es für den Computer wenig Sinn macht, Vorlagen zu verlinken, weil dies zur Folge hat, dass immer wieder das ganze Wiki danach von vorne neu abgesucht werden müsste! --Geonick 09:04, 17. Mär 2006 (CET)
falls das letzte an mich und die polnische vorlage gerichtet ist; ja du hast es erläutert aber auh ich habe meinen standpunkt erläutert ...Sicherlich Post 09:14, 17. Mär 2006 (CET)
Ich kann deinen Argumenten leider nicht richtig folgen. Ich richte meine Überlegungen an alle Infoboxen - die Vorlage "Schweizer Ort" ist da z.Zt. auch nicht brauchbarer. Ich interpretiere damit den Stand der Diskussion so: 1. Für die Frage 1 oben "Verbesserte Vorlage Geokoordinate anstatt Vorlage Koordinate" bleiben wir bis auf weiteres bei Vorlage Koordinate. 2. Für die obige Frage 2 (Umgang mit Infoboxen) werden Infoboxen entweder ignoriert (Artikel können immer noch unten Vorlage Koordinate haben) oder sie werden derart angepasst, dass die "Vorlage Koordinate" ({{Koordinate Text|...}}) an der Stelle eingebettet wird, wo zurzeit Länge/Breite, etc. steht. Bei der Umstellung der betroffenen Artikel könnte dann sehr wohl ein Crawler/Bot beigezogen werden. --Geonick 12:47, 17. Mär 2006 (CET)
dann ignorier sie wenn du dein Programm nicht umprogrammieren willst; ein umstellen der polnischen Infoboxen wird Sicherlich nicht erfolgen, die benutzerfreundlichkeit der boxen ist IMO viel zu bedeutend außerdem können durch diese Boxen andere Bots besser mit den Daten umgehen; ein einzelnes Programm welches nicht entsprechend programmiert ist ist halt pech...Sicherlich Post 14:01, 17. Mär 2006 (CET)

Lösungsvorschlag 1 für Vorlagen mit Georeferenzierung

Ich kann Geonick nur zustimmen, dass es extrem unpraktikabel wäre, nach hunderten von verschiedenartigen Vorlagen suchen zu müssen. Vor allem wenn immer andere Schlüsselwörter für die Koordinateninformationen genutzt werden. Wir müssen uns hier deshalb einmalig für einige Schlüsselwörter und deren Einsatz in den Vorlagen aussprechen und deren Nutzung beschreiben. Vorlagen, die sich nicht an diese Reglung halten, werden nicht in die Weiterverarbeitung mit aufgenommen. Die drei bestehenden Vorlagen "{{Koordinate ...}}" haben weiterhin Bestandsschutz, da derzeit nicht alle sofort durch eine Infoboxen und ähnliches ersetzt werden können. Im Laufe der Zeit werden aber viele davon in bestimmten Vorlagen (z.B. Stadt-, Berg-, Unternehmens- oder Museumsvorlagen) aufgehen und so die Nutzung und Wartung extrem vereinfacht. Um uns von anderen Schlüsselwörtern abzuheben, schlage ich vor sie alle mit Koordinate anfangen zu lassen:

|Koordinate_Breite = N/S (obligatorisch)
|Koordinate_Breitengrad = 44 (obligatorisch, hier auch Dezimalangabe möglich)
|Koordinate_Breitenminute = 44 (optional)
|Koordinate_Breitensekunde = 44,00 (optional)
|Koordinate_Länge = O/W (obligatorisch)
|Koordinate_Längengrad = 12 (obligatorisch)
|Koordinate_Längenminute = 33 (optional)
|Koordinate_Längensekunde = 33,00 (optional)
|Koordinate_Name = Wrack der Titanic (optional, bei mehreren Koordinaten in einem Artikel sinnvoll, z.B. verschiedene Standorte etc.; wenn kein Name da, dann gilt Artikelname )
|Koordinate_Scale = 25000 (optional)
|Koordinate_Type = city/landmark/waterbody/mountain/country/adm1st/adm2nd (optional)
|ISO 3166-2=DE-BY,AT-9  (optional, mit Komma getrennt für mehrere Regionen bei Bergen/Seen im Grenzgebiet)
|Einwohner = 100000 (optional)
|Höhe = 4500  (optional, Höhe für Pässe und Berge)

Type wurde weggelassen, da es durch die Funktionalität der "Koordinate_Name" entfällt, bzw. in der Vorlage ja definiert ist, wie die Koordinate angewendet wird. Bitte macht jetzt eure Verbesserungsvorschläge, dann können wir abstimmen. -- sk 14:20, 17. Mär 2006 (CET)

Ich kann den Vorschlag von sk fast unterstützen. Sein Vorschlag geht über 14 Zeilen, da käme es also auf 2 zusätzliche Zeilen auch kaum noch an, darum würde ich vorschlagen die Angaben in einer eigenen Geo-Vorlage zu kapseln. Wenn sich dann also z.B. was mit Kvaleberg oder mit dem CSS ändert oder so, müßte nur diese eine Vorlage geändert werden.
Zum Thema Benutzerfreundlichkeit: Benutzerfreundlich ist nicht nur dass, was "für Benutzer freundlich ist" sondern auch was es unseren Programmieren ermöglicht stumpfsinnige Routinearbeiten zu automatisieren, dazu zählt für mich perspektivisch auch die Übertragung der Geokoords. auf andere Sprachwikis oder die Bot unterstützte Übernahme aus anderen Geoquellen. Von da her ist ein Standard wichtig. Für einen Bot wäre eine gekapselte Vorlage sicherlich besser. Ob man mit 14 Zeilen wirklich soviel einfacher kommt wie mit der jetzigen 1 Zeile erschließt sich für mich auch nicht ganz. Trotzdem würde ich mich einer Meinungsmehrheit natürlich anschließen können. Übrigens: Schön wäre noch eine Ergänzung von Koordinate_Type um einen möglichen Wert district für Stadtteile, oder gibt es da Probleme. Kolossos 19:23, 17. Mär 2006 (CET)
hmm finde den vorschlag von sk ganz gut; habe aber noch eine bitte bzw. frage; Infobox:Polen ist immer eine stadt; die vorlage an sich gibt das auch so aus (siehe quelltext Vorlage:Infobox (Polen)): dem Programm müsste man doch beibringen können das auszulesen? ... das selbe würde ja für infobox von bergen etc. gelten und bei den meisten städten könnte man dann auch die Koordinate_Breite entsprechend in die vorlage "versteckt" integrieren und so die boxen entschlacken ...Sicherlich Post 19:45, 17. Mär 2006 (CET)
Hatte ich auch schon dran gedacht ob man die Mediawiki-Funktion zum parsen nutzen könnte, wäre gut wenn es gehen würde. Kolossos 21:03, 17. Mär 2006 (CET)
ohne mich im detail auszukennen; aber am anfang der Box steht ja der vorlagenname; also müsste das progrämmchen das erkennen und dort entsprechend die fehlenden daten abfragen ... vielleicht geht es auch anders - nur so als idee ;) ...Sicherlich Post 21:16, 17. Mär 2006 (CET)
@Kolossos: Eine Kapselung der Vorlage ist genau das was wir ja eigentlich nicht wollen, weil dann wieder die eigentliche Erzeugung außerhalb der Artikeltexte passieren könnte (wie derzeit bei Schweizer Orten). Ich dachte mir dabei, dass die Stadtvorlagen diese Schlüsselwörter direkt benutzen. Wenn also der Bot im Artikeltext dieses Schlüsselwort findet muss er nur "{{" und "}}" der entsprechenden Vorlage finden und dann die anderen vorhandenen Schlüsselwörter auslesen.
@Sicherlich & Kolossos: Das Parsen von einigen Angaben der Koordinaten z.B. Type oder Breite ist ja gerade jetzt schon das Problem, weshalb ich davon dringend abraten möchte, diese Bestandteile außerhalb des Artikels zu generieren. Derzeit muß eine Software nur den Artikel anschauen um alle relevanten Infos zu bekommen. Wenn wir einen Teil woanders hin auslagern verdoppeln wir den Aufwand, da bei jeder gefundenen Koordinate erst mal die externen Infos noch zusätzlich angeschaut werden müssten. Bei derzeit 30000 Koordinaten geht das vielleicht noch, aber wir stehen ja erst am Anfang. Der Aufwand würde sich nicht lohnen für die paar eingesparten Zeilen! -- sk 08:00, 18. Mär 2006 (CET)
hmm ca. 900 Städte in Polen mit je drei eingesparten Zeilen sind 2.700 eingesparte Zeilen ... das auf die städte der welt hochgerechnet und bedacht, dass jedesmal die zeilen mit gespeichert werden müssen wenn ewas an dem artikel geändert wird ... ;) ...Sicherlich Post 11:08, 18. Mär 2006 (CET)
Also ich finde Stefans Vorschlag übersichtlich und seine Argumentation (soweit ich sie verstehe - ich bin kein Programmierer) nachvollziehbar. Die paar eingesparten Zeilen hören sich nach Sicherlichs Berechnung sicherlich recht viel an, dürften aber bei der gesamten Wikipedia-Datenmenge wirklich kaum ins Gewicht fallen. --Mazbln 11:51, 18. Mär 2006 (CET)

Lösungsvorschlag 2 für Vorlage Geokoordinate und Vorlagen mit Georeferenzierung

@Sicherlich: Respekt vor deinen Beiträgen zur Georeferenzierung von Polen-Artikel, die du offenbar vor wenigen Tagen geleistet hast. Du warst es denn auch, der uns auf das Problem der Infoboxen gebracht hast. Dieses wirft grundsätzliche Fragen auf, auf die wir schon mit der Type-Angabe gestossen sind. Gehe davon aus, dass alle verfügbaren (knappen) Programmier-Ressourcen eingesetzt werden, auf die ein Wikipedia-Projekt ebenso zählen kann wie auf aktive Benutzer. Wir sind uns z.B. einig, dass Benutzerfreundlichkeit und Einfachheit Priorität hat. Und die Überlegungen von sk und kolossos gehen in die richtige Richtung.

Lasst mich zunächst die Vor- und Nachteile der bisherigen Vorschläge klären um dann einen Vorschlag zu machen, bevor wir abstimmen:

1a. Im Vorschlag von sk gibt es Verbesserungspotential: Scale sollte durch Ausdehnung ersetzt werden (Diskussion siehe oben) aber - noch wichtiger: Typ und Typ-Werte sollten deutsch sein und in Schlüsselwörtern dürfen keine Leerzeichen vorkommen. 

|Koordinate_Ausdehnung = 10 (optional) in km, allenfalls mit Dezimalangabe (0,5)
|Koordinate_Typ = Stadt/Landmarke/Gewässer/Berg/Land/Admin1/Admin2 (optional)
|ISO_3166-2 = DE-BY,AT-9 (optional, Komma getrennt für mehrere Regionen bei Bergen/Seen im Grenzgebiet)

Die Idee dieser alleinstehenden Schlüsselwörter ist nun, dass sie eindeutig erkannt werden wenn sie in beliebigen künftigen Vorlagen mit Datenbanklinks verwendet werden. Eine zusätzliche Angabe der Vorlage "Koordinate Artikel" im selben Artikel ist unerwünscht, falls mind. die erwähnten obligatorischen Schlüsselwörter vorhanden sind. Vorlage "Koordinate Text" wäre weiterhin in allen Fällen anwendbar.

1b. Infragegestellt ist der Umgang mit Type: Der Name der Infobox (d.h. der Textes zwischen {{ und dem ersten "|") könnte zwar herausgelesen werden, würde aber die von den einen gewünschte Type-Aufzählung (Stadt/Landmarke/Gewässer/Berg/...) frei den Benutzern überlassen und würde zudem - wie Type - eine 'Konkurrenz' zu Kategorien darstellen. Wenn ich mich entscheiden müsste zwischen Type-Angabe, die aus Infobox-Werten herausgelesen würde und Kategorien dann ist für mich klar, was den Vorrang erhielte: die Kategorien unten. (@Sicherlich: Was für ein Typ wäre nun z.B. {{Infobox (Polen)|...? @sk: Du hast Typ optional bezeichnet; willst du damit diese Angabe aufgeben, falls Infoboxen als 'Ersatz' für Vorlage "Koordinate Artikel" gelten sollten? Falls Typ obligatorisch wäre *und* dargestellt würde, wie erklären wir das den Lesern im Vergleich zu Kategorien?)

2. Der Nachteil einer so lockeren Regelung ist, dass der Hypertext-Linkmechanismus nicht mehr wie zurzeit bei Vorlage "Koordinate ..." funktioniert. Änderungen an diesen Schlüsselwörtern hätte auch eine Änderung von vielen CSS zur Folge (statt nur einer wie bei Vorlage Koordinate). Diese Regelung ist auch potentiell unklar, da sowohl Menschen wie auch Bots ein z.T. sehr weites Textumfeld lesen müssen, um den Zusammenhang zu sehen. Nun haben die englischen Kollegen eine weitere Mediawiki-Variante vorgeschlagen: vgl. z.B. beim Matterhorn das Vorlagen-Fragment {{Bergtabelle Koordinaten|45_58_N_7_39_E_type:mountain|45° 58' N; 7° 39' O}}. Der Vorteil davon ist, dass mind. Koordinaten-Angaben wieder schön doppeltgeschweift geklammert sind, was wieder mit vernünftigen Mitteln als Link interpretiert werden kann. Abgesehen davon, dass dieses Beginn-Ende eine Vorlage komplizierter macht, ist damit aber das Problem des redundanten Typs, der Höhe oder der Einwohner nur unbefriedigend gelöst.

Fazit mit Vorlage Geokoordinate

Nach reiflicher Überlegung komme ich daher zum Vorschlag, dass wir einerseits die "Vorlage Koordinate" leicht verbessern (Basis Vorschlag sk) und andererseits empfehlen, in Infoboxen keine Koordinatenangaben zu verwenden (dass in Infoboxen Höhe, Einwohner, etc. vorkommen, wäre weiterhin denkbar). Jeder georeferenzierte Artikel sollte also nach wie vor mind. einen Eintrag Vorlage "Koordinate..." enthalten (max. 5 gemäss heutiger MediaWiki-Version). Damit sind weitergehende Erweiterungen, wie sie oben bereits angedacht wurden (z.B. nur eine Koordinate in allen Wikis) leichter möglich. Diese Regelung ist einfach zu handhaben, entspricht der ursprünglichen Datenbank-Links-Idee und verlangt nach wie vor nur eine Darstellungsregelung (CSS). Sie wäre übrigens auch ganz ähnlich wie die vollständige Wikipedia:Personendaten-Liste. Hier also mein Vorschlag auf Basis von sk und Kolossos oben in leicht verbesserter Form: --Geonick 12:24, 18. Mär 2006 (CET) 

{{Geokoordinate Artikel/Text/Text Artikel
  |Breite = N/S (obligatorisch)
  |Breitengrad = 44 (obligatorisch, hier auch Dezimalangabe möglich)
  |Breitenminute = 44 (optional)
  |Breitensekunde = 44,00 (optional)
  |Länge = O/W (obligatorisch)
  |Längengrad = 12 (obligatorisch)
  |Längenminute = 33 (optional)
  |Längensekunde = 33,00 (optional)
  |Name = Wrack der Titanic (optional, bei mehreren Koordinaten in einem Artikel sinnvoll, 
          z.B. verschiedene Standorte etc.; wenn kein Name da, dann gilt Artikelname )
  |Ausdehnung = 10.000 (optional) in km, allenfalls mit Dezimalangabe (0,5)
  |Typ = Stadt/Landmarke/Gewässer/Berg/Land/Admin1/Admin2 (optional)
  |ISO_3166-2 = DE-BY,AT-9 (optional, Komma getrennt für mehrere Regionen bei Bergen/Seen im Grenzgebiet)
  |Einwohner = 100000 (optional)
  |Höhe = 4500  (optional, Höhe für Pässe und Berge)
}}
  • geokoordinate in eine eigenen box zu basteln wie wohl der vorschlag von dir geonick ist halte ich für nicht sinnvoll, weil es einfach eine redundante datenerfassung ist;
    • zum einen kommen in die Boxen je nach typ eh die angaben Einwohner, Höhe usw. weil es einfach grundlegende angaben sind.
    • Weiterhin gehören nach meinem (und wenn ich mir dir boxen so angucke nach der von vielen/der meisten) auch die korrdinaten in die Box. Die Box "darunter" zu basteln und quasi als teil der Box darzustellen dürfte spannend werden da die boxen sich wohl optisch unterschieden dürften.
    • Die Problematik der redundaten datenerfassung wird schnell klar; einwohnerzahlen bei orten ändern sich regelmäßig und müssten also stets in zwei boxen erfasst werden; wird regelmäßig nicht gepflegt werden
    • welcher typ die mit Vorlage:Infobox (Polen) gekennzeichneten boxen sind kannst du leicht an dem Quelltext erkennen dort steht "type:city"
    • nicht verstehe ich " Der Nachteil einer so lockeren Regelung ist, dass der Hypertext-Linkmechanismus nicht mehr wie zurzeit bei Vorlage "Koordinate ..."" ... tut er doch? siehe Łódź habe rechts oben den link?! oder meinst du was anderes
    • einem programm sollte doch beizubringen zu sein innerhalb einer box welche mit {{ anfängt nach einem schlüsselwort wie Breitengrad zu suchen und sich dann auch die anderen entsprechenden daten noch zu nehmen. ist das schlüsselwort nicht drin passiert nix und gut?!...Sicherlich Post 15:05, 18. Mär 2006 (CET) PS: habe erstmal mit dem boxenerneuern für pl-städte aufgehört, da es ja zumindest bzgl. der benamsung änderungen geben könnte

Sicherlich: Bitte informiere dich, woher die Vorlage (Geo-)Koordinate (en:Template:coor) kommt. Und nochmals ganz in Ruhe: Ich bin deiner Meinung, dass Höhe und Einwohner und auch Typ(!) redundant und daher zu vermeiden sind. Alle diese könnten aus dem Wiki-Text gelesen werden (Typ City könnte z.B. eine zusätzliche Kategorie 'Ort' sein). Als Kompromiss sind sie noch da aber optional. Die Vorlage "Infobox (Polen)" nutzt geschickt die Möglichkeit, andere Vorlagen einzubetten. Im Wiki-Text von Łódź ist von Vorlage "Koordinaten..." (und von type:city) nichts zu sehen: MediaWiki holt sich die Information von der Vorlage "Infobox (Polen)". Das bedeutet, dass die Vorlage "Koordinate..." in anderen Vorlagen vorkommt, d.h. Abhängigkeiten entstehen. Vorlagen in Vorlagen sind unerwünschte Indirektionen und sowohl technisch wie auch aus Autorensicht umstritten (Sichtbarkeitsprinzip: Man soll dem Wiki-Text von Lodz ansehen, dass "Infobox (Polen)" vom type:city ist und Vorlage "Koordinate Artikel" enthält).

Fazit mit Vorlage Geokoordinate und gemeinsamen Attributnamen

Nun habe ich einen neuen, alten Regelungsvorschlag, welcher alles unter einen Hut zu bringen versucht: Alle Schlüsselwörter (='Tags': Breite, Breitengrad, Breitenminute, Breitensekunde, Länge, Längengrad, Längenminute, Längensekunde, Name, Ausdehnung, Typ, ISO_3166-2, Einwohner, Höhe, alles deutsch, gemäss Vorschlag oben) in Vorlage "Geokoordinate Artikel/Text/Text Artikel" und in allen anderen Vorlagen sind gleich zu benennen mit dem Unterschied, dass in 'normalen' Vorlagen "Georef_" (oder "Geokoordinate_" oder "GPS_"?) vorangestellt wird und in Vorlage "Geokoordinate" nicht (da fehlt dann eine logische Klammer um alle Geo-Schlüsselwörter, was eine Sünde im grossen Wiki-Bruder XML ist, und wer instruiert dann alle Infoboxen-'Bastler', aber lassen wir's...). Wo diese Schlüsselwörter (Georef_Breite, Georef_Breitengrad) in Infoboxen vorkommen, darf die Vorlage "Geokoordinate Artikel" nicht vorkommen. Diese muss als Vorlage in die Infobox-Vorlage eingebaut sein (einzig wegen dem Link, ohne versteckte type-Angaben und wehe, wenn die Vorlage Geokoordinate nochmals ändert...). Typ muss in Vorlage "Geokoordinate" optional sein nur schon für den Fall, dass er in Infoboxen-Vorlagen nicht vorkommt (Sichtbarkeitsprinzip). Lieber wäre mir, wenn Typ ganz in Kategorien integriert würde. --Geonick 21:42, 18. Mär 2006 (CET)

"Vorlagen in Vorlagen sind unerwünschte Indirektionen und sowohl technisch wie auch aus Autorensicht umstritten" - nunja umstritten zeigt wohl das es durchaus vorkommt also es leute gibt die den nutzen sehen ;) ... wenn ich deinen vorschlag richtig verstehe dann sollte die Infobox (Polen) jetzt Geo Infobox (Polen) heißen und dein Progrämmchen merkt dann "oh da steht geo also praktische infos für mich?!" .. und was noch drin steht ist ihm wurst? damit könnte ich leben. für den typ:city ...weiß nicht ob ich das selbe meine, aber das könnte anhand der kats ja schon erkannt werden oder? wenn da steht Kategorie:Ort in XYZ ist es wohl ein ort?! wenn dadurch type:city wegfällt fände ich das toll!...Sicherlich Post 19:05, 19. Mär 2006 (CET)
Vorlagen in Vorlagen kommen vor, weil es Benutzer gibt, die einfach mal 'was machen... und die brauchts' auch! (man beachte auch, dass MediaWiki 'over-engineered', d.h. kaum wartbar geworden ist!). Nun ist aber Einfachheit und Nachnutzbarkeit der Georeferenzierungs-Arbeit angesagt. Stelle dir z.B. vor, man beschliesst später, jeder Koordinate noch eine Qualitätsangabe zuzuordnen: Würde nur Vorlage Geokoordinate verwendet, wäre alles klar...! Nun also: Das mit der Namensgebungs-Regelungen von Vorlagen (Infobox (Polen) => Geo Infobox (Polen)) innerhalb der von dir bevorzugten Regelung "Fazit mit Vorlage Geokoordinate und gemeinsamen Attributnamen" ist kein schlechter Vorschlag. Ich denke aber, dass das nicht nötig ist. Wichtig ist hier, dass Attributnamen (Koordinate_Breite, |Koordinate_Breitengrad, etc. vgl. oben) wirklich einheitlich sind und explizit im Wikitext erscheinen (was beides bei Infobox Polen nicht der Fall ist aber leicht noch geändert werden könnte). In der Zwischenzeit habe ich mich nochmals über die Syntax der Bergtabelle informiert (vgl. de:Matterhorn und en:Matterhorn): Diese hat den Vorteil, dass die Vorlage Geokoordinate (die ja hier immer noch im Zentrum steht), direkt im Wikitext sichtbar ist - also etwas, was genau eines der Probleme beim Lösungsvorschlag a la "Infobox (Polen)" ist. --Geonick 15:09, 22. Mär 2006 (CET)
so habe unter Vorlage:Geo Stadt (Polen) mal gebaut wie es wohl sein soll; allerdings nur demo; die vorlage an sich ist noch nicht angelegt. weiterhin würde da die vorlage {{Koordinate Text Artikel ... eingebaut sein; bis es anders geht. zu der vorlage
1.) ich finde es nach wie vor nicht sinnig die angaben wie "Koordinate_Breite=W" & "type=city " die in der vorlage eh immer gleich sind in die artikel einzubauen; das sollte ein Programm sich aus der zugrundliegenden Vorlage nehmen können wo man es "versteckt" einbauen kann
2.) muss die Vorlage "Geo Stadt (Polen)" heißen oder geht auch "Infobox (Polen)" weil das progrämmchen einfach die stichworte wie "Koordinate_Breitengrad=" erkennt?! ...Sicherlich Post 18:56, 22. Mär 2006 (CET)
Zu 2.) "Infobox (Polen)" genügt, weil das Progrämmchen - welches wächst und wächst - damit nichts besonderes anfangen kann ausser zunächst mal mit der öffnenden Doppelklammer ("{{"). Am liebsten wäre es ihm wie gesagt, es dürfte sich nur auf "{{Koordinate" konzentrieren... :->
Zu 1.) Ich beschwöre dich, Sicherlich: lass' "Koordinate_Breite=O" so drin. Das Progrämmchen kann nicht ahnen, dass der Artikel, den es vor sich hat, eine Stadt östlich Greenwich ist und dann landet Lodz noch in der Porcupine Abyssal Plain. Und verstecke bitte nichts, sondern pack' alles was dir lieb ist in die Infobox, bzw. in den Wikitext wie es z.Zt. der Fall ist. Der Artikelinhalt ist damit für jeden kontrollierbar - ich nenne es das Sichtbarkeitsprinzip. Der Wikitext ist die beständigste Information, die wir haben.
Noch etwas: Beim Betrachten deiner neuen Vorlage ist mir aufgefallen, dass die Koordinate(n)-Schlüsselworte konsequenterweise ohne '_' geschrieben werden sollten (also z.B. "KoordinateBreite). --Geonick 22:08, 22. Mär 2006 (CET) P.S. und "ISO 3166-2" sollte unbedingt "ISO_3166_2" geschrieben werden, damit es keine Unklarheiten gibt.
Ich kann mich Geonick nur anschliessen, was das Auslagern angeht. Bitte nix auslagern, da sonst alles nur komplizierter würde, für Benutzer und für Software. Die "ISO_3166_2" würde nach einigen Überlegungen doch besser in "Koordinate_Region" umbenennen! Wir haben auch Positionen die nicht ISO-konform sind z.B. Berge auf einer Grenze oder Punkte in Ozeanen (Ölplattform, Untergangsstelle etc.). Die sollten wir dort auch mit einbringen können. -- sk 08:11, 23. Mär 2006 (CET)

Zum "Progrämmchen:". Wie sieht dieses Progrämmchen aus? Welche Konstrukte kann das Programm auswerten? Kannst du es nicht mal hier posten (oder Teile davon)? --Arcy 08:08, 23. Mär 2006 (CET)

Das tu' ich gerne - es ist einfach noch nicht fertig. Es wertet z.Zt. Vorlage "Koordinate ..." aus und ich bin bereit dieses auch auf Schlüsselwörter "KoordinateBreite, KoordinateBreitengrad, KoordinateBreitenminute, Breitensekunde (etc...)" zu trimmen. Nur: Wir kämpfen auf dem Toolserver noch mit Dingen, die uns hier eh' fast keiner glauben würde:-> --Geonick 00:57, 24. Mär 2006 (CET)
@Sichtbarkeitsprinzip; ist ja auch in der jetzigen form für jeden kontrollierbar; wer die box verstehen will muss sich eh die vorlage angucken und in letzter konsequenz müssten die vorlagen alle jeweils mit {{subst: eingebaut werden; wegen der sichtbarkeit ... wird bei {{Koordinate ... aber glaube ich nicht gemacht ;o)
@ISO 3166-2 ... also wenn dann ISO_3166-2 .. wenn das so heißt sollte WP das nicht umdefinieren weil es besser aussieht; damit der nutzer eine chance hat zu wissen was es ist: "Koordinate_Region" sollte es auch nicht heißen; begrünung wie zuvor; keine Wikipedia-Geheimcodes ...Sicherlich Post 10:01, 23. Mär 2006 (CET)
Schau dir bitte den Wikitext von Lodz an ("Seite bearbeiten"); hier siehst weder du noch irgend ein Progrämmchen irgendetwas von 'type:city', denn diese Angabe ist nicht dort sondern in der aktuellen "Infobox (Polen)" und zwar 'versteckt' wie du es oben selber genannt hast. ISO_3166-2 ist problematisch, da es mehr als drei Möglichkeiten gibt für Bindestriche (vgl. Artikel Typographie); 'Koordinate_Region' (bzw. KoordinateRegion) ist tatsächlich noch besser (sk: das hatten wir doch schon mal?), da es ein sprechender, selbstdokumentierender Name ist (ISO_xxx_yy ist eher ein Wertebereich und Zahlen man sich eh' schlechter merken als 'Region'). Bleibt höchstens noch die KoordinateAusdehnung anstelle von KoordinateScale (???), dann wären unser Progrämmchen und ich happy! --Geonick 00:57, 24. Mär 2006 (CET)

Kommentare zu den beiden Regelungsvorschlägen

Wer soll den Text da oben noch mitverfolgen? Da könnt ihr doch gleich Telefonkonferenz machen. *grummel*

(a) Die Kommentare zu Type und ähnlichem versteh ich nicht - der kvaleberg hat die doch verarbeitet, als müssen die doch auch rein?! Die Verbesserungen betreffen dann also Dritt-Tools. Oder will wer einen de-spezfischen Kartendienst als kvaleberg-Ersatz aufstellen?
(b) Die ganzen Benennungen/Umbenennungen/Formate kranken mir an der fehlenden Sicht, Tools und Daten zwischen den Sprachvarianten der Wikipedia austauschen zu können. Je einfacher umso besser. Viele schoene Varianten machen Arbeit, die irgendwann wiederholt werden muss, wenn wieder wer was auszusetzen hat. Oder noch eine Box-Variante dazukommt, umgestellt wird, zwischen Wikis abgeglichen wird.
(c) Die Frage nach der Koordinaten-Notation ist mal fix ausgeklammert worden (taucht nur einmal am Anfang auf). Ich hab noch keine Zeit gehabt, denn ich denke, es hängt davon ab, was bei Kartenmaterial heutzutage als Gitter bevorzugt auftaucht - die historische DMS notation, die nautische DM.X notation, oder über GPS eingeflossene dezimale D.XX Notation. Letztere beiden würde viele Vorlagenprobleme/varianten nichtig machen.
cheers, GuidoD 16:51, 20. Mär 2006 (CET)
@(b) - du meinst die bisherigen Stadtboxen sind nicht geeignet bots dazu zu nutzen informationen zu aktualisieren, ergänzen und anzupassen und die "polnische box" ist dazu sehr gut geeignet? ...Sicherlich Post 20:13, 20. Mär 2006 (CET)
Zu a) GuidoD: Wir (vgl. Unterschrift) sind daran, eine Datenbank mit Arbeitstitel 'WikiPoint' aufzustellen. Die Funktionalität des kvaleberg-Services ist davon nicht betroffen - ausser wir verbessern die Vorlage, was meiner Meinung nach nötig ist. So wird dort type z.B. ja gerade nicht verarbeitet! Zudem werden die Parameter unsauber - d.h. ohne eigenen Namen - übergeben (vgl. dort: ?params={{{1}}} {{{2}}}). Daher die Verbesserungsvorschläge zur Vorlage "Koordinate ..." oben.
Und für alle, denen es wie mir Sorgen macht, dass der Kvalebergs Dienst offenbar nicht beeinflusst werden kann, mache ich auf dem Toolserver einen Weiterleitungs-Service, so dass eine allfällige neue Vorlage Geokoordinaten-Vorlage immer noch mit dem kvaleberg-Service zusammenpasst.
Zu b) Ganz deiner Meinung: unser 'WikiPoint'-Datenbankprojekt dient u.a. auch der Grundlage für die Integration von Koordinaten in Sprachvarianten. Daher mein Vorschlag oben, sich auf die Verbesserung der Vorlage "Geokoordinate Artikel/Text/Text Artikel" zu konzentrieren und folglich Koordinaten aus Infoboxen fernzuhalten. Alle Infoboxen (@Sicherlich: auch diejenige von Polen!) - müssten in diesem Falle nochmals vereinfacht werden und Koordinaten-Angaben der Vorlage "Geokoordinate..." im Wikitext selber überlassen.
Zu c) Die Frage nach der Koordinaten-Notation ist nicht ganz ausgeklammert worden: sk schlug vor, alternativ die Dezimalnotation zu verwenden, was ich einen guten Vorschlag finde und übernommen habe (vgl. Fazit oben) --Geonick 08:25, 21. Mär 2006 (CET)
Stadtboxen zu kürzen nur um eine zweite Box einzuführen halte ich für nicht sinnvoll ... daher wird die polnische box wohl so bleiben. Wenn es bessere Ideen gibt bitte ggf. auf Portal:Polen bescheid sagen. Bis dahin werden wir die neue Box verwenden ...Sicherlich Post 09:42, 21. Mär 2006 (CET) Sicherlich: Könntest du bitte Argumente bringen oder mal nix sagen und in der Zwischenzeit dich über die Vorlage Koordinate informieren? Danke, Geonick.
Argumente; gern nochmal:
  1. Stadtbox soll koordinaten enthalten weil sie einfach da rein gehören, siehe auch die deutsche Stadtbox welche wenn ich mich recht erinnere per Meinungsbild entstand (oder damals noch abstimmung)
  2. eine zweite Box ist optisch schwer an die erste anpassbar, da die boxen optisch recht unterschiedlich sind (weil ja wohl auh berge etc. rein sollen)
  3. einen extra box würde redundante datenerfassung bedeuten
  4. in der polnischen Box liegen die daten in maschinenlesbarer form vor
  5. die polnische Box ermöglicht ein abgleich von verschiedenene daten per bot, auch zwischen verschiedenen wikipedias,
...Sicherlich Post 10:32, 21. Mär 2006 (CET)

@Sicherlich: Wir sind hier im "Kommentar zu den beiden Regelungsvorschlägen". Darf ich deinen Worten entnehmen, dass du für das "Fazit mit Vorlage Geokoordinate und gemeinsamen Attributnamen" votierst (womit ich leben kann)? Damit sind Stadtboxen berücksichtigt - vorausgesetzt wir einigen uns noch auf Attributnamen (Vorschlag siehe Syntax im "Fazit mit Vorlage Geokoordinate"). Das hiesse auf Infobox Polen - aber nicht nur diese! - bezogen, dass man die Namen anpassen müsste, falls das Ziel sein soll, Koordinaten maschinell weiterzuverarbeiten.

  • Zu 2 und 3: Vorlage "Geokoordinate" ist keine Box sondern ein Datenbanklink. Keiner der beiden Regelungs-Vorschlägen oben führt zu redundanter Erfassung und keiner schlägt eine zweite Box vor (habe ich am Beispiel Bergtabelle in deinem Sinne als nicht sinnvoll bezeichnet). Der Hauptunterschied von beiden Regelungen ist, dass im Wikitext bei "Fazit mit Vorlage Geokoordinate" immer eine Vorlage "Geokoordinate..." verlangt wird (Koordinaten nur dort) und im Falle von Stadtboxen und Bergtabellen z.B. eine ausgefüllte Vorlage "Infobox (Polen)" (ohne Koordinaten) _und_ unten eine Vorlage "Geokoordinate" existieren würde. Eine Vorlage "Koordinate" gibt es schon lange (inkl. Meinungsbilder) und braucht's so oder so (dann halt als zusätzlicher(!) Bestandteil der polnischen Vorlage!).
  • Zu 5: Die aktuelle polnische Box arbeitet bezüglich Koordinaten mit Vorlagen in Vorlagen (du müsstest sagen "Box in der Box") sowie mit nicht einheitlichen Attributnamen. Beides erschwert den Abgleich. Oben stehen daher zwei Regelungen zur Diskussion.

Beachte also, dass es auch bei der von dir bevorzugten Regelung hier noch eine Diskussion zu Vorlage "Geokoordinate..." braucht. Nun bin ich interessiert, mal noch andere Stimmen hier zu hören. --Geonick 11:54, 21. Mär 2006 (CET)

    • ich votiere noch gar nicht; warte noch auf die antwort auf meine Fragen eine überschrift weiter oben. da ich mich eigentlich nicht betroffen fühle (alles was ich nutze funktioniert) werde ich jettz einfach mal die Box weiter einbauen; bis hier irgendwas relevantes passiert wird es wohl noch dauern...Sicherlich Post 12:07, 22. Mär 2006 (CET)
Ok; ist recht aufwändig, dir das Denken zu erleichtern ;-> aber Wikipedia braucht auch 'Macher' wie du. --Geonick 15:13, 22. Mär 2006 (CET)

Grundsätzliche Anmerkungen zu dieser Diskussion

Nachem ich gestern auf diese Diskussion hingewiesen wurde und wir mit unserem Projekt direkt von den hier diskutierten Varianten betroffen wären, ein paar Anmerkungen. Vorneweg: ich bin noch immer WP-Neuling, d.h. kenne mich mit den technischen Möglichkeiten nur sehr oberflächlich aus. Deshalb sei mir verziehen, wenn ich evtl. unrealistische Ansätze beschreibe. Aber vielleicht hilft ja genau eine Sicht, die noch nicht von zu viel Details verstellt ist, hier zu einem konstruktivem Ergebnis zu kommen. Zunächst scheint mit, dass in dieser Diskussion mehrere Gruppen aufeinander treffen, die aufgrund unterschiedlicher Nutzungsszenarien der Geo-Daten zu komplett unterschiedlichen Anforderungen kommen: z.B: Editoren, d.h. Leute die Artikel für WP schreiben, Vorlagenbauer, die an einer Standardisierung von Artikelgruppen arbeiten (und damit die Qualität von WP insgesamt verbessern und die Arbeit für die Editoren erleichtern) und Bot-Entwicklern, die die in WP gespeicherten Informationen nutzen wollen um daraus Mehrwert-Dienste zu bauen (die auch wiederum die Qualität von WP steigern helfen können). Auch wenn ich selbst der letzeren Gruppe zugehöre, bin ich der Meinung, dass im Zweifel immer das Interesse der Editoren im Hinblick auf eine einfache und robuste Erstellung von Artikeln im Vordergrund stehen muss. Von diesem Standpunkt ausgehend ergibt sich für mich zwangsläufig, dass es nicht sein kann, dass Vorlagen so umfassend ausgelegt sind, dass eine umfassende Auszeichnung von Artikeln mit Information durch den Editor erfolgt. Vorlagen sollten nach meiner Überzeugung ja gerade auch bestimmte Implikationen und Festlegungen vorgeben können, d.h. wenn es eine Vorlage "Infobox (Polen)" für Orte in Polen gibt, so sollte dies auch implizit festlegen, dass es sich um einen type=city, region=pl handelt und dass alle Geo-Koordinaten implizit im nördlichen und östlichen Koordinatenraum liegen. Eine entsprechende Erfassung durch den Editor ist dann nicht notwendig. Dies kann auch helfen, komplexe Ausnahmefälle, die aber nur in wenigen Konstellation auftreten i.d.R. gar nicht an den Editor rankommen zu lassen (will man z.B. für eine alle Orte eine Auszeichnung vornehmen, auf welchem Kontinent sich ein Ort befindent, so könnte dies für die meinsten Länder implizit festgelegt werden, und nur Vorlagen für Orten in kontinentübergreifenden Ländern bräuchten hier eine Information des Editors). Auch könnte jede nach Art des zu beschreibenden Objekts unterschiedlich komplexe Auszeichnungsformen genutzt werden. So könnte für einfache Locations die Auszeichnung eines Punkts mit Durchmessers ausreichend sein, für sehr grosse, unregelmässige Objekte (z.B. Kontinente) will man vielleicht deren Begrenzung durch Geo-Polygone beschreiben.

Ich denke, dass es sehr viele Informationen gibt, die einerseits sinnvoll beschrieben werden können, und für eine automatische Auswertung auch sinnvollerweise strukturiert erfasst werden sollten, aber andererseits die konkreten Optionen nur für jeweils begrenzten Teilmengen von Artikeln anwendbar sind. Deshalb würde ich eine "Eierlegende-Wollmilchsau-Vorlage" nicht für sinnvoll erachten. Sie würde entweder auf eine unnötig kleine gemeinsame Teilmenge hinauslaufen oder zu komplex werden, dass sie akzeptiert und korrekt genutzt werden würde.

Mein Fazit ist deshalbt, dass es für die qualitätsgesicherte und leicht erlernbare Erstellung von Artikeln sinnvoll ist Vorlagen zu nutzen, die bestimmte Implikationen und Vorgaben mit sich bringen. Entsprechend halte ich den Ansatz von "Infobox (Polen)" für sehr sinnvoll.

Bleibt das Problem, dass dann wir Bot-Entwickler ständig mit neuen Vorlagen zu kämpfen haben.

Nicht geeignet halte ich den Versuch, standardisierte Namen (oder Namensbestandteile) für Vorlagen-Parameter zu vergeben, da es hierfür m.W. in WikiMedia keine Validierungskonzepte gäbe, und es meines Erachtens nicht realistisch ist, dass sich Vorlagen-Entwickler aus einem Themenbereich über Konventionen in anderen Bereichen informieren, bevor sie sich einen Namen für einen Parameter ihrer Vorlage ausdenken. Das führt nur zu Problemen und Abstimmungsdiskussionen.

Gleichzeitig wäre es für mich als Bot-Entwickler aber auch nicht praktikabel, wenn ich für jede neue Vorlage einen speziellen Parser programmieren müsste, der die spezifischen Implikationen jeder Vorlage programmtechnisch umsetzt.

Statt dessen würde ich mir wünschen, dass es sowas wie "Meta-Vorlagen" gibt, die in den eigentlichen Vorlagen Verwendung finden (nicht in den Artikeln selbst) und die wiederum Implikationen und Konventionen der jeweiligen Vorlage für einen Bot beschreiben. Teile der Probleme von "Vorlagen in Vorlagen" könnten von vorneherein ausgeschlossen werden, wenn die Meta-Vorlagen selbst keinen Output erzeugen, sondern nur dokumentierenden Charakter haben. Deshalb könnten sie auch im <noinclude> stehen. Jetzt müsste man nur noch einen "Meta-Vorlagen"-Bot schreiben, der alle (Artikel-)Vorlagen findet, die direkt oder indirekt die für den eigentlichen Bot relevanten Meta-Vorlagen nutzen und die darin definierten Regeln auswertet.

Dies alles ist dann natürlich für Bot-Entwickler deutlich aufwändiger: Jeder Bot-Entwickler der Informationen auf Basis der Meta-Vorlagen nutzen will, müsste zunächst den "Meta-Vorlagen-Bot"-schreiben, der ihm dann rekursiv alle Vorlagen herausfindet, die direkt oder indirekt die für ihn relevanten Meta-Vorlagen nutzen. Darüberhinaus müsste jeder Bot dann auch noch die Vorlage-Ersetzungs-Mechanismen von MediaWiki nachimplementieren um von den Vorlagen-Parametern des Artikels zu den Parametern der der für ihn relevanten Meta-Vorlage zu kommen. Ein zweiter Nachteil ist die Performance bei der Suche nach zu parsenden Artikeln. Schon heute dauert bei uns die Suche in der Datenbank nach allen Artikeln die {{Koordinate enthalten fast ebenso lang, wie die anschliessende detaillierte Analyse aller geoindizierten Artikel. Dies würde noch deutlich langsamer werden, wenn nicht nur nach einer, sondern nach eine Vielzahl von Vorlagen gesucht werden müsste. Entsprechend wäre es wünschenswert, wenn direkt aus MediaWiki heraus Unterstützung für ein entsprechendes Feature vorhanden wäre. Alternativ könnte man natürlich auch einen eigenen Wiki-Meta-Vorlagen-Bot-Dienst aufbauen, der die Meta-Vorlagen-Suche, Artikel-zu-Meta-Vorlagen-Indizierung und Meta-Vorlagen-Parameter-Ermittlung implementiert und diesen anderen Bots zur Verfügung stellen.

Das mag erstmal nach viel Arbeit für Bot klingen (was es wahrscheinlich auch ist), erwwährleistet jedoch, dass man als Bot-Entwickler nicht ständig in der Angst leben muss, dass mal wieder eine neue Vorlage auftaucht, für die man dann die Bot-Programmierung anpassen muss. Die Entwickler der neuen Vorlage werden wahrscheinlich selbst darauf achten, die zutreffenden Meta-Vorlagen in ihre Vorlagen einzubauen. Und falls es doch mal ein Vorlagen Entwicker übersehen hat, kann man leicht selbst die Meta-Vorlage dort nachtragen. Auch scheint es mir dann leichter möglich, auch nach neuen Aspekte zu suchen, indem man ein neue Meta-Vorlage definiert und sie in den bestehenden Vorlagen einträgt, die diese Anspekte herleiten lassen.

Ein (aus meiner Sicht ein riesiger) weiterer Vorteil eines solchen Ansatzes könnte sein, dass Meta-Vorlagen, da sie ja nicht dafür vorgesehen sind, in Artikeln verwendet zu werden von vorneherein international ausgerichtet sein könnten, d.h. deren Namen und Parameternamen in allen Wikis gleich sein könnten. Dies würde einerseits die Arbeit für Bots die mehrsprachig arbeiten erheblich vereinfachen, gleichzeitig aber auch eine "diskussionsarme" Integration erlauben, da sie zwar in bestehende Vorlagen eingebaut werden müssten, jedoch nichts an deren Verhalten oder Parameter-Liste ändern würden.

Soweit meine grobe Ideenskizze. Kommentare von alten Wikipedia/Wikimedia-Hasen bezüglich Sinnhaftigkeit und Machbarkeit würden mich sehr freuen.

Noch ein paar Anmerkungen zu den diskutierten konkreten Vorlagen-Parametern und Notationen:

  • Da man in Wiki-Vorlagen (im Gegensatz zu Bots) nicht umrechnen kann, sollten m.e. immer die für die Darstellung in Wikipedia geeignetste Notation gewählt werden. Bei den Koordination heisst dies aus meiner Sicht die Grad/Minuten/[Sekunden[.Hunderstel]]-Notation anstelle einer Dezimalnotation.
  • Zur Ermittlung der Ausdehnung eines Objekt ist der bisher verfübare Scale m.e. völlig ungeeignet. Selbst wenn es möglich wäre ihn umzurechnen, bezweifle ich dass sich jemand die Arbeit machen würde. Gleichzeitig benötigten unterschiedlche Objekte evtl. unterschiedliche Arten der "Ausdehnungsangabe". Überschaubar grosse Objekte werden wahrscheinlich am einfachsten mit einem Durchmesser (in Metern/Kilometern) beschreiben. Für Länder wird man hingegen vielleicht eher die begrenzenden Längen/Breitengrade angeben. Und für Objekte, bei denen man möglichst genau und Überschneidungsfrei die Ausdehnung beschreiben will, macht sich vielleicht sogar jemand die Mühe und bestimmt ein Geo-Polygon.
  • Was die Frage der Nutzung von Kategorien für Dinge wie "Type" angeht, so sind Kategorien m.e. nur bedingt geeignet eine Typisierung innerhalb einer (begrenzten) Typ-Klasse vorzunehmen, da WP hier zu leicht erlaubt neue Kategorien anzulegen (was ja für Wikipedia auch gut ist) und dann hier die Bot-Programmierer ständig am hinterherprogrammieren wären, wollen sie vernünftig klassifizieren. Allerdings könnte ein oben beschriebener Meta-Vorlagen-Mechanismus auch hier evtl. weitehelfen: Wenn in einer Kategorie-Seite "Orte in Bayern" eine Meta-Vorage "GeoType" festlegt, dass es sich um eine Artikel dieser Kategorie GeoType=city haben, wäre einerseits die Redundanz aus den Artikel entfernt, gleichzeitig aber auch automatische sichergestellt, wenn jemand eine neue Kategorie "Orte in XXX" anlegt und dort auch die Meta-Vorlage nutzt, dass die Bots auch dies korrekt erkennen werden.
  • Ein Erweiterungswunsch von unserer Seite wären noch Parameter, die "Ist Teil von" oder "Liegt in"-Beziehungen zwischen von Artikeln beschrieben Locations (z.b. für Stadtteile (1:n-Relation) oder Seen (n:m-Relation)) darstellen. Für unsere Anwendung (und bestimmt viele andere auch) wäre es super, wenn wir z.B. nicht nur wüssten, dass ein Artikel einen Stadtteil beschreibt, sondern auch, von welcher Stadt. Selbst wenn wir zustätzlich zu den Koordinaten zu allen Artikeln noch eine Ausdehnung (als Radius) bekommen würden, könnten wir dies im allgemeinen nicht fehlerfrei automatisch ermitteln da die so beschriebenen Ausdehnung eines Objekts mit einem Radius nicht exakt und auch nicht überschneidungsfrei mit anderen Objekte festgelegt werden können. Hierfür müssten für jedes Objekt "Grenzpolygone" definiert werden -- was aber nicht praktikabel ist. Und da man nicht für jede dieser Beziehungen eine eigene Kategorie (z.B. Stadtteile von München) anlegen wollen wird, scheinen hierfür definierte Parameter, die Referenzen zu anderer Artikel aufnehmen, der beste Weg zu sein. Auch diese könnten dann wieder mit Hilfe von Meta-Vorlagen gefunden und automatisch ausgewerten werden. Hat man jedoch dann eine (einfach beschriebene) Ausdehnugn eines (Grossen) Objekts und gleichzeitig eine Vielzahl von Objekten, die sich als Unterobjekte des Grossen erklären, kommt man hier sehr schon sehr weit.

Ptma 09:35, 24. Mär 2006 (CET)

Vielen Dank, Ptma, für deine ausführliche Stellungnahme. In unseren Falle der Georeferenzierung versuchte ich immer genau die drei Standpunkte (Editoren, Vorlagen-Bauer und Bot-Entwickler), die du schön skizziert hast unter einen Hut zu bringen, um aus Mediawiki das Beste für alle herauszuholen. Als Software-Mensch ist mir eigentlich nichts zu schade. Aber wenn ich deine Ausführungen richtig verstehe, dann muss ich dich enttäuschen, denn diese sind aus verschiedenen Gründen nicht umsetzbar, denn: Die Erweiterungen sind sehr gross, erst recht mit dem aktuellen MediaWiki-Code. Und aus finanziellen und organisatorischen Gründen sind sie einfach nicht machbar in absehbarer Zeit. Und wie ich schon mehrmals ausführte, ist es unabdingbar und auch sinnvoll dass type:city und Breite=O _in den Wikitext_ kommt (Copy&Paste kostet nichts)! Soeben mussten wir übrigens einsehen, dass ein Direktzugriff auf Wikipedia.de über den Toolserver nicht geht. Bleibt also noch der Dump der Artikel (ohne Vorlage oder sonstige Tabellen): Da hinein muss die ganze Information!!! Ich habe auf de:WikiProjekt_Georeferenzierung#Fazit_mit_Vorlage_Geokoordinate_und_gemeinsamen_Attributnamen einen Kompromiss vorgeschlagen, der die Wünsche "der Editoren" noch stärker gewichtet. Und wir sind so nah dran... --Geonick 21:00, 24. Mär 2006 (CET)

Vorschlag: Kategorien differenzieren

Siehe: Wikipedia:Fragen zur Wikipedia#Vorschlag: Kategorien differenzieren

Dieser Vorschlag zielt dahin, auch in Google Earth etwas differenzierter auf die Objekte schauen zu können. -- Simplicius 11:11, 14. Mär 2006 (CET)

Verstehe nicht, welche Kategorie du differenzieren möchtest: Geht es um die Type-Angabe (aber die ist ja englisch) oder um 'echte' Kategorien (dort finde ich keine Kategorie 'Ort', nur 'Ort in der Schweiz', etc.)? -- Geonick 23:47, 15. Mär 2006 (CET)
Es ist vorstellbar über Werkzeuge wie CatScan oder Back-Category auch eine Kategorie 'Ort in Schweiz' auf seine unterordnung in Kategorie 'Ort' zurückzuführen. Die Stadtteile sind wirklich ein unschönes Problem, ich weiß nur nicht ob wir über eine Type-Angabe:district oder tausende Kategorien 'Stadtteil in XY' schneller und einfacher zum Ziel kommen. Kolossos 20:08, 16. Mär 2006 (CET)
Dass Kategorie 'Ort in Schweiz' auf Kategorie 'Ort' zurückgeführt werden kann, ist klar. Kategorien werden in MediaWiki ja in separaten Tabellen verwaltet. Type zu verfeindern ist eine reine Frage der Abmachung: Da es weltweit keine klare Definition Stadtteil gibt, wurden ja die Begriffshierarchie Admin1- und Admin2 gemacht. Nun müsste man einfach Admin3 zulassen. --Geonick 13:47, 18. Mär 2006 (CET)
Ich verstehe immer noch nicht, wo das Problem liegt: Kategorien können doch mit den MediaWiki-Mitteln jederzeit ergänzt werden. War ja übrigens schon immer mein Vorschlag, Koordinaten-Typ wegzulassen und durch Artikel-Kategorie(n) zu ersetzen. Ein Parser wie unserer kann ohne weiteres neben Vorlage "Koordinate Artikel/Text/Text Artikel" auch Kategorien auslesen. --Geonick 13:47, 18. Mär 2006 (CET)

Hola, mein Vorschlag bezog sich auf die Kategorien ([[Kategorie:...]]), nicht auf den Type.
Wobei "Kategorie" und "Type" in der Tat nach Doppelmoppel riechen, aber man muss immer schauen, ob etwas unbegrenzt oder abgezählt ist. Beim "Type" sollte man zu schätzen wissen, dass es eine abgesprochene, abgeschlossene Menge gibt. Hier fällt es zum Beispiel leichter, grafische Symbole zuzuordnen. Kategorien hingegen laufen immer auf eine händische Nachbearbeitung hinaus, fürchte ich.
Die Diskussion wegen neuer Kategorien ist schon im Archiv gelandet, leider. Siehe hier....
Was über die Facettenkategorisierung gesagt wurde (= Schnittmengensuche) finde ich auch richtig. -- Simplicius 17:01, 18. Mär 2006 (CET)

Den Vorteil der Abgeschlossenheit der 'Kategorie' Typ sehe ich auch. Daher bin ich (noch) nicht für dessen gänzliche Ablösung durch Kategorien. Betreffend Kategorien kann ich dir immer noch nicht folgen: Möchtest du Kategorien ändern, d.h. 'Ort' einführen? --Geonick 09:06, 19. Mär 2006 (CET)
Ja, ich möchte für Stadtteile eine andere Kategorie als schlichtweg "Ort", zum Beispiel "Ortsteil".
Für Deutschland gibt es eine geschlossene Anzahl kreisfreier kreiszugehöriger Städte sowie kreiszugehöriger Gemeinden. Hier macht die Angabe der Einwohnerzahl recht viel Sinn.
Die anderen Stadtteile, Quartiere, eingemeindeten Dörfer usw. sollte man in Google Earth und ähnlichen Applikationen zwar darstellen, aber nicht grössenbezogen nach Einwohnern.
Die Einwohnerzahl ist etwas verwaltungspolitisches. Hagen in Westfalen soll als Stadt ein Symbol kriegen je nach der Anzahl der Einwohner. Zum Beispiel rot. Hagen-Vorhalle soll auch ein Symbol bekommen, aber nicht einwohnerzahlbezogen, sondern eben nur als Ortsteil. Zum Beispiel rosa.
Also ist die Frage, wie die Kategorien nun heissen sollen usw. -- Simplicius 17:24, 20. Mär 2006 (CET)


Welche Notation für Geokoordinaten

Als bessere Basis einer Diskussion, habe ich ein paar Gedanken als Artikel zusammengefasst.

Wikipedia:WikiProjekt Georeferenzierung/Geokoordinate

ich selbst plädiere natürlich für dezimale Notation, ist einfach zukunftsträchtiger. Und mehr als Grad hat der Durchschnittsmensch für Orte eh nicht im Kopf. GuidoD 19:10, 20. Mär 2006 (CET)

WP-Fotoralley

Bei den Vorbereitungen des Projekts "Bebilderung von noch unbebilderten, jedoch bereits georeferenzierten Artikeln" (siehe Wikipedia Diskussion:Bilderwünsche#Projekt: WP Fotosafari? und Benutzer:Gnu1742/Fotorallye ist die Frage hochgekommen, wie man mit geringem Aufwand die gefundenen Koordinaten in eine einheitliche Notation bekommen könnte. Vorschläge? --jha 19:06, 30. Mär 2006 (CEST)

Gute Frage! Oben ist ein Vorschlag von mir eingebracht worden zu dem sich erst wenige der hier am Projekt Beteiligten geäussert haben. Offen ist vor allem auch die Frage, wie mit Infoboxen zu Städten und Orten umgegangen wird. Mit Zur_Info (Infoxbox Polen) steht ein Vorschlag bereit und weiter oben sogar einer zur alternativen Dezimalnotation. Ansonsten gilt immer noch die Syntax der hier im Projekt beschriebenen Vorlage "Koordinate...". Auf Toolserver sind wir daran, eine Liste von Artikel mit fehlerhaften Koordinaten zusammenzustellen - der Toolserver ist z.Zt. aber leider nur beschränkt nutzbar (und wikisign ist auch aufgegeben worden...) --Geonick 18:18, 1. Apr 2006 (CEST)

Gauß Krüger Koordinaten

Kann man bei kvaleberg Karten verlinken, die Gauß-Krüger-Koordinaten verwenden? Zum Beispiel die Karte unter http://www.geoinfo-muenchen.de, die um einiges übersichtlicher und detaillierter ist als die anderen im Web vorhandenen Karten. Ein Benutzer fügt im Moment Links zu dieser Karte in verschiedene München-Artikel ein, ich fände es schöner, wenn man das über die Koordinaten-Vorlage mit erledigen könnte. --08-15 00:03, 21. Mär 2006 (CET)

Das ist zur Zeit dort nicht implementiert aber möglich; etwas analoges wurde z.B. für die Schweizer CH1903-Koordinaten gemacht. Ein Problem scheint zu sein, dass Herr Kvaleberg schwer zu erreichen ist. Eine bessere (u.a. deutschsprachige) Lösung oder mind. ein Ersatz ist daher schon angedacht worden. Eine andere Frage hier ist, wer (und ob überhaupt) die Koordinatentransformation machen soll, zumal besagter Service auch offenbar mit WGS84-Koordinaten umgehen kann. --Geonick 12:16, 21. Mär 2006 (CET)

WGS84-Koordinaten als Ausgabe geht, aber auch als Eingabe? Ich habe keine Möglichkeit gesehen; interessant wäre es natürlich, zumal die Software auch bei diversen anderen Städten im Einsatz ist. --08-15 19:49, 21. Mär 2006 (CET)

Google Earth

Hallo, um es auch einmal kurz zu thematisieren: Google Earth stellt seit März 2006 detailliertere Auflösungen für Deutschland zur Verfügung. Personen sind zwar noch nicht erkennbar, aber Strauchwerk, Trampelpfade etc. Gebäude, die bereits fleissig verortet wurden, sind somit erstmalig mal in schöner Auflösung inmitten städtischer Bebauung gut erkennbar. Das sollte motivieren, mehr solcher Artikel mit einer Geokoordinate zu versehen. Der von Google Inc eingekaufte Datenbestand ist übrigens aus Kostengründen älter als bei der gröberen Auflösung. Stadien, die anlässlich der Weltmeisterschaft gerade im Bau waren, sind also plötzlich nicht mehr zu sehen. -- gfi 19:30, 30. Mär 2006 (CEST)

Bezüglich Personen: Man sollte sich mal den Zwinger in Dresden auf den Monitor holen, da und in ganz Dresden kann man sehr wohl Personen sehen, wenn auch nur die Farbe ihrer Kleidung als Punkt und einem langen Schatten daran. Bei diesem allerdings sieht man schon welche Bewegungen der Mensch grade macht.
Bezüglich Aktualität: Zumindest in Berlin scheinen die Daten so von ca. April-Juni 2005 zu sein, erkennbar an den diversen Baustellen in der Stadt z.B. Lehrter Bahnhof. Auf jeden Fall eine riesen-klasse Sache, wie lange musste ich darauf warten, dass ich endlich auch mal die östlichen Stadtteile Berlins sehen konnte =) --BLueFiSH ✉ 18:54, 31. Mär 2006 (CEST)
Die deutschen Daten scheinen von den Firmen http://www.geocontent.de/ und http://www.aerowest.de/ zu stammen, wobei die ultrahochauflösenden Aufnahmen von der letzteren zu stammen scheinen. Ist schon schön, allerdings errinnert mich Deutschland von weiten an einen Patchworkteppich. --Kolossos 22:12, 31. Mär 2006 (CEST)
Es wird wohl zu einigen Feinjustierungen der vorhandenen Koordinaten kommen. Und vielleicht gibt es nun auch neues Interesse. Sollte man mal eine kleine publicity-Aktion machen, auch unter Einbezug von {{Lagewunsch}} (Kategorie:Geografische Lage gewünscht)? -- Simplicius 23:16, 31. Mär 2006 (CEST)

Zur Info

Wikipedia:Formatvorlage Stadt (Polen) ist neu ...Sicherlich Post 19:36, 30. Mär 2006 (CEST)

Danke für die Initiative. Ich würde noch folgende kleine Verbesserungen begrüssen: Folgende Zeilen 
 |ISO 3166-2=
 ...
 |type=city
 |Koordinate_Breite=N
 |Koordinate_Breitengrad=
 |Koordinate_...

sollten aufgrund der oben diskutierten Gründe so aussehen:
  |ISO_3166_2=
  ...
  |KoordinateTyp=city

. 

Damit könnte ich leben und wir könnten die Diskussion zu "Koordinate..." und Infoboxen zu einem vorläufigen Abschluss bringen. Dabei möchte ich nochmals darauf hinweisen, dass hier die Attribute "KoordinateTyp, KoordinateBreite, etc. ein Ersatz der üblicherweise empfohlenen Vorlage "Koordinate Artikel" darstellen; d.h. dass letztere (unten) im Artikel nicht mehr ein zweites Mal verwendet werden soll (die Verwendung von "Koordinate Text" im Lauftext ist natürlich weiterhin möglich). --Geonick 18:11, 1. Apr 2006 (CEST)
Ja sieht gut aus, aber bei "ISO_3166_2=" sollte der komplette Code also "PL-SL" und nicht nur "SL" stehen. -- sk 21:13, 1. Apr 2006 (CEST)
Nachtrag: Ich wäre für "Koordinate_Breite" da das besser vom Menschen zu lesen ist. Mein Programm hat damit zumindestens keine Probleme. -- sk 12:18, 18. Apr 2006 (CEST)
Ok; habe mein Codebeispiel oben gekürzt und schliesse mich der Variante "Koordinate_Breite" an - Hauptsache, die Koordinaten-Namen sind *in sich* einheitlich benannt. --Geonick 14:12, 18. Apr 2006 (CEST)
Wer bearbeitet Fehler in der KMZ-Datei?
Habe nämlich heute die Koordinaten Artikel Münster (Westfalen) betreffend überprüft und Ungenauigkeiten beseitigt. Danach sind präziser die Daten zu folgenden Artikeln:

Neu hinzugekommen sind:

Falls es einfacher sein sollte, die entsprechenden Daten aus einer KML-Datei zu extrahieren, so kann ich die auch anbieten, da ich bereits eine für mich gebastelt habe. Muss dann nur noch die Darstellung und der Text angepasst werden. Verlinkt sind die Einträge (außer Münster selbst) dort schon: [2] --mfg, NickKnatterton - Kommentar? 23:48, 30. Mär 2006 (CEST)

Bitte die Koordinaten in der Wikipedia selbst korrigieren (Wiki-Prinzip), die Aktualisierung der KML-Datei passiert dann automatischen einen Monat später. --Kolossos 07:13, 31. Mär 2006 (CEST)
Echt? So einfach ist das? Na dann bin ich mal gespannt. Die Koordinaten hab ich ja bereits in den Artikeln aktualisiert. --mfg, NickKnatterton - Kommentar? 08:43, 31. Mär 2006 (CEST)
Etwa jeden Monat gibt es einen Dump der gesamten deutschsprachigen Wikipedia. Der wird dann nach alle Koordinaten durchsucht und daraus wird eine neue KMZ-Datei für Google Earth erstellt. -- sk 09:20, 31. Mär 2006 (CEST)
Gibts eine deadline für den nächsten Dump, aus dem die Daten extrahiert werden? Dann wüsste ich jeweils immer, wann Toreschluss für ein paar neue Koordinaten sind. -- Simplicius 09:21, 31. Mär 2006 (CEST)
Der Dump wird in unterschiedlichen Zeitabschnitten erzeugt. Ein System hab ich da noch nicht erkennen können. Wahrscheinlich wird das je nach aktueller Belastung der Server gemacht. Da die Erzeugung der KMZ immer ein paar Stunden in Anspruch nimmt, wenn auch der größte Teil vollautomatisch geschieht, bin ich deshalb dazu übergegangen ca. aller 3-4 Wochen den neusten Dump zu nutzen. Derzeit hab ich den Dump vom 20. März 2006 genutzt und gerade sehe ich das ein neuer vom 27. März verfügbar ist. Meine Art den Dump nach Koordinaten zu durchsuchen dauert ca. 10 Stunden. Dann noch mal ca. 2-3 Stunden für die Aufbereitung und Onlinestellung. Aber es kommen bessere Zeiten. Geonick arbeitet ja an einer  Online-Filterung der Koordinaten, was mir und den anderen Nutzern viel Zeit ersparen würde.--sk 17:49, 31. Mär 2006 (CEST)
Steht eigentlich die Nummer der Auflagen in der Datei? Ist ja schon ein Klassiker. -- Simplicius 18:16, 31. Mär 2006 (CEST)
Nein, hab nie mitgezählt. Hab immer nur das Datum reingeschrieben. Ich denke es wird vielleicht die 15. Auflage sein (Schätzwert). -- sk 18:53, 31. Mär 2006 (CEST)
Dann mach doch mal ne Zählung a la v2006.01 :-)) -- Simplicius 23:13, 31. Mär 2006 (CEST)
Hab gerade mal für dich durchgezählt. Es ist die 7. deutsche Auflage und die 5. englisch. Also insgesamt sind bisher 12 verschiedene Dateien bereitgestellt worden. -- sk 09:57, 1. Apr 2006 (CEST)
Ist das WikiProjekt Georeferenzierung ein Freie Software-Projekt oder ein Google-Ableger?
Wenn man sich die Diskussionen im Rahmen dieses Wikiprojektes anschaut, hat man den Eindruck, dass es sich um ein Projekt handelt, das vor allem irgendwelche Marktführer bzw. nur einen Marktführer, nähmlich Google und dessen Software und APIs bedient. Insofern funktioniert das Projekt marketingmässig für Google wohl recht gut.

Mittlerweile hat man aber den Eindruck, dass alles auch dementsprechen (dementgooglet) aufbereitet werden muss/soll. Scale (Massstabsangaben) im Google-Stil. (das Problem hatte ich auch schon/war auch schon angefixt.)

Eigentlich bin ich nur vom Google-Maps-Hype genervt. OK.Stop! Google Media Markt ist geil. Aber müssen wir hier alle im Chor hinterherschreien: Jaa!! und unsere Scheine (Arbeit) ohne sicheren Gegenwert in die GeoGoogleTonne werfen. 

Aber zurück zur Überschrift.

Mit freier Software oder freien Daten hat Google Earth und Google Maps nichts zu tun. Arcy

Ja und? Die Google-Anwendungen sind halt die aktuell besten und leichtest verfügbaren Kartenressourcen. Soll man bewusst Inkompatibilität herbeiführen, um dem bösen, unfreien und gewinnstrebenden Google-Onkel eins auszuwischen? --::Slomox:: >< 03:10, 1. Apr 2006 (CEST)
Google in allen Ehren. Aber mit freier Software und freien Daten hat Google nichts am Hut. Soll das heissen, dass sich das Wikipedia:Projekt Georeferenzierung von WIKI-Grundlagen (Freie Software & Freie Daten) im Hinblick auf Geodaten distanzieren soll ? Arcy 03:25, 1. Apr 2006 (CEST)
Von welcher Inkompatibilität redest du? Von der allein selig machenden Inkompatibilität zu Google? Arcy 03:31, 1. Apr 2006 (CEST)
Beste Kartenresourcen? Wo finde ich eine gute Straßenkarte für ... Bremen, Köln oder München. Sorry. ! Arcy 03:34, 1. Apr 2006 (CEST)
Immer mit der Ruhe. Ich weiß jetzt nicht, was das Wort „WIKI-Grundlagen“ meinen soll, Grundlage eines Wikis ist erstmal nur freies Editieren. Auf jeden Fall bedeutet das Zugänglichmachen der kostenfrei abrufbaren Google-Karten keine Einschränkung oder gar Distanzierung irgendwelcher Prinzipien. Das die Google-Karten in jeder Hinsicht und ultimativ die besten sind, habe ich nicht gesagt, aber es gibt keine andere Kartendatenbank, in der du so leicht und weltweit relativ hochauflösende Satelliten- und Luftbilder findest. --::Slomox:: >< 03:57, 1. Apr 2006 (CEST)
Das wir auch gerne z.B. Nasa World Wind unterstützen würden, sieht man ja daran, dass es auch schon mal eine Punktdatei [3] dafür gab, aber leider hat die Software so viele Punkte (ca.5000) einfach nicht verkraftet. Wenn sich das bessert bin ich jederzeit bereit auch für solche freie Software die Daten zur Verfügung zu stellen. Aber derzeit muss man Google allen Respekt zollen, denn sie tretten der deutschen Landesvermessung mal gehörig auf den Schlips. Bin mir sicher die kriegen derzeit nicht mal mehr ein Bruchteil ihrer Orthophotos los. Vielleicht überdenken die mal ihre Lizenzbestimmungen. -- sk 09:51, 1. Apr 2006 (CEST)
Auch ich würde Nasa Worldwind oder ein anderes Vektor-Straßenkartensystem gerne unterstützen wenn es möglich wäre. So viel dazu. Zudem halte ich die Thematik "freie Software" für eine Teilmenge vom größeren Ziel "freies Wissen", und in der Beziehung sind Google-Daten recht lehrreich und zumindestens frei zugänglich. Auf freie Straßenkarten die von Freiwilligen mit GPS-Hilfe erstellt wurden und die mit professionellen Systemen konkurieren können werden wir wohl noch  lange warten müssen. Kolossos 20:36, 1. Apr 2006 (CEST)
Lieber Arcy, Danke für die Belebung dieses Aspekts zur Verbesserung der Vorlage "Koordinate..." sowie der Vorlagen-Schlüsselwörter. Mit der Lizenzfrage triffst du einen empfindlichen Nerv. Das Dilemma ist wohl, dass es z.Zt. keine Alternative gibt (neben Worldwind sowie Map24, multimap, etc.). In Diskussionen kürzlich hier waren wir nahe dran, uns auf Radius (oder Grösse, bzw. Koordinate_Grösse) in km zu einigen. Das Unglaubliche daran ist, dass damit sowohl das Bedürfnis nach schönem Google Maps-/Earth-Ausschnitt abgedeckt ist wie auch weitere - künftige hoffentlich freie - Dienste (Anm. EU-Bürger können da jetzt Druck machen vgl. publicgeodata.org). Wäre dies nicht eine Einigung Wert? Hat jemand eine Idee, wo wir eine (deutschsprachige) Alternative zum Kvaleberg-Service aufziehen könnten, um zu Beweisen, dass das geht (dann müsst ihr noch etwas warten, der Toolserver funktioniert macht uns z.Zt. das Leben schwer...)? --Geonick 21:56, 1. Apr 2006 (CEST)
Falls ein Interesse für einen eigenen Server besteht, müsste man das ein wenig organisieren (wofür genau, wer hat die Verwaltungsrechte, Träger, Impressum) würde aber schon irgendwie gehen, denke ich.


Eine Plattform in Art einer festen IP, Namensadresse, Server und guter Anbindung zu haben, ist wohl für weitergehende Experimente immer ganz nützlich. Dazu müsste man sich halt mehr und näher zusammensetzen.


Es ist im Übrigen wohl grundsätzlich klar, dass immer Vorsicht angesagt ist, wenn kommerzielle Unternehmen etwas umsonst anbieten (man weiss nicht ob es auf Dauer so bleibt).


Zuvor aber müsste man schon mit jedem Unternehmen Korrespondenz führen, ob ein direktes Ansteuern per Parameter gewünscht oder toleriert wird (vgl. deeplink-Problematik auf Bilder, Frames auf Inhalte Dritter usw.). Die Antwort müsste im Dokumentationswesen verwahrt werden. usw.


Für eine Einzelperson wäre es egal, für mehrere Personen ist ein Verein wegen dessen eigener Rechtsfähigkeit günstiger. -- Simplicius 09:52, 8. Apr 2006 (CEST)
Hinweis Meinungsbild
Hallo, auch ein Hinweis an dieser Stelle, weil es u.a. auch um den Ortsbezug geht: im Meinungsbild Wikipedia:Meinungsbilder/Angabe Adressen, ÖPNV und Öffnungszeiten geht es um zusätzliche Angaben in Artikeln über Museen, Archive, Theater, Zoos, Hochschulen und so weiter. Danke. -- Simplicius 11:45, 2. Apr 2006 (CEST)

Hinweis ist offtopic. Was hat das Meinungsbild mit der Georeferenzierungsarbeit zu tun? Arcy 12:59, 2. Apr 2006 (CEST)
Postanschrift und ÖPNV-Haltestelle sind sicherlich Informationen mit Raumbezug.


Wir können natürlich auch sagen, wir reden hier nur noch über Google Earth... -- Simplicius 13:21, 2. Apr 2006 (CEST)
Wenn Du deuschlandweit Haltestellen georeferenzieren willst, dann bist Du hier mit deinem MB sicherlich richtig. Ist das deine Absicht, dein Vorschlag für die WP, der Hintergrund?. -- Arcy 14:40, 2. Apr 2006 (CEST) *g*
Das wurde auch bereits thematisiert mit dem Ergebnis, dass es anscheinend (noch) kein System von stabilen Bezeichnungen/IDs gibt, über die man http://www.deutsche-bahn.de, http://www.vrr.de usw. ansteuern kann.


Ebenso gibt es noch keine Datei mit Haltestellen des ÖV plus Geookordinaten, sodass eine Umkreissuche möglich wäre im Sinne von "hier sind meine GPS-Daten, zeig mir die Richtung in die nächstgelegene U-Bahn-Station"


Letzeres (Ansatz von Stefan Kühn) könnte dann beides verbinden: die Angabe der Geokoordinate allein könnte auch schon dazu führen, die (in Luftlinie) nächstgelegenen Haltestellen zu finden. -- Simplicius 14:44, 2. Apr 2006 (CEST)
Ansteuerung der DB: Wo wurde das thematisiert?


Sollen auch die Fahrpläne übernommen werden?


Ist ein Routing nicht sinnvoller (z.B. am Rhein)?


Mit wievielen Haltestellen rechnest du Deutschlandweit?


-- Arcy 22:31, 2. Apr 2006 (CEST) >>oO*g*Oo<<
Ist schon zu lange her, mit genau diesen Fragen und einigen anderen müsste man so etwas neu angehen, und vermutlich geht das nur auf der Grundlage einer privaten Initiative im open source Bereich. -- Simplicius 16:47, 3. Apr 2006 (CEST)
Es mag ja vielleicht lange her sein aber doch nicht gelöscht.


"... nur auf der Grundlage einer privaten Initiative im open source Bereich.": Und was soll dein Hinweis nun hier?


Welche Open Source Initiative? es gibt zwar Diverse OS-Initiatitven bezüglich Geodaten, aber keine einzige die mit deinen Ideen zusammenpasst. Arcy 21:38, 4. Apr 2006 (CEST)


-- Arcy 18:40, 3. Apr 2006 (CEST)


aber mal ehrlich.

komm wieder auf den teppich zurück.

mach schluss mit wolke wp 007 - liezenz zum schreiben

jeder ist hier irgendwie mal ein aO.

anonsten viel spass beim einpflegen deiner liebsten adressen (schulen krankenhäuser, schwimmbäder ...). 

und vergiss die baumärkte nicht!



Arcy 00:10, 5. Apr 2006 (CEST)

Kannst ja nochmals einen Löschantrag stellen, das Meinungsbild ist ja noch nicht vorbei. Aber Vorsicht: Wiedergänger! -- Simplicius 16:49, 15. Apr 2006 (CEST)
Nochmals ?  Wo ist der erste ? Arcy 18:01, 15. Apr 2006 (CEST)
Such selbst. -- Simplicius 18:48, 15. Apr 2006 (CEST)
Bin doch kein Hund! Ist das hier Geocaching ? 09:10, 16. Apr 2006 (CEST)
Verwende doch mal die Funktion "Links auf diese Seite". Ich kann dir jetzt nicht noch das ganze MediaWiki-Grundsystem erklären. :-)) Simplicius 10:28, 16. Apr 2006 (CEST)
Möh! Wen du es mir nicht verraten willst, dann verrat es doch dem verehrten Publikum ;-) Arcy 14:39, 16. Apr 2006 (CEST)
Dieses ? Arcy 14:56, 16. Apr 2006 (CEST)
Karten automatisiert erzeugen
Unter en:Tarr_Steps habe ich eine automatisch erzeugte Karte gefunden. Die benutzte Vorlage en:Template:GBthumb sieht sehr kompliziert aus. Können wir so etwas auch in der deutschsprachigen Wikipedia machen? -- sk 15:55, 3. Apr 2006 (CEST)

Hab ich schonmal gemacht, siehe Wikipedia_Diskussion:Karten#In_Karten_einen_Punkt_einzeichnen_lassen. Leider fehlt der Lösung eine Umrechnung von Geokoordinaten in Bildkords., aber diese könnte ggf. extern erfolgen. Man müßte Vor- und Nachteile zur Alternative mal  abklären, aber aus meiner Sicht besser als tausend Punktkarten hochzuladen. Kolossos 20:34, 4. Apr 2006 (CEST)
Umkreissuche
Ich habe unter Wikipedia:Umkreissuche dem von Benutzer:Kolossos erstellten Programm eine ständige Heimat im Wikipedia-Namensraum gegeben.--Olaf2 18:29, 3. Apr 2006 (CEST)

Ich weiß zwar nicht wie ich die Ehre verdiene, aber vielleicht ist es so wirklich übersichtlicher. Kolossos 20:28, 4. Apr 2006 (CEST)
  • dafür wurdest du aber hier von mir zu einem Link heruntergestuft -- Arcy 21:33, 4. Apr 2006 (CEST)
Google Earth und Vorlage
Letzter Kommentar: vor 18 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Die Satellitenbilder von Google Earth sind ja nun flächendeckend für Deutschland hochaufgelöst, falls es nicht noch ein paar Ausnahmen gibt. Wie ich sehe, müsste man nun insbesondere für Gebäude viele Koordinatenangaben nachjustieren.

Ehe ich damit in den nächsten Wochen anfange, habe ich dazu aber auch mal eine Frage: was macht die Abstimmung darüber, die Vorlage in die Senkrechte zu bringen, sodass man die Koordinaten nur einmal eintragen muss statt doppelt?

Eine andere Frage noch zur Zuverlässigkeit der Positionierung der Google Earth Aufnahmen der Erdoberfläche: welchen Ellipsoiden verwendet Google Earth eigentlich überhaupt und entspricht dieser noch den alten gröberen Aufnahmen? -- Simplicius 16:58, 15. Apr 2006 (CEST)

Da ich gelegentlich mein GPS-Gerät mitlaufen lasse, kann ich für Dresden, Chemnitz und Hannover einen max. Gesamtfehler von 3-10m abschätzen, dieser Fehler kann z.T. auch durch das GPS-Gerät bedingt sein. Also aus meiner Sicht sind die Bilddaten gut für Gebäude verwendbar. GE arbeitet genauso wie der GPS-Standard und auch wir hier mit WGS84, somit muß man zum Glück keine Ahnung von der Koordinatenumrechnung und den Ellipsoiden haben.


Wenn es erstmal bei der alten Vorlage bleibt, sollte es mit dem Koordinaten-Ermittlungstool eigentlich ganz gut gehen.


Kolossos 17:24, 16. Apr 2006 (CEST)
Ok, dann trage ich WGS84 mal im Artikel über Google Earth ein.


Das Tool ging bei mir übrigens nicht im Internet Explorer, wohl aber im Mozilla. Wohl irgendwelche Sicherheitseinstellungen bei mir im Browser.


Mit nur einem einfachen GPS-Gerät ohne Referenzstation dürfte man wohl kaum besser als 3-10 m messen. Jedenfalls können unterschiedliche Ellipsoiden schon mal um bis zu einige hundert m abweichen, das war der Grund für meine Frage nach dem System. -- Simplicius 18:40, 16. Apr 2006 (CEST)
Leider hat Sicherlich auf die Verbesserungsvorschläge auf Zur_Info von sk und mir noch nicht reagiert. Meines Wissens herrscht daher immer noch 'status quo': Wer will, dass 'seine' Artikel auch in Google Earth erscheinen, sollte also weiterhin mit der Vorlage 'Koordinate Artikel' arbeiten - also auch dort wo in Infoboxen Attribute wie 'KoordinateBreite' (etc.) enthalten sind. Sobald wir dort zu einer 'Harmonisierung' kommen, kann in diesen Fällen die Vorlage 'Koordinate Artikel' weggelassen werden. --Geonick 15:39, 17. Apr 2006 (CEST) (P.S. Wir sind bald endlich fertig mit dem Basistool, das die Basis für einen aktuellen Index mit georeferenzierten Artikel bildet).
Was spricht denn dagegen, bereits die Vorlage Koordinate Artikel per Bot zu ändern? -- Simplicius 16:34, 3. Mai 2006 (CEST)Beantworten
Commons-Bilder mit Koordinatenangabe
Ich würde gerne für Bildobjekte von Commons-Bildern Koordinatenangaben hinzufügen und als Vorlage in der Bildbeschreibung einbauen. Also: "Das Gebäude/Objekt auf dem Foto hat die und die Koordinate."

  • Frage 1: Ist das sinnvoll?
    • 

  • Frage 2: Kann mir jemand beim Schreiben der Vorlage helfen?
Schöne Grüße, Longbow4u 08:46, 21. Apr 2006 (CEST)

So wie es http://www.flickr.com/ macht und man dann kleine Fotos auf dem virtuellen Globus sieht ist schon spannend. Dafür braucht allerdings jedes Bild seine eigenen Koords.
Andererseits wäre das aus meiner Sicht viel Aufwand und eine arge Dopplung zu dem was es hier in der WP schon gibt. Setze also lieber Links von hier zu den Commons, den Rest könnte dann zumindest für Kategorien und Bildergalerien theoretisch ein Bot übernehmen.
Eine andere Möglichkeit für die es schon Software gibt, ist einen GPS-Empfänger und eine Digicam zeitlich syncron laufen zu lassen, am Ende hat man dann automatisiert die Koordinaten der Kamera zu den einzelnen Bildern im Moment der Aufnahme im EXIF-Bildanhang.
Wenn du trotzdem willst, die englischen Vorlagen gibt es dort schon. Kolossos 09:37, 21. Apr 2006 (CEST)
Danke Kolossos, das war ziemlich genau das, wonach ich gesucht habe. Longbow4u 11:26, 21. Apr 2006 (CEST)
Wie Kolossos schon erwähnt hat, können Koordinaten in den Header von JPEG-Dateien geschrieben werden (EXIF-Format). Dafür gibt es Software wie z.B. Exifer. Damit sind die Koordinatenangaben beim Objekt dort wo sie hingehören und nicht getrennt davon (bei Text geht's nicht anders). Neben Koordinaten gibt es viele weitere beschreibenden Metadaten, die man auf diese Weise ablegen kann wie z.B. Aufnahmezeitpunkt. --Geonick 20:52, 21. Apr 2006 (CEST)
Ich habe das Template:Location nach Template:Coor dms gestaltet und auf die Standard-Vorlage Template:Information abgestimmt. Wie ich es mir in der Praxis vorstelle, habe ich hier mal als Beispiel ausprobiert: Image:Hildesheim-Hoher.Weg.Huckup.01.JPG. Es ist jetzt schön einfach und auch für Ungeübte zu verwenden. Allerdings weiß ich nicht, ob man noch weitere Attribute vergeben soll, wie die Region oder den Medientyp (Bild, Video, Audio). Was denkt ihr? @Geonick: Metadaten mit Exifer sind nachträglich bestimmt nur aufwendig einzufügen. Vielleicht gibt es bald Digikams mit GPS, so dass sie von Anfang an eingefügt werden.  Longbow4u 19:35, 22. Apr 2006 (CEST)
Kleinere Flugplätze (zB Flugplatz Anklam)
Hallo, besteht Interesse von Seiten des Projektes Georeferenzierung an kleineren Flugplätzen? Ich frage deshalb, da einige dieser Flugplätze zur Löschung vorgeschlagen wurden (siehe Betreff) und bei entsprechendem Interesses des Projektes Georeferenzierung das als Argument in der Löschdiskussion verwendet werden könnte. Ich habe die zur Löschung vorgeschlagenen Flugplätze jetzt mal referenziert und würde das auch bei den restlichen noch nicht referenzierten Flugplätzen machen. Grüße --Hans Koberger 12:24, 24. Apr 2006 (CEST)

Grundsätzlich ist natürlich auch die Georeferenzierung kleinerer Flughäfen erwünscht. Dies als Argument gegen eine Löschung einzusetzen, halte ich jedoch für gewagt. Es gelten immer noch die Relevanzkriterien und diese sind nicht abhängig von der Georeferenzierung. Ich habe mir jetzt aber noch keine Meinung über die Relevanz dieser und anderer Flughäfen gebildet. --Raymond 12:45, 24. Apr 2006 (CEST)
ACK Raymond --BLueFiSH ✉ 01:48, 25. Apr 2006 (CEST)
Wenn die Relevanzkriterien gelten würden, müssten diese Flugplätze bleiben. Aber so sieht es leider zur Zeit nicht aus. --Hans Koberger 06:57, 25. Apr 2006 (CEST)

Bestandsaufnahme - Wartung
Hallo,

das WikiProjekt Wartung führt eine Bestandsaufnahme, aller Qualitätsinitiativen, Wartungsseiten und WikiProjekte durch. Ziel ist es, einen Überblick über die Wartungsinfrastruktur der Wikipedia zu gewinnen und inaktive/nicht mehr benötigte Wartungs- und Projektseiten ausfindig zu machen. Schreibt deshalb euch bekannte Projekte (falls nicht schon geschehen) in die Liste(n). Arbeitet ihr selbst aktiv bei einem Projekt mit, so tragt euch bitte in die Betreuerliste ein. --Steffen85 (D/B) 22:23, 28. Apr 2006 (CEST)

EU
Letzter Kommentar: vor 18 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Könntet ihr euch mal um die Angabe bei der EU kümmern? Danke. --Forrester Bewerte meine Arbeit! 19:27, 30. Apr 2006 (CEST)

Da wir nur Punktdaten verarbeiten können halte ich das für wenig sinnvoll, alle Staaten der EU sollte allerdiungs georeferenziert sein. Kolossos 22:26, 3. Mai 2006 (CEST)Beantworten
Openstreetmap.org
Letzter Kommentar: vor 18 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Ich habe durch Zufall Openstreetmap.org [4] gefunden und mir jetzt ein GPS bestellt um dort freie Karten zu erstellen. Das wäre doch eigentlich schlau beide Projekte (Wikipedia und OpenStreetmap) zusammen zu führen. Zumal ja bei Städten eigentlich ein Gebiet und nicht eine einzelne Koordinate referenziert werden müsste. Eure Meinung dazu? Oder gibt es einen besseren Platz das zu diskutieren? Tabacha 10:21, 3. Mai 2006 (CEST)Beantworten

Wenn du einer Koordinate z.B. Koordinaten fehlen! Hilf mit.unbenannte Parameter 1:53_50_00_N_13_40_10_E, 2:53_50_00_N_13_40_10_E  folgst, kommst du auf eine Seite einen Verknüpfung mit Openstreetmap.org beinhaltet. Dein Beispiel mit den Städten ist nicht so gut, da glaube ich keiner mit dem GPS einmal auf der Stadtgrenze entlang um seine Stadt laufen wird. Generell wäre eine Speicherung von Linien und Flächen sinnvoll, aber das müsste dann besser von der Wikisoftware unterstützt werden. -- sk 13:25, 3. Mai 2006 (CEST)Beantworten
Ich habe dort im Wiki mal eine Seite aufgemacht da ich denke, dass die Seite schon sehr interessant für uns sein kann, z.B. was die Anzeige-Software oder die Pfad-Bearbeitung angeht. Kolossos 16:34, 6. Mai 2006 (CEST)Beantworten
Idee - Flußführer in Wikipedia mit GPS Daten
Letzter Kommentar: vor 18 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
Ich beschäftige mich mit GPS und mit Paddeln.
Die Flußführer vom DKV sind zwar gut, aber meist veraltet und besitzen keine 
GPS Daten.

Und meiner Meinung nach sollten Flußbeschreibungen auch frei sein!

Im Internet gibt es schon einige Ansätze von Flußführern mit GPS Daten. Die 
werden aber alle als normale HTML Seiten geführt (Mail an den Autor, ...).

Um so was aktuell zu halten, kam mir die Idee mit einem Wiki. 
Erst wollte ich ein Wiki (ich benutze TWiki) so umändern, daß es mir auch die Tracks für meinen GPS Empfänger liefert. Ich will ja an die GPS Daten der Flußbeschreibung 
und diese dann als Track in einen Garmin oder anderen GPS Empfänger laden.

Dann kam ich auf die Idee die Erstellung der Flußbeschreibung und die Track 
Generierung zu trennen.


  • Flußbeschreibung mit Wiki
    • 

  • Track Generierung über Browser PlugIn oder andere Programmen.
Das läßt sich ohne Probleme erledige, wenn ich die GPS Daten aus dem HTML Code 
extrahieren kann. Belastet auch die Wikipedia Server nicht!

Diese Idee hat mich dann weiter dazu gebracht, Wikipedia als Wissensplattform 
für die Flußbeschreibungen zu nehmen. (Warum auch immer was neues erfinden?)

In Wikipedia könnte man die bestehenden Flußbeschreibungen (z. B. 
Die Blau) um einen Absatz oder eine neue 
Seite Flußbeschreibungen ergänzen. Der Aufbau müßte dann halt fest vorgegeben 
sein (Vorlage?) unter Ausnutzung der bestehenden Wikipedia Syntax.

Das Ganze ist natürlich nicht nur aus Paddeln beschränkt!
Das muß auch für Wandern, Ski Touren, Fahrradfahren, ... funktionieren.

Was haltet ihr von dieser Idee?   ---WikiPeter 01:07, 4. Mai 2006 (CEST)Beantworten

Du kannst die Daten auch bei Openstreetmap.org hinterlegen (s.o.) (vorrausgesetzt der Server läuft wieder :-)), das ist IMHO besser geeignet als die Wikipedia. Tabacha 07:28, 4. Mai 2006 (CEST)Beantworten



Hallo WikiPeter, eine interessante Sache für Interessierte. Die Georeferenzierung im Projekt Wikipedia setzt immer die Relevanz (Enzyklopädiewürdigkeit) des zu referenzierenden Ortes, Objektes, Teil eines Flusses usw. voraus. In dem hier in Frage kommenden Relevanzkriterium (Spezielle Relevanz) der Wikipedia heißt es:
„Eine Enzyklopädie hat mitnichten die Aufgabe, jedes Stück Wissen der Welt zu sammeln, sondern ihr wesentlicher Zweck ist es, dieses Wissen aufzubereiten. Da zum Wissen der Welt im enzyklopädischen Zusammenhang nicht das private, das intime oder das triviale Wissen einzelner Personen oder Institutionen zählt, hat eine Aufbereitung gewisse Bedeutungsbezüge zu klären. Nicht jede Kaffeetasse oder jeder Kleintierzüchterverein, nicht jeder Sänger oder jede Bürgerinitiative prägt die Kultur ihres Landes, wird überregional wahrgenommen oder macht Geschichte. Anders formuliert: Es nützt uns nichts, wenn die Wikipedia ein Datengrab ist, in dem tendenziell unendlich viele Trivialitäten vermerkt sind, aber nationale oder international anerkannte Hochschulen, touristisch bekannte Gebäude oder Dinge mit bedeutender Historie gar nicht bzw. sehr dürftig beschrieben werden.“
Ich könnte mir vorstellen, dass manche Benutzer die Enzyklopädiewürdigkeit eines Flussführers unter Umständen in Frage stellen. Grüße, Hans. --Hans Koberger 07:44, 4. Mai 2006 (CEST)Beantworten
Ich halte Flüsse an sich erstmal generell für Wikipedia-relevant. Die nötigen Trackdaten sollten allerdings auf einem getrennten Server liegen und dabei am besten in Form einer Datenbank vorliegen. Somit sollte dann auch eine Pfadvisualisierung Richtung Google Earth oder dergleichen möglich sein. Mit Scripten-Code siehe Input und anderes könnte ich dich versorgen mit Zeit sieht es im Moment jedoch schlecht aus. Die Idee Pfade verarbeiten zu können steht hier jedenfalls schon lange im Raum. Kolossos 09:03, 4. Mai 2006 (CEST)Beantworten
Vernünftige Bedienungsanleitung
Letzter Kommentar: vor 18 Jahren22 Kommentare5 Personen sind an der Diskussion beteiligt
Die Vorlage {{Lagewunsch}} verweist auf Wikipedia:WikiProjekt Georeferenzierung, doch ist diese Seite als Bedienungsanleitung reichlich ungeeignet.

Zum Beispiel, der Einsatz der Parameter region=... type=... wird nicht vernünftig erklärt.

Ergebnis: Stefan Kühn ist ständig in den neu verorteten Artikel am nachbasteln. 

Lösung: Eine vernünftige Bedienungsanleitung - und das am besten für eine neue, vertikale Vorlage - muss her. 

Und zum Thema vertikale Vorlage noch ein Hinweis: In der englischsprachigen Wikipedia sind die Koordinaten in der Städtebox ein Zweizeiler:

{
...
| latd = 42 | latm = 16 | lats = 31.26 | latNS = N
| longd = 83 | longm = 43 | longs = 51.02 | longEW = W
...
}

Das steht abgekürzt für Latitude und Longitude, degree, minute und second, sowie North South und East West. Sieht doch narrensicher aus.

Grüsse, Simplicius 13:01, 6. Mai 2006 (CEST)Beantworten

Die Nutzung von Latitude und Longitude finde ich schlecht, weil 99% der Leute das so oder so verwechseln. Ich arbeite eigentlich nur dass nach, was am Anfang vergessen wurde, wo man den Sinn von type und region noch nicht so richtig sah. Die neuen Koordinaten sind fasst alle korrekt. Einzig und allein sind irgendwelche Schusselfehler, die immer mal wieder auftreten, ständig zu finden. Ich hab gerade bei cirka zehn deutsche Orte das region:BE ausgewechselt. Warum auch immer das dort stand? Ansonsten würde ich es so wie es gerade ist lassen. Die Umformatierung kann später auch ein Bot übernehmen. Lieber würde ich die Infobox für Deutschland einführen und dort die Koordinateneinbindung so vornehmen wie es bei der Infobox für polnische Orte gemacht wurde.-- sk 17:41, 6. Mai 2006 (CEST)Beantworten
Eingedeutscht könnte man sicherlich 

{
...
| Breite_G = 42 | Breite_M = 16 | Breite_S = 31.26 | Breite_NS = N
| Laenge_G = 83 | Laenge_M = 43 | Laenge_S = 51.02 | Laenge_OW = W
...
}

verwenden. Die polnische Alternative ist:

|Koordinate_Breite=N
|Koordinate_Breitengrad=52
|Koordinate_Breitenminute=13
|Koordinate_Breitensekunde=0
|Koordinate_Länge=O
|Koordinate_Längengrad=21
|Koordinate_Längenminute=02
|Koordinate_Längensekunde=0

Das Wort "Koordinate_" finde ich etwas zuviel des Guten. Kann man sich da irgendwo in der Mitte mal treffen? -- Simplicius 19:28, 6. Mai 2006 (CEST)Beantworten

Ich sehe derzeit nur die Möglichkeit über eine Abstimmung zu einem Ziel zu kommen. Du kannst ja mal eine Abstimmung vorbereiten. Weil wir ja damit auch eine ganze Menge Vorlagen um uns herum extrem beeinflussen und die Bots eine Menge arbeit bekommen werden. Ich muss generell der deutschen Community ein Lob aussprechen, dass hier nur sehr wenige Koordinatenvorlagen existieren. Das Chaos in der englischen Wikipedia ist extrem kontraproduktiv und erinnert stark an den Turmbau zu Babel. Ich hab gerade den englischen Dump durchforstet und stehe nun vor vielen neuen Problemen in den 43000 Koordinaten. -- sk 20:27, 6. Mai 2006 (CEST)Beantworten
Ich persönlich fände es am sinnvollsten, wenn man sich auf den Zweizeiler einigen könnte, denn trotz mehrere Variablen sind es ja eigentlich nur zwei Werte. Ich spreche mal Herrn Sicherlich dazu an. -- Simplicius 21:09, 6. Mai 2006 (CEST)Beantworten
hmm ich finde den einzeiler übersichtlicher (und könnte jetzt auf pl verweisen wo das so gemacht wird ;) ) ... außerdem ist es IMO deutlicher es es um koordinaten handelt und nix anderes; mit kurzen variablen habe ich gerade dumme erfahrungen gemacht (bsp war Gemeinde - schön kurz aber jetzt dumm weil sie eine andere logische verwendung "blockiert" ;) .. gibt es eigentlich auf de schon andere vorlagen die die koordinaten in anderer version verwenden (also nicht {{Koordinate .. sondern so wie in der pl-box?..Sicherlich  Post  21:26, 6. Mai 2006 (CEST)Beantworten
achja; die pl-box ist schon in einigen mehreren artikeln drin ... ich würde ungern nochmal alle ändern lassen nur um externen programmen die bearbeitung zu ermöglichen ...Sicherlich  Post  21:28, 6. Mai 2006 (CEST)Beantworten
Diese Zugänglichkeit ist durchaus wichtig. Geoinformation ist Information wie andere auch, der Mensch befriedigt seine meisten Bedürfnisse nun mal im Raum, wie nicht nur Geografen wissen. Und wir schreiben die Sachen ja auch hier in diese Datenbank und nicht auf Papyrus, um diese Informationen vielfältig erschliessen zu können.


Jede neue Vorlage im Alleingang, was anderes ist die Infobox zum Beispiel für Polen wohl nicht, macht es schwieriger. Auf der anderen Seite braucht man solche Experimente auch, um zu sehen, wie etwas ausschauen könnte. Das soll also kein Vorwurf sein. -- Simplicius 21:52, 6. Mai 2006 (CEST)Beantworten
dem "Vorlage im Alleingang" möchte ich vehement widersprechen; sowohl im portal:Polen als auch mit pl-WP erfolgte eine abstimmung; da wir ein internationales projekt sind ja durchaus relevant. Ansonsten würde ich sie mal in marketingsprache "first mover" nennen. Denn sie hat die sache ja scheinbar angestoßen. Aber anyways; für mich ist die untereinanderschreibung und die deutliche benennung übersichtlicher und scheint mir auch für den nutzer klarer ... aber natürlich IMO ... (ein meinungsbild wo jeder mal sagen kann wie man eine variable nennen will die zudem noch nur für externe programme relevant ist halte ich für übertriebene selbstverwaltung) ...Sicherlich  Post  22:14, 6. Mai 2006 (CEST)Beantworten
Ich kann mir aber eigentlich nicht vorstellen, dass es Euch völlig egal ist, ob polnische Ortschaften in Google Earth auftauchen?


Irgendwo habe ich auch eine Vorlage in einer Vorlage gesehen, interessante Konstruktion. In der Informatikersprache nennt man manche Vorstösse auch Insellösungen. Sie verhungern irgendwann.


In der Open Source-Bewegung bemüht man sich übrigens immer um [offene] Standards, damit nicht-bezahlte Programmierer in einer endlichen Zeit noch weiterkommen.  -- Simplicius 22:23, 6. Mai 2006 (CEST)Beantworten
@ google-earth; man könnte auch andersherum argumentieren ;) und wenn du mich persönlich fragst; ja mir egal .. ansonsten wie gesagt; die aktuelle version besteht bereits; nachteile in der einführung einer neuen version sehe sind m.E.: weniger leserfreundlich und es müssten viele inhaltslose edits durchgeführt werden. Vorteile sehe ich nicht ...Sicherlich  Post  23:05, 6. Mai 2006 (CEST)Beantworten
achja und die aktuelle pl-Lösung wurde ja auch mit dem geo-leuten abgestimmt und extra nochmal geändert; also in zwei wochen kommt der nächste mit noch nem besseren einfacheren, schöneren, schnelleren oder wie auch immer vorschlag? naja vielleicht wäre es mal wichtiger optische probleme durch die koordinaten wie beim Flughafen Krakau anzugehen statt variablen hin und her zu benennen ...Sicherlich  Post  23:08, 6. Mai 2006 (CEST)Beantworten
Auch ich bin für eine kleine Abstimmung, auch wenn ich dabei die alten Vorlagen befürworten werde, da diese deutlich kompakter, einheitlicher und flexibler sind als alles neue. So können z.B. diese Vorlagen mit und ohne Sekundenangaben betrieben werden. Die alten Vorlagen können auch problemlos in beliebigen Boxen betrieben werden. Kolossos 13:25, 7. Mai 2006 (CEST)Beantworten
ich weiß ja nicht, ob die "polnische variante" zu den neuen zählt; aber auch diese kann problemlos mit oder ohne sekundenangabe betrieben werden. wenn die alte das  {{Koordiante Artikel Text ..  ist dann glaube ich eigentlich nicht, dass sie durch die "neuen" abgeschafft wird ...Sicherlich  Post  13:31, 7. Mai 2006 (CEST)Beantworten
Was die Sache mit den ggf. fehlenden Sekunden angeht, wie Kolossos anmerkt, lässt sich das wohl lösen.


Momentan gibt es zwei Varianten in den Infoboxen: a) Boxen, in denen Zeilen für die Geoangaben vorhanden sind, in der Regel fehlen region, type usw. b) Boxen, in die die Vorlage mit geschweiften Klammern eingefügt wird.


Habe ich das eigentlich verständlich formuliert?


Die erste Variante finde ich übersichtlicher, weil man nicht geschweifte Klammern innerhalb der geschweiften Klammern hat.


Die zweite Variante garantiert aber eines: Einheitlichkeit. Ich vermute, dass dies deshalb der bessere Weg ist.


Zwar gehen die meisten Infoboxen (auch in der englischen Wikipedia) schon einen anderen Weg, aber: die zweite Variante garantiert circa 4 diskrete Versionen (Artikel, Artikel Text usw.),  die Anzahl der Infoboxen wird wachsen, die Infoboxen werden verändert, sie werden umbenannt, langfristig müsste Stefan Kühn (DER Leistungsträger bei der Auswertung der Dumps) also ein Ministerium für Infoboxen eröffnen.


Etwas anderes als die 3 Grundtypen sollte Stefan daher auch gar nicht mehr weiter erfassen, mögen die Createurs de Infoboxen (oder wie heissen die in der Autowerbung?) ihre Boxen anpassen.


Insbesondere braucht man dringend eine Vorlage, die es erlaubt, 20 Objekte in einem Artikel zu referenzieren, also muss dann (nur) in diese Vorlage auch der Parameter "Name/Bezeichnung/Titel" oder so aufgenommen werden.


Ich sag mal so:

  • man braucht wohl mal eine Seite, in denen drei neue Fassungen vorgestellt und dann diskutiert werden (z.B Wikipedia:WikiProjekt Georeferenzierung/Vorlagen)
    • 

  • dabei sollte eine Kommentierung (Bedienungsanleitung) stehen
    • 

  • eventuell sollte man auch die entsprechenden Vorlagen mal testweise setzen
    • 

  • angesichts der Zahl der bereits per Koordinantenvorlage und/oder Infoboxen irgendwie georeferenzierten Artikel (30.000) sollte es auch ein Meinungsbild geben - anhand dessen sich die Benutzer auch informieren können.


Grüsse -- Simplicius 11:06, 10. Mai 2006 (CEST)Beantworten
ohja zum glück wurde ja schon lange nicht mehr darüber diskutiert also nur hier oder  hier hier und ist ja auch schon einen ganzen monat her! das kann ja nicht so bleiben.. aber nur zu; zum glück gibt es nicht viel anderes zu tun als die umgestaltung der geo-referenzierung und anpassung der boxen die vor gar nicht so langer zeit wohl okay waren ...Sicherlich  Post  11:20, 10. Mai 2006 (CEST)Beantworten
Yep, ihr könnt die Infobox Ort in Polen doch gerne weiterverwenden. Es gibt noch 200 andere Länder, die sicher bald folgen werden a la "Ort in Mexiko". Es wird also nicht bei nur ein paar Vorlagen für Berg und See bleiben.


Mein Ziel ist es, dass eine Geo-Standardvorlage einfach eingebettet wird und kein Eigenweg stattfindet. Dazu muss sie einfach genug sein.


Ein paar Fragen stelle ich hier. Ich hoffe Wikipedia:WikiProjekt Georeferenzierung/Vorlagen erfasst den Stand der Vorschläge von Stefan Kühn und anderen. -- Simplicius 12:01, 10. Mai 2006 (CEST)Beantworten
Generell sehe ich derzeit keine Notwendigkeit, die bestehende Form der Koordinateneingabe umfassend zu ändern. Einzig die Infoboxen sollen durch eine neue Form (so wie Polen) besser nutzbar gemacht werden. Wichtig ist dabei einen Standard zu definieren und auch zu propagieren. Alle anderen bisher aufgetrettenen Probleme lassen sich durch minimale Änderungen sehr schnell und einfach lösen (mit den bestehenden Mittel. Siehe meine Sammlung_bekannte_Probleme-- sk 18:57, 10. Mai 2006 (CEST)Beantworten
Die doppelte Eingabe (bzw. Korrektur) nervt aber und da ist Sicherlichs Vorstoss sogar schon einen Schritt voraus, den die Standardvorlagen auch gehen sollten. Das ist eben noch die andere Seite der Initiative, abgesehen davon, dass die bekannten Probleme gleich mitgelöst werden sollten. -- Simplicius 23:08, 10. Mai 2006 (CEST)Beantworten
Gibt es den überhaupt schon eine Vorlage, die eine einmalige Koordinateneingabe mit der Möglichkeit verbindet sowohl mit Minuten- als auch mit Sekundengenauigkeit zu arbeiten? Kolossos 13:30, 11. Mai 2006 (CEST)Beantworten
Ja, siehe Krakau und die Vorlage von Sicherlich et al., oder eigentlich sämtliche Vorlagen in der englischsprachigen Wikipedia, soweit ich sehen konnte. -- Simplicius 13:50, 11. Mai 2006 (CEST)Beantworten
Ich unterstütze die Meinung von sk. Wie oben schon mehrmals gesagt, wäre ich froh um die 'neue' Vorlage; inkl. Infobox-Regelung. Wir wollten unsere automatische und hochaktuelle Extraktion von Koordinaten aus der deutschen Wikipedia schon lange fertig haben, aber wir kämpfen noch mit notorischen Stabilitätsproblemen des vom Verein e.V. bereitgestellten Toolservers... Geonick 22:52, 11. Mai 2006 (CEST)--Beantworten
Ermittlung von Koordinaten mit Google Maps
Letzter Kommentar: vor 18 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Ist es möglich Geo-Koordinaten mit Google Maps über den Browser zu ermitteln? Gruß --Kirschblut 17:53, 11. Mai 2006 (CEST)Beantworten

hier Arcy 18:10, 11. Mai 2006 (CEST)Beantworten
Habe ich gesehen - werde ich aber nicht so richtig schlau draus. Angenommen ich habe in Google Maps z. B. auf den Berliner Dom gezoomt. Wie kann ich dann die Koordinaten dazu bekommen? Gruß --Kirschblut 18:17, 11. Mai 2006 (CEST)Beantworten
Hat sich schon erledigt. Hab's in den en Wikipedia gefunden. Google Maps can be used to find coordinates. Find the place you require coordinates for, and double click on it to centre the map around that point. Then click the "link to this page" link, and the coordinates (in degrees and parts of a degree in decimals) appear in the address bar, eg "http://maps.google.co.uk/?ll=51.455558,-2.605047&spn=0.032304,0.069523". In this case the latitude is 51.455558, and the longitude is -2.605047. The reverse is possible by entering the lat and long into the search bar, with a space between them. --Kirschblut 18:25, 11. Mai 2006 (CEST)Beantworten
Anfordern von Daten der Landesvermessungsämter
Letzter Kommentar: vor 18 Jahren7 Kommentare6 Personen sind an der Diskussion beteiligt
Gemäß einem heutigen Vortrag von Jörg Tauss beim ChaosComputerClub in Dresden gibt es beim Bund und einigen Ländern (Berlin, Brandenburg, S-H ...) seit neuerem ein Informationsfreiheitsgesetz. Und Hr. Tauss hat mir Mut gemacht, dass man auf dessen Grundlage die Herausgabe von Geodaten bei den Ämtern einfordern könnte. Damit hätten wir eine echte Basis für Wikimaps also für wirklich freie Karten. Wer hat Lust auf eine Antragsstellung oder wie beurteilt ihr die Chancen? Kolossos 20:32, 13. Mai 2006 (CEST)Beantworten

Na das glaube ich erst wenn ich die Daten in der Hand habe. Also wenn ich das richtig verstanden habe dann bekommst du Akteneinsicht, aber das Produkt "ATKIS" und Co werden sie dir nicht frei zur Verfügung stellen. -- sk 20:38, 13. Mai 2006 (CEST)Beantworten
Freier Zugang ist tatäschlich nicht mit 'alle erhalten die Daten' und schon gar nicht mit 'kostenlos' gleichzusetzen. Bezüglich topografische Daten sind die Länder schon lange daran, sich die Rechtsgrundlagen geben zu lassen, dass das so bleibt; siehe EU/INSPIRE. Das EU-Parlament und die USA sind da 'offener'. Was was man z.Zt. machen kann, ist eine Petition hier unterschreiben. -- Geonick 18:35, 14. Mai 2006 (CEST)Beantworten
Ist der CCC dann nur eine schöne Traumwelt? Konkret, ich hätte nichts gegen die Datensätze (die Zahlen reichen schon) für die Grenzen Europas, Deutschlands, der Bundesländer oder der Kreise in keiner Weise was einzuwenden. Ich würde daraus gerne entsprechende KML-Dateien generieren. Man sollte deshalb mal verschiedene Behörden auf verschiedenen Ebenen anschreiben. -- Simplicius 14:22, 16. Mai 2006 (CEST)Beantworten
Schau mal auf Statistik Berlin-Brandenburg und Flächennutzungsplan Berlin - damit wird der "Einsichtnahme" hinreichend genüge getan, aber in der Fußzeile steht, "Geschützt. Keine Vervielfältigung, darunter kein Aufnahme in Datenbanken". - Sicherlich besteht die Tendenz, und kraft des politischen Willens kann auch manche Behörde jetzt eher geneigt sein, Dir ein paar Geodaten zu spendieren, wenn Du sie nett fragst und eine gute Begründung angibst, aber einfach so, neee, da werden dann notfalls Hilfsbegründungen vorgeschoben. Irgendwo hab ich in Erinnerung ein Meldung, wo ein Verein schon jahrelang mit einer Behörde im Clinch steht, die die Daten nicht rausrücken will, wozu sie eigentlich verpflichtet ist, aber immer neue "technische Verzögerungen" auftreten.


Aber hey, fragen darfste in einem demokratischen Land immer, und aus eigener Erfahrung kann ich Dich nur ermutigen - wenn es für die Beamten einfacher ist, Dir das Gewünschte zu geben, anstatt ständig abschlägige Antworten zu formulieren, dann machen die das auch. Du musst halt nur dran bleiben, und stoisch jedem Verweis auf eine andere Behörde und Entscheidungsorgan folgen, jeden Verweis auf ein Gesetz nachlesen und in Klärungsfragen münzen, bis es dann letztlich zum ersten Sachbearbeiter wieder zurückgeht, dem Du nachgewiesen hast, dass er kann und soll. *hehe* nur leider denke ich mal, wissen viele noch gar nicht, was sie derzeit können und sollen, und gerade da ist so ein Vortrag vom CCC ganz gut: die geben Dir einen Haufen Verweise auf Rechtsgrundlagen mit, die Du in den "Verhandlungen" mit den Amtsträgern gut einfließen lassen kannst, um den Prozess abzukürzen, bis sie Dir geben, was Du willst. GuidoD 16:56, 16. Mai 2006 (CEST)Beantworten
Günstig wäre ein gemeinsamer Beschluss der Behörden, bestimmte Daten frei zur Verfügung zu stellen. Im Bereich der Bibliotheken gibt es auch Zusammenschlüsse, um gemeinsam Normen für Volltexte usw. zu erarbeiten. -- Simplicius 17:42, 16. Mai 2006 (CEST)Beantworten
Was haben die Daten der Vermessungsämter mit "Wikimaps zu tun? Als Bilder natürlich ne Menge. Ansonsten ist in den Wikipedias die Einbindung von Karten- / Mapsservern nicht möglich, da eine Anbindung an solche bisher noch nicht vorgesehen ist und entsprechende Softwareanbindungen nicht existieren. Daran ändert auch keine Freistellung von Geodaten durch den Staat irgendetwas. Darüber hinaus sind Unmengen von Geodaten als Basis für Wikimaps bereits vorhanden. Arcy 19:02, 16. Mai 2006 (CEST)Beantworten
Kolossos hat deutlich formuliert, worum es geht: eine echte Basis für freie Karten, deutlicher geht's nicht mehr. Und was die Einbindung angeht: die haben wir für Punktdaten auch nicht, und trotzdem geht es, siehe WikiProjekt Georeferenzierung. -- Simplicius 16:52, 1. Jun 2006 (CEST)
Was willst Du? Echt Ey! Was ist eine echte Basis für freie Karten? Ist das was technisches ? Ist das was rechtliches ? Gibt es das schon ? Wer soll die liefern. Welches Format. Also echt ey! erzähl mal! Arcy 22:45, 1. Jun 2006 (CEST)
Ist Dir eigentlich klar wieviele Karten es in der Wikipedia gibt, die noch nicht georeferenziert wurden? -- Arcy 22:48, 1. Jun 2006 (CEST)
Es geht um primäre, orginale Daten. Und die wären für spätere Projekte von Vorteil. -- -- Simplicius - ☺ 15:52, 3. Jun 2006 (CEST)
Google Earth Bilder und WGS 84
Noch mal nachgefragt: wie genau sind eigentlich diese Satellitenaufnahmen hinsichtlich WGS84? Anscheinend seitdem hochauflösende Bilder da sind, liegen einige Icons reichlich daneben. Es ist noch nicht mal ein bestimmter Trend in irgendeine überwiegende Richtung, aber oftmals macht es 2 Sekunden aus. 

Was ich mich jetzt frage, wenn ich die Daten in den Wikipedia-Artikeln korrigiere und wieder passend mache: wie genau ..... oder mit anderen Worten: hat es jemand mal nachgeprüft anhand von im Bildmaterial erkennbaren trigonometrischen Punkten?
-- Simplicius 16:52, 1. Jun 2006 (CEST)

Ich weiß leider nicht, wie genau GE ist, Ich habe in meiner Region jedoch festgestellt, dass die in GE falschen Punkte in den meisten Fällen solche sind, bei denen die Koordinatenangaben gerundete Angaben zu den Sekunden enthalten. Wenn der Ort nicht zufällig bei 0 Sekunden liegt, passt es bei hoher Auflösung natürlich nicht.
 Beispiel bei mir um die Ecke: Hornbach hat in Wikipedia die Koordinatenangabe 49° 12′ n. Br., 7° 22′ ö. L. - was bei GE zu einem Punkt irgendwo in der Wiese zwischen Althornbach (nördlich, 49° 12' 12" N 7° 22' 30" O) und Hornbach (südlich 49° 11' 14 N 7° 22' 10" O) führt. Sekundengenaue Angaben in der Wikipedia aus Zeiten als Google noch geringere Auflösungen hatte und daher wohl aus anderen Quellen stammen, passen dagegen in GE sehr oft exakt ins Bild. Gibt es in anderen Regionen ähnliche Beobachtungen? -- I.S 16:38, 1. Jun 2006 (CEST)

Hallo, ich bezog mich dabei auf die sekundengenauen Angaben für Gebäude etc. Hier zeigen sich große Ungenauigkeiten, was möglicherweise nicht nur damit zusammenhängt, dass alles vorher zu grob gerastert war, um diese Differenzen festzustellen. -- Simplicius 18:39, 1. Jun 2006 (CEST)

2 Sekunden: Eine Bogensekunde in Hamburg entspricht 18,60. Wie geanau muss es den sein? Arcy 19:10, 1. Jun 2006 (CEST)
Das Problem der Genauigkeit wird auch an anderer Stelle diskutiert: [5], [6] - leider ebenfalls mit unbefriedigenden Ergebnissen -- I.S. 21:46, 1. Jun 2006 (CEST)
Ja stimmt. Aber die Frage ist nicht, wer diskutiert was, sondern welche Genauigkeit will die Wikipedia. Symplicus will beispielsweise genauere Daten (Ungenauigkeiten < 50 m). Wo gibt es hier in der Wikipedia Probleme mit 50 m Ungenauigkeit? Was sind die konkreten Fälle? Arcy 22:41, 1. Jun 2006 (CEST)
Die Frage nach konkreten Fällen reiche ich an Sir Gawain weiter, der im grösseren Umfang viele Koordinaten nachkorrigiert hat. -- -- Simplicius - ☺ 16:18, 3. Jun 2006 (CEST)
Hallo I.S., 

also eigentlich geht es um zwei Fragen: a) wie genau sind die Bilder von Google Earth projeziert, b) ist was durch die neue Auflösung "verrutscht"?

Danke für die Links, ich habe die mal gerade grob überflogen und mein erster Eindruck ist folgender: die verwenden ihre GPS-Daten, stellen eine Abweichung zur Ermittlung von Koordinaten per Google Earth fest und fragen sich dann, ob sie ihrem GPS-Empfänger trauen können. Kolossos hat das auch mal erlebt. 

Lösung: Es gibt ja genügend Punkte, die von Vermessungsingenieuren als topographische Punkte bestimmt wurden. Jemand müsste sich mal die Mühe machen, für ca. 10 solcher Punkte, wenn sie auf den Aufnahmen sichtaber sind, die Koordinaten per Google Earth zu erheben. Daraus liessen sich tatsächliche Abweichungen ableiten. 

Dabei muss man noch aufpassen, dass nicht Differenzen zustandekommen, weil man Höhe und Breite nach einem anderen Ellipsoiden als den für WGS84 verwendet, etwa Bessel etc.

Bei den Satellitenbildern wäre noch zu prüfen, wie gut die Aufnahmen entzerrt wurden, so könnten die Differenzen innerhalb eines Fotos/"Rechtecks" noch variieren. 

Ich habe nämlich das Gefühl, dass wir sonst jedesmal, wenn Google Inc. andere Datenquellen einspeist, die Koordinaten der Objekte in Wikipedia Earth verändern, und somit den Problemen von Google Earth hinterherlaufen würden, ohne tatsächliche Ungenauigkeiten in der Georeferenzierung zu korrigieren. -- Simplicius - ☺ 16:02, 3. Jun 2006 (CEST)

Z.B. bei Korbach lag vor 1-2 Monaten GE und GM ca 5 km voneinander, jetzt liegen sie gleich, aber wahrscheinlich beide falsch (Koordinaten fehlen! Hilf mit.unbenannte Parameter 1:51_14_1_N_8_51_24_E_type:city(pop)_region:DE, 2:51° 14' 1" N, 8° 51' 24" O ).--KaHe Disput
Gemäß amtlichen Geodatenzentrum.de liegt Korbach bei Koordinaten fehlen! Hilf mit.unbenannte Parameter 1:51_16_33_N_8_52_10_E_type:city(pop)_region:DE, 2:51°16'33"  N, 8°52'10" O . Der Abstand beträgt also 4.8 km in anderen Regionen beträgt die Genauigkeit (wie oben erwähnt) allerdings 10-15 m. Es hilft also wohl nur vorher die Region prüfen. Unter Layers gibt es ein übrigens ein Kästchen mit "populated Places" wenn diese Orte auf der grünen Wiese liegen ist das schon mal verdächtig. Kolossos 21:08, 3. Jun 2006 (CEST)
Leute, ich denke zur Überprüfung an einen einen trignometrischen Punkt. Das ist ein spezieller Stein auf einem Berg oder im Gelände, oder zum Beispiel eine Kirchturmspitze, also etwas, was auf den cm genau bestimmt wird.


Mir gehts darum, dass ich den Eindruck habe, dass manche Bookmarks früher über einer Burg in Google Earth lagen, und jetzt deutlich daneben. -- ☺ 21:53, 3. Jun 2006 (CEST)
Beruhen die Daten vom Goedatenzentrum eigentlich auf auf WGS84 oder auf dem Potsdam-Datum? Ggf. müsste man sie wohl vorher umrechnen (z.B. hier: [7] [8]). Eine Abweichung von 4,8km lässt sich damit aber wohl nicht erklären. -- I.S. 22:12, 3. Jun 2006 (CEST)
Ich vermute WGS84 aber weiß es auch nicht definitiv. Die alten unscharfen Google-Daten lagen einfach z.T. daneben, das erkennt man am nahegelegenen Marsberg, welches es jetzt einfach doppelt gibt. In den neuen schärferen Bildern, also in über 80% von Deutschland, konnte ich solche Abweichungen noch nicht finden und kann mir diese auch nicht vorstellen. Kolossos 23:10, 3. Jun 2006 (CEST)

Also, momentan vorhandene Abweichungen in Google Earth lassen sich konkret feststellen, wenn man sich zur Prüfung an so etwas hält: Trigonometrischer Punkt.  Objekte wie Dörfer oder Inseln lassen sich dafür nicht als Referenz benutzen.


Für uns macht es nur Sinn, die tatsächlichen Koordinaten anzugeben. Wenn es dann unter Google Earth nicht korrekt passen sollte, ist das nicht unser Problem. Die zu klärende Frage ist dabei aber, ob Google Earth eine durchaus gleichwertige Möglichkeit zur Georeferenzierung darstellt.  -- Simplicius - ☺ 11:33, 4. Jun 2006 (CEST)
Solange es keine Hinweise gibt, dass die neuen hochaufgelösten Aufnahmen auch arg daneben liegen, solange kann auch GE genutzt werden. Kolossos 13:47, 5. Jun 2006 (CEST)
Primär hat mich die Genauigkeit der groben und der feinen Auflösung interessiert. Ferner hätte ich gerne noch gewusst, wie stark Bessel- und WGS84-Koordinaten voneinander abweichen. Ich werde Sir Gawain noch mal fragen, der hat hunderte von Nachkorrekturen gemacht. -- Simplicius - ☺ 14:03, 5. Jun 2006 (CEST)
Hi! Meine Erfahrung mit den hochauflösenden Aufnahmen von Google Earth ist, dass die Bilder etwa eine Abweichung zwischen 0-3 Metern von den Koordinaten haben, die mir mein GPS-Empfänger liefert. Da das imho recht genau ist, vertraue ich den Aufnahmen mit Hochauflösung mittlerweile (allerdings immer in Kombination mit der eingeblendeten Straßenkarte – sicher ist sicher). Ich kann übrigens Kolossos nur zustimmen: Die alten unscharfen Google-Daten lagen häufig genug ziemlich daneben, was man sehr schön an Übergängen von Bereichen mit hoher und niedriger Auflösung sehen konnte. Da passte oft überhaupt nichts zusammen -- Gruß Sir Gawain 15:14, 10. Jun 2006 (CEST)

Das bedeutet mit anderen Worten, dass die Bilder mit niedriger Auflösung in der Tat nicht besonders gut verwendbar sind. Sag mal, wie groß waren die Korrekturen, die du im Schnitt machen musstest? -- Simplicius - ☺ 15:29, 10. Jun 2006 (CEST)
Das ist von Region zu Region unterschiedlich. Im Ruhrgebiet beispielsweise waren die Aufnahmen mit niedriger Auflösung in Nord-Südrichtung um etwa einen Kilometer zu weit nördlich positioniert. Wer sich in dem Bereich auf Google Earth verlassen hat, lag vollkommen falsch. Aber das Ruhrgebiet war auch das krasseste Beispiel an Falschpositionierung, was mir unter gekommen ist. Ein gutes Durchschnitts-Beispiel - weil noch unkorrigiert - ist die Burg Altena. Dort sieht man jetzt sehr schön, wie weit meine damalige "Näherung" (unter Zuhilfenahme von Falk-Stadtatlanten) von der Realität abweicht. -- Gruß Sir Gawain 15:40, 10. Jun 2006 (CEST)
Meintest du von der Google-Realität? -- Simplicius - ☺ 15:50, 10. Jun 2006 (CEST)

Jou, meinte ich. Wobei ich ja oben geschrieben habe, dass die "hochauflösende Google-Realität" bei mir ziemlich genau mit der von TomTom ermittelten Realität übereinstimmt. -- Gruß Sir Gawain 15:56, 10. Jun 2006 (CEST)
Wikipedia und der Terrorismus
"..Die geografischen Daten des Berliner Olympiastadions, der Hamburger AOL- oder der Münchener Allianz-Arena kann man zudem bequem im Online-Lexikon Wikipedia nachschlagen. Nicht Google Earth und ähnliche Programme seien das Problem, sondern die Raketen und dass es dafür einen Schwarzmarkt gibt, sagt Heil..." http://www.heute.de/ZDFheute/inhalt/9/0,3672,3943721,00.html -- sk 17:21, 12. Jun 2006 (CEST)

*g* wenn - siehe Diskussion oben drüber - die daten denn genau wären und man ihnen auch trauen könnte. also doch lieber selber erst mit GPS ein fussballspiel besuchen liebe terroristen!. soviel zeit muss sein. Arcy 19:05, 12. Jun 2006 (CEST)
Na wenigstens kam auf diese Weise unser kleines Projekt mal in die Medien.
PS: Für Terroristen mit Linuxbetriebssystem gibt es jetzt auch eine Google Earth Version. Kolossos 12:52, 13. Jun 2006 (CEST)
Neue KML
So ich hab eine neue KML der deutschsprachigen Wikipedia produziert. 34549 Koordinaten sind drin. Ich habe mein Programm von AutoIt auf Perl umgestrickt. Dadurch dauert der ganze Filterungsprozess nur noch ein Bruchteil der üblichen Zeit. Wenn ich den Dump heruntergeladen habe benötige ich jetzt nur noch ca. 30 Minuten bis ich die neue KML online stellen kann.

Eine große Neuerung in der KML ist, dass jetzt die Kontinente in der Ordnerstruktur eine Ebene weiter höher greückt sind. Dadurch kann man jetzt z.B. problemlos alle afrikanischen Städte mit einmal ein- oder ausschalten. Insbesondere beim ein- und ausschalten von Europa scheint mir das günstiger. Schreibt mir mal eure Meinung. Ansonsten viel Spaß. -- sk 00:08, 17. Jun 2006 (CEST)

Die neue Ordnerstrutur find ich klasse. Sie macht es viel einfacher zu navigieren. Schon von dem Hintergrund aus, wenn ich 'ne Stadt suche und  nicht weis wie groß sie ist. Des weitern hab ich auch das Gefühl, das die Daten trotz das die Datei jetzt größer ist sehr viel schneller geladen werden. Naja, vielleicht liegt's auch an der neuen Version von Google Earth. --Monsterxxl <°))))> 22:50, 17. Jun 2006 (CEST)
Ich glaube die Version 4 scheint die großen Punktdaten besser handeln zu können. Zumindest sieht die Datei genauso aus wie früher, nur halt mehr Punkte. -- sk 11:13, 18. Jun 2006 (CEST)
Eine Frage
Ich habe einige Ort mit Koordinaten versorgt, leider wird die Anzeige oben rechts nicht dort angezeigt wo sie soll. Z.B. Wassel was habe ich falsch gemacht? --81.14.207.15 22:04, 2. Jul 2006 (CEST)

Bei mir geht es jetzt, vielleicht ein temporäres oder Browser spezifisches Problem. Kolossos 23:01, 2. Jul 2006 (CEST)


P.S.:Diskussionen werden immer unten weitergeführt. Und scheinbar wars du nicht angemeldet.

Also bei mir geht es nicht, Koordiate wird zwischen "Karte" und der Karte angezeigt --Fuchs1978 06:17, 3. Jul 2006 (CEST)

Ist repariert. Problem siehe hier. --BLueFiSH ✉ (Klick mich!) 10:48, 3. Jul 2006 (CEST)
Radiobeitrag zum WikiProjekt Georeferenzierung
Ich wurde vom SWR2 zu unserem Projekt ausgefragt. Ergebnis: Das begehbare Internet -- sk 14:26, 3. Jul 2006 (CEST)

Das neue Google Earth setzt ja auch auf die Frage um, wie man am besten 3D-Systeme in der Bedienung steuern kann, ähnlich deiner Disseratation. Bemerkenswert. -- Simplicius - ☺ 11:33, 14. Jul 2006 (CEST)
SRTM-Daten
Hallo zusammen. Wer Interesse hat, schaue mal auf www.srtm.com. Dort finden sich aus SRTM-Daten erzeugte Reliefkarten. Dank Stefans KML-Dateien sind nun auch Wikilinks einblendbar. Evtl. helfen die Karten um Koordinateneinträge zu verbessern oder schnell mal nach der Lage eines Berges oder einer Insel zu suchen... Leider ist der Server nicht der schnellste, aber ich arbeite daran... ;-) -- hbr 17:45, 7. Juli 2006 (CEST)

Zeilenumbruch
Mir ist heute aufgefallen, dass Koordinaten (im Text) mit der Vorlage:Koordinate Text Artikel nun in einer neuen Zeilen beginnen, siehe bspw. Molkenhaus (Harz). Es liegt wahrscheinlich an der Vorlage:Text oben rechts. Muss das jetzt so sein? -- Netnet @ 23:57, 11. Jul 2006 (CEST)

Nein, der generierte Quelltext zeigt

<p>Das erste Molkenhaus (</p>


<div id="coordinates_3_ObenRechts"><a href=...</div>


<p><span class="coordinates"><a href=


und diese Absatzeinfuegung sehe ich nirgendswo in den Vorlagen. Warum die trotzdem reinkommen, hmm. GuidoD 00:22, 12. Jul 2006 (CEST)
Habe den Div in der Vorlage:Text_oben_rechts durch ein span ausgetauscht, jetzt ist es wieder normal. Wurde bei der Anlage der Vorlage in div geändert. --BLueFiSH ✉ (Klick mich!) 00:28, 12. Jul 2006 (CEST)
Koordinaten in Skin "Klassik" nicht mehr sichtbar
Ich verwende den Skin "Klassik" und sehe die Koordinaten überhaupt nicht mehr. Das nervt. -- Simplicius - ☺ 11:32, 14. Jul 2006 (CEST)

gar keine mehr oder nur die, die im Monobook oben rechts stehen nicht mehr? Der Eintrag in MediaWiki:Standard.css, dass die Oben-rechts-Anzeige ausgeblendet werden soll (was bei Klassik nicht oben rechts ist, sondern am Ende des Artikels da wo die Vorlage steht), ist nämlich schon ne Ewigkeit da drin. --BLueFiSH ✉ (Klick mich!) 12:16, 14. Jul 2006 (CEST)
Ich sehe sie mit "Klassik" jetzt auch dort nicht mehr, wo sie positioniert sind. Gibt es eine Abhilfe? -- Simplicius - ☺ 16:43, 14. Jul 2006 (CEST)
Vorlage:Koordinate Artikel müsste jetzt wieder sichtbar sein. Eventuell sollte man aber mal überlegen, ob es für Ottonormalo im Klassik-Skin besser ist, gar nichts oder die Koordinate am Ende des Artikels zu sehen. Wenn man sie global ausblendet, kann sich der interessierte Benutzer diese ja auch wieder persönlich einblenden. Gruß --BLueFiSH ✉ (Klick mich!) 01:38, 17. Jul 2006 (CEST)
Jo, die Koordinate ist wieder zu sehen und aus Oslo kriege ich jetzt ein "Warning: dir(/home2/egil/kvaleberg-www/wiki/skins): failed to open dir: No such file or directory in /home/egil/public_html/wiki/includes/Skin.php on line 23" zurück, wir sind also einen Schritt weiter ;-)) Simplicius - ☺ 08:37, 17. Jul 2006 (CEST)
kvaleberg will nicht
Dadurch, dass Kvaleberg im Moment nicht geht, ist wohl der schlimmste anzunehmende Unfall für unser Projekt jetzt eingetreten. Hat jemand eine Idee für Abhilfe? Ansonsten hilft wohl nur warten. Kolossos 14:03, 17. Jul 2006 (CEST)

Ersatseiten
Zur "Kvaleberg-Problematik":  Ersatzseiten sind eigentlich ganz einfach: ;-)
Es werden zwei irgendwie definierte Zahlenwerte (unsere Koordinaten) als Parameter weitergegeben und wieder ausgelesen , definiert verarbeitet und Seiten entsprechend neu eingebaut.

Die Kvaleberg-GIS-Extension hat da ein paar gute Funktionen. Sie ist aber nicht als nötig um, einen X -und Y-Parameter in einem Link zu einer anderen Seiten (nach map42.space) einzubauen.

Arcy 23:55, 19. Jul 2006 (CEST)

Das Thema hat sich schon erledigt, es geht inzwischen wieder. Außerdem hatte Magnus Manske da was temporäres beigesteuert. --BLueFiSH ✉ (Klick mich!) 00:02, 20. Jul 2006 (CEST)
was mein "erledigt" genau. und wo ist das temporäre gelandet ? Arcy 01:07, 20. Jul 2006 (CEST)
Bitte mal vorbeischauen
Wikipedia_Diskussion:Formatvorlage_See#Geo-Koord. --BLueFiSH ✉ (Klick mich!) 21:19, 19. Jul 2006 (CEST)

Blöde Frage
Es wurde der Wunsch geäußert nach den Koord. der Talbrücke Judental. Als Autor + Fotograf weis ich wo das Ding liegt, habe die Brücke auch über den benachbarten Ort schön lokalisieren können [9]. Nun steht im Artikel: Die Geokoordinaten werden den Google Maps entnommen. Ich sehe aber keinen Button oder ähnliches der mir das ermöglicht. Für einen klitzekleinen Tipp wäre ich äußerst dankbar, dann aknn ich auch mit der Zeit den anderen Brücken eine Lage per Korrd. geben. --Störfix 08:45, 23. Jul 2006 (CEST) P.S. Ach ja, und mir meldet er die Seite zu hjl_get_Coor [10] kann nicht geöffnbet werden.

Also bei mir wird die Webseite hjl_get_Coor angezeigt. Probiers mal mit Firefox. Falls die Seite nicht funktioniert, dann probiers mal mit Google Earth. Kolossos hat ein Tool dafür gestrickt. -- sk 09:50, 23. Jul 2006 (CEST)
Danke, aber bei zwei verschiedenen Rechnern (zu Hause und im Büro) kann ich die Seite zu hjl_get_Coor nicht öffnen und firefox will ich deshalb nicht installieren. Im übrigen weis ich immer noch nicht, wo auf der Google-Seite die Koordinaten zu finden sind. --Störfix 10:08, 23. Jul 2006 (CEST)
In Google Maps gibt es einen Link namens "Link to this Page". Die referenzierte Adresse kannst du kopieren, sie sieht etwa so aus:
"http://maps.google.com/?ie=UTF8&ll=50.259779,10.96722&spn=0.001458,0.003927&t=k&om=1"
Die Koordinaten sind nun 50.259779 nördlicher Breite und 10.96722 östlicher Länge. Die Dezimalstellen kannst du dann noch in Minuten und Sekunden umrechnen. Gruß 84.162.38.210 14:21, 23. Jul 2006 (CEST) --

Danke! Habe es endlich gefunden. Die Koordinaten sind in der Seitenadresse versteckt. --Störfix 14:52, 23. Jul 2006 (CEST)

Neue Vorlage mit Koordinaten
Hallo,
ich habe heute die Vorlage:Koor dms erzeugt, die sich an dem englischen en:Template:Coor dms orientiert. Meiner Meinung nach ist diese Vorlage um einiges gelungener, als die deutsche Variante Vorlage:Koordinate Text Artikel. Zum einem ist sie viel kuerzer zu schreiben (=> echt minimalistisch) und redundanzfrei (und weniger fehleranfaellig), da die Koordinaten nicht zweimal angegeben werden muessen. Zusaetzlich ist der Text, der von dieser Vorlage erzeugt wird, auch besser, da er immer im selben Format ist (und keinerlei Spielereien wie "nördl. Breite" anstatt "N" oder so etwas zulaesst). In Infoboxen, wie Vorlage:Infobox Flughafen, wo Koordinaten in einem Feld uebergeben werden (und man somit in einem Artikel die Koordinaten Vorlage komplett ohne Zeilenumbruch in einer Zeile zu schreiben hat), waere so eine Angabe mittels Koor auch wesentlich uebersichtlicher, da um einiges weniger Text dastehen wuerde, was dem Editor zugute kommen wuerde. --LugPaj 18:33, 24. Jul 2006 (CEST)

Ist so schon mal nicht zu gebrauchen, da sie zwingend Grad, Minute und Sekunde voraussetzt und keinerlei Platz für type, region oder scale lässt. Beachte bitte auch die lang geführten Diskussionen um eine Reform der Koordinate weiter oben. --BLueFiSH ✉ (Klick mich!) 19:19, 24. Jul 2006 (CEST)
Das Muss zu Grad, Minute, Sekunde sehe ich weniger als Problem an (unbekannte Werte kann man ja nullen); allerdings fehlen definitiv die Metadaten wie type und region. -- fragwürdig ?! 19:37, 24. Jul 2006 (CEST)
Das sehe ich anders. Zum einem gibt es sehr wohl Platz fuer type, region und scale (Parameter 9). Hier[11] kann man auch eine Beispiel sehen, wie in der englischen Wikipedia dies benutzt wird. Wegen den Sekunden, finde ich das nicht wirklich schlimm. Man kann sie immer mit 00 auffuellen. In dieser Art haette man auch immer ein einheitliches Bild von Stunden/Minuten/Sekunden. Man koennte es aber auch abaendern und die Sekunden optional machen, in dem man checkt, ob ein 8. Parameter uebermittelt wurde. (Wenn >= Parameter, dann mit Sekundenangabe, ansonsten ohne), was ich allerdings nicht als schoen empfinden wuerde. Die obige Diskussion habe ich durchgelesen, allerdings kam finde ich nichts fuer mich brauchbares raus, da ich nach einem minimalistischen Ansatz suche, den man komplett auch in eine zeile schreiben kann (zB innerhalb von Vorlagen Parametern) und sich immer noch uerbersichtlich editieren laesst. --LugPaj 19:44, 24. Jul 2006 (CEST)
Hallo LugPaj, generell möchten wir hier eher keine neuen Vorlagen einführen. Da dann ähnlich wie im englischen demnächst hunderte andere sich dazu gesellen. Eine Datenbankabfrage ist dann fast nicht mehr machbar. Wenn ich das richtig sehe, dann brauchst du es für die Infoboxen der Flughäfen. Könntest du dich mit der polnischen Variante anfreunden? (Vorlage:Infobox (Polen) Bsp. Warschau.) Das wird aus meiner Sicht die Zukunft für die Infoboxen sein. Grund: Mit der Aufdrösellung der Angaben kann man leicht weitere Dienste einbauen (z.B. Karte etc). Und es müssen keine Angaben doppelt eingetragen werden. Wichtig wäre halt, dass wir für alle Infoboxen einen Standard finden. Und die polnische Variante ist bisher das Beste. Wenn alle die selben Schlüsselwörter benutzen, dann kann man auch automatisch neue Infoboxen finden, die Geokoordinaten beinhalten. -- sk 19:59, 24. Jul 2006 (CEST)

Hallo sk, im Prinzip kann ich mich damit anfreunden. Allerdings kann man bei der polnischen Vorlage keine Region angeben. Der Type airport waere eh vorgegeben. Die _ gefallen mir nicht wirklich, konsistent ist das in dieser Vorlage leider eh nicht (wenn ich mir die Felder KreisfreieStadt und Koordinate_Breite) anschaue. Ein Leerzeichen wuerde mir da besser gefallen. Aber egal, solange es ein "standard" waere. --LugPaj 21:23, 24. Jul 2006 (CEST)
Die Region wird automatisch gebildet aus dem fest vorgegebenen „PL-“ und der Variable für den ISO 3166-2:PL-Code. --Raymond Disk. 21:39, 24. Jul 2006 (CEST)
Das mit PL- hab ich vor ein paar Minuten schon bei als hier angeregt. Die sollen das bitte umstellen. -- sk 22:19, 24. Jul 2006 (CEST)
Ah, ok, habe das nun mit der Region verstanden..:). Ich wuerde in der Flughafen inbox dann dasselbe Schema wie in der Vorlage:Infobox (Polen) benutzen, oder gibt es Einsprueche dagegen? Die Vorlage:Koor dms wuerde ich dann loeschen lassen. --LugPaj 22:50, 24. Jul 2006 (CEST)

Das wäre das beste. Ich würde dann beim nächsten Dump das mit rausfiltern. -- sk 10:05, 26. Jul 2006 (CEST)
Hmmm Ich würde auch nur ungerne eine weitere Variante einführen wollen. Zudem finde ich es verwirrend, wenn man die Sekunden „Nullen“ müßte. 0 hat für eine andere Bedeutung als gar keine Angabe der Sekunden. --Raymond Disk. 21:08, 24. Jul 2006 (CEST)
Eine Zusammenführung der verschiedenen Vorlagen zu einer einzigen (redundanzfreien) Vorlage fände ich besser, als noch mehr Vorlagen einzuführen.


Aber zu den Argumenten:


Es wäre kein Problem, die Vorlage Koor dms um zwei Felder region und type zu erweitern. Ausserdem könnte man anhand es Types für Ortschaften die Anzeige der Sekunden vielleicht auch unterdrücken. -- Simplicius - ☺ 09:09, 25. Jul 2006 (CEST)

Bin auch gegen neue Vorlagen, aber ich finde, es ist Zeit, mal die Frage der Doppeleingabe der Werte anzugehen. Es ist wesentlich eleganter und weniger fehleranfällig, nur einmal den Wert für Grad, Minuten und Sekunden einzugeben bzw. später abzuändern, anstatt zweimal, wie es derzeit erforderlich ist. Auch eine Vereinheitlichung der Vorlage mit derjenigen der englischen Wikipedia bzw. Wikimedia Commons wäre auch wünschenswert zwecks Synergieeffekten / leichterer Mitarbeit in anderen Projekten. Longbow4u 13:10, 25. Jul 2006 (CEST)
Zwei Type-Angaben
Die Artikel Nantucket, Fehmarn, Langeoog, Cudjoe Key, Juist, Tavernier, Key West, Big Coppitt Key, Poel, Duck Key, Borkum, Pellworm, Langeneß und Hooge haben alle zwei type-Angaben isle und city. Was können wir da machen? Eigentlich sollte jede Kooridnatenangabe nur einen Type haben? Irgendwelche Ideen? -- sk 20:44, 24. Jul 2006 (CEST)

Es wäre günstig wenn solche Koordinaten in der Ausgabe also quasi Google Earth gedoppelt werden könnten. Also einmal als Insel und einmal als City angezeigt werden. Wenn du das per Abfrage rausfiltern könntest, wär das super. Schade wärs, wenn eine der beiden untergehen würde. Bezüglich der Region-Angabe hab ich auch schon mal "region:DE-BE/BR" als Angabe gesehen, ich glaub, dass hast sogar du so eingetragen. Gruß --BLueFiSH ✉ (Klick mich!) 22:44, 24. Jul 2006 (CEST)
Bei den Regionen bitte immer kompletter ISO-Code also ncith "region:DE-BE/BR" sondern "region:DE-BE/DE-BR". Aber bei den Inseln und Städten bin ich mir nicht so sicher, das würde ich lieber trennen. Doppelungen mache ich bisher nicht, weil bei der gleichen Koordinate in Google Earth dann nur ein was angeklickt werden kann. -- sk 18:26, 25. Jul 2006 (CEST)
Na gut, dann wars halt "region:DE-BE/DE-BR" was ich gesehen hatte =) Wegen Google Earth gehts mir ja nur darum, dass man Langeoog auch noch sieht, wenn man die Städte nicht eingeblendet hat, nämlich als Insel, oder halt andersrum. Welcher der beiden gedoppelten Punkte nun konkret aufgerufen wird, ist ja egal, der Artikel ist ja in beiden Fällen der gleiche. Lässt sich das nicht irgendwie realisieren? Mehrfache Koordinaten in einem Artikel wertest du ja meines Wissen nach auch nicht aus, die sind nur verlinkte Optik und zum Kvaleberg-Anklicken. --BLueFiSH ✉ (Klick mich!) 19:01, 25. Jul 2006 (CEST)
Hilfe benötigt
Hab gerade mal diese Fehlerliste angelegt, da ich keine Zeit habe die alle alleine zu koorigieren. Bitte helft alle mit. Besten Dank! -- sk 22:17, 24. Jul 2006 (CEST)

Angaben zu 60" sind ein Umrechnungsfehler der Kvaleberg-Soft, die können universell auf 00" gesetzt werden. Wohlgemerkt 3'60 = 3'00 ergibt ernstlich den gleichen Dezimalwert. Ich hab auch schon einige Male abgenommene Dezimalwerte per Kvaleberg umrechnen lassen, und habe ein x'60" zurückbekommen. Prüf mal die Liste auf diesen Standardfehler, ich schätze mal, die dürfte arg eingedampft sein danach. GuidoD 23:23, 24. Jul 2006 (CEST)
ich glaube, dieses Tool macht wohl auch diesen Fehler --Atamari 23:35, 24. Jul 2006 (CEST)
Bei 60" hab ich immer die Minuten um 1 erhöht. War das jetzt falsch? --BLueFiSH ✉ (Klick mich!) 06:30, 25. Jul 2006 (CEST)

Das kann man so pauschal nicht sagen. Nimm Fehlerbild Burg Neurandsberg bei Koordinaten fehlen! Hilf mit.unbenannte Parameter 1:49_04_60_N_12_45_00_E_type:landmark_region:DE-BY, 2:49° 4' 60" N, 12° 45' 0" O . Kvaleberg wird nicht 4'60" sondern 5'60" einblenden, womit Rundung 4'60" zu 5'00 korrekt wäre. Wenn der Nutzer allerdings eine dezimale Koordinate bei Kvaleberg eingegeben hatte, um sie sich in Landkoordinaten umrechnen zu lassen, dann hat man kräftig aufgerundet. Im übrigen, der Kvaleberg-Server x'60"-Werte ganz allgemein, bei x'61" kommt aber doch ein "out of range" Fehler. Stefans Fehlerliste ist nur allzuoft laut Kvaleberg gar keiner. GuidoD 09:30, 25. Jul 2006 (CEST)
Atamari hat Recht, das Koord-ermittlungs-Tool macht auch diesen Fehler. Ist mir gestern abend noch aufgefallen beim Nachprüfen aller Koordinaten. Ist natürlich mehr Arbeit, aber es lohnt sich die Koordinaten grundsätzlich mal zu prüfen. --Raymond Disk. 07:45, 25. Jul 2006 (CEST)
Ich würde ja gerne helfen und habe mich mal an Heringen (Werra) und an Brachttal versucht. Was da allerdings falsch gewesen sein soll, ebenso wie in Hochheim am Main, erschließt sich mir nicht. --ST ○ 09:24, 25. Jul 2006 (CEST)
Bei Brachttal war jemand schneller. Bei Heringen (Werra) hast du es doch richtig korrigiert. Löscht bitte die korrigierten Artikel in der Liste. -- sk 18:23, 25. Jul 2006 (CEST)

Ich habe sie durchgestrichen. Ach so, jetzt hab ich's geschnallt. Ich backe mir die Werte immer mit Google-Earth. Das scheint zu funktionieren. --ST ○ 18:54, 25. Jul 2006 (CEST)
Probleme durch ref?!
stört ein  <ref> </ref>  bei der auswertung der "polenbox" bsp.: hier?! ...Sicherlich  Post  21:02, 25. Jul 2006 (CEST)

erledigt; ist ja im datumsfeld also euch Sicherlich wurst egal ;) ...Sicherlich  Post  21:02, 25. Jul 2006 (CEST)
Vorlage:Infobox Flughafen
Hallo, ich hatte weiter oben schon angefangen zu diskutieren. Ich wollte dann folgende Felder in der Vorlage:Infobox Flughafen einfuegen. Eigtl habe ich das Beispiel von weiter oben hier uebernommen, aber Vorlage:Infobox_(Polen) ist fast (bis auf den type) identisch. Den type braeuchte man eigtl nicht, da es nur um airports geht und man das fest in die Vorlage einbauen sollte. Bei der Polen Infobox steht anstatt Koordinate_Type=city type=city. Nun ist meine Frage, ob ich nun Koordinate_Type oder type (was ich nicht schoen finde...) verwenden soll, bzw ob der type wirklich wichtig ist, oder ob man den als Feld nicht weglassen koennte.

|Koordinate_Breite = N/S
|Koordinate_Breitengrad = 44
|Koordinate_Breitenminute = 44 
|Koordinate_Breitensekunde = 44
|Koordinate_Länge = O/W 
|Koordinate_Längengrad = 12
|Koordinate_Längenminute = 33
|Koordinate_Längensekunde = 33
|Koordinate_Type = airport 
|ISO 3166-2=DE-BY,AT-9  

--LugPaj 23:38, 25. Jul 2006 (CEST)

Den „type“ würde ich hier weglassen und direkt in der Vorlage fest vorgeben. Statt „ISO 3166-2“ würde ich die Variable „Koordinate_Region“ nennen. Ansonsten schaut es doch gut aus :) --Raymond Disk. 00:18, 26. Jul 2006 (CEST)

Ich denke es geht darum, dass man aus den Vorlagen Parametern auch alle wichtigen Informationen rausparsen kann, in dem man immer dieselben Parameter bei verschiedenen Vorlagen benutzt. Deshalb dachte ich, dass der type auch reinmuss, auch wenn er eigtl fest vorgegeben ist.--LugPaj 08:23, 26. Jul 2006 (CEST)

Hmm gutes Argument. Ich denke, da können die Profiparser unter uns (u.a. sk) mehr zu sagen. Da halt ich mich dann lieber mal bedeckt ;-) --Raymond Disk. 08:37, 26. Jul 2006 (CEST)


Dezimalangaben müssen (wegen Kvaleberg) mit Punkt geschrieben werden --BLueFiSH ✉ (Klick mich!) 06:20, 26. Jul 2006 (CEST)
Bitte mit rein Type mit reinschreiben. So muss man beim Parsen sich nur den Artikel anschauen um zu wissen, das es sich um einen Flugplatz handelt. Wenn das erst in der Vorlage steht muss man jedesmal noch die entsprechende Vorlage einlesen. Also lieber die Type-Angabe mit eintragen. -- sk 10:07, 26. Jul 2006 (CEST)

@sk, waere es nicht besser, dann Koordinate_Type und Koordinate_Region (wie von Raymond angeregt) anstatt type und ISO 3166-2 zu bentutzen? Somit waeren diese Parameter besser als Block zu erkennen.--LugPaj 10:55, 26. Jul 2006 (CEST)


Habe gerade erst den Abschnitt Zur Info hier in dieser Diskussion gelesen. Dort wurde "KoordinateTyp" vorgeschlagen, (welche immerhin kein deutsch-englischer Mischmasch ist) allerdings denke ich, wenn dann sollte man das mit Unterstrich schreiben.  --LugPaj 17:54, 26. Jul 2006 (CEST)
Damit kann ich auch leben. Dieser Standard entwickelt sich ja noch, aber der Weg ist der richtige. Dann müssen wir halt noch mal per Bot durch die Polnischen Orte turnen. Das haben die demnächst so oder so vor, da kann man das gleich mit einfädeln. -- sk 21:18, 26. Jul 2006 (CEST)
"|type=city" -->  "Koordinate_Typ=city" und "|ISO 3166-2=MZ" -->  "Koordinate_Region=PL-MZ" hab ich mal bei Wikipedia_Diskussion:Formatvorlage_Stadt/Polen#Bei_einem_Botlauf_zu_.C3.A4ndern hier vorgeschlagen. "_Typ" damit alles deutsch ist. -- sk 21:23, 26. Jul 2006 (CEST)

Danke, dann besteht von meiner Seite jedenfalls nun Klarheit.--LugPaj 21:58, 26. Jul 2006 (CEST)

Sollte die Region nicht besser in zwei Teilen, also das Land und das Bundesland getrennt in zwei Feldern notiert werden???--Tobi 00:15, 27. Jul 2006 (CEST)

Dann wollen die Leute das gleich wieder wegrationalisieren, weil es z.B. in polnischen Städten nie ändert. Aber ein weiteres Problem sind Grenzfälle. Also z.B. Berge die genau auf der Grenze liegen z.B. "DE-BY/AT-7" wäre bei einer Aufteilung problematisch einzubinden. Ich würde die Region so zusammen lassen. -- sk 08:34, 27. Jul 2006 (CEST)
Artikel ohne Koordinaten
Da ich so begeistert bin, von eurer Unterstützung bei der Abarbeitung der Fehlerliste, hab ich mal folgende Listen erstellt.

Die Listen beinhalten Artikel ohne Koordinaten, die einen Kategorie besitzen, welche auf einen Raumbezug schließen lassen. Für Hinweise und Kommentare bin ich dankbar. Viel Spaß beim abarbeiten. Beim nächsten Dump werden die Listen dann mit erneuert. -- sk 12:00, 30. Jul 2006 (CEST)

Bei dem Umfang wird doch schon mal eins deutlich: es geht um eine Fülle von Ortschaften weltweit, die in irgendeinem anderen Wiki demnächst auch mal verortet werden. Eine zentrale Datenbank, und von hier aus der Verweis/Verlinkung auf den Eintrag per Kennung statt per Koordinanten wäre sinnvoller. 

Die kml-Datei könnte dann Verweise erhalten, welche Wikis dazu schon einen Artikel anbieten. Klingt technisch ein bisschen kompliziert. Ist es auch. Aber sinnvoller. -- Simplicius - ☺ 13:04, 30. Jul 2006 (CEST)

Aehnlich wie bei den Bildern mit wikipedia commons, sollte es Koordinaten geben, wie man per identifier einbindet, anstatt mit Gradangaben, finde ich. Aber so etwas wuerde ich mir auch fuer Zahlen jediglicher Art Wuenschen. Wozu muss man zB die Einwohnerzahlen von Muenchen in allen Sprachen in allen Artikeln reinschreiben? Eine Datenbank, die einmal die Zahl beinhaltet und dann ein Modul, was verschiedene Outputs fuer verschiedene Sprachen anbietet, waere echt super.--LugPaj 15:58, 30. Jul 2006 (CEST)

Noch ein anderer gedanke. Waere es nicht sinnvoll einen Bot zu schreiben, der Koordinaten, die in einer anderen Sprache schon angegeben sind, automatisch zu uebernehmen? --LugPaj 16:00, 30. Jul 2006 (CEST)

Der Gedanke mit dem Bot erscheint mir wesentlich besser (da realistischer und resourcenschonender) als die ID-Lösung. Da es in der engl. WP jedoch Unmengen an Vorlagen gibt, bräuchten wir für einen Extrakt wohl einen Programmierer der den Dump parsen kann. Kolossos 09:20, 1. Aug 2006 (CEST)
Aktuell würde ich von einem Bot jedoch abraten. Dazu sind mir viele Koordinaten zu ungenau. Weniger bei einzelnen Gebäuden, aber  bei größeren Objekten hat man in 100 Wikis 100 verschiedene Koordinaten. Jeder legt seinen Stadt/Gemeinde/Provinz/Land/Gewässer-Mittelpunkt halt etwas anders. Irgendwann (tm) kommt mal ein Daten-Wiki ähnlich wie Commons, ich denke, darauf sollten wir warten. --Raymond Disk. 10:14, 1. Aug 2006 (CEST)
Wenn dieses Datenwiki (!?) denn mal da sein sollte (-: Wie sollen die Daten dann genauer werden? Oder liefert das Datenwiki dann die Daten und all die Arbeit hier war umsonst? Arcy 11:28, 1. Aug 2006 (CEST)
Die Daten für so eine gemeinschaftliche Datenbank sollten im ersten Schritt aus den bestehenden Datensätzen erzeugt werden und dann schrittweise verbessert werden. Derzeit fände ich einen Kontrolle gut, die z.B. in EN und DE sich die Koordinatendifferenzen anschaut. Wenn die beiden Koordinaten mehr als 1000 Meter auseinanderliegen, ist da ein Fehler drin. Ich muss mal schauen, ob ich sowas demnächst mal bastel. -- sk 11:43, 1. Aug 2006 (CEST)
Ganz grob stelle ich mir das so vor, dass in so einem Datenwiki die Koordinaten aller Wikis von z.B. Berlin zusammengetragen werden und sich dann geeinigt wird auf eine Koordinate für diese Stadt. Wie man dann rückverlinkt, über eine ID, Artikelnamen wie in Commons usw... keine Ahnung... aber die Idee finde ich spannend. Insgesamt wäre es sowieso gut, wenn sich im Bereich Metadaten vorher noch was bewegen würde, so dass man z.B. alle Metadaten auf eine Extraseite pro Artikel ablegen könnte.


@sk: Deine Idee der Koordinatenprüfung gefällt mir auch. Beim Arbeiten der Fehlerliste sind mir nämlich schon viele grobe Schnitzer aufgefallen... --Raymond Disk. 13:15, 1. Aug 2006 (CEST)
Ich habe mal aus sk seinen Auszügen, die Orte rausgesucht die zwar in der englischen WP eine Georef. haben in deutschen jedoch nicht im Extrakt stehen. Siehe Artikel_ohne_Koordinate/da_in_engl_WP. Die Koordinaten sollten also in der engl. WP zu finden sein. Oftmals sind es leider auch einfach Vorlagen welche beim extraieren nicht erkannt wurde. Wenn gewünscht könnte ich mit etwas Aufwand auch noch Geotags dazu generien, jedoch ohne region und ohne Typ. Kolossos 20:50, 3. Aug 2006 (CEST)
Hab jetzt mal genauer, danach erscheint mir die Liste durchaus Treffer-reich. Somit überlege ich nun eine Google Earth-Layer zu entwickeln der die Artikel anzeigt und die Geotags gleich mitliefert. 
Die Vorlagen welche nicht erkennt werden sind scheinbar:

ein Beispielartikel steht immer dahinter. Kolossos 20:40, 5. Aug 2006 (CEST)

So ich hab jetzt alle Abweichungen ermittelt. Wikipedia:WikiProjekt_Georeferenzierung/Fehlerliste#Koordinatenabweichung. Wenn man DE und EN Koordinaten zusammenwirft, hat man ca 80000 Koordinaten. Davon waren nur 800 weiter als 2000 m voneinander entfernt.  @Kolossos, die nicht erfassten Vorlagen (z.B. Infobox der franzözischen Städte) werde ich beim nächsten Mal mit reinnehmen. Schreibt mir einfach die Vorlagen, die ich noch mit rausfiltern soll. -- sk 21:04, 3. Aug 2006 (CEST)
So auf Artikel_ohne_Koordinate/da_in_engl_WP gibt es jetzt auch Geotags zum reinkopieren. Ihr könnt euch also austoben, denn einfacher wird es wohl kaum noch, da die Ausgangsdaten kaum die für einen Bot nötige Qualität besitzen. Kolossos 19:47, 9. Aug 2006 (CEST)
_region:XX_ und Sprach(aus)wahl
Mein Versuch für eine Georeferenzierung einer Lokation in Paris (Frankreich) unter "region" das (korrekte) ISO-Kürzel (+Département) "FR-75" einzugeben führte zu dem (unerwünschten) Ergebnis, dass die referenzierte "Abfrageseite" in Französich kam.
Wie kann ich erreichen, dass trotz Wiki-gerechter Notation die Abfrage in Deutsch bleibt? Etwa: _region:DE/FR_ ??? --
hd 14:14, 31. Jul 2006 (CEST)

Gar nicht, das soll so. --BLueFiSH ✉ (Klick mich!) 14:26, 31. Jul 2006 (CEST)
AFAIK überhaupt nicht, da die Ausgabeseite kvaleberg.com nur eine Übergangslösung darstellt und keine Sprachauswahl kennt. „Zum Ausgleich“ erhält jeder, der einen deutschen Ort auswählt, eine deutschsprachige Seite präsentiert ;-) Sobald das Feature direkt in die Wikipedia integriert ist (Wann? Keine Ahnung!) wird auch die Sprachpräferenz berücksichtigt. Die von dir vorgeschlagene Lösung führt jedoch in die Irre, da dann keine Selektion der reinen Koordinaten nach Ländern mehr möglich wird. --Raymond Disk. 14:30, 31. Jul 2006 (CEST)
Das ist ein Fehler der Ausgabeseite. Die nutzt diese Region-Angabe um sich für eine Sprache zu entscheiden. Also bei Koordinaten in Deutschland kommt immer die Seite mit deutschen Quellen in deutscher Sprache. Bei einer Koordinate in Frankreich kommt immer die Seite mit den französischen Kartenquellen und leider auch in Franzzösisch. -- sk 14:32, 31. Jul 2006 (CEST)
Die Kvaleberg-Seiten sind ein Wiki. Wir könnte die deutschen und franz. Seiten also auch ins Englische übersetzen. Wäre das eine Lösung? Kolossos 09:22, 1. Aug 2006 (CEST)
Grundsätzlich ja, da hätte man alle (?) Seiten einheitlich auf Englisch. Wobei ich gestern Schwierigkeiten hatte, auf die Edit-Seite zu kommen. Kamen ziemlich komische Fehlermeldungen. --Raymond Disk. 10:10, 1. Aug 2006 (CEST)
Wißt ihr was da falsch läuft?
Wenn ich in Google-Earth in Wien auf das Icon mit Bundeskanzleramt (Österreich) klicke, öffnet sich bei mir ein neues Firefox-Fenster mit zwei Tabs: [12] und [13]. Wißt ihr was da falsch läuft? lg Gugganij 02:48, 8. Aug 2006 (CEST)

Noch was, etwas ähnliches passiert, wenn ich auf das Icon Österreichische Nationalbibliothek klicke. Eigenartig. Gugganij 02:51, 8. Aug 2006 (CEST)

Mit welchem Zusatz arbeitest du? Mit der großen Datei von sk oder der Datenbanklösung von Kolossos (mir)? Kolossos 09:20, 8. Aug 2006 (CEST)

Grüß dich, ich habe mir die kmz-Datei von dieser Seite heruntergeladen. Gugganij 16:56, 8. Aug 2006 (CEST)
Dafür bin ich wohl zuständig. Manchmal scheint die UTF8-Konvertierung in GE zu streiken, die Datenbankeinträge scheinen erstmal richtig zu sein, da es mit Umgebungssuche funktioniert. GE hab ich auch kurz getestet, bei mir gings. An Blogspot hab ich keine Anteile, da könnte es sich um einen IE Popup-Schädling auf deinem Rechner handeln. Kolossos 22:23, 8. Aug 2006 (CEST)
Danke für die Fehlerrecherche. Dass mit dem IE Popup-Schädling kann's nicht sein, da ich nur Firefox verwende. Dass Problem taucht zwar noch immer auf, aber so wichtig isses auch wieder nicht.   Danke dir. lg Gugganij 00:33, 9. Aug 2006 (CEST)
Bei mir ist das auch schon mehrmals passiert. Ich glaube das hängt mit den Artikeln zusammen, deren Wörter aus mehreren Bestandteilen besteht. Dann wird von GE nur der erste interpretiert und der zweite irgendwie verschluckt. Konnte den Fehler auch noch nicht reproduzierbar wiederfinden. -- sk 10:03, 9. Aug 2006 (CEST)
Neue KML
So die neue KML ist da. Folgende Neuerungen: generell werden jetzt bevorzugt die Koordinaten aus den Infoboxen genutzt, Infobox französische Gemeinden und Infobox italienischer Gemeinden werden mit eingelesen. Alle Ortschaften werden jetzt nach Einwohnerzahl unterschiedlich dargestellt. Die Fehlerlisten und Atikel ohne Koordinaten werde ich gleich mal erneuern. Einige Infoboxen (z.B. Infobox Ort der Färöer) wurden wegen mangelnder Nutzung nicht eingebunden. -- sk 16:57, 10. Aug 2006 (CEST)

ISO-Code bei Italien und Frankreich
Bei Italien (ISO 3166-2:IT) und bei Frankreich (ISO 3166-2:FR) gibt es ISO-Codes für die 1. und 2. Ebene der administrative Einheiten also Regionen/Provinzen bzw. Regionen/Départements. In den Ortsartikeln von italienischen und französzischen Gemeinden werden aber beide genutzt. Meiner Meinung nach sollten wir das einheitlich für alle machen, also wie in Deutschland, Österreich oder anderswo, nur die oberste administrative Einheit nutzen. Was meint ihr dazu? -- sk 16:23, 11. Aug 2006 (CEST)

Recht hast Du. Es sollte auf jeden Fall einheitlich sein um ein allgemein auszuwertendes "Bild" zu schaffen. Nur bin ich mir nicht sicher, ob es wirklich die oberste Ebene sein soll. Wenn wir die kleineren Einheiten nutzen (trotz der Mehrarbeit) gibt es die Möglichkeit das ganze spezifischer auszuwerten und zugänglich zu machen. -- Monsterxxl <°))))> 16:57, 11. Aug 2006 (CEST)








Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:WikiProjekt_Georeferenzierung&oldid=20064934“