Wikipedia Diskussion:WikiProjekt Georeferenzierung/Pfad-Koordinaten

Integration oder separates Wiki

Ich bin aus folgenden Gründen dafür, die Pfaddaten als getrenntes Wiki zu führen. Es sollte international die Punktdaten nutzbar machen, damit fallen lokale Wikipedia-Unterseiten aus. Die Commons haben schon genug damit zu tuen Ordnung in die 1 Mio. Bilder zu bringen, also geht das aus meiner Sicht auch nicht. Also bin ich für ein neues Wiki bei der Foundation zu beantragen (http://meta.wikimedia.org/wiki/New_project) und dieses dann entsprechende Verlinkung, schließlich hat sich der Geohack mit seiner Verlinkung auch bewährt. So wäre auch die Software am besten anpassbar und wenn das Projekt scheitern sollte, was ich nicht hoffe, so wäre das Aufräumen ein leichtes. Kolossos 23:52, 11. Mär. 2007 (CET) P.S.:http://meta.wikimedia.org/wiki/Geo war wenn mich meine Errinerung nicht täuscht schon mal recht eindrucksvoll lauffähig. Man müßte also nicht unbedingt das Rad komplett neu erfinden. Kolossos 23:52, 11. Mär. 2007 (CET)

Hmm. Ich bin weiterhin der Meinung Koordinaten gehören in Dateiform. Denn sie werden i.A. nicht von Menschen, sondern von Maschinen gelesen. Änderungen an einzelnen Punkten von Pfaden sind m.E. auch eher selten. Also Dateien. Da aber in den Dateiformatdefinitionen vermutlich nicht für alle Meta-Informationen Platz vorgesehen ist brauchen wir also Beschreibungen für diese Dateien. Genauso wie das bei Commons gemacht wird. Die können aber m.W. bislang nur Grafiken, Bilder, Videos und Krach-Dateien speichern. Ob "man" nun Commons aufbohrt oder ein neues, ähnliches Datawiki macht, wo neben Koordinaten, Pfaden und Flächen auch andere Daten (Berghöhen, Einwohneranzahlen, Geburts- und Sterbedaten, Wahlergebnisse, Chartsplatzierungen usw. usf.) lagern können, die von allen Wikis refernziert würden, ist erstmal unwichtig. Wenn ich es mir genau überlege, kann man das textlastige Mediawiki dafür ja gar nicht brauchen, ein datenzentriertes Wiki bräuchte man dafür. Hmm. Das wurde m.E. ja alles schon mehrfach diskutiert, aber es gibt da wohl erhebliche Schwierigkeiten.
OK. Vorschlag: Geokordinaten in SVG-Dateien speichern, die in Commons oder auch in de-Wikipedia lagern. SVGs kann Mediawiki ja schon jetzt abspeichern. Diese SVGs werden per Vorlage in die Wikipedias eingebunden. Damit es nicht zu kompliziert wird, kann man ein Hilfsscript machen, das aus populären Geo-Formaten (KM*, ...) solche SVGs macht. --Walter Koch 11:29, 6. Apr. 2007 (CEST)

Polyline statt Pfad, Codierung, OpenStreetMap?

Folgendes:

• Generell: Ich bewundere euren Tatendrang und ich hoffe, es kommt etwas Nützliches heraus. Dabei kann ich es nicht lassen, daran zu erinnern, dass es immer noch einiges zu verorten gibt an 'Orten von Interesse'...
• Zum Titel der Unterseite (Pfad...): 'Pfad' ist ein Begriff aus der Computergraphik. Was wir hier aber wahrscheinlich erfassen wollen, sind raumbezogene, linienhafte Geometrien und die sind in der deutsch- (und englisch-)sprachigen GIS-Welt bekannt unter dem Namen 'Linienzug', 'Polylinie' machnmal (zu) einfach 'Linie'. => Ich schlage 'Polylinie' vor.
• Was ist eine gültige Polylinie? Zur Definition von Polylinien braucht es mehr als nur zu sagen, es sei eine Liste von Koordinaten! 2D und/oder 3D? überschneiden? etc. Es macht keinen Sinn, nur wenige dutzend Stützpunkte zuzulassen: Polylinien sollen sehr gross werden können.
• Zur Codierung (Format): Schon die Einigung hier zur Codierung einer Punktkoordinate war schwer genug (und ist immer noch nicht optimal). Zum Glück gibt es Organisationen und Leute, die sich schon seit 15 Jahren damit herumschlagen! Ich denke da v.a. an das Open Geospatial Consortium und an ISO 19100.

"Das Rad nicht neu erfinden" ist ein gutes Stichwort oben. Daher folgender Vorschlag:

• Externe Datenbank: scheint mir die beste Lösung zu sein. Weitere Argumente dafür: Es könnte eine auf Geo-Typen optimierte Datenbank sein. ISBN und PubMed-ID etc. haben's auch so gemacht (siehe Hilfe:Datenbanklinks).
• Als Codierung denke ich (auch) an etablierte Geo-Formate:
  • KML-Fragmente sind nur ein Behelf, da dies ein grafikorientiertes Format ist, das speziell für Google Earth entwickelt wurde.
  • GML wäre prädestiniert, ist aber etwas komplex. Zudem ist die Frage, ob Version 2.x oder 3.x.
  • Wenn schon SVG, dann unbedingt die von der offiziellen Spezifikation empfohlene Angabe des Koordinatenreferenzsystems (CRS) WGS84, bzw. EPSG 4326: Siehe SVG-Spec..
  • GeoRSS Simple, wäre eine interessante pragmatische Alternative! siehe hier.
• Zur Erfassung/Kontrolle: Mit was sollen diese Linien erfasst und v.a. kontrolliert werden? Hier evtl. zuerst mal openstreetmap.de näher anschauen. Die haben sich bereits mit alledem herumgeschlagen.
• Zur Darstellung: über OpenLayers?

Hat jemand Kontakte zur englischsprachigen Community? Ein Zusammentun mit der Openstreetmap.org wäre m.E. prüfenswert! Geonick 09:46, 13. Mär. 2007 (CET)

Man sollte auch durch automatisierte Übernahme von offiziellen, freien Quellen erstmal eine Grundlage schaffen. So wäre es gut, wenn zumindest die Ländergrenzen vohanden wären, damit die selbsterstellten Linien nicht ganz im luftlerren Raum schwirren. Kolossos 10:12, 13. Mär. 2007 (CET)

OpenStreetMap

Hab mal mit einem von OSM gesprochen. Ich würde gerne Openlayer für die Punktdaten der Wikipedia unterstützen, dieses könnten dann auch in OSM eingeblendet werden. So könnte ein Zusammenarbeit sinnvoll sein, jeder könnte sich auf seine Stärken konzentrieren und man würde nicht die verfügbaren Kräfte spalten. Kennt sich jemand mit Openlayers aus? Mein Kenntnissstand: da die Punkte anklickbar sein sollen, wird es sich um Marker handeln (nur auf Kacheln malen, nützt nix), aufgrund unserer großer Datenmengen sollten diese allerdings aus der Datenbank je nach Betrachterpunkt gezogen werden. Einen großen Mapserver oder dergleichen will ich aber nicht aufsetzen, sondern würde ein kleines PHP-Skript bevorzugen. Eine Verlinkung oder Einbindung von OSM in die WP wäre natürlich auch vorstellbar. Ideen? --Kolossos 17:34, 22. Mär. 2007 (CET) Etwas finanzielle Unterstützung für bessere Hardware von OSM wäre auch nicht schlecht. Ideen?

Meinst du sowas wie die openstreetmap:Slippy Map MediaWiki Extension? — Raymond ^{Disk. Bew.} 10:03, 20. Mai 2008 (CEST)

Openstreetmap nutzen

Wir können auch speziell getaggte OSM-Objekte selektieren und damit nutzen:

• http://www.informationfreeway.org/api/0.5/*%5Bname=Elberadweg%5D

gibt beispielsweise die Node-Koordinaten und die sich ergebenden Pfadkoordinaten für den Elberadweg aus [1]. Daraus könnte man im ersten Schritt über einen XSLT-Prozess eine KML generieren und z.B. in GoogleMaps anzeigen. Siehe auch [2]. Später finden sich dann sicherlich auch andere (freie, performante) Lösung. Wir müssten von der Wikipedia also nur auf ein Skript verweisen und einen bestimmten key und einen value übergeben. Somit würden wir die Kräfte nicht teilen. Die Art des tagging ist bei OSM äußerst frei, man könnte also (wenn nötig) wohl auch Wikipedia-keys einführen. Wir würden von dem ganzen vorhandenen Skripten und Daten profitieren (GPS-Upload, 60 GB Daten, ...). 3 verschiedene Editoren stehen zur Auswahl, und gerade der Potlatch-Editor ist nicht schwer in der Bedienung, einfach mal testen und oberhalb der OSM-Karte auf Edit gehen. OSM könnte durch die Bündelung auch profitieren, da die Daten nochmal geprüft würden und sich sowohl der Nutzerkreis also auch der Editorenkris vergrößert würde. --Kolossos-OSM:Kolossos 12:12, 10. Mai 2008 (CEST)

Die XSL unter http://wiki.openstreetmap.org/index.php/Converting_OSM_to_GML#Version_0.2 kann uns vielleicht auch weiterhelfen, die Datei ist jedenfalls recht übersichtlich. --Kolossos 15:47, 19. Mai 2008 (CEST)

Ja. BINGO das war es wohl.Das folgende Toolserverkommando erzeugt eine KML:

xsltproc osm2kml.xsl data-Elberadweg.osm > Elberadweg.kml

Dabei ist die osm2kml.xsl sicher noch verbesserbar. Das Ergebniss ist die Elberadweg.kml die man sich auch in Google Maps anschauen kann. --Kolossos 22:57, 19. Mai 2008 (CEST)

Und in ein Script gewickelt siehts dann so aus: http://tools.wikimedia.de/~dschwen/osm/index.php?name=Elberadweg

:-) --Dschwen 23:28, 19. Mai 2008 (CEST)

Oder eben auch http://tools.wikimedia.de/~dschwen/osm/index.php?name=Weser http://tools.wikimedia.de/~dschwen/osm/index.php?name=Spessart http://tools.wikimedia.de/~dschwen/osm/index.php?name=Borkum , und was einem noch so einfallen kann. Leider zentriert das KML auf google maps noch nicht ordentlich. --Dschwen 23:59, 19. Mai 2008 (CEST)

Wow, du hast 31 min gebraucht ;-). Ein paar Anmerkungen:

• Wir sollten uns die Flexibilität der API beibehalten. So wäre das konkrete Tagging am Beispiel Eberadweg nicht über den "name" sondern über "ncn_ref=Elberadweg""ncn_ref=R2" "ncn_ref=Elberadweg", da der Weg ja auch über Straßen mit einem anderen Namen verlaufen kann. Vielleicht sollten alle Parameter stur an die API weitergereicht werden. Andererseits wollen wir vielleicht auch eigene Parameter wie Pfadfarbe und Icons übergeben. Auch sollten wir vorgeben, ob Pfade, POIs oder beide zurückgegeben werden soll. So würde ich z.B. bei Bahnstrecken die Bahnhöfe/Haltestellen gerne mit haben.
  • Done. Geh mal auf http://tools.wikimedia.de/~dschwen/osm/index.php da kannst Du einen query wie in OSMXAPI API beschrieben eingeben, das wird jetzt einfach durchgeschleift (ich hoffe da habe ich nicht irgendwelche fetten Sicherheitsluecken uebersehen. am besten filtere ich noch Zeichen wie das @ raus...). Leider ist der toolserver gerade grottenlangsam, so das selbst fuer die statischen KML files manchmal ein timeout von google maps kommt. --Dschwen 17:34, 20. Mai 2008 (CEST)
• Gibt es einen Schutz, dass nicht das komplette planet.osm file also die ganze Erde angefordert wird? Oder schützt uns da nur das timeout? Und was passiert auf dem API-Server in einem solchen Fall?
  • Schutz ist die maximale PHP Variablengroesse von 16Mb --Dschwen 15:29, 20. Mai 2008 (CEST)
    • Ich dachte du startest über PHP ein paar Konsolenbefehle (wget, xsltproc...), dann würde die Größe der Aktion dem PHP erstmal egal sein. Anfragen ohne Filterparameter kannst du aber auf jeden Fall blocken. Kann man irgendwo deinen Quelltext sehen? Vielleicht verstehe ich ihn ja. Ich verwende dazu immer eine *-source.php, damit ist das immer aktuell, wenn du willst, kann ich dir die geben. Achso ich habe die Dresdner-OSM Leute, sk und geonick angesprochen und um Rat gefragt, dazu sollte unsere Diskussion für Einsteiger lesbar und unsere Beispiele lauffähig bleiben. Dazu sollten wir das Procedere mal auf der Projektseite beschreiben.--Kolossos 18:00, 20. Mai 2008 (CEST)
      • Wget? Viel zu riskant! Niemals Konsolenbefehle mit queryparametern starten, da kann zuviel schief gehen. Es gibt doch file_get_contents! Die XSLT Extension ist auf dem toolserver nicht installiert, dafuer benutze ich den Konsolenbefehl (mit md5gehashtem query string als filenamen). Ja, bitte, gibt mir mal Dein -source.php --Dschwen 18:18, 20. Mai 2008 (CEST)
        • Die Source-Datei du brauchst nur den Dateinamen in der letzten Zeile anpassen. --Kolossos 19:27, 20. Mai 2008 (CEST)
          • Hier kannste den sourcecode jetzt sehen. --Dschwen 19:37, 20. Mai 2008 (CEST)
• Die KMLs können auf jeden Fall noch zu KMZs ge-gezippt werden. Das spart Platz und beschleunigt die Übertragung.
• Ein "&action=purge" wäre nicht schlecht um den Cache aktualisieren zu können.
  • Kann ich einbauen, zur Zeit werden Cachedaten, die aelter als 24h sind eh neu geladen. --Dschwen 15:29, 20. Mai 2008 (CEST)
    • Ok, sind jetzt 7 Tage und action=purge ist eingebaut. --Dschwen 15:31, 20. Mai 2008 (CEST)
• Wenn der Aufruf ohne Zoomstufe "z=..." erfolgen würde, würde es auch mit der Zenitrierung klappen.
  • Done. Klappt! Prima. --Dschwen 15:29, 20. Mai 2008 (CEST)
• Neben GoogleMaps wäre die reine KML für Google Earth auch interessant. Eine Minivorlage wäre da schonmal nicht schlecht.
  • action=kml --Dschwen 15:34, 20. Mai 2008 (CEST)
• Können wir auch mehrere Einschränkungen vornehmen? Also, zeige mir z.B. nur alle Flüße mit dem Namen Weser. ...
  • Hehe, jetzt sehe ich es auch. Da gibts wohl noch einen Bach in Belgien, der auch weser heisst.
• Langsam sollten wir uns auch Gedanken machen, wie die Einbindung in die Wikipedia aussehen könnte. Oben neben der Koordinate oder unten im Artikel mit mehr Platz, um ohne Geohack auf verschiedene Dienste verweisen zu können?
  • Oben faende ich nicht so pralle, dann lieber bei den Externen Links. --Dschwen 17:34, 20. Mai 2008 (CEST)
• Mit Umlauten wie in "Südring" und "...straße" haben wir wohl noch ein kleines Problem. --Kolossos 10:08, 20. Mai 2008 (CEST)
  • Geht jetzt auch [3]. --Dschwen 17:48, 20. Mai 2008 (CEST)

Ich arbeite das mal in beliebiger Reihenfolge ab... --Dschwen 15:29, 20. Mai 2008 (CEST)

Noch was vergessen? --Dschwen 17:48, 20. Mai 2008 (CEST)

Oh jeh, http://osmxapi.hypercube.telascience.org/api/0.5/*[name=Weser] macht nen Internel Server Error. Hab ich OpenStreetmap kaputt gemacht? --Dschwen 17:58, 20. Mai 2008 (CEST)

Bei mir geht es wieder. Solange du nicht auf die live-API von openstreet. org zugreifst sollte sich der Schaden in Grenzen halten und die Abfrage ohne Filterkriterien fangen die ja bei informationhighway/osmxapi.hypercube.telascience.org aus gutem Grund schon selber ab. --Kolossos 19:49, 20. Mai 2008 (CEST)

Jetzt mit etwas mehr errorchecking. Aber schau Dir dies mal an [4] anscheinend kommt google maps mit ge-gzip-ten kml dateien nicht klar. Was mach ich da falsch? --Dschwen 20:58, 20. Mai 2008 (CEST)

Die eingepackte Datei hieß "[Content]", vielleicht funktioniert es wenn die Datei xyz.kml heißt, gerade die eckigen Klammern könnten Probleme bereiten. --Kolossos 21:23, 20. Mai 2008 (CEST)

Es gibt da so eine kleines Internetlexikon, die sagen dort unter Keyhole_Markup_Language "Das Format KMZ ist eine datenkomprimierte KML-Datei im Format ZIP." Der Test läuft auch in Google Maps. Ich hatte das mit VRML verwechselt, da wurde wirklich gzippt. Haben wir einen Zipper auf dem Toolserver? --Kolossos 21:46, 20. Mai 2008 (CEST)

Ok, gzip durch zip ersetzt, und nun funktioniert es. --Dschwen 21:59, 20. Mai 2008 (CEST)

---

Haben wir noch ein Leerzeichen Problem? "*[name=Freiberger Mulde]" geht nicht obwohl die API da was liefert. --Kolossos 22:29, 20. Mai 2008 (CEST)

---

Neue Anmerkungen die mir so einfielen:

• In den query-String von http://tools.wikimedia.de/~dschwen/osm/index.php mogelt sich hartnäckig, wenn man die unteren Beispiele kopiert, am Anfang ein Leerzeichen, was dann zu einem Fehler führt. Vielleicht bekommt man das weg. Eine Kleinigkeit.--Kolossos 07:24, 21. Mai 2008 (CEST)
• Ich habe gelernt, statt *[name=Weser] bekommt man auch über way[name=Weser] einen ordentlichen Flußverlauf, es werden also auch die Nodes auf dem Flußverlauf durch die API übergeben.--Kolossos 07:24, 21. Mai 2008 (CEST)
• KML unterstützt linestrings (Pfade) und points (anklickbare POIs) recht seperrat, wärend OSM die Nodes sowohl für die Pfade als auch den für die POIs nutzt. Aus meiner Sicht wäre es das sauberste, eine Query für die paths und eine für die POIs zu machen diese durch getrennte XSLTs zu leiten und danach zu einem KML-Dokument zusammenzuführen. Für die POIs werde ich mal eine xslt erstellen. --Kolossos 07:24, 21. Mai 2008 (CEST)
• Etwas zweitrangig und wohl schwieriger umzusetzen wäre mein Wunsch, die einzelnen Pfadstückchen nach Möglichkeit (wenn zusammenhängend) zusammenzusetzen. Vorteil könnte das für die Performance bringen, haustächlich hätte ich aber Lust einem Pfad wie der Elbe in Google Earth lang zu fliegen (Play-Button), was mit den Teilstücken nicht geht. Aber wie gesagt der Wunsch ist sekundär.--Kolossos 07:24, 21. Mai 2008 (CEST)
• Wenn die index.php einem helfen würde, noch eine BBOX intuitiv zu generieren (OSM bzw. Google Maps Fenster) wäre das nicht schlecht. Wenn dann in der index.php ganz unten noch der fertige Vordruck für eine Wikipedia-Vorlage stünde, wäre das aus meiner Sicht schon nahezu perfekt. --Kolossos 07:15, 21. Mai 2008 (CEST)