Wikipedia Diskussion:WikiProjekt Georeferenzierung

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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. ). 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)

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)

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)

@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.

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).

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)

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)

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)

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)

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)

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)

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)

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)

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)

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:

• Münster (Westfalen) (zeigte irgendwohin aber nicht ins Zentrum von Münster)
• Aasee (Münster)
• Haus Lütkenbeck
• Fernmeldeturm Münster
• Halle Münsterland
• Roggenmarkt (Münster)
• Fürstbischöfliches Schloss Münster
• Zwinger (Münster)
• Servatii-Platz
• St.-Mauritz-Kirche (Münster)
• Haus Rüschhaus
• Erbdrostenhof

Neu hinzugekommen sind:

• Botanischer Garten Münster
• Mühlenhof-Freilichtmuseum Münster
• Preußenstadion
• Wolfgang Borchert Theater
• Stadtmuseum Münster
• Justizvollzugsanstalt Münster
• Flughafen Münster/Osnabrück
• Buddenturm

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)

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.

• Google Earth
• Google Maps

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)

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)

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)

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)

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

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)

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)

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)

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

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 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