Next week myself and other people from FOSSGIS e.V. will be present at the INTERGEO fair which is hosted In my hometown this year.
Working at the booth of my employer for most of the time, I will be at the OSGeo Park on Wednesday.
This should be a good place to spread the word about Openstreetmap. Karlsruhe was the first mayor german city to be completely mapped and this is also the place where the authors of the Openstreetmap book live.
Both of them will also be present at the OSGeo Park.
In diesem Jahr habe ich meine alljährliche Radtour von Karlsruhe nach Nürnberg dazu genutzt zwei komplette Fernradwege in Openstreetmap zu vervollständigen! Den Kraichgau-Hohenlohe-Weg von Bad Schönborn nach Rothenburg ob der Tauber sowie den Bibertalweg zwischen Rothenburg ob der Tauber und Fürth.
Letzteren gab es zwar schon weitgehend, die zugehörige Relation war aber in einem sehr häßlichen Zustand. Offensichtlich ist das leider bei vielen bestehenden Relationen der Fall 🙁
Das sind vermutlich auch noch Nachwirkungen der API Umstellung von 0.5 auf 0.6.
Unabhängig davon sollte man aber schon Wege splitten, wenn der Radweg nicht über den kompletten Weg läuft, denn es soll ja im Endeffekt ein Weg mit eindeutigem Verlauf zu erkennen sein.
Schön zu sehen ist auf dieser Radtour immer der jährliche Fortschritt des OSM Projektes. Während vor 3 Jahren außerhalb der Ballungsräume KA, HN und N noch fast nichts gemappt war. Konnte ich in diesem Jahr schon zu 99% auf gemappten Wegen radeln.
Zwei kurze Wegstücke habe ich sogar mit Hilfe des automatischen Routings der OSM Garminkarte zurückgelegt. An dieser Stelle mal ein herzliches Dankeschön an die Macher von mkgmap und an der Author der All in one Garmin Map.
Trotzdem gibt es natürlich insbesondere auf
der Hohenloher Ebene und im Gebiet Frankenhöhe noch viel zu tun!
Ich bin übrigens zum Freund von amenity=bench bzw. tourism=picnic_site geworden 🙂 Es ist nämlich überaus praktisch, wenn man seine kurzen Pausen sitzend verbringen kann, weil man auf dem GPS gesehen hat, dass in wenigen Metern eine Sitzgelegenheit ist.
Was jetzt noch fehlt ist eine POI Suche nach Fahrradhändlern, die hätte ich in diesem Jahr gut gebrauchen können.
Der Kraichgau-Hohenlohe-Weg ist nämlich leider nicht ganz vollständig. Es fehlt das Teilstück zwischen Langenburg und Schrotzberg!
Aufgrund einer Fahrradpanne musste ich hier leider vom geplanten Weg abweichen 🙁
Ach und nochwas ist mir aufgefallen: Bei Beschilderungen für Radfahrer ist Baden-Württemberg den Bayern um Längen vorraus.
Es interessiert in der Regel durchaus wie weit es noch bis zum nächsten Dorf ist. Bei KFZ Wegweisern eine Selbstverständlichkeit. In Bayern findet man soetwas selbst auf offiziellen Fernradwegen außerhalb der Ballungsräume eher selten.
A while back Markus Bärlocher asked me to help importing data he obtained from his municipal administration to Openstreetmap.
The most useful data in such a case is shapes of buildings. Other data has to be processed manually with the help of a WMS Server.
Today I imported the buildings which are already visible on the attached slippy map.
Auf dem ADFC Tourenportal findet sich eine recht brauchbare Karte aller mit dem Bett & Bike Label ausgezeichneten Übernachtungsmöglichkeiten für Tourenradler. Soweit so gut. Nun hätte man diese Betriebe aber gerne als Wegpunkt im GPS Gerät oder für Garmingeräte noch besser im sogenannten POI (Point of Interest) Format mit passendem Logo.
Man stelle sich nur mal vor man möchte am Ende des Tages schnellstmöglich zur nächsten Übernachtungsmöglichkeit. Wenn man eine Routingfähige Openstreetmapkarte und die passenden POIs im Gerät hat gar kein Problem. Leider gibt es die POI Daten jedoch beim ADFC nicht als download. Nun ja zumindest nicht direkt…
Da die Onlinekarte ihre Daten ja auch irgendwoher bekommen muss habe ich mal den Firebug angeworfen und geschaut wie die URL heißt, von der die Daten geladen werden. Herausgekommen ist letztendlich ein Python Script, das die Daten scheibchenweise runterlädt und in einem für die Weiterverarbeitung mit dem Garmin-POI-Loader (der Dank wine auch unter Linux läuft) geeigneten Format ausgibt.
Da ich kein Copyright an den Daten habe kann ich leider die fertige POI-Datei nicht direkt zum download anbieten. Falls jemand passende Ansprechpartner beim ADFC kennt, vielleicht kann sich ja Openstreetmap sogar bald über eine Datenspende freuen.
Als passendes Logo für den Garmin lädt man am besten das Favicon von http://www.bettandbike.de und konvertiert es in eine BMP-Datei.
Zum Schluß noch eine Anmerkung zum Garmin-POI-Loader. Leider kann GPSBabel nicht wirklich gut mit dem GPI-Format umgehen, ich empfehle derzeit daher ausdrücklich die Verwendung des POI-Loaders.
Unter http://www.poi-factory.com/garmin-csv-file-format findet sich eine gute Beschreibung des Inputformats für den POI-Loader.
Tim Alder hat die deutsche Geohack-Webseite nun so erweitert, dass wir im OSM Wiki ein template mit Verweisen auf OSM Spezialkarten pflegen können. Dadurch ist es nun zum Beispiel möglich mit 3 Mausklicks vom Wikipedia-Artikel eines Skigebietes auf die OpenPisteMap zu kommen! Ähnlich schön ist das natürlich bei der Reit- und Wanderkarte.
Bisher ging das nur sehr umständlich über die manuelle Eingabe von Geokoordinaten im URL.
Hier mal ein Beispiel:
Auf der Wikipedia-Seite von Zermatt öffnet man den Link “Koordinaten”. Von dort gelangt man über einen weiteren Link “Mehr Openstreetmap-Karten” zur “Zermatt-Version” des Templates. Wählt man hier nun die OpenPisteMap aus sieht man das Skigebiet von Zermatt.
Leider geht das bei der englischen Wikipedia noch nicht, weshalb ich den Artikel auch auf deutsch geschrieben habe.
Wer sich ein wenig näher mit Geodaten befasst stellt recht schnell fest, dass man da mit unglaublichen Mengen an historisch gewachsenem Zeug zu kämpfen hat. Ähnlich grausam ist das eigentlich im EDV Bereich nur noch beiCharacter Encoding. Im Geodatenbereich hat sich jedoch das Gegenstück zu Unicode leider noch nicht in der Breite durchgesetzt. Jedes Land wenn nicht sogar jedes Bundesland kocht da meist sein eigenes Süppchen.
Daten die man von öffentlichen Stellen in Deutschland bekommt sind meist in der Gauß-Krüger-Projektion mit Bessel-Ellipsoid in 3° breiten Meridianstreifen. Für die südlichen Bundesländer sind das GK2 für RLP, GK3 für BW und GK4 für Bayern.
Für OSM brauchen wir die Daten aber im “GPS Format” mit geographischer Länge und Breite bezogen auf WGS84 (epsg:4326). Es stellt sich also die Aufgabe die Daten möglichst genau in diese Formate zu überführen.
Weil OSM ein freies Projekt ist verwenden wir dazu natürlich freie Software!
Ein Kommandozeilenprogramm zur Konvertierung von im Geobereich üblichen Vektorformaten ist das Kommandozeilentool ogr2ogr.
Da die Kommandozeilen ein wenig kryptisch sind veröffentliche ich hier mal die passenden Konvertierungsbefehle für die GK-Zonen, mit denen ich bisher zu tun hatte.
Es geht darum die Aufgabe zu lösen Dateien in GK-Format in eine OSM geeigenete Darstellung (epsg:4326) zu überführen. Dankenswerteweise gibt es dafür eine amtliche Korrekturdatei zum Download. Damit erreicht man Genauigkeiten von etwa einem halben Meter. Für OSM ist das also mehr als ausreichend. Strenggenommen ist die Korrekturdatei zwar für ETRS89 und nicht für WGS84 (Danke Tobias), aber das können wir für die nächsten paar Jahre mal vernachlässigen.
Hier sind die Befehlszeilen die man auf einem Debian GNU/Linux (apt-get install gdal-bin) zur Konvertierung benötigt. Die amtliche Korrekturdatei BETA2007.gsb sollte im aktuellen Pfad liegen.
GK Zone 2 (RLP, NRW):
ogr2ogr -s_srs '+proj=tmerc +lat_0=0 +lon_0=6 +x_0=2500000 +y_0=0 \
+k=1.000000 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext' \
-t_srs epsg:4326 -f <dateityp> <outfile> <infile>
GK Zone 3 (BW, SHH):
ogr2ogr -s_srs '+proj=tmerc +lat_0=0 +lon_0=9 +x_0=3500000 +y_0=0 \
+k=1.000000 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext' \
-t_srs epsg:4326 -f <dateityp> <outfile> <infile>
GK Zone 4 (BY):
ogr2ogr -s_srs '+proj=tmerc +lat_0=0 +lon_0=12 +x_0=4500000 +y_0=0 \
+k=1.000000 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext' \
-t_srs epsg:4326 -f <dateityp> <outfile> <infile>
GK Zone 5 (SN):
ogr2ogr -s_srs '+proj=tmerc +lat_0=0 +lon_0=15 +x_0=5500000 +y_0=0 \
+k=1.000000 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext' \
-t_srs epsg:4326 -f <dateityp> <outfile> <infile>
Wenn man nach dem gewünschten Dateityp gefragt wird ist das ESRI Shapeformat typischerweise dem Autocad DXF vorzuziehen. Für ersteres gibt es fertige Konvertierungsprogramme ins native OSM Datenformat. Diese sind zwar noch stark verbesserungsfähig, aber dennoch halbwegs brauchbar.
In the meantime there are quite a lot of nice OSM based Slippy-Maps all around the Web. Usually they are based on Openlayers.
Now it happens from time to time, that I find something on one of this maps which needs to be corrected in the Openstreetmap database.
Unfortunately it is not very straight forward to load exactly the corresponding bounding box of the map into josm.
This has been solved in a very convenient way as far as the OSM Inpector is concerned. All you need to do there is to press the “load in josm” button on the Website.
Wouldn’t it be nice to have this feature in any Slippy Map?
Well, here we go:
Based on Jochens code I have been able to code a Bookmarklet which does exactly this!
All you need to do is to add this URL to your Bookmarks.
Now, if you call the bookmark while browsing a Slippy-map an running josm with the remote plugin enabled, then josm is instructed to download all the OSM-data for the section displayed in the slippy-map.
Update: This is confirmed to work with IE6-8 and Firefox. This does not work with Opera, because they have a security code in place which is blocking access to localhost from within scripts (see discussion on Opera forum).
Neueste Kommentare