Wenn ich aus dem Fenster und in die Nachrichten schaue, scheint die Zeit der Hochwasser wieder los zu gehen. Viele Flussrandbewohner schauen wieder auf die Flusspegel. Die meisten zwar wahrscheinlich eher online, trotzdem denke ich dass es interessant sein könnte die Pegelmesser in der Umgebung zu mappen. (Kann ja sein dass man wirklich mal raus geht um auf den Pegel zu schauen, falls die Wasserstands-Server wegen großer Nachfrage wieder down sind.)

Gemappt wird das ganze mit man_made=monitoring_station und monitoring:water_level=yes weitere Tags zur genaueren Beschreibung sind im Wiki zu finden. Eine Overpass Abfrage gibts natürlich auch. Wenn die Pegelstände jetzt noch OpenData wären, könnte man super Apps draus bauen.

Bild: CC-BY-SA Michael Sander

Bild oben: CC-BY ubahnverleih - Pegel Hochwasser 2013 Dresden

Der Dienst Mapillary, der Crowdsourced Streetview-Bilder sammelt, hat die Bilder bekanntermaßen zur Nutzung für OSM frei gegeben. Allerdings ist der Wechsel zwischen Editor und Mapillary Webseite immer ein wenig nervig. Leider habe ich keine Ahnung von JOSM-Plugins, habe aber einen anderen Weg gefunden die Bilder in JOSM zu bekommen. In GPX-Dateien können URLs zu Bilder hinterlegt werden. JOSM kann diese Bilder anzeigen. Also habe ich ein Tool gebaut, welches die Mapillary-API benutzt und aus den Informationen GPX Dateien erzeugt, welche dann in JOSM geladen werden können.

Das Tool ist unter http://osm.lyrk.de/mapillary2JOSM/ zu finden. Einfach die Karte an den gewünschten Platz schieben und auf Download GPX klicken. Die blauen Linien zeigen an welchen stellen Bilderstrecken vorhanden sind. Es kann passieren, dass in einem Kartenausschnitt zu viele Bilder vorhanden sind und die API aussteigt. In solch einem Fall einfach noch ein Stück rein zoomen und noch mal probieren. (Ja ich weiß, es gibt Orte an denen auch auf maximalem Zoom zu viele Bilder vorhanden sind - außer das Browserfenster kleiner ziehen habe ich da auch noch keine Lösung dafür.)

Ist die GPX-Datei geladen, kann man sie einfach in JOSM werfen und auf die Bilder klicken.

So ganz glücklich bin ich noch nicht, da JOSM Bilder aus GPX-Dateien anders anzeigt, als wenn ich georeferenzierte Bilder direkt in JOSM lade. So wird die Aufnahmerichtung des Bildes nicht angezeigt, obwohl sie in der GPX-Datei steht. Auch kann man sich nicht einfach mit Pfeilbuttons durch die Bilder durch klicken. Ich habe da schon versucht JOSM-Session-Dateien zu schreiben, aber der coole Bildviewer kann wirklich nur mit lokalen Dateien umgehen. Falls jemand eine Idee hat wie sich das lösen lassen könnte wäre ich sehr interessiert. Vielleicht ließt ja auch ein JOSM-Entwickler mit und kann da mehr zu sagen.

Ich hoffe das Tool hilft beim mappen. Der Code liegt auf github und das Skript kann auf http://osm.lyrk.de/mapillary2JOSM/ benutzt werden.

Vor ein paar Tagen habe ich es endlich geschafft den CRE zu Wikidata zu hören. Ich finde das ganze Projekt sehr spannend und mein erster Gedanke dazu war, wie es mit der Verknüpfung von Wikidata und OpenStreetMap aussieht. Ich scheine logischerweise nicht der erste zu sein, der daran gedacht hat und so gibt es auch schon einen Tagvorschlag für OSM, dem glaube ich nicht viel entgegensteht.

Ich habe mich dann mal ran gesetzt und versucht die WikiData-API anzuzapfen, die ehrlich gesagt ziemlich schrecklich ist. (In JSON eingebettetes JSON oder alternativ in XML eingebettetes JSON und solche Sachen, oder habe ich die Falsche API erwischt?)

Ich habe dann nach einer Sache gesucht, die man gut auf einer Karte visualisieren kann und fand dann heraus, dass einige Städte in Wikidata einen Link zu Ihrem Wappen (coat of arms image) haben. Also habe ich einige Städte in der Umgebung mit wikidata-Tag versehen und deren Wikidata-Seiten mit dem Verweis zum Wappen.

Nach etwas rumschlagen mit den APIs ist dann diese Karte heraus gekommen. Das ganze ist noch äußerst langsam, was an den vielen zugriffen auf die sehr langsamen APIs liegt, zeigt aber was möglich ist. Und nur einen Bruchteil davon was möglich sein wird, wenn Wikidata weiter gut befüllt wird und Objekte in OpenStreetMap fleißig Wikidata-Tags erhalten.

Allerdings glaube ich nicht, dass ein Wikidata-Tag sämtliche Meta-Informationen an OpenStreetMap Objekten ersetzen sollte, da die APIs eher langsam sind und man direkt in OpenStreetMap enthaltene Daten einfach deutlich schneller verarbeiten kann. Wikidata kann aber (soweit ich das jetzt nach »mal kurz rein schauen« beurteilen kann) komplexe Informationen, wie z.B. die Bürgermeister einer Stadt mit zeitlicher Zuordnung deutlich besser abbilden als Openstreetmap.

Ich habe allerdings ein wenig Angst, dass wir uns in Zukunft in eine Relevanzdiskussion versticken, wie sie schon der Wikipedia nicht gut getan hat. Nach dem Motto: »Die Öffnungszeiten müssen doch nicht in OSM, denn das Objekt ist doch in Wikidata drin und da sind die Öffnungszeiten.« Ich finde solche Informationen gehören trotzdem nach OSM. Auch Informationen wie z.B. die Bevölkerung population gehört schon allein deswegen in OSM, weil man damit beim rendern gut die Wichtigkeit von Labels für Städtenamen feststellen kann oder bei einer Adresssuche die Reihenfolge der Ergebnisse festlegen. Man könnte zwar auch hier OpenStreetMap und Wikidata verknüpfen, aber ich will mir nicht ausmalen, wie lange dann das verarbeiten der Daten dauern würde. Viel mehr hoffe ich, dass die Projekte sich gegenseitig bereichern, wobei das übertragen von OpenStreetMap-Daten nach Wikidata ein Lizenzproblem darstellen würde, da Wikidata unter CC0 steht. Das übertragen von Wikidata nach OpenStreetMap dürfte hingegen kein Problem sein.

Falls ihr lust habt könnt ihr ja mal ein wenig auf der Wappen-Karte rumklicken und mal euren Heimatort mit Wikidata-Tag versehen und in Wikidata den Ort dann mit Wappen versehen. Weitere Ideen sind natürlich auch willkommen.

Update: Grenzrelationen mit wikidata-Tag werden nun auch mit angezeigt.

Ich wurde vor einiger Zeit gefragt wie man am einfachsten zu OSM beiträgt ohne große Vorkenntnisse oder besondere Hardware zu haben. Speziell war die Frage auch wie man Gebäude oder Hausnummern einträgt. Jetzt bin ich mal dazu gekommen eine Videoanleitung dazu aufzunehmen. Ihr dürft das Video gern empfehlen, falls ihr ähnliches gefragt werdet. Insgesamt würde mich interessieren wie groß das Interesse an Videoanleitungen für OSM ist und zu welchen Themen.

photo by blinkenarea

Wie jedes Jahr fand auch dieses Jahr das CCC-Familientreffen zwischen Weihnachten und Silvester statt. Ich wusste zwar, dass ich den OSM-Stand besuchen will, dass ich da fast den ganzen Kongress verbringen werde hatte ich mir nicht gedacht. Ich setzte mich einfach dazu und blieb da. Es war wie ein vier Tage langer Stammtisch mit vielen interessierten Gästen. Ich glaube ich habe noch nie so vielen interessierten Openstreetmap erklären können. Da das Publikum des Kongresses natürlich technisch fit ist, gab es auch sehr viele technische Fragen zur Verarbeitung und Abfrage von Daten. Und wieder einmal fiel mir auf wie genial die OverpassAPI und Overpass Turbo ist. (die man nun endlich flattrn kann!!hinthint*) Viele Fragen bei denen ich sonst »Das ist gar nicht so einfach« sagen müsste konnte ich so in zwei Minuten mit Overpass turbo beantworten.

An Tag 4 veranstalten wir noch einen kleinen Workshop. Ich war ein wenig überrascht als irgendwann etwa 40 Leute vor uns standen. Wir haben uns dann in zwei Gruppen geteilt. Peter hat sich um die technisch interessierten gekümmert und Thomas und ich haben das Projekt an sich vorgestellt und erklärt.

Es waren sehr spaßige vier Tage an denen ich auch viele neue Mapper kennen gelernt habe und wir hoffentlich viele neue Mapper rekrutiert haben.

Vielen Dank an alle die dafür gesorgt haben, dass diese 4 Tage so super waren :)

(Leider habe ich keine Bilder von der OSM-Assembly. Wenn jemand welche hat würde ich mich drüber freuen die auch mal zu Gesicht zu bekommen)

Die meisten Menschen verbringen ihre Weihnachtszeit irgendwo mit Familie und Verwandtschaft. Oft wohnt diese auch mal an einem anderen Ort. Und schon wissen die meisten Mapper auch schon worauf ich hinaus will. Früher fand ich die Weihnachtsspaziergänge immer doof. Seit ich OSM kenne freue ich mich auf diese Spaziergänge und jetzt muss ich die Familie ins freie zwingen.

Falls in der Zielumgebung noch keine Gebäude oder Straßen eingezeichnet sind eignet sich die Vorweihnachtszeit prima dazu das nachzuholen. Es ist zu empfehlen sich verschieden Mappinggegenden herraus zu suchen, falls die Familie eine andere Spazierroute überlegt.

Außerdem empfehle ich WalkingPapers bzw FieldPapers statt Apps. Stift und Papier sind bei einem Spaziergang sozialer anerkannt als die ganze Zeit auf sein Smartphone zu starren. Außerdem kann man so ein Zettel auch mal weiter reichen und jemandem anderen Hausnummern aufschreiben lassen. Wenn man noch eine Kamera mit nimmt kann man auch Fotos von POIs machen (lassen). Mit etwas Glück lässt sich auch jemand mit unserer Sucht anstecken.

In diesem Sinne wünsche ich frohes mappen und erfolgreiche Weihnachten.

Als ich im Sommer diesen Jahres die Unterkunftskarte überarbeitete schimpfte ich ein wenig darüber, dass es kaum schöne Tiles gibt. Ich experimentierte ein wenig mit Tilemill herum und kam zu recht brauchbaren Ergebnissen. Allerdings ist das Aufsetzen eines eigenen Tileservers nicht so schnell getan. Außerdem wollte ich auch schon die ganze Welt abgedeckt haben, was dann doch etwas dickere Hardware erfordert.

Ich sprach also mit Thomas, weil der sich mit so Serverkram auskennt und wir beschlossen, das ganze mal anzugehen. Also einen hübschen Kartenstil und eine weltweite Abdeckung mit dicker Hardware. Es stellte sich relativ schnell raus, dass wir noch dickere Hardware benötigten.

Die nächsten Monate verbrachte ich also in Tilemill, Photoshop und mit gdal auf der Kommandozeile. Außerdem wartete ich viel auf Render-Ergebnisse. Ich glaube Thomas hing eigentlich die ganze Zeit im Terminal auf einem Server herum und fluchte oder freute sich über den schnellen Server.

Mehrfach schien es als wären wir fast fertig, mussten dann aber doch noch einmal für ein paar Wochen zurück in den Keller, meist um an Performance herum zu schrauben.

Auf dem letzten Dresdner Stammtisch konnten wir schon mal was von unseren Karten zeigen und kamen auch zu einer Deadline, was ungefähr so ablief:

»Wann startet ihr?«
»Irgendwann nächste Woche.«
»Ok dann schau ich Montag 19 Uhr mal rein.«
»Ähm äh OK, dann starten wir Montag 19 Uhr.«

So nun es soweit. Die Webseite ist online. Die Tiles sind online und wollen benutzt werden. Für nicht kommerzielle Projekte ist die Benutzung kostenlos, und wer die Tiles kommerziell benutzt darf unseren Server bezahlen und hoffentlich auch mal unseren Kühlschrank befüllen. Ja damit sind wir jetzt die böse kommerzielle Seite des OSM-Universums, hoffen aber der Community auch genug wieder zurückgeben zu können.

Ach ja wir haben auch tolle Retina-Tiles, damit Karten auch auf modernen hochauflösenden Geräten hübsch aussehen.

Ich mappe gerade in einer eher außergewöhnlichen Gegend. In Spitzbergen. Das ist diese Insel und Inselgruppe da im Norden von Norwegen. Ja dort ganz im Norden. Und nein ich befinde mich da jetzt nicht. Das wäre wohl zu der Jahreszeit wirklich sehr kalt.

Wie komme ich dazu?

Ich spiele in letzter zeit ein wenig mit Satellitenbilder herum und in den TrueMarble Bildern fehlt Spitzbergen vollkommen. Ich versuchte also Landsatbilder in diese Daten einzuarbeiten. Dabei fiel mir irgendwann auf, dass die Umrisse der Inseln von Spitzbergen in Openstreetmap nur sehr grob eingezeichnet sind. Noch gröber als Landsat-Bilder, die ja nur eine 30m Auflösung haben. Das ließ mich nicht los, da die Landsatbilder ja PublicDomain, und damit auch für OSM nutzbar sind, lag es doch nahe da etwas zu tun.

Die richtigen Bilder

Das erste Problem ist die richtigen Bilder zu finden. Die Landsat Satelliten machen die ganze Zeit Fotos von der Erde. Klingt erst mal gut. Das führt aber dazu, dass es sehr viele Bilder gibt. Das Problem dabei: Die sind nicht alle so schön klar wie wir das von den Bing-Bildern kennen, denn es gibt das sowas, was sich Wolken nennt und blöderweise ziemlich oft zwischen Satellit und Erde schwebt. Glücklicherweise bietet der Earth-Explorer der USGS eine Funktion die Bilder nach Wolkenbedeckung zu filtern. Ein weiteres Problem ist, dass Spitzbergen ziemlich nördlich ist, und es deswegen die hälfte des Jahres dort dunkel ist.

Das nächste Problem hat damit zu tun, dass es dort sehr kalt ist. Das wiederum heißt, dass zwischen den nördlichen Inseln ein Großteil des Jahres das Meer zugefroren ist, und somit die Uferlinien nicht zu erkennen sind.

Tatsächlich gibt es nur eine Handvoll gute Landsat7 Bilder von Spitzbergen, die allerdings auch sehr verschneit sind. (Nur die Landsat7 Bilder zwischen 1999 und 2003 sind wirklich benutzbar, weil seit 2003 die Bilder wegen einem Defekt am Satelliten große Störungen aufweisen). Glücklicherweise umkreist uns seit diesem Jahr Landsat 8 und versorgt uns seit März mit Bildern. Und hier habe ich tatsächlich 2 Serien von Bildern gefunden die recht vielversprechend sind. Besonders die Bilder vom September sind gut, da hier sehr viele Inseln komplett Schneefrei sind.

Und jetzt in JOSM damit. denkste.

Die Landsatbilder sind Georeferenziert und kommen als JPG mit einem zusätzlichen File, welches die Geo-Informationen enthält oder als GeoTiff. (Einem Bildformat, welches die Geoinformationen direkt enthält.)

Jetzt sollte es ja einfach möglich sein ein GeoTiff in JOSM als Hintergrund-Layer zu benutzen. Denkste! Ja OK dieses GeoTiff ist ja auch ein ziemlich spezielles Format was nur im GIS-Umfeld benutzt wird… OH MOMENT. Ja es gibt irgendwelche Plugins die sowas können sollen – die haben aber alle bei mir nicht funktioniert.

Ich habe mir dann GDAL genommen und gdal2tiles.py angeworfen und die Tiles auf einen lokalen Server geworfen und sie dann als TMS-Layer eingebunden. Wobei das auch nicht auf Anhieb klappte, weil es verschiedene Vorstellungen gibt wie so ein TMS aussieht – die einen fangen beim Südpol an zu zählen, die Anderen beim Nordpol. {-y} ist übrigens die Lösung.

Na dann mal abmalen

So endlich kanns losgehen. Also so fast, denn ein paar kleinere Probleme gibt es noch: Auch wenn es auf der ganzen Inselgruppe nicht so sehr viel Daten gibt, begrenz die API die Fläche die man herunterladen kann. Das heißt man muss sich immer kleiner Stückchen herunterladen, an denen man gerade arbeiten will. ist aber (bis jetzt) nicht wirklich störend.

Außerdem sind die Landsatbilder sehr dunkel, weswegen ich das Bild noch mal in Photoshop geworfen habe, um es ein wenig aufzuhellen. Dummerweise ist Photoshop – ja dieses unglaublich teure Profitool – zu dämlich beim speichern eines Tiffs die Geodaten aus dem Inputfile wieder mit abzuspeichern. Aber auch dafür gibt es ein kleines GDAL skript welches die Information von einem in ein anderes Bild übertragen kann.

Die Daten

So kommen wir nun zum eigentlichen abzeichnen. Die Küstenlinien der Inseln sind Daten die 2008 mal importiert wurden - mit source=gadm_v0dot9. Ich hab es nur kurz überflogen, aber es kann sein, dass es mit diesen Daten sogar Lizenzkonflikte gibt, bin mir da jetzt aber nicht sicher. Wie schon angesprochen sind die Daten nicht sehr genau, was wohl mehrere Gründe hat:

Da oben ist niemand. Sicher aus gutem Grund. Außerdem liegen die Inseln doch sehr weit auseinander. Außerdem sind selbst die kleinen Inseln ziemlich groß. Deutlich größer als sie erscheinen mögen, da ist man nicht mal schnell mit nem GPS-Gerät einmal um die Insel gelaufen. Das größte Problem dürfte auch sein, dass nicht immer klar ist, wo denn eigentlich die Grenze der Inseln ist. An einigen stellen gibt es hier ähnliche Probleme wie auf Antarktika: Teile der Inseln sind einfach ganzjährig mit Eis Bedeckt, und dieses Eis ragt auf das Meer hinaus, so dass die Uferlinie nicht sichtbar ist. Teilweise sind OSM-Uferlinien Kilometer von der (in dieser Aufnahme) sichtbaren Linie entfernt.

Ein Problem mit den Bildern ist, dass die Sonne sehr tief steht, und es lange Schatten gibt, wodurch aus den Bildern die nördlichen und östlichen Ufer nicht immer klar hervorgehen. Das war auch ein Grund warum ich die Bilder noch einmal aufhellen musste

Auf den Bilder sind oft Seen zu sehen, von denen ich denke, dass es das Tauwasser von dem ganze Eis ist. - Da habe ich aber auch keine Ahnung ob und wie man das Tagt.

Uferlinien

Es war das erste mal, dass ich mit Coastlines gearbeitet habe. Diese haben die Eigenheit, dass man sie richtig herum malen muss. Also Inseln müssen immer gegen den Urzeigersinn gemalt werden. Das ist im Wiki auch noch einmal erklärt.

Und weiter?

Ich habe jetzt ein paar dutzend kleine Inseln im Norden bearbeitet. Ich habe das source Tag mit source=landsat8 ersetzt und noch source:date=19-SEP-13 dran gehangen, damit klar wird aus welchem Landsat-Bild abgemalt wurde.

Wenn es Interesse gibt, hier weiter an den Uferlinien zu arbeiten (oder auch andere Dinge die man auf Landsatbildern erkennt), dann würde ich mir auch die Mühe machen mehrere Landsatbilder zusammen zu setzen und als Tileserver anzubieten. Über Feedback würde ich mich auf jeden fall freuen.

PS: Es ist jetzt ganz schön spät geworden. Ich bitte selbst grobe Rechtschreibfehler und Satzverschachtelungsfehler zu entschuldingen

Vor einiger Zeit hielt ich während einer Busfahrt die Kamera aus dem Fenster und nahm alles auf. Ich wollte das mit dem Videomapping einfach mal testen. Gestern kam ich dann endlich mal dazu, das Video auszuwerten.

Nach einigen Minuten hatte eine Wetterstation meine Aufmerksamkeit. Im Wiki ist das einzige Ergebnis, welches ich zum Thema Wetter-Station bekam die how to map a Seite. Dementsprechend habe ich das ganze als man_made=measurement_station + measurement=weather eingetragen. Ich fand das recht interessant, da man mit measurement ja alle möglichen Stationen eintragen kann und schaute mal auf Taginfo, was es da noch so für Messstationen gibt.

Allerdings stieß ich später auf man_made=monitoring_station was ziemlich ähnlich aussieht und das gleiche abdecken könnte. Wenn es da einen Unterschied geben sollte, wüsste ich ihn gern, aber ich denke, der Vorteil von monitoring_station ist, dass hier Eine Station mehrere Werte messen kann. Es ist auch ein wenig mehr verbreitet als measurement_station.

Auf jeden Fall fände ich es interessant noch mehr Messstationen zu mappen, glaube aber, dass man sich mal auf ein Schema einigen sollte. (HAHA in OSM auf EIN Tag einigen, ich bin lustig ich weiß.)

Statistik

measurement_station: 1 766 mal verwendet

monitoring_station: 2 741 mal verwendet

Ich habe irgendwann aufgehört mir alle OSM-POI-Editoren für iOS anzusehen, weil ich mit der Editing Funktion von OpenMaps recht zufrieden war. Außerdem wurden es immer mehr Editoren. (was ja gar nicht schlecht ist.) Funktionen die den mobilen Editoren meist fehlten war das Bearbeiten von ways. – Wenn sie überhaupt bearbeitet werden können und nicht nur ein neuer Punkt gesetzt wird. Aber von PushPin bin ich schon begeistert. Man kann mit diesem Editor Die Tags von ways bearbeiten (das Editieren der Geometrie ist allerdings nicht möglich) und das Interface ist auch nett anzusehen. Außerdem muss man nicht aufwendig in Tags wühlen, sondern man hat gleich eine Vorauswahl von Tags, die man benutzen kann und die meist zu dem ausgewählten Objekt passen. Eigentlich hat man auch keine Tags in diesem Sinne zur Auswahl, sondern eher eine Anzahl an Eigenschaften. Das kann natürlich schon etwas die Auswahl einschränken, weil man nicht alle Tags abdecken kann, aber vereinfacht die Sache enorm. Eigentlich finde ich die App nicht deswegen genial, weil ich sie gern nutzen will, sondern weil es die App ist, die man jedem in die Hand drücken kann. Man brauch für die Bedienung fast kein OSM Vorwissen. Es ist die App die man jedem Menschen empfehlen kann, wenn er fragt wie man denn am besten bei OSM mitmacht. Nicht ganz, denn etwas ganz wichtiges fehlt: Eine deutsche Übersetzung. Ich glaube dass eine Übersetzung extrem viele Berührungsängste lösen und viele Missverständnisse umgehen kann.

Genial wäre hierfür ein kollaboratives Google-Spreadsheet in das die verschiedenen Textteile crowdsourced in verschiedene Sprachen übersetzt werden können. Diese Art der App-Übersetzung wurde für den Podcastclient Instacast erfolgreich durchgeführt.

Ich habe die Entwickler von PushPin schon mal deswegen angeschrieben, bekam aber noch keine Antwort.

Wenn man nicht nur Nodes auf einer Karte auswerten und darstellen will, muss man sich irgendwann überlegen wie man den Mittelpunkt von Flächen erhält um da ein Icon oder eine Stecknadel zu platzieren. Für die Unterkunftskarte habe ich mir das schon ziemlich zeitig überlegen müssen und bin jetzt noch einmal drauf gestoßen, weil ich nun auch Multipolygone auswerte. Ich habe mich damals für eine Ziemlich einfache Lösung entschieden. (schon allein weil die Positionierung von Icons nicht das war worauf ich bei einer Unterkunftskarte viel Energie verschwenden wollte.)

Ich nehme mir einfach alle Nodes der Fläche daher und suche mir dann jeweils die extremsten Punkte in jede Himmelsrichtung heraus und nehme dann jeweils den Durchschnitt der nördlichsten und südlichsten Punkte für die Latitude und für die Longitude den Durchschnitt aus östlichstem und westlichstem Punkt. (Ist im Bild vielleicht besser zu erkennen was ich meine.)

Der Nachteil an der ganzen Geschichte ist, dass es Flächen gibt in denen das wie in der rechten Skizze nicht funktioniert. Als Beispiel könnte das ein Zeltplatz, der sich um einen See zieht sein. Der Marker würde dann mitten im See liegen. In der Praxis habe ich aber kein Beispiel gefunden wo es wirklich passiert ist.

Lösen ließe sich das Problem in dem man den Geometrischen Schwerpunkt der Fläche errechnet. Die Formel für Polygone sieht gar nicht so kompliziert aus und ich bin am Überlegen das mal auszuprobieren. Update: Bekam gerade eine Mail, die sagte, dass der Geometrische Schwerpunkt das Problem doch nicht unbedingt löst.

Bei Multipolygonen wird das ganze ein wenig komplizierter und ich bin mir nicht sicher ob es da überhaupt eine Perfekte Lösung gibt. Bei Multipolygonen mit inneren Flächen sehe ich weniger ein Problem, auch wenn der Mittelpunkt auf der ausgestanzten Fläche liegt (mittlere Skizze). Das kommt häufig bei Häusern mit Innenhof vor - und hier gehört der Innenhof ja irgendwie mit zum Gebäude. Klar wenn man einen Renderer baut, der dann auch Namen in Wälder mit Löchern schreiben soll, muss man sich hier auch ein paar mehr Gedanken machen.

Richtig problematisch wird es aber wenn ein Polygon aus mehreren Flächen besteht die einigen Abstand voneinander haben. Hier kann es Passieren, dass der Marker dann einfach zwischen die Flächen gesetzt wird. Ist auch nicht wirklich schlimm - kann aber möglicherweise verwirren. Die Renderer scheinen hier das Symbol einfach in alle Flächen zu malen, was ich bei dynamischen Markern weniger passend finde. Vielleicht sollte ich hier überlegen einfach den Mittelpunkt der größten Fläche für die Stecknadel zu wählen.

Weitere Ansätze dazu würden mich auch interessieren - das ist ja auf keinen fall ein neues Problem. - Wie macht das eigentlich osmfilter --alltonodes?

Nachdem die Unterkunftskarte Permalink und Suche bekamen habe ich mich nun ein bisschen ums Aussehen gekümmert. Aus Faulheit habe ich bis jetzt immer fertige Icons benutzt. Schöne Icons gab es zwar, aber nie alle die ich brauchte. Nun habe ich mich selbst mal dran gesetzt und selber (hoffentlich hübsch) Symbole gemacht. Auch den Renderingstyle habe ich geändert. Ja ich finde den osm.org Renderingstyle ziemlich hässlich. Und es gibt auch wenige alternativen. Mapquest ist ein wenig besser aber auch nicht gerade hübsch. Ich habe mich jetzt für den Style von Mapbox entschieden. Der ist zwar schön hat aber auch einen großen Nachteil: Mit dem kostenlosen Account bei Mapbox bekommt man nur begrenzt Tiles ausgeliefert. So wenige, dass es selbst für die paar Besucher der Unterkunftskarte knapp wird. Das ist doof - ich will bitte schöne Tiles für umsonst. Kennt da jemand noch was? Gibt es sonst überhaupt schöne Tiles außer von Mapbox?

Ach ja außerdem habe ich unterkunftskarte.de registriert und diese dahin umgezogen. Permalinks auf die alte Karte werden auch dahin weitergeleitet.

Ein paar kleine verbesserungen gab es auch noch. ich weiß nur nicht mehr genau was ;)

Auf den letzten Beitrag zur Unterkunftskarte habe ich viel positives Feedback bekommen und sie war sogar mit Titelbild im OSM Blog \o/

Aber es wurden auch ein paar Sachen nachgefragt, die mir selbst schon ein wenig gefehlt haben. Natürlich will man auch nach Orten suchen können und einen Kartenausschnitt weiter leiten. Beides geht nun. Dank leaflet plugins war das ganze auch echt schnell eingebaut. (Ach ja und leaflet habe ich bei der Gelegenheit auch gleich mal aktualisiert.) Das einzige was immer noch fehlt ist die anzeige von Relationen. Da scheint es einige große Zeltplätze zu geben, die als Relation gemappt sind und deswegen auf der Unterkunftskarte noch nicht angezeigt werden. Da muss ich noch ein wenig rum basteln.

(ab hier etwas technischer)

Das Problem ist die Koordinaten zusammen zu basteln, weil Relationen nur auf Wege verweisen und Wege nur auf punkte, welche dann endlich Koordinaten haben. Schön wäre es wenn Overpass API die Mittelpunkte von Wegen und Relationen schon vor berechnen könnte.

Für die Permalinks benutze ich das leaflet Plugin Leaflet Hash. Hier gibt es nicht irgend ein Link auf dem Permalink steht, sondern der Link wird bei jedem verschieben der Karte in der Adressleiste aktualisiert. Kleine Anpassungen musste ich noch bei der Erkennung der aktuellen Position machen, damit der Permalink nicht überschrieben wird.

Für die Suche benutze ich L.GeoSearch im Nominatim Modus. Das ist auch schnell eingebaut, gefällt mir aber noch nicht so ganz, da man keine Auswahl der Ergebnisse hat, sondern die Karte sofort an die Stelle des ersten Suchergebnisses springt. Bei gleichnamigen Orten ist das nicht ganz optimal. Eine Auswahlliste unter dem Suchfeld wäre besser. So muss man seinen Suchbegriff schon bei der Eingabe genauer beschreiben.

Vor mehr als einem Jahr baute ich eine Interaktive Karte mit OSM, auf der Man Zeltplätze, Hotels und andere Unterkünfte angezeigt bekommt. Und als ich jetzt mal schauen wollte wo ich denn in den Urlaub hin will, stellte sich diese als wirklich nützlich heraus.

Allerdings zeigte sich schon nach kurzer Zeit, dass es nicht nur reicht, dass ein Zeltplatz als solcher eingetragen ist, sondern dass es besonders wichtig ist, dass auch der Link zur Webseite des Zeltplatzes mit getaggt ist. Ich ignorierte tatsächlich alle nicht verlinkten Plätze bei meiner Suche nach einer Unterkunft. Für andere ist vielleicht die fehlende Telefonnummer ein sofortiges (unbegründetes) Ausschlussmerkmal.

Was ich damit sagen will:

1. Taggt mehr zusätzliche Infos

2. Schreibt Software, welche diese Zusätzlichen Infos Auswertet und anzeigt

3. Probiert doch mal die Unterkunftskarte aus

4. Sagt mir bescheid wenn ihr eine besonders Günstige Übernachtungsmöglichkeit an der Ostsee habt / kennt :)

PS: Die Webseiten von Zeltplätzen sind überdurchschnittlich oft sehr hässlich

Gestern habe ich den OSM-Podcast gehört in dem es auch um 3D Modelle ging. Dabei kam die Frage auf, wie man denn überhaupt Gebäudehöhen misst. Ich habe jetzt eine iPhone App gefunden, welch dies einigermaßen gut kann (und dabei nicht nur den Lagesensor zur berechnung benutzt)

Die App Measured Bedient sich dabei der Schuhgröße. Das klingt erst einmal ein bisschen komisch ist aber gar nicht so dumm, denn damit hat man ein Entfernungsmaß, welches man ohne Probleme überall einsetzten kann.

Der Ablauf bei Messen ist so: Man schießt ein Bild mit der Kamera, setzt dann immer ein Fuß hinter den anderen und zählt dabei die »Schritte«. Dann gibt man die Anzahl der Schritte in Die App ein und macht dann noch ein Foto. Jetzt kann man auf dem Bildschirm Linien ziehen und bekommt die Höhen oder Breiten und wenn man will sogar die Abstand zum Objekt.

So die Theorie. Praktisch nervt es sehr, dass man die Anzahl der schritte eingeben muss, bevor man das 2. Foto schießt. Das habe ich sehr oft vergessen. Demnächst werde ich einfach erst die Anzahl der schritte eingeben und dann diese Anzahl laufen. Außerdem werden die Maße erst immer in Zoll angegeben und man kann dann auf Meter umschalten. Theoretisch kann man Meter auch als Standart-Maß einstellen - aber irgendwie merkt er sich das nicht. Das Erklärungsvideo in der App ist mit iOS6 ein wenig kaputt. Gibt es aber auf Youtube. Außerdem sieht es ein wenig seltsam aus, wenn man einen in der Fußgägerzone Fuß hinter den anderen Setzt.

Wie genau ist das denn jetzt. Ich habe ein paar mal meine Türhöhe gemessen. Wenn man sich an alle Vorgaben hält, dann habe ich eine Abweichung von nur 3 Zentimetern gehabt. Draußen war es ein wenig schwieriger, weil durch mehr gelaufene Schritte natürlich mehr Abweichung entsteht. Außerdem kann ich die Gebäude zum Vergleich nicht Nachmessen. Eigentlich soll man mindestens ein drittel der Entfernung zum Objekt laufen bis zum 2. Bild. Auch das hab ich draußen nicht gemacht. Trotzdem sind die Ergebnisse realistisch und ich gehe von einer Abweichung von 10% aus. Das finde ich in Ordung.

Ein wichtiges Feature ist, was gerade für das Mappen von Vorteil ist, ist dass man erst einmal die Ganzen Fotos machen kann und die Messungen dann später anzeigen/malen kann. Außerdem sind die Messungen in Projektordnern sortiert.

PS: Als nächstes werde ich mal probieren ob man damit auch Brückenhöhen messen kann.

Für eine App die 2,69€ kostet finde ich das alles in Ordnung. Ich werde mal die Entwickler anschreiben ob man die Schrittanzahl nicht im Nachhinein noch eingeben könnte.

Außerdem habe ich jetzt mal zusätzlich zur Höhe “source:height=Measured App” mit angegeben, falls jemand mal mit genaueren Messungen kommt, nicht verwirrt ist.

(Mit schritten meine ich in diesem Eintrag immer Einen Fuß direkt hinter den nächsten gesetzt)

Während der OSMAddressCorrector nicht verfügbar war, baute ich mir meine eigene Karte, welche unvollständige Adressen anzeigt. Was genau angezeigt wir und mehr hab ich hier noch mal aufgeschrieben

Viel Spaß beim Adressen vervollständigen :)

http://osm.lyrk.de/address/

Vor ein paar Wochen schrieb ich hier die Idee nieder ein Gerät zu bauen, welches auf einer Autofahrt Schilder erkennt und davon ein Foto macht, damit man es später z.B. Geschwindigkeitsbegrenzungen in OSM eintragen kann. in den Kommentaren wurde dann angemerkt, dass man das doch auch mit einem Smartphone umsetzen könnte. Ich habe keine Ahnung warum ich auf diese Idee nicht gekommen bin. Diese Geräte haben Kamera und GPS und sind mittlerweile auch schnell genug für Bildverarbeitung. Außerdem sind sie extrem verbreitet.

Da ich mich mit dieser ganzen Android-bastelei noch nicht beschäftigen wollte, habe ich erst einmal angefangen mich mit Bilderkennung zu beschäftigen. Ich bin echt beeindruckt, was mit OpenCV alles möglich ist und vor allem wie schnell so etwas umgesetzt ist.

Bis jetzt haben wir also eine Software, die das Livebild der Kamera abgreift, dann die Farben so filtert, dass nur noch rot übrig bleibt und dann Kreise erkennt. Und nachdem wir noch ein wenig mit den Parametern herumgespielt haben ist die Trefferquote erstaunlich hoch. Ich habe ein 1 Stündliches Testvideo durch die Software geschoben - Dabei hat das Programm etwa 70-80% der erkennbaren Schilder erkannt und nur 5% der erfassten Bilder waren Fehltreffer. (Als erkennbare Schilder bezeichne ich hier Schilder mit Rotem Rand wie z.B. Überholverbot, Geschwindigkeitsbegrenzung, Halteverbot. Außerdem zähle ich Schilder, bei denen der rote Rand sehr ausgeblichen ist nicht mit dazu). Bei einem anderen Video bekam ich sehr viele Fehler, durch das Rote runde Rücklicht des vorherfahrenden Fahrzeuges. Hier muss ich wohl noch ein wenig optimieren.

Die beschriebenen Tests habe ich einfach mit Videos von Autofahrten, welche ich auf Youtube fand gemacht. Dies entspricht natürlich nicht wirklich dem, was später heraus kommen soll - Bei den Videos habe ich alle 25 Frames/Sekunde ausgelesen. Das führte dazu, dass selbst auf meinem 2,5Ghz Prozessor die Verarbeitung 4 mal so lang brauchte, wie das Video.

In der Praxis sollen aber überhaupt nur etwa 3-4 Bilder/sekunde aufgenommen werden. Um die benötigte Leistung noch weiter zu senken, ist zu überlegen, ob es die volle Auflösung sein muss. Ich weiß auch nicht ob smartphone überhaupt hochauflösende Bilder in der Frequenz schießen können. (Schon allein, weil ich überlege ein 50€ smartphone für so etwas zu benutzen)

Einen Live-Test habe ich nun schon mal mit dem MacBook und dessen Kamera unternommen. Das Bild Dazu sieht man oben.

Was ich mir eigentlich noch wünsche, ist, dass ich auch Blaue runde Schilder, wie Abbiegebeschränkugen erkennen könnte. Außerdem ist vielleicht zu überlegen ob man für Länder, dessen OSM-Daten noch sehr lückenhaft sind auch Ortseingangsschilder erkennen will um Orte richtig zu benennen.

Ich habe ja eigentlich wenig mit Hardware Basteleien am Hut. Doch ich habe eine kleine Idee. TomTom und die anderen Kartenanbieter für Navigationssoftware sammeln ihre Daten für Geschwindigkeitsbegrenzungen usw. meines Wissens nach vollautomatisch mit Streetview ähnlichen Autos mit vielen Kameras.

(Bildquelle: http://commons.wikimedia.org/wiki/File:Mapping_van_tomtom_with_five_lidars.jpg)

Warum bastelt man sich nicht was ähnliches um die OpenStreetMap-Daten zu verbessern. Natürlich nicht so riesig und aufwändig – Ich denke da eher an eine kleine Kiste, die man sich irgendwo in die Ecke der Windschutzscheibe klebt. Als Grundlage würde sicher ein Rasberry Pi genügen. Der nimmt wenig Strom und sollte genügend Leistung haben um Bilderkennung zu können. Außerdem ist er schön klein. Jetzt noch ein günstiges GPS-Modul und eine Webcam mit etwas besserer Auflösung und ausreichender Framerate.

Jetzt bräuchte man eine Software die erstmal die wichtigsten Verkehrsschilder, wie Geschwindigkeitsbeschränkungen und Abbiegebeschränkungen erkennt. Von diesen Schildern wird jetzt einfach ein Bild gemacht und zusammen mit den GPS-Koordinaten gespeichert.

Jetzt bräuchte man noch eine Plattform, auf die man diese Bilder hochladen kann und sie dann auf einer Karte angezeigt werden können. Von einer Automatischen Verarbeitung und Eintragung der Daten halte ich noch nicht viel, da es ja auch Temporäre Geschwindigkeitsbegrenzungen und Baustellen oder ähnliches gibt. Ob man die Daten jetzt selber einträgt, oder das anderen Mappen überlässt kann dann jeder selber entscheiden. Oft sind solche Bilddaten ja auch zur Überprüfung komplizierter Kreuzungen hilfreich.

Wenn man jetzt noch ein WLAN-Modul in das kleine Gerät mit einbaut, könnten die Bilder auch automatisch hochgeladen werden, sobald ein offenes WLAN oder ein heimisches Netzwerk in Reichweite ist. Dann könnte man dieses Gerät z.B. auch einfach dem Bekannten, der beruflich den ganzen Tag Auto fährt in sein Fahrzeug einbauen.

Ich denke, dass sich solch ein Gerät für unter 100€ bauen lässt. Softwareseitig könnte man sicher die Bilderkennungssoftware/Framework OpenCV benutzen. (Ist das erste was ich gefunden habe. Vielleicht gibt es ja für diesen Anwendungsfall etwas besseres.) Vorerst müsste man ja nur rote Ringe mit weißem inneren (Geschwindigkeitsbegrenzungen) und blaue Kreise (Abbiegebeschränkungen) erkennen.

Kurz vorweg: Ich schreibe hier nicht über Fußwege, welche unabhängig von Straßen sind, sondern von Bürgersteigen, also diesen Gehsteigen die direkt an die Straße anschließen.

Ich bin eigentlich ein großer Fan vom Fußgängerrouting in OSM. In Fremden Städten ist man schnell am Ziel. Aber auch in der Eigenen Stadt kann man schnell schauen welcher Weg denn jetzt eigentlich der kürzere ist. Natürlich funktioniert das ganze nur, wenn es auch die passenden Daten in OSM gibt. Doch zuviel von Fußwegen kann das ganze auch Kaputt machen. Wenn nämlich normale Bürgersteige auch als Fußwege eingetragen werden. Dann sieht das ganze auch mal schnell so aus:

Das Problem an der Sache ist einfach, dass man in der Realen Welt an jeder Stelle von der Straße auf den Fußweg kommt. In der OSM-Daten allerdings nur da wo die Straßen und die Fußwege gemeinsame Punkte haben. Klar könnten die Routingprogrammierer da ein wenig optimieren, doch ich denke es macht keinen wirklichen Sinn Bürgersteige als Fußweg zu mappen. Natürlich ist das wieder so eine Diskussion wie das Spurmapping, aber ich glaube von dem kann man lernen, dass es nur Sinnvoll ist den Bürgersteig als separaten way zu Mappen, wenn eine Bauliche Trennung besteht - man also nicht jederzeit von dem Bürgersteig auf oder über die Straße kommt, weil z.B. eine Leitplanke dazwischen ist.

Lösung

Ich kann allerdings verstehen, dass man eintragen will, dass an dieser Straße z.B. nur links ein Bürgersteig ist. Dazu gibt es das Tag Sidewalk welches an jeden Highway gehangen werden kann. Also sidewalk=both/left/right/none Ich weiß nicht ob es schon routingsoftware gibt, welche das auswertet, aber ich finde diesen Tag ganz sinnvoll.