OpenStreetMap

Nakaner's diary

Recent diary entries

Schwäbisch für Babel m OSM-Wiki

Posted by Nakaner on 29 September 2014 in German (Deutsch)

Heut Oabend hats me in d Finger gjuckt. Jedes Moal, wenn i uf mei Benutzerseita im Wiki guck, denk i, da fehlt doch ebbes. Da stoat "DE-4, EN-3", abber was isch mit deiner Mudderspoach? Ja, fürs Schwäbische hat s bisher im OSM-Wiki noch kein Vorlag gebba. Hat halt no koiner gmacht.

Aber jetzt gibt s oine. Wer Schwäbisch spricht oder versteht, kâ jetzt in sei Benutzerseita oina von de folgende Vorlaga eibinda:

  • Bei Mudderschproachler wird des azeigt.
  • Bei Leid die fast so guat wie Muddersproachler Schwäbisch schwätza, wird des azeigt.
  • Die übrige Stufe 3, 2 und 1.
  • (kam mr hier weglassa) :-)

Wenn ihr in eurer Benutzerseita scho Babel nutza dehnd und es so aussieht, wie bei mir bis heut Oabend

{{Babel|de-4|en-3}}

Wenn ihr Mutterschproachler seid, dann ergänzet des oifach zu

{{Babel|swg|de-4|en-3}}

Ansonschta

{{Babel|swg-4|de-4|en-3}}

oder swg-3, swg-2, …, je nach dem auf was vor m Nivo ihr Schwäbisch verschtehât.

Mei Benutzerseita im OSM-Wiki (bloß uf Englisch und Hochdeitsch)

Für die viele Schreibfähler bitt i eich um Vergäbung. S letschte Moal Schwäbisch han e im Abibuch gschrieba, wo e Sprüch von Schüler und Lehrer ufgschrieba han. Wenn ihr des da oba ganz andersch gschriebe hättet, kann s sei, dass ihr oifach z weit von mr weg wohnat.

Im OSM-Wiki kann man nun auf seiner Benutzerseite angeben, dass bzw. wie gut man Schwäbisch versteht. Bisher gab es im OSM-Wiki dazu keine Vorlage, aber ich habe sie heute Abend angelegt. Die Vorlagen sehen wie folgt aus:

Wenn ihr auf eurer Benutzerseite schon Babel zur Anzeige der Sprachkenntnisse benutzt, dann dürfte etwas ähnlich folgendem Codeschnipsel auf eurer Benutzerseite zu finden sein

    {{Babel|de-4|en-3}}

Wenn ihr Muttersprachler seid, dann ergänzt das einfach zu

{{Babel|swg|de-4|en-3}}

oder swg-3, swg-2, …, je nach dem auf welchem Niveau ihr Schwäbisch versteht.

Meine Benutzerseite im OSM-Wiki

Verkehrszeichenzählung in Bayern

Posted by Nakaner on 21 July 2014 in German (Deutsch)

Laut dem Twitteraccount von Skobbler soll in Bayern der Schilderwald gelichtet werden. Na gut, habe ich mir gedacht, warum zählen wir nicht mal selber, was denn schon alles gemappt ist. Dazu gibt es die Overpass-API und den Overpass-Turbo als GUI dazu. Die Abfrage war folgende:

node(area:3602145268)["traffic_sign"]; out meta;

Das Ergebnis waren gerade eben 17082 Nodes. Als Ways gemappte Schilder (wozu eigentlich) habe ich nicht gezählt, da diese meistens zur Dokumentation der Access-Beschränkungen verwendet werden, wie es das Verkehrszeichen-Tool vorschlägt.

Das ist der Link zur Abfrage. Ich rate davon ab, auf "Ausführen" zu klicken, da die Abfrage ein Weilchen dauert und 3 MB Daten liefert. Das ist für manchen schwachen Rechner vielleicht zu viel.

Kleinere Gebiete kann man jedoch schon abfragen, z.B. das Stadtgebiet von München. Dazu trägt man einfach die ID der Boundary-Relation addiert um 3600000000 ein. Diese ID bekommt man, indem man auf osm.org nach dem gewünschten Gebiet sucht. Das wäre die Abfrage für München (178 Schilder):

node(area:3600062428)["traffic_sign"]; out meta;

OpenRailwayMap-Mappingwochende 1

Posted by Nakaner on 14 July 2014 in German (Deutsch)

Vom Freitag, den 11. bis Sonntag, den 13. Juli 2014 fand in Köln das erste OpenRailwayMap-Mappingwochenende (mit Taggingdiskussion) statt. Es diente dem Austausch der Eisenbahnmapper und der Diskussion über Ergänzungen und Veränderungen am Eisenbahn-Taggingschema. Mit Emrah Kutlu war auch ein Vertreter von Mentz DV dabei.

Der Freitagabend begann locker im Lokal K in Köln-Ehrenfeld mit dem Eintrudeln und einer Vorstellungsrunde der Teilnehmer. Wir redeten über die Öffentlichkeitsarbeit der OpenRailwayMap und der Gewinnung neuer Mapper (insbesondere von bahninteressierten Nichtmappern als Bahnmapper). Im Anschluss stellte jeder seine Mappingtechniken vor.

Der Samstagvormittag begann mit dem Frühstück im Lokal K, welches in eine Vorstellung von Mentz DV und deren Nutzung von OSM-Daten überging. Wir erkannten, dass manches, was man bisher eher aus Spaß mappte, doch sinnvoll war. Emrah klärte darüber auf, dass auch das Mappen von Sitzbänken sinnvoll ist. Es ermöglicht ein besseres Routing im Rollator-Modus, wo die Existenz von Sitzbänken zum Ausruhen die Routenfindung beeinflusst.

Als er diverse Eisenbahnroutingfehler vorstellte, erklärten wir ihm die Tags service=*, usage=* und maxspeed=*. Wir erkannten den Bedarf des Einführens eines Tags für die Regelfahrtrichtung. Die Regelfahrtrichtung ist die Richtung, in die ein Gleis normalerweise befahren wird (bei zweigleisigen Strecken in Deutschland in der Regel das rechte Gleis in Fahrtrichtung). Wenn auf einer zweigleisigen Strecke vor und nach einer Kurve die Möglichkeit besteht, das Gleis zu wechseln, so könnte ein Router über das kurveninnere Gleis routen, auch wenn das das Gegengleis ist und mit dieser Fahrt andere Zugfahrten blockiert werden würden. Deshalb werden Gegengleisfahrten in der Praxis in der Regel nicht geplant.

Am Samstagnachmittag unterbrachen wir die Diskussionen und gingen, wie es der Name der Veranstaltung sagte, mappen. Von Köln West aus fuhren Consti, Alex, Michael und Emrah nach Euskirchen. Emrah verlies die Gruppe dort und fuhr zwecks Heimreise zum Flughafen, der Rest fuhr weiter nach Bad Münstereifel und über Euskirchen wieder zurück nach Köln. Zwei Mapper spazierten von Köln West über die Südbrücke und die Hohenzollernbrücke zum Hauptbahnhof.

Die Fahrt von Köln nach Euskirchen fand in einem Dieseltriebwagen der Baureihe 628 der Südostbayernbahn statt. Mangels GPS-Empfang (außer direkt an der Tür und am Faltenbalg) wurde reines Video- und Fotomapping ohne Georeferenzierung betrieben, auch wenn die Strecke ab Hürth-Kalscheuren nicht elektrifiziert ist. In Euskirchen stiegen wir in die Regionalbahn nach Bad Münstereifel um. Die Strecke nach Bad Münstereifel ist eine nicht elektrifizierte Nebenbahn. In Bad Münstereifel blieben wir sitzen und fuhren mit demselben Zug zurück nach Euskirchen. Diese Fahrt fand in einem Diesel-Talent (Baureihe 644/944 und 643.2) statt, in dem überall sehr guter GPS-Empfang bestand. So war es möglich, georeferenzierte Fotos aufzunehmen. Alex fotografierte fast jedes Signal und Consti ging seiner Leidenschaft nach – Fahrscheinautomaten samt Automatennummer für seine Fahrkartenautomatenkarte. Beim Wenden in Bad Münstereifel lies der Triebfahrzeugführer freundlicherweise den Vorhang zum Führerstand offen, sodass wir nach hinten durch den Führerstand fotografieren konnten.

In Euskirchen nahmen wir nicht den RE, sondern die 30 Minuten später fahrende RB nach Köln. In der Zwischenzeit fotomappten wir den Bahnhof und seinen Vorplatz. Alex fotografierte mit einem 70–300 mm-Teleobjektiv vor allem Signale, Signalnummern und entfernt liegende Objekte im Gleisvorfeld, während ich mit einem 18–105-mm-Objektiv Übersichtsfotos erstellte. Auch das Bahnhofsgebäude und der Vorplatz wurden gemappt. Zum Leidwesen von Consti hatten die zwei Automaten der Stadtwerke im Busbahnhof keine Nummer.

Der Bahnhof Euskirchen bekommt gerade neue Ks-Signale und ein Elektronisches Stellwerk (EStW). Die neuen Signale sind noch nicht alle aufgestellt, die schon aufgestellten, sind noch mit Ungültigkeitskreuzen gekennzeichnet. Wir werden nur die neuen Signale in OSM eintragen, da die alten nicht mehr lange stehen werden. Die Ergebnisse der Mappingtour in die Eifel sind derzeit noch nicht in OpenStreetMap eingetragen. Das folgt noch. Nach der Ankunft im Lokal K fuhren wir mit den Taggingdiskussionen fort. Die Ergebnisse können dem Protokoll entnommen werden. Gegen 20:00 Uhr stieß mit jotpe ein lokaler Mapper hinzu. Kurz nach Mitternacht beendeten wir die Taggingdiskussionen und fuhren in die Ferienwohnung ins Belgische Viertel.

Consti und Peter reisten am nächsten Morgen direkt von der Ferienwohnung aus ab, Alex und Michael fuhren wieder ins Lokal K, wo sie auf spth aus dem Raum Frankfurt (Main) trafen. Zu dritt arbeiteten wir einen Großteil der Taggingdiskussionsthemen ab. Hervorzuheben ist hier die ORM-Meinung zum Mappen von Bahnhöfen als Fläche. Wir entschieden uns für die Umstellung diverser Eisenbahninfrastruktur-Tags, die derzeit noch kaum verwendet werden und deren Key- oder Valuewahl sehr ungünstig war.

Die Taggindiskussionen gingen dann noch bis etwa halb Sechs am Abend.

Das ausführliche Protokoll ist im OSM-Wiki zu finden.

Das Lokal K ist unserer Ansicht nach ein für solche Treffen geeignete Örtlichkeit. Wir bedanken uns hiermit bei den Kölner Wikipedianern für die Gastfreundschaft und empfehlen es hiermit weiter. Wenn es eine Dusche hätte, könnte man sogar dort übernachten.

Es ist geplant ein zweites Treffen zu veranstalten, um noch offene Fragen zu klären. Dieses Treffen wird vermutlich etwas zentraler in Deutschland oder im Raum Frankfurt am Main stattfinden.

Location: Ehrenfeld, Köln, Regierungsbezirk Köln, Nordrhein-Westfalen, 50667-51149, Deutschland, Europäische Union

Wie gut sind die Öffnungszeiten in meinem "Revier" erfasst?

Posted by Nakaner on 14 February 2014 in German (Deutsch)

Viele Mapper sind bestrebt die nähere Umgebung um das eigene Heim, möglichst gut zu erfassen. Auch ich bin so. Doch einer Frage wollte ich auf den Grund gehen: Wie gut sind die Öffnungszeiten erfasst?

Öffnungszeiten sind etwas, was man mal so nebenbei erfassen kann. Wenn man irgendwo hin laufen oder Rad fahren möchte, kann man, ausreichend Zeit vorausgesetzt, Zwischenstops einlegen und dabei die Öffnungszeiten von Ladengeschäften und Gastronomiebetrieben erfassen.

Ich habe mich jetzt mal eine Stunde hingesetzt und mich intensiver mit der Overpass-API und den MapCSS-Fähigkeiten des Overpass-Turbo auseinander gesetzt. Möchte man für einen kleineren Bereich die Öffnungszeiten-Abdeckung grafisch darstellen, so genügt folgender Code:

<osm-script>
    <union>
        <query type="node">
            <has-kv k="shop"/>  <bbox-query {{bbox}}/>
        </query>
        <query type="way">
            <has-kv k="shop"/>  <bbox-query {{bbox}}/>
        </query>
        <query type="node">
            <has-kv k="amenity" regv="^(restaurant|pub|bar|fast_food|food_court|ice_cream|cafe)$"/>  <bbox-query {{bbox}}/>
        </query>
        <query type="way">
            <has-kv k="amenity" regv="^(restaurant|pub|bar|fast_food|food_court|ice_cream|cafe)$"/>  <bbox-query {{bbox}}/>
        </query>
        <recurse type="way-node" />
    </union>
    <print/>
</osm-script>

{{style:

    node[opening_hours!=.],way[opening_hours!=.]
        { color:red; fill-color:red }

    node[opening_hours],way[opening_hours]
        { color:blue; fill-color:blue; }

}}

Beispiel-Abfrage aus Karlsruhe

Hat ein POI Öffnungszeiten, ist er blau, andernfalls rot. Ob die Öffnungszeiten-Syntax eingehalten wurde, wird nicht geprüft.

Der obere Teil der Abfrage (osm-script) fragt die Objekte von der Overpass-API ab, der untere Teil rendert sie entsprechend.

Dieser Blogpost basiert auf einem Blogpost von tyr_asd.

EDIT: Overpass-Abfrage korrigiert und Link auf korrgierte Abfrage eingefügt.

Wo sind die über 110 Überwachungskameras in Düsseldorf?

Posted by Nakaner on 13 January 2014 in German (Deutsch)

Die Verbrauchersendung Markt im WDR-Fernsehen (montags 21:00 Uhr) wurde heute gezählt, wie oft das Kamerateam bei einem Bummel durch die Düsseldorfer Innenstadt gefilmt wurde. Fazit mindestens 110 mal. (Nachzulesen im Transkript der Beitrags im letzten Absatz)

Diese Zahl hat mich neugierig gemacht und ich habe mal die Overpass-API befragt (via [Overpass-Turbo(http://overpass-turbo.eu/)). Mit folgender Abfrage kam ich nur zu einem enttäuschenden Ergebnis – nur 12 Nodes mit man_made=surveillance. Dabei habe ich gleich auch noch nach Ways gesucht, die mit man_made=surveillance getaggt sind:

node(area:3600062539)["man_made"="surveillance"]; out meta; way(area:3600062539)["shop"="supermarket"]; out meta;

Abfrageergebnis (dem Link folgen, auf Ausführen klicken und ein Weilchen warten)

Nur mal zum Vergleich: Der Erzfeind Köln (Relations-ID 62578) hat hat 51 Nodes und 1 Way mit man_made=surveillance, das ergibt somit ca. 20.000 Einwohner pro Kamera. (Düsseldorf hat 49.500 Einwohner pro Kamera) Deutlich besser sieht es in Karlsruhe aus, dort sind 81 Nodes mit man_made=surveillance eingetragen, das ergibt "nur" 3650 Einwohner pro Kamera.

Eines muss man jedoch beim OSM-basierten Kamerazählen beachten. Wenn in einem Ladengeschäft mehrere Kameras hängen, wird diese Information meist nur an den Node bzw. den Way, der das Geschäft repräsentiert getaggt. Hinter einem shop=supermarket, man_made=surveillance, surveillance=indoor kann sich also auch ein Dutzend Kameras verstecken.

Mein persönliches Fazit meiner Overpass-API-Abfrage ist, dass ich künftig in jedem Ladengeschäft, das ich betrete, einen Blick nach oben werfe. Daheim oder schon unterwegs mit Vespucci auf meinem Android-Smartphone werde ich dann meine Erkenntnis in OpenStreetMap eintragen. Nachdem ich jetzt langsam bei alle Ladengeschäfte in meiner Umgebung die Öffnungszeiten erfasst habe, muss ich mich beim Einkaufen ja irgendwie beschäftigen. :)

Übrigens, mein Dank geht an Roland Olbricht für dieses tolle Abfragetool und User a_peter für die Erklärung, wie man innerhalb einer Grenzrelation abfragt.

Location: Stadtmitte, Stadtbezirk 1, Düsseldorf, Regierungsbezirk Düsseldorf, Nordrhein-Westfalen, Deutschland, Europäische Union

Bahnhofsmapping – ein Lückenfüller

Posted by Nakaner on 7 April 2013 in German (Deutsch)

"Folgende Anschlusszüge können leider nicht warten …", meistens erzeugt dieser Satz Frust und häufig eine lange Wartezeit auf den nächsten Zug. Doch diese Wartezeit kann man, nachdem man sich ein Fahrgastrechteformular besorgt hat, sinnvoll für OSM nutzen. Bahnhöfe (vor allem Hauptbahnhöfe, nicht die Haltepunkte mitten in der Pampa) sind meistens voller POIs und ein Paradies für Detailmapper. Außerdem kann man fast ohne Vorbereitung (ein Blick mit dem Smartphone auf openstreetmap.org bzw. in OsmAnd) loslegen. Bahnhofsmapping kann man in drei Teile aufteilen:

Teil 1: Verkehrswege

In den meisten Umsteigebahnhöfen sind zwar schon alle Bahnsteige und die dazu gehörigen Gleise erfasst, aber an den Fußwegen, insbesonder im Bahnhofsgebäude findet man bestimmt noch etwas zum Mappen. Hierzu zu nimmt man einfach ein Blatt Papier oder einen Notizblock und skizziert den Grundriss der Bahnhofshalle und die Bahnsteigzugänge. Später kann man dann am Notebook mit JOSM die erfassten Informationen ins Indoor-Mapping-Schema pressen. Wichtige Tags habe ich am Ende dieses Blogpost zusammengestellt.

Teil 2: POIs/Ladengeschäfte

Die Skizzen aus Teil 1 kann man anschließend mit sichtbaren allen POIs füllen. In einem Bahnhof gibt es viele mappbare Dinge: Läden, Telefonzellen, Verkaufs-/Fahrscheinautomaten, Fahrkartenschalter, Sitzbänke. Bei Ladengeschäften kann man auch noch gleich die Öffnungszeiten eintragen. Gebräuchliche Tags habe ich am Ende dieses Blogpost gesammelt.

Zwei Ebenen hat fast jeder Bahnhof. Die Bahnsteighalle und die Bahnsteige bilden meist die eine Ebene, darunter bzw. darüber gibt es oft noch eine Unter- oder Überführung, in welcher sich auch noch mehr oder weniger viele Läden befinden.

Teil 3: Bahnsteigdetailmapping

Ein Bahnsteig ist nicht nur einfach ein Bahnsteig. Meistens hat er noch ein Dach oder Unterstände für die Reisenden, dazu kommen noch Sitzbänke, Mülleimer, Fahrscheinautomaten (bei S-Bahn-Stationen und kleineren Bahnhöfen) usw. Hier kann man sich als Detailmapper richtig austoben. Auch hierfür habe ich gebräuchliche Tags gesammelt.

Der Vorteil des Bahnsteigdetailmapping ist, dass man dazu auch auf dem Nachbarbahnsteig stehen kann und so seinen Zug nicht so leicht verpasst.

Zeitbedarf

Abhängig von der Bahnhofsgröße und Wartezeit kann man meistens nicht alles erfassen. Ich habe mit Bahnhofsmapping mal Wartezeiten in Dessau Hbf, Würzburg Hbf und Heilbronn Hbf überbrückt. Die drei sind mittelkleine Hauptbahnhöfe (7 bis 11 Gleise, eine Unterführung, eine Bahnhofshalle). In Heilbronn habe ich für Bahnsteighalle, POIs und Bahnsteigmapping etwa 40 Minuten benötigt.

Wo gibt es noch etwas zu tun?

Ich habe nach dem Zufallsprinzip mir einfach ein paar Bahnhöfe ausgesucht und die verbesserungswürdigen aufgelistet:

  • Frankfurt (Main) Hbf: Ladengeschäfe in Prellbocknähe, Bahnsteigzugänge, Bahnsteigdetailmapping
  • Köln Hbf: Ladengeschäfte, Bahnsteigzugänge, Bahnsteigdetailmapping
  • Dortmund Hbf: Ladengeschäfte, Bahnsteigdetailmapping
  • München Hbf: Ladengeschäfte, Bahnsteigdetailmapping
  • Uelzen: Bahnsteige (derzeit nur teilweise vorhanden), Bahnsteigzugänge, Ladengeschäfte
  • Memmingen: Bahnsteigzugänge, Ladengeschäfte, Bahnsteigdetailmapping
  • Singen (Hohentwiel): Bahnsteigzugänge, Ladengeschäfte, Bahnsteigdetailmapping
  • Köthen: Bahnsteigzugänge, Ladengeschäfte, Bahnsteigdetailmapping

Meine Fazit ist, dass man selbst in ganz großen Verkehrsknoten (z.B. Frankfurt (Main) Hbf) noch einiges tun kann.

Vorbilder für das Bahnhofsmapping gibt es natürlich auch:

  • Hannover Hbf (sehr viele Ladengeschäfte vorhanden)
  • Stuttgart Hbf (nur DB-Teil, Aktualität wegen Stuttgart 21?)
  • Würzburg Hbf (nur Bahnhofshalle und Bahnsteigzugänge)
  • Heilbronn Hbf (Ladengeschäfte, Bahnsteigzugänge, Bahnsteigdetailmapping)
  • Dessau Hbf (Ladengeschäfte, Bahnsteigzugänge)

Tagsammlung

Die Zuordnung zu Stockwerken kann mit layer=* und im Gebäude mit level=* erfolgen. Für Öffnungszeiten gibt es den Schlüssel opening_hours=*. Die Syntax muss unbedingt eingehalten werden!

Bei fast allen Objekten außer Treppen und Rolltreppen kann man auch noch die Rollstuhltauglichkeit erfassen (wheelchair=yes/no).

Bahnsteig

  • Bahnsteig: public_transport=platform railway=platform rail=yes ref=(Gleisnummer) wheelchair=yes/no, ggf. area=yes
  • Sitzbank: amenity=bench
  • Mülleimer: amenity=waste_basket
  • Bahnsteigüberdachung: building=roof (ggf. 3D-Tagging)
  • Unterstand: amenity=shelter shelter_type=public_transport, ggf. building=yes und 3D-Tagging
  • Videoüberwachung: man_made=surveillance surveillance=outdoor/indoor/public
  • Snack-/Getränkeautomat: amenity=vending_machine vending=food/drinks

Bahnsteigzugang

  • Treppe: highway=steps incline=up/down step_count=(Stufenzahl)
  • Aufzug: highway=elevator (auf Node)
  • Rolltreppe (mit Stufen): highway=steps conveying=yes/forward/backward/reversible incline=up/down
  • Laufband (Rolltreppe ohne Stufen): highway=footway conveying=yes/forward/backward/reversible incline=up/down
  • Unterführung: highway=footway layer=-1 tunnel=passage level=(Stockwerksnummer, z.B. -1 oder 0) lit=yes/no passage_type=T01/T02/...
  • Überführung: highway=footway layer=1 bridge=yes level=(Stockwerksnummer, z.B. 1 oder 0) lit=yes/no
  • ebenerdiger Zugang: railway=crossing (auf Node)

Bahnhofshalle

  • Haupteingang: entrance=main (auf Node)
  • anderer Eingang: entrance=yes (auf Node)
  • Telefonzelle: amenity=telephone operator=Deutsche Telekom ref=(Nummer, steht auf dem Telefon) payment:coins=yes/no payment:telephone_cards=yes/no
  • Fahrkartenautomat: amenity=vending_machine operator=Deutsche Bahn payment:coins=yes payment:notes=yes payment:electronic_purses=yes payment:debit_cards=yes vending=public_transport_tickets
  • Fahrkartenschalter/Reisezentrum: shop=ticket operator=Deutsche Bahn name=Reisezentrum opening_hours=(Öffnungszeiten)
  • Blumenladen: shop=florist
  • Bäcker: shop=bakery
  • Zeitschriften/Kiosk: shop=kiosk
  • Fast-Food: amenity=fast_food cuisine=burger
  • Manche Läden kann man schwer einer Kategorie zuordnen, z.B. Le Crobag. Ich denke amenity=cafe passt am besten.
  • Bahnhofsminisupermarkt: shop=convenience name=Yorma's
  • Toiletten: amenity=toilets fee=yes/no wheelchair=yes/no opening_hours=* operator=*
  • Schließfächer: Hierfür gibt es noch kein Tag. Laut Taginfo wird amenity=lockbox achtmal verwendet, dazu fee=yes operator=*
  • Restaurant: amenity=restaurant cuisine=german/burger/... smoking=no/dedicated/...

EDIT: Rolltreppen ergänzt, richtiges Tag für Schließfächer (amenity=lockbox statt amentiy=lockers) und wheelchair=* ergänzt

Vier Verfahren zum Adressmapping im Vergleich

Posted by Nakaner on 19 March 2013 in German (Deutsch)

Nachdem ich vor etwa einem Monat von meinen Erfahrungen vom Adressmapping mit dem Auto berichtet habe, bin ich von User Markus59 auf die Android-App Keypad-Mapper 3 hingewiesen worden. Den Hinweis habe ich zum Anlass genommen, mal drei gebräuchlichsten Adressmappingverfahren und Keypad-Mapper 3 einem gemeinsamen Test zu unterziehen. Folgende Techniken werden verglichen:

  1. GPS-basiertes Verfahren
  2. Walking Papers mit Cadastre Style
  3. Keypad-Mapper 3
  4. Audiomapping

Die Aufnahme georeferenzierter Fotos habe nicht in Betracht gezogen, da das andauernde Fotografieren von Häusern als Fußgänger Anwohner vermutlich zum Ansprechen des Mappers verleiten würde, selbst wenn man eine Warnweste mit dem Aufdruck "VERMESSUNG" tragen würde.

Das Testgebiet

Den Test habe ich im Dessauer Stadtteil Törten durchgeführt. Törten ist dörflich geprägt. Der Ortskern ist, für anhaltinische Dörfer typisch, locker mit Einfamilienhäusern und Nebengebäuden bebaut. Im Ortskern habe ich mein Walking Paper getestet. An den Ortskern grenzt ein Wohngebiet mit Doppelhaushälften, alle in Reih und Glied entlang der Straße angeordnet. Dort kamen die drei anderen Verfahren zum Einsatz.

GPS-basiertes Verfahren

Wie geht das?

Mit dem GPS-basierten Verfahren habe ich vor etwa eineinhalb Jahren mit dem Adressmapping begonnen. Beim GPS-basierten Verfahren setze ich mit einem GPS-Gerät (bei mir Garmin Dakota 20) einen Wegpunkt vor mittig auf die Straße vor das Haus und notiere auf einem Formular (PDF, 35 kB) Wegpunktnummer, Hausnummer und die Straßenseite (rechts/links). Wenn die Hausnummern geordnet sind und die Bebauung homogen ist (bei Baugebieten der Fall), genügt es bei einer Hausnummernreihe, wie z.B. 18 16 14 12 10, nur vor der 18 und der 10 einen Wegpunkt zu setzen. Neben den Hausnummern notiere ich auch noch jedes mal, wenn sich der Straßenname ändert (z.B. beim Abbiegen) den Straßennamen und die Fortbewegungsrichtung (z.B. Richtung Norden, abgekürzt "Ri. N").

ausgefülltes Walking Paper, gerendert mit Maperitive und Cadastre Style

Vor- und Nachteile

Das GPS-basierte Verfahren ist gut für Gebiete geeignet, in denen keine hoch aufgelösten Luftbilder vorliegen, d.h. Gebiete, in denen man keine Gebäude vernünftig abzeichnen kann. Das war in Deutschland bis vor einigen Monaten fast flächendeckend der Fall. Zum Abzeichnen sollten die Bilder eine Auflösung von mindestens 30, besser 20 cm aufweisen.

Das Verfahren hat den Nachteil, dass man recht lange für die Auswertung in JOSM benötigt, wenn die Gebäude nicht einfach 3–5–7–9 durchnummeriert sind. Dann muss man vor jedes Gebäude einen Wegpunkt setzen und dessen Nummer sowie die Hausnummer und Straßenseite (rechts/links) notieren. Das frisst viel Zeit und man kommt nur langsam voran. Ungenauigkeiten bei der Positionsbestimmung erschweren die Zuordnung der Wegpunkte zu den Gebäuden. Diese ist gerade dann schwer, wenn die Luftbilder zu schlecht zum Abzeichnen der Gebäude sind. Man muss dann nämlich den GPS-Track in JOSM über den Layer mit den Bing-Bildern legen. Die dünne, graue Schrift kann man jedoch auch als Nicht-Farbenblinder nur schwer auf dem bunten Bing-Bild, vor allem auf grauem Asphalt, lesen.

Im Wohngebiet in Törten, wo die Bebauung homogen ist (vgl. Mapnik-Karte und Bing-Bilder), habe ich in 16 Minuten 106 Hausnummern erfasst. Das Mappen ging außergewöhnlich schnell voran, weil ich nur am Anfang und Ende der Straße einen Punkt setzen musst. Es gab nämlich keine Sprünge und Lücken in der Nummerierung. Die Auswertung dauerte 14 Minuten, insgesamt also 3,5 Hausnummern pro Minute Arbeitszeit (Summe Messung und Auswertung). Normalerweise bin ich höchstens halb so schnell.

Walking Papers

Wie geht das?

Walking Papers waren bisher mein Lieblingsverfahren zur Adresserfassung. Auf http://walking-papers.org/ habe ich mir mein Arbeitsgebiet ausgedruckt und bin mit diesen Zetteln und einem Klemmbrett losgezogen. Das Mappen selbst ist ziemlich simpel: Einfach die Hausnummern in die Hausumrisse schreiben, mehr nicht.

ausgefülltes Formular

Vor- und Nachteile

Walking Papers sind vor allem dann interessant, wenn man keinen GPS-Empfänger hat oder der GPS-Empfang, wie in Innenstädten/Straßenschluchten üblich, schlecht ist. In Innenstädten, wo die Bebauung oft kreuz und quer ist, sind Walking Papers auch deshalb vorzuziehen, weil man die Zuordnung der Hausnummer zu dem Gebäude gleich vor Ort vornehmen kann. In Wohngebieten kann man meistens das Hauptgebäude eines Grundstücks leicht erkennen: das Wohnhaus, in Innenstädten, wo alles aneinander gebaut ist, geht das nicht so leicht.

Ein Walking Paper lenkt einen jedoch leicht vom Adressmapping ab. Hier sieht man noch einen Fußweg, der fehlt, da noch einen Briefkasten und am Ende notiert man noch alle Straßenbeläge. Normale Walking Papers sind ein universell geeignetes Mapping-Hilfsmittel. Wenn man aber nur Hausnummern und vielleicht noch die Gebäudenutzung erfassen will, greift man am besten zu selbst gerenderten Walking Papers.

Im Ortskern von Törten habe ich in 34 Minuten 68 Hausnummern erfasst. Die Auswertung dauerte 14 Minuten, insgesamt also 1,5 Hausnummern pro Minute Arbeitszeit (Summe Messung und Auswertung). Der Wert ist eigentlich nicht mit den anderen Verfahren vergleichbar, da nicht dieselben Rahmenbedingungen gegeben sind.

Keypad-Mapper 3

Was ist Keypad-Mapper 3 und was kann das?

Keypad-Mapper 3 ist eine Android-App zur Erfassung von Hausnummern mit einem Android-Smartphone. Wie beim GPS-basierten Verfahren setzt man einen GPS-Punkt vor das Haus (das Abspeichern übernimmt die App) und gibt Hausnummer und Straßenseite (Links/Rechts/Vorn) ein. Keypad-Mapper 3 erzeugt eine .osm-Datei, die die Nodes mit den addr:*-Tags enthält und mit JOSM geöffnet werden kann. Außerdem wird der gelaufene Weg als .gpx-Track gespeichert. Die App setzt die Adress-Nodes um einen vom Nutzer angegebenen Abstand neben die Straße. Wenn in der Gegend schon die Gebäude abgezeichnet wurden, ist dieser Abstand eigentlich unbedeutend, da man (ich mache es zumindest so) die Tags der Adressnodes auf den Gebäudeumriss kopiert und den Node löscht.

Screenshot Keypad-Mapper 3

Meine Meinung, meine Erfahrungen

An der App gefällt mir, dass man damit sehr unauffällig mappen kann. Alle anderen Verfahren sind auffällig, weil man entweder ein Klemmbrett oder Feldbuch mit sich führt und auffällig umherschaut oder weil man "wie ein Bekloppter" :-) Nummer in ein Handy spricht. Gegenüber dem GPS-basierten Verfahren spart man sich das Aufschreiben von Wegpunkt- und Hausnummer. Weil man keine großen Möglichkeiten hat, Notizen zu machen, wird man nicht durch andere mappbare Sachen (POIs, Straßenbeläge, Hundekottütenspender usw.) abgelenkt. In kniffligen Situationen kann man aus der App heraus georeferenzierte Fotos aufnehmen.

Es wäre schön, wenn man aus der App heraus mehrere Fotos auf einmal aufnehmen könnte. Ich nutze Android 2.3, welches keine Panoramafotofunktion hat. Wenn ich eine georeferenzierte Rundumansicht möchte, muss ich jedes Bilder einzeln aufnehmen und anschließend wieder zurück zu Keypad-Mapper 3, dann wieder ein Bild aufnehmen usw. Wie ich dem Markus59 schon geschrieben habe, vermisse ich eine aktustische Warnung, wenn der GPS-Empfang schlecht wird. Als Vermesser bin ich es gewohnt, dass meine (Profi-)Empfänger "Schlechter PDOP!" über einen Lautsprecher ausgeben.

Außerdem vermisse ich die Angabe des HDOP oder PDOP in den .gpx-Dateien. Der HDOP eignet sich gut, um die Zuverlässigkeit der GPS-Positionierung beurteilen zu können. JOSM kann sogar um die einzelnen Trackpoints herum Kreise zeichnen, deren Radien von den DOP-Werten abhängen. Großer Radius heißt hoher DOP-Wert, was ein Indiz für eine schlechte Positionierung ist.

Beim Mappen sollte man nicht bummeln, lieber etwas zügiger gehen, damit der Track schön gerade ist. Die Adressnodes werden nämlich rechtwinklig zur Fortbewegungsrichtung in der vorgegebenen Entfernung zum Track (Position des Smartphones) abgelegt. Läuft man langsam, ist der GPS-Track mehr zick-zack als gerade und die Punkt landen im Nachbargebäude und/oder zu nahe an der Straße.

Im Ortskern von Törten habe ich in 16 Minuten 74 Hausnummern erfasst. Die Auswertung dauerte 15 Minuten, insgesamt also 2,4 Hausnummern pro Minute Arbeitszeit (Summe Messung und Auswertung). Der Wert ist eigentlich nicht mit den anderen Verfahren vergleichbar, da nicht dieselben Rahmenbedingungen gegeben sind.

Audiomapping

Was ist Audiomapping und wie geht das?

Beim Audiomapping nimmt man fortlaufend während des gesamten Mappens eine Tonspur auf und lässt gleichzeitig einen GPS-Logger laufen. Das kann eine Smartphone-App, wie z.B. GPSLogger (Android), oder, wie bei mir, ein eigenständiges Gerät (Garmin Dakota 20) sein. Wie beim GPS-basierten Verfahren koordiniert man die Häuser über ihre Lotfußpunkte auf die Straße. Mittig vor dem Haus sagt man die Nummer und die Straßenseite, also "Siebenundzwanzig a links".

WICHTIG: Der GPS-Track sollte zeitlich nach der Audiodatei beginnen. Dazu schneidet man mit GpsPrune einfach den Anfang des Tracks so weit ab, bis man sich an einem markanten Punkt befindet, den man gesprochen hat (z.B. die erste Hausnummer). JOSM kann zwar auch GPS-Tracks bearbeiten, man muss dabei aber aufpassen, dass der Zeitstempel erhalten bleibt. In JOSM lädt man nun den Track, anschließend klickt man im Ebenenmanager rechts auf die Ebene des GPS-Tracks und wählt "Audio importieren". Mit der Punkt-Taste kann man das Abspielen starten bzw. anhalten, mit F6 zurückspulen. Man lässt den Ton nun so lange laufen, bis man den Moment erreicht, an dem der Track beginnt. Nun drückt man [.], dann F6, um zurückzuspulen und klickt rechts auf die Audio-Ebene im Ebenenmanager und wählt "Ton synchronisieren". Wenn die Synchronisation nicht genau genug ist, kann man sich nun langsam an die optimale Synchronisation herantasten.

Meine Meinung, meine Erfahrungen

Audiomapping ist umständlich. Beim Eintragen der Adressen in JOSM bin ich mit Maus und Tastatur schneller, als die Tonausgabe abläuft. (Ich weiß, man kann die Abspielgeschwindigkeit erhöhen.) Das Synchronisieren ist stets eine Fummelei. Wenn man es nicht tagtäglich macht, vergisst man es leicht wieder. Für 107 Adressen habe ich 20 Minuten zum Mappen benötigt und 35 Minuten zur Auswertung. Zur Auswertung gehört auch das Abschneiden des Anfangs des Tracks und das Konvertieren der Tonspur in das WAV-Format, die mein Smartphone im .3gp-Format speichert, da JOSM nur WAV lesen kann. Man schafft mit Audiomapping also nur etwa 1,9 Adressen pro Minute Arbeitszeit, der niedrigste Wert

Fazit

In Gebieten mit sehr enger oder unübersichtlicher Bebauung sind Walking Papers das Mittel der Wahl. Ansonsten kann man stattdessen, wenn man ein Android-Smartphone nutzt, Keypad-Mapper 3 verwenden. Audiomapping hat sich in diesem Test als nicht so praktikabel herausgestellt. Ich habe den Eindruck, dass es nicht sehr verbreitet ist. In JOSM wird es deutlich schlechter unterstützt (umständlicher in der Anwendung) als die Verwendung georeferenzierter Fotos.

Abschließende Bitte

Unter meiner Nutzerseite habe ich im OSM-Wiki eine Seite zur Sammlung der Techniken zum Adressmapping angelegt. Wer andere Verfahren als die hier beschriebenen kennt, möge doch bitte dort eine (kurze) Beschreibung des Verfahrens hinterlassen. Später könnte man die Beschreibungen dann auf die Seite des Karlsruher Schemas verschieben und ins Englische übersetzen.

Nachtrag

Changeset GPS-Wegpunkte-Verfahren: 15421678

Changeset Walking Papers: 15421830

Changeset Keypad Mapper 3: 15421297

Changeset Audiomapping: 15424733

Location: Törten, Roßlau, Dessau-Roßlau, Sachsen-Anhalt, Deutschland, Europäische Union

Versuche mit motorisiertem Adressmapping in Dessau

Posted by Nakaner on 23 February 2013 in German (Deutsch)

Die Erfassung von Hausnummern ist eine zeitintensive Arbeit, für die oft mehrere Möglichkeiten gibt. Die einen zeichnen zuerst von Bing alle Gebäude ab und schreiben dann vor Ort die Hausnummern auf Walking Papers oder Field Papers, andere setzen mit einem GPS-Gerät einen Wegpunkt vor jedes Haus auf die Straße und notieren Wegpunktnummer, Hausnummer und Straßenseite (rechts oder links). Wieder andere nutzen für das Adressmapping die Android App Keypad-Mapper 3

Ich selbst habe in der Vergangenheit Walking Papers und dem GPS-basierten Verfahren gearbeitet, bin jedoch aufgrund seiner Einfachheit auf die Technik mit Walking Papers umgestiegen, da man damit Zeit spart. Setzt man GPS-Wegpunkte, so weisen diese je nach Abschattung und Multipath-Effekten Ungenauigkeiten von bis zu 15 Metern auf, was eine Zuordnung zu den Gebäude in JOSM deutlich erschwert und Zeit frisst. Wenn jedoch, wie in Dessau bis zum 21. November 2012, nur alte, schlecht aufgelöste Bing-Bilder vorliegen, kann man nur das GPS-basierte Verfahren verwenden.

Um schneller in der gesamten Kernstadt von Dessau (d.h. Dessau-Nord, Dessau-Mitte, Dessau-Süd, Alten und Ziebigk) alle Adressen erfassen zu können, kam mir im Herbst letzten Jahres das Studienmodul Projektmanagement in meinem Studium des Vermessungswesens gerade recht. Die Aufgabenstellung "Messen Sie irgendetwas!" interpretierte ich gemeinsam mit den Usern (Kommilitonen) weltvermesserer89, 2170martin und BW12 sehr frei und nutzte sie für die Erprobung einer neuen Mappingtechnik, dem motorisierten Adressmapping.

Dazu fuhren wir vier Ende November 2012 insgesamt drei Stunden mit dem Auto durch Dessau-Ziebigk und Dessau-Siedlung und erfassten mittels Audiomapping alle sichtbaren Hausnummern. In dem Moment, in dem das Auto ein Gebäude mit einer sichtbaren Hausnummer mittig passierte, sprach der zuständige Ansager "Piep" gefolgt von der Hausnummer, wenn es auf der rechten Straßenseite lag, bzw. "Pup" gefolgt von der Hausnummer, wenn es auf der linken Straßenseite lag. Die aufgezeichnete Tonspur wurde mit einem GPS-Track (Garmin Dakota 20, Aufzeichnungsfrequenz 1 Punkt/Sekunde) in JOSM synchronisiert. Gleichzeit wurde ein Video (Blickrichtung nach vorn) aufgezeichnet, aus dem Straßenbeläge, Tempolimits und POIs (meist Zebrastreifen, Briefkästen, Durchfahrtsverbote, Abbiegebeschränkungen und Einbahnstraßen) erfasst wurden. Weil wir mit nur 20 km/h unterwegs waren, konnte fast jeder Piepton einem Gebäude zugeordnet werden.

Die Aufgaben waren wie folgt verteilt und wurden zwischendurch getauscht:

  • Fahrer: nur für das Fahren zuständig
  • Beifahrer: Videoaufnahme und Aufzeichnung des GPS-Tracks
  • hinten rechts: Ansagen der Hausnummer der rechten Straßenseite wie im Folgenden beschrieben und Starten und Stoppen der Tonaufnahme (Smartphone)
  • hinten links (meistens ich): Planung der Fahrtroute, Abbiegeanweisungen für den Fahrer, Ansagen der Hausnummern der linken Straßenseite

In JOSM wurde die Tonspur mit dem GPS-Track synchronisiert und ein Node mit den addr:*-Tags mittig auf jedes Gebäude gesetzt. Auf ein Abzeichnen der Gebäude wurde zu Projektbeginn (Anfang November 2012) verzichtet, da die Bing-Bilder in Dessau damals zu schlecht aufgelöst waren. Man hätte nämlich die Gebäudeumrisse nach Erscheinen der neuen Bing-Bilder (damals nur noch eine Frage der Zeit) alle verbessern müssen und somit unnötige Arbeit geschaffen.

Das Erscheinen der neuen Bing-Bilder am 21. November 2012 brachte die gesamte Projektplanung durcheinander. Die neuen Bilder wiesen eine Auflösung von 15 cm auf, sodass ein Abzeichnen der Gebäudeumrisse und Anbringen der addr:-Tags an den building-Way angeraten war. Es war in meinen Augen der Community gegenüber nicht verantwortbar, weiter nur Nodes zu setzen. Im gesamten Messgebiet, auch dort, wo wir schon fertig waren, zeichneten wir daher alle Gebäude ab und kopierten die addr:-Tags auf den building-Way.

Wie zu Projektbeginn geahnt und eingeplant, waren Nachmessungen nötig. Im Rahmen der Nachmessungen wurden widersprüchliche und uneindeutige Aufzeichnungen geklärt sowie die Adressen in kleinen Stichstraßen erfasst, welche der Wirtschaftlichkeit halber nicht befahren wurden.

Es wurden nur wenige neue POIs und Einbahnstraßenregelungen bei diesem Mappingprojekt erfasst, da diesbezüglich das Gebiet schon recht gut gemappt war.

Zu Präsentationszwecken und einer guten Benotung wegen renderte ich nach dem Projekt noch einen Stadtplan im Maßstab 1:5000 (Format DIN A1) mit einem angepassten Style mit Maperitive.

Mein Fazit

Unabhängig davon, ob brauchbare Luftbilder vorliegen oder nicht, ist eine motorisierte Erfassung von Adressen nicht sinnvoll, da sie gegenüber dem klassischen Adressmapping mit Walking Papers oder GPS keine Zeit- und Genauigkeitsvorteile liefert. Kommerzielle Geodatenanbieter erfassen Adressdaten teilweise zwar auch motorisiert, nehmen jedoch nicht jede einzelne Hausnummer auf und ermitteln die übrigen Hausnummern durch Interpolation. Das ist meiner Meinung nach mit dem Qualitätsanspruch von OSM nicht vereinbar. Wenn hoch aufgelöste Orthophotos vorliegen, ist die motorisierte Erfassung gänzlich ungeeigent, da man zu Fuß genauso schnell ist. Man kann nämlich nebenbei noch die Gebäudenutzung (z.B. Wohnhaus oder Garage) erfassen und man stößt bei der Auswertung seltener auf Widersprüche, wodurch die Nachmessungen eingespart werden.

Die motorisierte Erfassung eignet sich somit nur für kaum kartierte Gebiete, in welchen nicht einmal die Straßenverläufe vorhanden sind, und für Überlandfahrten, bei denen Tempolimits, Durchfahrtsverbote, Straßenbeläge usw. erfasst werden sollen.

EDIT: Keypad Mapper 3 ergänzt EDIT2: Aufzählung besser formatiert

Ein Hauch Liegenschaftskarte mit Maperitive

Posted by Nakaner on 16 February 2013 in German (Deutsch)

Seit ich beim Mappen von Hausnummern die Gebäudenutzung (z.B. Wohnhaus, Garage) miterfasse, ärgere ich mich darüber, dass es keine Kartenstil gibt, der die Gebäudenutzung rendert und gleichzeitig wenig Toner/Tinte verbraucht. Deshalb habe ich jetzt Cadastre Style, einen schwarz-weißen Stil für Maperitive, entwickelt. Cadastre Style (deutsch: Kataster-Kartenstil) lehnt sich an die amtliche Liegenschaftskarte an.

Hausen an der Zaber mit Cadastre Style gerendert

Abbildung: Hausen an der Zaber mit Cadastre Style und Maperitive gerendert

Cadastre Style verzichtet größtenteils auf Flächenfarben und verwendet stattdessen Schraffuren, um Toner zu sparen. Außerdem kann man dadurch mittels Farbstiften seine Notizen hervorheben, was beim Standard-Mapnik-Stil nicht funktioniert, da er recht bunt ist. Weil auf Flächenfarben weitestgehend verzichtet wird, kann man mit harten Bleistiften auch einfacher die Hausnummern auf die Gebäude schreiben (und diese Hausnummern auch leichter lesen).

Die Gebäudenutzung wird durch drei verschiede Schraffurarten und noch viel mehr (baden-württembergische) Abkürzungen angegeben. Wie in manchen Liegenschaftskarten werden Wohnhäuser aufsteigend schraffiert. Ist die Nutzungsart eines Gebäudes angegeben (z.B. building=garage), aber das Gebäude kein Wohnhaus, wird senkrecht schraffiert. Horizontal wird schraffiert, wenn keine Nutzungsart (building=yes) angegeben ist. Handelt es sich um eine Nutzung, die kein Wohnen ist (z.B. Lagergebäude) wird sie abgekürzt angegeben.

Bestimmte Nutzungsarten wie Schule und Kindergärten werden auch erkannt, wenn sie "falsch" getaggt sind. Ein Kindergarten muss entweder building=kindergarten oder building=yes + amenity=kindergarten getaggt sein.

Hat das Gebäude schon eine Hausnummer, wird diese mittig in das Gebäude geschrieben, wenn der addr:housenumber-Tag am Gebäude-Umriss hängt. Hängt der Tag an einem einzelnen Node (z.B. Eingang), wird die Hausnummer an der Stelle des Nodes gerendert.

Auf Landnutzung wird vollständig verzichtet. Straßen werden in vier Kategorien eingeteilt, die man anhand ihrer Breite und ihres Grautons unterscheiden kann. Als Flächen gemappte Straßen und Wege werden nicht unterstützt. Seen sind die einzigen Objekte, die eine Flächenfarbe bekommen. Weil man Adressmapping beitreibt, werden POIs der Übersichtlichkeit nicht gerendet, es sei denn, es handelt sich um eine Gebäudenutzung, wie z.B. eine Schule.

Ganz zufrieden bin ich mit dem Stylesheet noch nicht. Die Positionierung der der Gebäudenutzung und Hausnummern stimmt noch nicht ganz. Außerdem weiß ich nicht, wie ich die Umrisslinie der Gebäude dünner zeichnen kann.

Unter http://wiki.openstreetmap.org/wiki/User:Nakaner/Cadastre_Style sind alle Abkürzungen und Schraffuren beschrieben. Das Stylesheet selbst ist CC-BY-SA 2.0-lizensiert und liegt auf Github.

Location: Dürrenzimmern, Brackenheim, Verwaltungsgemeinschaft Brackenheim, Landkreis Heilbronn, Regierungsbezirk Stuttgart, Baden-Württemberg, Deutschland, Europäische Union
Older Entries | Newer Entries