Ich habe mir zwecks Qualitätssicherung in Maperitive eine Regel (MaperitiveRules/Surface) für die Verwendung und visuelle Darstellung der Oberfläche erstellt.

Ursprünglich eigentlich nur für meinen Umkreis gedacht, habe ich spaßeshalber einfach mal die Autobahnen (inkl. Ab-/Auffahrten) in Deutschland durchlaufen und visualisieren lassen. Naja, was soll ich da noch großartig sagen, seht selbst: AutobahnOberflaeche.png

Mehr als die Hälfte der Autobahnen in Deutschland hat keine Oberfläche. Jetzt könnte man ja fragen: warum sollte es?

Ein Gedanke könnte folgender sein: Bundeslandabhängig werden im Sommer Autobahnen aus Beton (concrete) wegen Blow-ups durchaus mal eine Höchstgeschwindigkeit von 80 km/h festgelegt.

Bei kühlen Temperaturen aber Sonne ein Wohngebiet in Leiferde mit Hausnummern versehen. Endlich mal wieder Bewegung! Und wieder festgestellt, daß das Taggen von Adressen länger dauert als das Aufschreiben vor Ort.

Die Trennung von Ost und West ist deutlicher den je! Google hat neue Luftaufnahmen von Potsdam veröffentlicht, auf denen deutlich wird, das der Osten keine Chance mehr hat, den “Rückstand” noch aufzuholen… Es ist sogar schon soweit, das sich die Jahreszeiten verschieben!

Im Westen ist schon Sommer, im Osten noch nicht mal Frühling:

:-) Fröhliches Mappen mit besserer Sicht auf sonst von Bäumen verdeckte Häuser!

Edit: Damit “4000 gelöschte Orte” nicht so abstrakt daherkommen, habe ich auf umap daraus eine Karte erstellt.

Kürzlich stieß ich wieder einmal auf einen der Mapper, der etliche place-Nodes löschte, weil die ja auch am landuse stehen (oder er sie (teilweise) dorthin kopiert hatte).[0]

Nun steht ja im Wiki, dass man places sowohl als node, als auch als way als auch mit beidem mappen kann, also ist das, was die Mapper da treiben, im Prinzip nicht verkehrt. Mich stören aber zwei Dinge: Zum Einen sind die Nodes in der Regel einige Jahre älter als die Umringe der Ortschaften. Mit diesen Löschungen geht ein Teil der OSM-Geschichte verloren. Zum Anderen schaffen es manche der Mapper nicht, alle Tags zu kopieren…

… See full entry

Welche Tools existieren zur Kartierung von Veranstaltungsarealen?

Häufig ist, insbesondere bei größeren Veranstaltungen, wie Volksfesten eine detaillierte Kartierung erwünscht. Wenn das Volksfest im nächsten Jahr wieder stattfindet, sind die Attraktionen häufig wieder am selben Ort errichtet, so daß es sinnvoll ist, für eine Neukartierung die Version aus dem letzten Jahr als Vorlage zu benutzen. Kann man auf diese wieder zurückgreifen? Kann man für bestimmte Areale mehrere austauschbare Karten definieren, was für die Kartierung von Festplätzen sehr sinnvoll wäre.

Welche Tools existieren, um die Route von Umzugsveranstaltungen auf Openstreetmap zu definieren?

#ElMapaDelAsado

• OpenMapMeatMap? The idea was born by the journalist Miguel Graziano and realized by mapache or Mapa Ché ;-). #ElMapaDelAsado shows the prices of meat collected by the crowd. Miguel Graziano said to weeklyOSM: “The map was born with the intention of responding to higher prices and the loss of purchasing power of wages.”

Here the statement from Miguel Graziano:

“El Mapa del Asado nació en medio de una situación compleja y con la intención de dar una respuesta al aumento de precios y la pérdida de poder adquisitivo de los salarios. La idea es compartir los datos de los comercios (carnicerías) en donde el producto se ofrece a menor precio para combatir la inflación.

… See full entry

Ok, eher Softporno, hab diesmal nicht alles durchgezählt, sonst hätt ich 3 Tage statt einen gebraucht.

In den letzten 4 Wochen wurden deutschlandweit 12.500 Objekte erstellt oder geändert die (zum heutigen Stand) Öffnungszeiten beinhalten. Das ist recht dehnbar, aufgrund solch diffuser Daten ne Statistik zu bauen (wenn wer ne vernünftige Overpass-abfrage parat hat, wo opening_hours hinzukamen, nur her damit), ich versuchs trotzdem:

Da ich etwa einmal monatlich opening_hours korrigiere, kann ich grob übern Daumen abschätzen, dass bei den (“neuen”) Objekten etwa 50-80% dabei sind, wo die Öffnungszeiten wirklich neu sind. Bei sage und schreibe 460 Warnungen und Fehlern hab ich ein wenig das Gefühl, dass die Sensibilität endlich etwas steigt und das Abkippen von Phantasie- und “aus-dem-Bauch”-Murx stark abgenommen hat. (Ok, 460 neue Fehler in 4 Wochen ist kein Pappenstiel, das sind etwa 2-5% Abfall aber naja…)

Was wollte ich?

Achja, grobe Fehlerverteilung frei aus dem Kopf und völlig unwissenschaftlich unstatistisch:

• 40% falsche Wochentage
• 10% falsch gesetzte Komma oder Semikoli
• 20% fehlende Komma oder Semikoli
• 2% Verwendung von Komma statt Semikolon (in aller Regel korrekt und sinnvoll renderbar aber schematisch falsch)
• 10% Verwendung komischer Zeichen wie langen oder anderen exotischen Bindestrichen etc.
• 5% Verwendung von Klartext a la: “Küchenzeiten” oder “Auf Anfrage” etc.
• 2% vertan im Tag a la website (opening_hours=www.example.org) oder Strasse etc.
• diverse andere

Nach Korrektur aller Werte bleiben etwa 2-5% übrig, die inhaltlich und schematisch korrekt sind, aber nicht “schön”. also 9:00 statt 09:00.

In den Monaten November und Dezember war ich ziemlich untätig bzgl. meiner Auswertungen. Im Januar habe ich wieder mehr Zeit investiert und einiges produktiv gestellt, das ich hier grob darstellen möchte.

Neu: Prüfung der Distanz zwischen OSM-Hausnummern und offiziellen Geokoordinaten

Direkt erstmal der große Dämpfer in Deutschland: es gibt nur wenige Gemeinden, die Hausnummerlisten mit Geokoordinaten zur freien Nutzung bereitgestellt haben. Nur dann ist die folgende Funktion verfügbar, z.B. in Berlin, Köln, Würzburg und Freiberg. Für die ganzen sächsischen Gemeinden werde ich die Funktion demnächst aktivieren.

Bei den entsprechenden Gemeinden gibt es auf der Auswertungsseite den zusätzlichen Link “vergleichen mit offiziellen Geokoordinaten” (siehe z.B. Freiberg). Es wird dann eine zweiteilige Seite angezeigt, auf der links die Hausnummern mit den größten Distanzen zwischen der OSM-Position und der offiziellen Position aufgelistet werden. Nach dem Klick auf den Link “Karte” werden Soll- und OSM-Ist-Position rechts auf der Karte angezeigt, mit Klick auf “Josm” wird der Bereich im Editor geöffnet.

Distanzen von mehr als 50m können, müssen aber nicht, auf echte Fehler hinweisen. Meist ist dann bei der OSM Adresse die falsche Straße angegeben, oder die offizielle Koordinate ist räumlich nahe an der Straße, während die OSM-Adresse an einem Gebäude auf dem Grundstück (z.B. in einem Schrebergarten) angegeben ist.

Ich hoffe, diese Auswertung hilft, den einen oder anderen Fehler zu finden. Die Funktionalität wurde vom OSM-User malenki angeregt, vielen Dank dafür!

Kleine Verbesserungen

… See full entry

… Kotzt mich an.

Für einen Englisch-Muttersprachler mag sich das vielleicht aus dem Zusammenhang erschliessen, mir nicht, und etlichen anderen offenbar auch nicht. Ich finde die Benamsung denkbar ungünstig. Dict.cc meint bspw. auch “housing terrace” oder “terrace houses”. Klingt mir sinniger. Oder meinetwegen terrace_row.

Ich hab mich grad auf buildings spezialisiert (bzw. überlappende korrigieren) und da stoss ich ständig auf “Terrassen”. Richtig, so ne Aussenterrasse am Einfamilienhäusschen mit Wintergarten meist.

Nunja, jetzt hab ich mal ne manuelle Auswertung (für Thüringen) gemacht, um mir ein Bild zu machen.

Es gibt in Thüringen 784 ways mit building=terrace, davon sind 5 Stück “falsche” Terrassen. Ja, ich reg mich schon wieder ab, ich hab ein Brett vorm Kopf, es is alles gar nicht so schlimm.

Sondern! viel! schlimmer!

Wenn man sich das Tag etwas schönredet und nicht alles auf die Goldwaage legt, findet man 75 Gebäude, die halbwegs ins Schema passen, bleiben nach Adam Riese um die 600 Gebäude übrig, die falsch getaggt sind. Bei den 600 sind recht viele zusammenhängende (terrace) Einzelgebäude einzeln als terrace gemappt:

… See full entry

Nach Jahren wieder mal in OSM. In meiner Stadt ist ja schon alles gemapped… Vielleicht finde ich mal ne Kleinigkeit, die man noch ergänzen könnte… Ansonsten weiterhin mit Moped unterwegs…

Nun also Testbetrieb - das ging aus dem Pressebericht aber nicht ganz so hervor…

Es sieht stark nach einem aufgebohrten Google Maps aus, da ja Google Maps alle Grundfunktionalität von freimobil.com auch bietet. Hier hat man also eigene, fest definierte POIs - die eigenen Haltestellen und die Bahnhöfe - hinterlegt.

Dass man bei der VAG natürlich bei den Bussen der Meinung ist, man sei alleine im Stadtgebiet unterwegs, ist andererseits nun nicht ganz überraschend.

Probleme gibt es ganz offenkundig bei der Lokalisierung der Haltestellen im IG-Nord.

Das Routing erledigt dann natürlich die Google-Maps-Engine, vielleicht mit Ausnahme des ÖPNVs, da nur VAG und DB/BSB-Routen angeboten werden. Bei den Radwegen führt das zu den üblichen Problemen, weil das Radwegenetz in Google nicht aktuell ist. Andererseits fällt das in Freiburg nicht sonderlich auf, da die Radfahrer dort ja ohnehin fast überall unterwegs sind.

Aber dafür hab ich dem Graphhopper nun den FR2 beigebracht - jedenfalls im Südteil. Im Nordteil muss ich noch nachlegen. So hatte freimobil.com ja doch noch etwas Gutes :-)

1. Kapitel: Der Geograph

Der sechste Planet war zehnmal größer. Ihn bewohnte ein alter Mann, der gewaltige Bücher schrieb.

»Sieh an! Da kommt ein Entdecker!«, sagte er, als er den kleinen Prinzen zu Gesicht bekam.

Der kleine Prinz setzte sich auf einen Tisch und ruhte sich ein wenig aus. Er war schon so viel gereist!

»Wo kommst du her?«, wollte der alte Mann wissen.
»Was ist das für ein dickes Buch?«, sagte der kleine Prinz. Was machen Sie hier?
»Ich bin ein Geograph«, sagte der alte Mann.

»Was ist ein Geograph?«
»Das ist ein Gelehrter, der alle Meere, Flüsse, Städte, Berge und Wüsten kennt.«
»Das ist sehr interessant«, sagte der kleine Prinz. »Das ist endlich ein echter Beruf!«

Er warf einen Blick auf den Planeten des Geographen. Noch nie hatte er einen so majestätischen Planeten gesehen.

… See full entry

Dass Freiburg im Breisgau in puncto IT sich nicht gerade mit Ruhm bekleckert, hat sich ja schon mit der Entscheidung der Remigration zu Microsoft Office gezeigt. Die Freiburger Verkehrs AG steht dem natürlich in nichts nach.

Und so begab es sich, dass man den Internet-Auftritt “http://freimobil.com” kreierte. Google-Karte mit Googles Radwege-Routing und eventuell sogar Googles POIs.

Das Ergebnis spricht für sich.

Fürs Fahrradrouting in Freiburg empfehle ich das da zum Vergleich: https://www.komoot.de/plan/@47.9939425,7.8149700,14z oder, noch besser, das hier: http://map.bikecitizens.net/de-freiburg#/!/2/1/-,-/-,-

VAG halt, wie sie leibt und lebt - mehr kann man dazu nicht sagen. Eine nette Beta, aber irgendwie noch nicht richtig brauchbar.

Ein kleiner Nachtrag, da ich es nun in die Wochennotiz geschafft habe: Das Problem bei freimobil.com: Das Fahrradrouting mit Google Maps ist bekanntermaßen grottenschlecht. Aber das Fahrradrouting mit den Openstreetmap-Standardseiten ist leider auch nicht viel besser, trotz aktuellerer Radwege. Die oben genannten Radroutingseiten machen es aber besser. Warum aber graphhopper oder mapzen nur beim Fußgängerrouting den FR2 korrekt routen und sonst Straßen gegenüber explizit ausgewiesenen Radwegen bevorzugen, erschließt sich mir nicht.

Wie ein Testbericht in der Presse zeigte, waren aber auch andere Routing-Ergebnisse bei freimobil.com nicht sehr viel besser, da einige wichtige POIs nicht gefunden wurden, wie die Pädagogische Hochschule.

Und natürlich stellt sich mir die Frage, warum bei einem auf Freiburg bezogenen Dienst ein städtisches Unternehmen nicht auf Kartenmaterial des städtischen Vermessungsamtes zurückgreift oder des Garten- und Tiefbauamtes mit dessen sehr ambitionierten Plänen zum Ausbau des Radwegenetzes.

Das verstehe wer will. Ich nicht.

Nach einer Baumaßnahme hatte sich die St 2187 geändert. Hier wurde eine gefährliche S-Kurve herausgenommen und durch einen sehr leichten Bogen mit Leitplanken ersetzt. Zudem wurde der Höhenunterschied ausgeglichen.

Ich habe die Daten mit meinem Garmin GPS-Gerät erfasst und eingepflegt.

interessieren mich herzlich wenig.

Was mich aber interessiert, ist, wie das abenteuerliche Tagging zustande kommt, wo ich via QA immer wieder drüber stolpere:

Fahrstühle sind in aller Regel KEINE Gebäude. Steht im Wiki? Nein steht’s nicht, richtig lesen hilft:

Kartieren von Aufzügen in Gebäuden
Zeichne die Umrisse des Gebäudes und füge building=yes + elevator=yes hinzu.  

Na? Genau, das eigentliche Gebäude soll die Tags bekommen, nicht der Fahrstuhl. Soweit ich das mit meinen bescheidenen Englischkenntnissen richtig verstehe ist es im Proposal besser und eindeutiger beschrieben:

Elevators located within buildings could also be tagged as a property as building=* 
with elevator=yes if the specific location of the elevator(s) is unknown.

Badusch!

Was ich auch nicht raffe, sind mehrere Fahrstühle übereinander, vorzugsweise in Bahnhöfen (Leipzig bspw. oder Rostock). Josm wirft einen Fehler? Ah der kennt bestimmt noch keine Fahrstühle, schnell hochladen, vielleicht merkts keiner.

Gut, jetzt kann man vlt. einwenden, dass die “Bodenfläche” sich ja “gleichzeitig” auf jeder Etage befindet. Ja? Nein, die Bodenfläche befindet sich auch gleichzeitig NICHT auf jeder Etage.

Was ich von “highway” halte, weiss ich noch nicht genau, auch so ein Doppelding, aber davon erzähle ich ein anderes Mal.

Konsterniert ab.

Kann mir jemand erklären wie man die Karte der Schweiz auf mein Garmin GPSmap st Navi lädt?

Einführung

Daten eintragen ist das eine, was Apps daraus machen, das andere.

In letzter Zeit teste ich vermehrt mit Osmand und Magic Earth. Osmand wird monatlich aktualisiert, Magic Earth wohl so aller 2-3 Monate. Von daher hat man immer eine recht aktuelle Datenbasis.

Für mein Verständnis haben die Apps für den Normalo 2 Hauptfunktionen:

• POI-Suche
• Navigation

Die weiteren Funktionen sind für den Normalo teilweise uninteressant, dafür für den Mapper umso wichtiger.

Tags und Probleme in OSM

## POI Die POI-Suche nach Namen ist teilweise bisschen hakelig, da keine Fehler zugelassen werden, da kann aber OSM nichts dafür. Die allgemeine Suche nach POI funktioniert dafür gut. Interessant ist die Funktion in Magic Earth POI als Kontakt im Telefonbuch abzulegen. Es zeigt sich dann, wie wichtig es ist, dass bei einem POI alle Daten angeheftet sind, d.h. auch Adresse usw. an jedem POI heftet, damit es dann auch in den Kontakten landet. Bei beiden Apps kann man die Website des POI direkt aufrufen, ebenfalls sehr gelungen. Was nur bei Osmand funktioniert: Auswertung der Öffnungszeiten, Aufruf weiterer Kontaktmöglichkeiten (twitter, facebook usw.) - alles in allem auch sehr komfortabel, wenn man unterwegs ist (muss dann natürlich eingetragen sein). ## Navigation im Simulationsmodus Osmand und Magic Earth bieten beide einen Simulationsmodus für die Navigation. So kann man sich in Ruhe anschauen, was die Apps aus den Daten machen.

Aufgefallen ist mir folgendes:

… See full entry

Zusammenfassung

Über die OSM-User Nakaner und malenki (vielen Dank an Beide!) habe ich am Freitag die sächsische Mitteilung über die Veröffentlichung von vier Datensätzen gefunden. Den Datensatz über die 932.727 amtlichen Adressen in Sachsen habe ich mit einigen Nacharbeiten gestern importiert und eine erste landesweite Auswertung (grafisch, tabellarisch) durchgeführt.

Lizenzrechtliches

Die Lizenz ist Deutschland 2.0 mit Namensnennung und leider die Daten wegen der notwendigen Namensnennung nicht für uns direkt in OSM nutzbar. Ein informierter OSM-Kollege wird aber nachhaken, ob wir eine extra Freigabe für OSM bekommen können.

Für meine Auswertung reicht die Lizenz aus, weil ich auf der Auswertungsseite jeder Gemeinde die Lizenzangaben aufführe. Die Geokoordinaten sind zwar in der Auswertungsdatenbank gespeichert, derzeit aber auf der Website nicht verfügbar, um einen Mißbrauch in OSM zu verhindern.

Nacharbeiten zur Datenquelle

Zur Auswertung des Adress-Datensatzes musste ich noch zwei Anpassungen vornehmen:

• Inverse Geokodierung: von der Geokoordinate einer Adresse habe ich die Gemeinde und den Gemeindeschlüssel in OSM geholt. Eigentlich ist bei jeder Adresse der ORT angegeben, der Wert ist aber bei ländlichen Gemeinden der Ortsteil, ein Siedlungsname oder ähnliches.

• Nach der inversen Geokodierung traten 41 Adressen auf, die mit ihren Geokoordindaten außerhalb der sächsischen Landesgrenze lagen. Mit der Angabe in ORT konnte die richtige Gemeinde zugeordnet werden. Ob der Grenzverlauf ungenau ist oder die Adressen gültig sind, obwohl sie außerhalb der Gemeinde und des Landes liegen, habe ich nicht geklärt (dürfte eher vor Ort herauszufinden sein). Tabelle mit den besonderen Adressen.

Import und ignorierte Hausnummerlisten

… See full entry

Moin !

seit längerer Zeit bin ich Verfechter die Daten in OSM zu prüfen und entsprechend zu kennzeichnen. Es gab hierzu auch mehrere diskussionen. Bis heute habe ich immer lastcheck verwendet.

Gestern ist mir erst bewußt bekannt geworden, dass es auch schon check_date gibt welches im Wiki schon dokumentiert ist (osm.wiki/Key:check_date) und auch von der Syntax besser zu start_data, end_date …. entspricht.

Deshalb werde ich künftig dieses verwenden und soweit es mir möglich war habe ich meine Tags geändert.

Ich poste dieses um auch entsprechend Werbung für die QA zu machen.

gruß Jan

i future i will use check_date instead of lastcheck!!!

regards Jan

Einleitung

Zuletzt habe ich in OSM markante POI mit verschiedenen Social-Media-Tags ergänzt. Dass diese sinnvoll sein können, zeigen Apps wie Osmand und Magic Earth die z.B. Telefonnummer, Website auswerten und Osmand auch andere Tags wie contact:facebook auswertet und innerhalb der App verlinkt. Im mobilen Einsatz ist es sehr bequem, wenn diese Tags gesetzt sind, da viele Handys appbasiert am effektivsten arbeiten.

Nun ist es ja bekanntlich so, dass viele Geschäfte inzwischen nur noch eine Facebook-Website besitzen, also kommt man um facebook ohnehin nicht umhin. Andere Tags wie twitter, youtube oder alle sonstigen wie vimeo, pinterest oder instagram habe ich gleich mitgesetzt. ## Status quo Während ich in Magic Earth nach POI wie “Flughafen Dresden” suchte, sah ich, dass dieser nur absolut stiefmütterliche Tags besitzt, nicht einmal eine postalische Adresse. Auch andere Gebäude haben durch das Taggen der Nummer auf den Eingang nicht einmal eine postalische Adresse. Die Datenqualität in OSM kann nur als dürftig beschrieben werden.

Klar kann sich nun der OSM-Mapper hinsetzen, aber das kann ja nicht Sinn der Sache sein tausende POI händisch nach Updates zu untersuchen. Bei unserem Konkurrenten google ist es z.B. so, dass jeder User die Fehler in den Daten melden kann. Bei OSM ist das nur über openstreetbugs möglich. Aber sein wir ehrlich: openstreetbugs ist nur für Leute gedacht, die überhaupt verstanden haben was OSM ist, nicht für App-Benutzer, die vielleicht gar nicht wissen, was OSM ist. Bereits das Beispiel MapDust von skobbler zeigte, wie die Nutzer mit unsinnigen Fehlermeldungen das System fluten können. # Anforderungen Was braucht OSM also? Unter höchstmöglicher Produktivität stelle ich mir das folgendermaßen vor: OSM erstellt eine Bug-API die alle Apps nutzen können. Der User kann dann in der App jegliche Tags, z.B. das Feld “Website” oder “contact:facebook” usw. als fehlerhaft melden. Dann hat er verschiedene Meldegründe:

… See full entry