Landshut Projekte

Allgemeines Stammtisch Erfassungsstatus Mapping-Regeln Projekte Projektdetails Tipps Interessante Links

2023-07-25 Landshuter Hochzeit (LaHo) - Parkplätze in der Neustadt temporär ausschalten

Dieses Jahr gabs nach 6 Jahren (wegen Corona) wieder eine LaHo, und damit auch die Anfrage der Stadt, die Parkplätze in der Neustadt unsichtbar zu machen. Vorgehensweise:

JOSM - Neustadt großzügig herunterladen, Standard OSM Karte als Hintergrund. Dann sieht man die markierten Parkflächen, an denen sich auch die Besucher orientieren.

Die Attribute wie

amenity=parking
amenity=byclicle_parking

etc...

Umbenannt in:

amenity=laho_no_parking
amenity=laho_no_byclice_parking

Zum Rückgängig machen habe ich https://overpass-turbo.eu verwendet mit folgendem Script:

node
  [amenity~".*laho.*"]
  ({{bbox}});
out;
area
  [amenity~".*laho.*"]
  ({{bbox}});
  (._;>;);
out;

RegExp auf amenity, sollte eigentlich selbsterklärend sein. Dann werden diese Elemente grafisch hervorgehoben.
Browser neben JOSM ziehen und händisch die Edits rückgängig machen. Das sind ca 20 Elemente.

Man könnte natürlich die Parkplätze noch mit einem zusätzlichen Tag versehen, das für den Renderer uninteressant ist um das nicht per Auge raussuchen zu müssen. Vom Gernot kam ausserdem der Vorschlag, ein note-Tag für diese Zeit mit anzuhängen.

--Alex

2016-05-25 Browsing OSM

Nach langer bastelei will ich (--F6F) meinen ersten wurf hier präsentieren. Sicher ist vieles noch nicht fertig und verbesserungswürdig aber fürs erste schon ganz "nett". Bei meinem Projekt (http://open-landshut.de/) ging es mir darum die Daten welche in OSM hinterlegt sind eine Suchmaschine oder einem Menschen in Textform zugänglich zu machen.

So werden zum Beispiel Öffnungszeiten welche für Geschäfte in OSM hinterlegt sind mit Google findbar. Sie werden von mir auf einer Einfachen Seite dargestellt was auf vielen webseiten von Geschäften oft nicht sind. Zum Beispiel hier: http://open-landshut.de/osm/en/detail/node/286639782/

Nach Geschäften und einrichtugen kann man entweder nach Ort http://open-landshut.de/osm/en/place/ oder über die Postleitzahl suchen http://open-landshut.de/osm/en/postalCode/ Wer in den Urls das en druch ein de ersetzt kann meine verusche Osm ein wenig Deutsch beizubringen betrachten. zb: http://open-landshut.de/osm/de/place/Altdorf/

In machen fällen ist es kompliziert die komplette adresse zu kommen. Während 286639782 alle daten hinterlegt hat. Felehen zb hier http://www.openstreetmap.org/way/142034442 postleitzahl und Ort. Welche aber über ein paar abfragen in der PostGis datenbank ergänzt werden können siehe: http://open-landshut.de/osm/en/detail/way/142034442/ Leider sind diese art von Abfragen etwas langsam weswegen einmal ermittelte Werte für einige Zeit vorgehalten werden. Dafür bietet sich memcached an.

Soweit für ein Geschäft Bilder in osm hinterlegt sind werden auch diese auf der Geschäftsseite angezeigt. Zb: für das Haus International: http://open-landshut.de/osm/en/detail/node/2310125076/ oder bei Blumen Brunner: http://open-landshut.de/osm/en/detail/way/216882625/ Thumbnails werden nur gezeigt wenn ich die Bilder auch selbst hoste. Kommen die Bilder von einer anderen Quelle werden nur links darauf angezeigt.

Eventuell bietet mir der nächste Stammtisch eine Gelegenheit zu zeigen was schon alles geht und neue Anregungen und Ideen zu Sammeln.

2016-01-20 oneway=no

Ich (--Blutsauger) habe auf der bayerischen Mailingliste eine Diskussion um die Verwendung von oneway=no losgetreten:

https://lists.openstreetmap.de/pipermail/bayern/2016-January/001157.html

Zur Verwendung von oneway=* siehe im englischen Wiki https://wiki.openstreetmap.org/wiki/Key:oneway

und im deutschen Wiki https://wiki.openstreetmap.org/wiki/DE:Key:oneway

Zusammenfassung des mail-Threads (bitte dort die einzelnen Links zu verwandten Themen raussuchen, das sind nur eine Handvoll Beiträge):

Es handelt es sich hier eigentlich mehr um einen 'menschlichen' Hinweis als ein maschinell auswertbares Attribut, denn oneway wird als default immer als 'no' angesehen, ausgenommen Kreisverkehre und Autobahnen (bzw. vergleichare), wo das wiederum widersprüchlich ist.
Bei scheinbaren Kreisverkehren, also zweiseitig ausgerichteten Straßen, die zufälligerweise im Kreis angeordnet sind, macht ein expliziter Hinweis auf oneway=no Sinn, um Aerial image Mapper davon abzuhalten, falsche Annahmen zu treffen. Beispiel
Regional bedingt macht oneway=no eventuell Sinn, falls die restliche Umgebung von Einbahnstraßen umgeben ist, wie beispielsweise in Wohnsiedlungen.
Das kann sich insbes. auf Teilstrecken von Straßen beziehen, die nicht durchgängig ein gleiches oneway Attribut haben.
Umwidmung durch Baureferat o.ä.: da macht es Sinn, neben dem expliziten oneway=no einen entsprechenden Verweis in den comments zu hinterlegen (gutgemeintes Mapping durch veraltete Ortskenntnis verhindern) Beispiel - History anschauen!
Auf separat gemappten Radwegen neben Straßen kann oneway=no explizit verwendet werden um darauf hinzuweisen, dass der Radweg in beide Richtungen befahrbar ist. Nicht wie sonst üblich, nur in Richtung der Kfz-Fahrstrecke. Siehe aber bitte dazu auch weitere Diskussionen zu den Tags oneway:bicycle=* und cycleway=opposite - Beispiel. Im deutschen Wiki wird auf die Verwendung von oneway und Fahrrad auch nochmal explizit eingegangen.
Zum Thema 'unterschiedliche oneways für Linienverkehr' siehe diesen Beitrag.
Router werden wohl oneway=no nicht auswerten (im Gegensatz zu oneway=yes), haben aber eine große Latenzzeit der Kartenupdates (->nächster Punkt).
oneway=no sollte nicht verwendet werden, um zeitlich und örtlich beschränkte Baustellen zu markieren (Einbahnstraße wird zweiseitig, Autobahnbaustelle mit vereinten Fahrbahnen). Diese sollten das construction-Tag (https://wiki.openstreetmap.org/wiki/DE:Key:construction) verwenden; man geht dort von 6-9 Monaten als Schwellwert für dauerhaftes Tagging aus.
Die entstehende Datenmenge spielt keine Rolle, wenn der Informationsgehalt tatsächlich gesteigert werden kann.
Im Umkehrschluß verwässert die überflüssige Verwendung von oneway=no explizite Suchen. Wie ärgerlich das sein kann, zeigt u.a. dieser Beitrag.

Mit dieser Overpass-Abfrage könnt ihr euch in München alle oneway=no getagten Wege anzeigen lassen und ein Bild machen.

2015-12-08 POIs aktuell halten

Gerade im Bereich der Innenstadt gibt es viele Einrichtungen (v.a. Geschäfte), die nicht von langer Lebensdauer sind. Auch ist es viel einfacher, etwas neu Entdecktes einzutragen als Überflüssiges zu löschen. Es wird nach einer Methode gesucht, diesen Prozess der Qualitätssicherung zu vereinfachen und auf ein machbares Maß Arbeit zu reduzieren.

(von --Blutsauger (talk) 09:34, 16 December 2015 (UTC))

Die Erfahrung bei der Hausnummern-Erfassung (in Landshut wie in Passau) zeigt, dass ein Volumen von mehreren tausend Datensätzen durchaus mit weniger als 5 Personen zu bewerkstelligen ist. Wichtig ist, dass die Aufgabe aufteilbar ist und die Transaktionen möglichst zeitnah mit einer Auswertung der OSM-Daten (Ist/Soll-Vergleich) einhergehen.

Workflow

Gesucht ist eine Liste von POIs im Stadtgebiet Landshut. Hat man sich der Aktualität eines POIs versichert, erhält dieser einen Tag checkdate=yyyy-mm-dd mit dem aktuellen Datum. Sind erst einmal alle POIs erfasst, ergibt sich durch Sortieren der Daten automatische eine Art TODO-Liste, die in moderaten Abständen erledigt werden kann. Die Bearbeitung erfolgt sinnvollerweise über eine Weboberfläche und JOSM. Das Tag 'checkdate' hat zwar (noch) keinen aktuellen Status, wird aber bereits in anderen vergleichbaren Projekten (z.B. Briefkasten-Leerungszeiten Lübeck) schon so verwendet.

Update 2016-01-28: check_date=* wurde von user 'Lübeck' in den Anmerkungen dieser Seite vorgeschlagen. Sehr lesenswerter Artikel, der auch die diversen Probleme dieses Ansatzes etwas beleuchtet. Ich habe derzeit die Auswertung so eingestellt, dass sowohl check_date, also auch lastcheck erkannt werden, beim Eintragen eines Wertes aber check_date verwendet wird.

Werkzeug

Ich habe die Skripte auf einer Fedora Core 6 Distribution von gefühlt 2005 am laufen. Es gibt Skripte für bash und Overpass, ein wenig HTML zur Seitengestaltung ist mit dabei. Wer den vollen Funktionsumfang genießen will, setzt sich selber einen Web-Server auf.

Vorschau

Um zu erahnen, was das Ziel dieser Arbeit ist, vorab ein paar Screenshots:

Tabellarische Auswertung des Tags check_date (erste Spalte mit Alter in Tagen). Die Links 'Update/View' beinhalten einen Verweis auf die JOSM-Weboberfläche, wodurch ein angeklicktes Objekt samt Umgebung direkt in JOSM heruntergeladen und ausgewählt wird. Einträge, deren Datum älter als 100 Tage ist, werden rot hinterlegt und wandern in der Liste automatisch nach oben. Eignet sich auch für Armchair- und Offline-Mapping.

Darstellung der POIs auf einer OpenLayer-Karte. Die nach 'check_date' farblich sortierten Links verweisen wieder nach JOSM. Bis ein Edit von JOSM über den OSM Server wieder in der Auswertung landet, vergehen nur wenige Minuten. Deshalb eignet sich diese Methode insbesondere für das Online-Mapping mit bestehender Internetverbindung.

Verlinkung nach JOSM. Es wird automatisch ein Vorschlag für das Tag 'check_date' angelegt. Das Hochladen zum OSM Server erfolgt wie gewohnt bei JOSM als Transaktion, in der auch mehrere Änderungen zusammengefasst werden können.

Community Effekt - ?

Dieses Experiment wurde in Landshut im Dezember 2015 gestartet, im Rahmen des lokalen Stammtischkreises. Die 'Aufgabe' bestand darin, ca 2000 POIs (alle amenities, shops, craft, tourism usw.) durchzugehen und entweder mit 'ja, gesehen' updaten, oder löschen. Ggf. Namen, TelNr. etc. korrigieren.

Der Vorteil an Landshut ist, dass es innerhalb des Stadt-Polygons bisher keine check_date, last_check oder ähnliches gab. In dem gesteckten Zeitraum sind alle check_date's wohl auf diese Aktion zurürckzuführen. Bei einem Fehlschlag des Experiments fühlt sich keiner auf den Schlipps getreten, wenn alle check_date's wieder gelöscht werden.

Aktiv mitgemacht haben ca. 5 Personen. Erwartungsgemäß wurden POIs in der Innenstadt als erstes aktualisiert. Die Neugierde und Aktivität der meisten hielt aber nur kurz an, bzw. war der 'Offline-Fundus' schnell erschöpft. Freunde fragen, die nicht bei OSM sind hilft: Welche Kneipen sie in den letzten Wochen besucht haben, ob der Parkplatz an der Uni noch so existiert. Oder andere OSM'ler anschreiben, die in letzter Zeit editiert haben und gerade einen Flecken in der Stadt gut in Erinnerung haben.

Die Auswahl der POIs läßt sicher noch Wünsche offen, so tragen z.B. hunderte von Parkbänken zur Statistik bei. Deren Aktualität hat keine große Bedeutung. Andererseits jedoch werden ja auch Jägerstände gemapped, die von Haus aus dem Verfall gewidment sind. Es wäre also 'effektiver', sich um Jägerstände zu kümmern, die älter als 1 Jahr sind, und um Parkbänke erst, wenn sie älter als 10 Jahre sind, usw. Das lässt die derzeitige Auswertung noch nicht zu.

Die Auswertung der Änderungen läßt noch jede Menge Rückschlüsse zu, z.B. wieviele POIs wurden gelöscht, Namen geändert, die Position verschoben, etc.Das ist aber noch nicht programmiert...

Dann gab es Anfragen, ob man die Abfrage nicht auf Tags wie 'check_date:opening_hours', 'check_date:phone' etc. erweitern könnte. Das wäre sicherlich möglich. Allerdings mag dadurch das Tool durch spezial-Mapper, die beispielsweise nur Leerungszeiten aktualisieren, 'verwässert' werden. Es geht hier eben primär um die reine Existenz eines POIs.

Nach zwei Monaten sind 70% der 2000 POIs aktualisiert. Das ist insbesondere einem einzigen Mapper zu verdanken, der einen Löwenanteil davon aktualisiert hat. Auch wenn diese bemerkenswerte Leistung vielleicht nicht mit höchster Präzision erfolgte, ist es doch ein wichtiger Schritt und motoviert andere, mit zu machen.

(Ab hier nur Programmierungs-Zeug)

Datenaufbereitung

Statt wie bei den Hausnummern die OSM-Daten komplett herunterzuladen und auf der lokalen SQL-Datenbank zu arbeiten, habe ich mich diesmal für einen Ansatz mit der Overpass-API entschieden. Die einzelnen Vorteile werden im Folgenden noch weiter erläutert.

Um eine einfache HelloWorld!-Abfrage zu generieren, verwendet man am besten den Assistenten von Overpass Turbo. Der generiert dann ein Beispiel 'Zeige alle Theater in Wien'. Auf der Overpass-Turbo-Seite sieht man dann die Ergebnisse auf der Karte mit Info-Blasen markiert. 'Overpass Turbo' ist ein einfach zu bedienendes Web-Frontend für die Overpass-API. Diese wiederum bietet eine auf OSM Bedürfnisse zurechtgeschnittene Programmiersprache. Für die Overpass API gibt es auch fertige Bindings für perl oder python, ich versuche mich mit reinem Shell-Skript.

Weil die Overpass Syntax schon recht gewöhnungsbedürftig ist und es meiner Meinung nach noch zu wenig Dokumentation gibt, kommt jetzt die detaillierte Verwandlung von HelloWorld! nach 'Hello POIs'.

'theater in wien'

Gibt man in den Assistenten von Overpass Turbo diesen Suchbegriff ein, wird folgendes Skript generiert:

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“theater in wien”
*/
[out:json][timeout:25];
// fetch area “wien” to search in
{{geocodeArea:wien}}->.searchArea;
// gather results
(
  // query part for: “theater”
  node["amenity"="cinema"](area.searchArea);
  way["amenity"="cinema"](area.searchArea);
  relation["amenity"="cinema"](area.searchArea);
);
// print results
out body;
>;
out skel qt;

Das Ergebnis kann man sich dann auf der Karte ansehen oder die Rohdaten anzeigen lassen. Beides soll genutzt werden, und zwar automatisiert, deshalb erstmal ein wenig

Overpass API Syntax

Uns interessiert zuerst die Zeile {{geocodeArea:wien}}->.searchArea;

Die geschweiften Klammern sind eine Overpass-Turbo Spezialität und werden beim Ausführen der Anfrage in einen Zahlenwert umgerechnet, mit dem die Overpass-API etwas anfangen kann. Sichtbar wird das, wenn man sich das Skript in der XML-Darstellung anzeigen läßt. Das geht über die Funktion Exportieren->Abfrage->Nach XML konvertieren:

<osm-script output="json" timeout="25">
  <id-query into="searchArea" ref="3600109166" type="area"/>
  <union into="_">
    <query into="_" type="node">
      <has-kv k="amenity" modv="" v="cinema"/>
      <area-query from="searchArea" into="_" ref=""/>
    </query>
    <query into="_" type="way">
      <has-kv k="amenity" modv="" v="cinema"/>
      <area-query from="searchArea" into="_" ref=""/>
    </query>
    <query into="_" type="relation">
      <has-kv k="amenity" modv="" v="cinema"/>
      <area-query from="searchArea" into="_" ref=""/>
    </query>
  </union>
  <print e="" from="_" geometry="skeleton" limit="" mode="body" n="" order="id" s="" w=""/>
  <recurse from="_" into="_" type="down"/>
  <print e="" from="_" geometry="skeleton" limit="" mode="skeleton" n="" order="quadtile" s="" w=""/>
</osm-script>

Wie man sieht, ist aus 'wien' jetzt 3600109166 geworden. Woher man diese Information bekommt, weiss ich noch nicht. Mir reicht erstmal die Id einer einzelnen Stadt. Die Overpass-Abfrage muss jetzt so umgebaut werden, dass statt der Angabe des Stadtnamens diese Id drinsteht. Das sieht dann so aus:

area(3600109166)->.searchArea;

Damit hat man eine reine Overpass-Abfrage (ohne Turbo-Spezialitäten). Die drei Queries erklären sich selbst, es gibt drei Tabellen, die 'gejoined' werden:

  node["amenity"="cinema"](area.searchArea);
  way["amenity"="cinema"](area.searchArea);
  relation["amenity"="cinema"](area.searchArea);

Nützlich für die Aufgabe der POIs ist es beispielsweise, ALLE amenities zu finden, BIS AUF 'place_of_worship':

way["amenity"]["amenity"!="place_of_worship"](area.searchArea);

Der Ausgabeteil ist ebenfalls nicht zu übersehen:

out body;
>;
out skel qt;

out body; wird durch out meta center; ersetzt. 'meta' ermöglicht es uns, Meta-Informationen wie Id, letzter editierender Benutzer usw. mit auszugeben. 'center' statt 'body' bedeutet, dass die Koordinaten auch bei ways und relations ausgegeben werden (irgendein Mittelpunkt).

Die unscheinbare Operation >; bedeutet 'recurse down' und bewirkt, dass die Ergebnisliste nicht nur einzelne nodes und ways beinhaltet, sondern auch die einzelnen Nodes der ways. Für meine POI Liste ist das uninteressant, ja es stört eher. Das out skel qt; ist mir selber noch nicht ganz klar.

Jetzt fehlt noch die Erklärung der ersten Zeile:

[out:json][timeout:25];

Das legt das Ausgabeformat fest. Man sieht das, wenn man im Overpass Turbo rechts oben an der Karte auf die Datenansicht wechselt. Zur leichteren Verarbeitung möchte ich das aber auf .csv-Format umstellen:

[out:csv(::id,lastcheck,"amenity","shop",tourism,name,
         "addr:street","addr:housenumber",::type,::lat,::lon,::user;true)];

Die Datenfelder können ohne "..." auskommen, wenn keine Sonderzeichen enthalten sind. Die Felder ::id, ::lat, ::lon usw. sind die Meta-Felder (die kriegen wir nur durch die Angabe out meta, siehe oben). Die Doppelpunkte müssen immer ausserhalb der "..." stehen, also ::"user". 'true' bedeutet 'Kopfzeile mit Feldnamen ausgeben', optional kann man einen Separator angeben, default ist Tab.

Das fertige Beispiel der POI-Suche sieht jetzt so aus:

[out:csv(::id,lastcheck,"amenity","shop",tourism,name,"addr:street","addr:housenumber",::type,::lat,::lon,::user;true)];
area(2663882467)->.searchArea;
(
  node["amenity"](area.searchArea);
  way["amenity"]["amenity"!="place_of_worship"](area.searchArea);
  node["shop"](area.searchArea);
  way["shop"](area.searchArea);
  node["tourism"](area.searchArea);
  way["tourism"](area.searchArea);
);
out meta center;

Datenaufbereitung

Overpass command line options

So, das query-Skript könnte man jetzt auf der OverpassTurbo Seite hinterlegen und abfragen. Schöner ist es aber, das Skript selber zu haben und es der API zu übergeben. Das Ergebnis im CSV-Format soll zurückgegeben werden.

Dafür kann das Kommando wget eine Datei als 'Attachment' (in Form eines POST-Requests) an den Server übertragen:

wget -O target.csv --post-file=query.ql "http://overpass-api.de/api/interpreter"

target.csv sieht jetzt so aus:

@id	lastcheck	amenity	shop	tourism	name	addr:street	addr:housenumber  .....
130053572		recycling					
158262198		bank			Raiffeisenbank	Flurstraße	7d

Wie man daraus jetzt eine HTML-Tabelle generiert erkläre ich nicht im Detail. Lediglich folgende Gimmicks möchte ich zeigen:

JOSM fernsteuern

JOSM RemoteControl

JOSM hat einen Mini-Webserver, der per HTTP-Request Kommandos entgegennimmt. Diese Funktion nennt sich 'remote control' und muss in JOSM erst noch in den Settings eingeschaltet werden. Um so eine Aktion anzustossen, erzeugt man sich eine HTML-Datei mit in etwa folgendem Link:

<a href=http://localhost:8111/load_and_zoom?left=12.1570168&right=12.1590168&
        top=48.5335125&bottom=48.5315125&select=node1596462481>

Die Koordinaten bekommt man aus der CSV-Datei, ich dehne die Koordinaten eines Punktes dann jeweils um den Wert 0.001 nach links/rechts/oben/unten. Mit dem 'select' Argument selektiert JOSM das angegebene Objekt, das 'node', 'way' oder 'relation' vorneweg hat. Diese Namen erhält man von Overpass durch das Meta-Feld ::type.

Man kann der URL auch noch ein

&addtags=lastcheck=2015-12-09

dazugeben, das löst das Hinzufügen eines key/value Paars aus (mit vorheriger Abfrage). Achtung: URL-encoden (Sonderzeichen umwandeln). Im Fall meiner POI Auswertung habe ich mich entschieden, das Tag 'lastcheck' zu verwenden. Es wurde schon des öfteren darüber in diesem Zusammenhand diskutiert, ein Proposal dazu gibt es aber wohl nicht. Dieses lastcheck wird dann auch zum Sortieren der Liste verwendet.

OverpassTurbo fernsteuern

Overpass Turbo Development

Eine Möglichkeit der grafischen Anzeige der Ergebnismenge wurde ja anfangs gezeigt. Der Nachteil besteht darin, dass die Abfrage manuell erfolgen muss, entweder durch Laden einer bei OverpassTurbo hinterlegten Abfrage oder durch Copy&Paste ins Edit-Fenster. Es gibt aber auch die Möglichkeit, die komplette Abfrage als Teil der URL mitzugeben - auch wenn sich die dann über mehrere Zeilen zieht. Auch hier kann man wieder einen Hyperlink in einer HTML-Datei verwenden, um durch Anklicken die grafische Anzeige auf der Turbo Seite zu erhalten:

<a href=http://overpass-turbo.eu/?Q=... >

Nach dem ?Q= folgt der Text der Abfrage, allerdings URL-encoded!, das sieht dann z.B. so aus:

http://overpass-turbo.eu/?Q=node%5B%22amenity%22%3D%22drinking_water%22%5D(%7B%7Bbbox%7D%7D)%3B%0Aout%3B

Zum URL-encoden habe ich folgenden recht simplen (aber sehr unperfekten) Ansatz im Netz gefunden:

echo 'Meine Ausgabe!'| perl -p -e 's/([^A-Za-z0-9])/sprintf("%%%02X", ord($1))/seg'

Und noch ein Beispiel aus meiner Experimentierkiste:

Ausprobieren!

2015-10-25 Überprüfung und ergänzung der Radwege

Überprüfung und ergänzung der Radwege in OSM mittels daten der Stadt Landshut

Gernot hat Daten der Stadt Landshut erhalten die zeigen wo sich im Stadtgebiet Radwege finden. Die Wege sind in 3 Gruppen unterliedert.

Gehwege die mit dem Rad befahren werden dürfen
Radwege entlang der Straße
Eigenständige Radwege

Die Inforamtionen liegen als GPX tracks vor die entlang der straße führen. Wegen den vielfältigen tags für Radwege und der etwas ungenauen Straßenzuordnung fällt ein automatischer oder ein Teilautomatischer import aus.

Workflow

Um die wege einfach mit den Daten aus osm ablgeichen zu können ist es nötig die Daten

Farblich vom Rest zu trennen am besten eine Farbe je Radwegkategorie (auf der Straße, eigenstädig ...)
Editierbar zu halten damit schon abgearbeitete bereiche einfach entfernt werden können

Zwar lassen sich gpx tracks gut eifärben was es einfach macht die importierten Datan vom rest zu unterscheiden jedoch lassen sich diese Layer schwer bis gar nicht editieren. Eine konvertierung zu OSM pfaden machte die Daten editierbar aber das einfärben fast unmöglich. Auch das definieren eines eigenen karten stiels war nicht erfolgreich da dieser immer nur auf die jeweils aktive osm ebene angewendet wird.

Als nächstes versuchte ich die gpx tracks der Radwege mittels cspilt zu teilen. Somit ensteht eine nummerierte liste aller Radwege die einfach abgearbeitet werden kann. Radwege können dadurch auch einfach auf verschiedene Bearbeiter verteilt werden.

csplit GW_Rad_frei.gpx '/^<trk>$/' '{*}'

den Weg schnippsel feht dann jedoch der GPX header und footer. Welchen man einfach mit einer for schleife und echo anhängen kann.

for i in xx*; do cat ../gpxHeaderFooter/header.txt > GW_Rad_frei_$i.gpx; cat $i >> GW_Rad_frei_$i.gpx; echo -e "\n</gpx>" >> GW_Rad_frei_$i.gpx; done

Header: <?xml version="1.0"?> <gpx version="1.1" creator="GDAL 1.11.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ogr="http://osgeo.org/gdal" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> <metadata><bounds minlat="48.530786289070775" minlon="12.125628791333353" maxlat="48.553063363823298" maxlon="12.207090709916912"/></metadata>

Footer: </gpx>

Gehweg Fahrrad frei	Radweg entlang Straße	eigenständiger Radweg
13	222	147

Details: Liste der Radwege

2014-11-27 Drohnen-mapping

Diskussion im Forum
Phantom 2
IRIS+
interaktives Panorama-Bild mit 'Hugin' von user 'zarl' erstellt.
Hier geht's zur detailierten Beschreibung des Projekt Drohnen-Mapping in Landshut

2014-07-15 FKK Badesee Tagging und seine Folgen

Folgende lustige Geschichte hatte Gernot pünktlick zum Niederbayern-Stammtisch zu berichten:

Vor drei Wochen oder so hat mich die Stadt Landshut wegen einer etwas ungewöhnlichen Beschwerde angerufen. Bekanntlich nutzt die Stadt ja einen auf OSM basierenden Stadtplan auf ihrer Homepage. Und angeblich hatten radikale Nacktbader unter Berufung auf unseren Plan einen privaten Fischweiher unsicher gemacht.

Was war passiert? So ziemlich jeder in Landshut kennt den Badesee Gretlmühle ([1]) - und die meisten wissen wohl auch, dass es einen See weiter nördlich die Nacktbader gibt (natürlich nur vom Hörensagen :) ). Dementsprechend war der See nördlich auch bei OSM als FKK-See getaggt und ich habe mir nichts weiter dabei gedacht.

[1] http://www.openstreetmap.org/#map=16/48.5763/12.2257

Wie ich jetzt aber gelernt habe (vom etwas aufgebrachten Vorsitzenden des Angelvereins), war das schon immer ein privater Weiher vom Angelverein Altdorf und die über Jahre übliche FKK-Nutzung war schon immer illegal, nur wurde früher wenig dagegen unternommen. Der neue Vorsitzende möchte dem jetzt aber -- wohl auch auf Grund von jüngsten Beschädigungen und Beschwerden -- Einhalt gebieten.

Dummerweise hatten sich einige FKK-Jünger bei Diskussionen dann aber wohl auf den "offiziellen Stadtplan der Stadt Landshut" berufen.

Nachdem ich das ganze aber in Rekordzeit repariert und auch persönlich nochmal mit dem Vorsitzenden vom Angelverein gesprochen habe, sind die Wogen jetzt wieder geglättet und einige Leute mehr wissen über OSM Bescheid. :)

2014-04-15 Höhenwanderweg Landkarte für die Stadt Landshut

Die Tourismus-Abteilung der Stadt Landshut möchte eine neue Karte des Höhenwanderwegs auf Grundlage von OSM erstellen. Details zu diesem Projekt gibt es hier.

2014-03 Das einfachste Routing, das es gibt (afaik)

Osm Routing in Python, kürzeste Strecke Via A*

Vor einiger Zeit wurde in der Wochennotiz ein wenig über routing berichtet im besonderen über Fahrradrouting. Ich fand den Artikel sehr interessant und irgendwie hat mich das Thema dann nicht mehr los gelassen also habe ich mir gedacht - schreib doch mal deinen eignen Router! Da ich auch immer schon mal was mit Python machen wollte war Python das Werkzeug der Wahl. (sorry für die teilweisen etwas diletantischen Ausführungen)

Mein Skript besteht im grossen und ganzen aus 3 Teilen.

Im ersten werden die Daten eingelesen und das Daten/Straßen Netz generiert.
Dann wird die "DB" von nicht mehr benötigen Nodes gereinigt.
Im letzten Abschnitt beginnt das Routing. Mein vorgehen bei der Suche nach dem kürzesten Weg basiert dabei auf dem A* Algorithmus

Einlesen der Daten

Als Daten Quelle habe ich einen kleinen XML-Export von der Openstreetmap Seite gewählt. Ein ensprechender export kann hier generiert werden: http://www.openstreetmap.org/ -> Export Die XML Daten Parse ich mit dem Python SAX Modul und Speichere alle Knoten und im Falle von wegen ihre Verbindungen untereinander. Um die Logik hinter meinem einlese Prozesses besser verständlich zu machen möchte ich vorher kurz auf den Aufbau des XML Exports eingehen.

Aufbau OSM XML Export

Osm arbeitet mit Nodes - Jeder Punkt in der OSM Datenbank wird durch einen Node repräsentiert. Der verschiedene Eigenschaften haben kann. Darüber hinaus gibt es noch wege (ways) die angeben wie Punkte sich zu einem weg zusammenfinden und Relationen die mehrere Wege, Nodes und Objekte zusammen fassen können. Wichtig für das Routing ist:

Wo befindet sich der Node
Welche Wege führen von ihm zu anderen Nodes?

Nodes im OSM Export

Am Anfang der exportierten XML Datei liegen "alle" Informationen über die sich im export befindlichen Nodes. Das beinhaltet ihre GPS positon in Lat und Lon, wer den Node erstellt hat die Node ID und die user ID. Damit ist die Frage nach dem Wo befindet sich der Node beantwortet. Besonders Wichtig ist auch die Node ID da sie zur eindeutigen identifizierung des Nodes benutzt wird. Z.B. der Node '60974942 liegt an lat="48.5529181" lon="12.1036861".

 <node id="60403748" lat="48.5584609" lon="12.1081531" version="4" 
  timestamp="2009-12-12T15:01:54Z" changeset="3356284" uid="43021" user="Czmartin"/>
 <node id="60403749" lat="48.5584212" lon="12.1071380" version="8" 
  timestamp="2008-12-15T19:44:59Z" changeset="397422" uid="14502" user="blutsauger"/>
 <node id="60974942" lat="48.5529181" lon="12.1036861" 
  version="5" timestamp="2013-06-05T20:16:22Z" changeset="16437079" uid="129061" user="Singvogel"/>
 <node id="60975133" lat="48.5555168" lon="12.1022909" 
  version="8" timestamp="2013-06-05T20:16:22Z" changeset="16437079" uid="129061" user="Singvogel"/>
 <node id="130251197" lat="48.5559983" lon="12.1221390" version="3" 
  timestamp="2012-09-11T18:07:23Z" changeset="13072996" uid="701122" user="hummelchen"/>
 <node id="130251198" lat="48.5559210" lon="12.1221270" version="3" 
  timestamp="2012-09-11T18:07:23Z" changeset="13072996" uid="701122" user="hummelchen"/>
 <node id="130251199" lat="48.5545124" lon="12.1182772" version="7" 
  timestamp="2010-10-25T16:09:23Z" changeset="6174866" uid="18315" user="gernot">
   <tag k="name" v="Landshut / Altdorf"/>
   <tag k="traffic_sign" v="city_limit"/>
 </node>
 <node id="130251200" lat="48.5553591" lon="12.1199496" version="3" 
  timestamp="2012-09-11T18:07:23Z" changeset="13072996" uid="701122" user="hummelchen"/>

Wege im OSM Export

Eine weitere wichtige Frage ist: Welche Verbindungen haben die Nodes untereinander wird ein wenig weiter unten im Export beantwortet. Ein weg listet alle zu ihm gehörenden Nodes auf. So gehören Z.B. die Knoten "60974942" und "60975133" zum weg "An der Bahn". Ihre Position (via gps) konnten wir ja schon aus dem oberen teil des Exportes ermitteln.


<way id="8591118" version="6" timestamp="2013-01-14T16:58:46Z" changeset="14650538" uid="179033" user="user_179033">
   <nd ref="60974942"/>
   <nd ref="60975133"/>
   <tag k="highway" v="footway"/>
   <tag k="name" v="An der Bahn"/>
 </way>
 <way id="8818311" version="5" timestamp="2011-05-27T19:37:17Z" changeset="8265957" uid="149876" user="dbusse">
   <nd ref="63658314"/>
   <nd ref="253122101"/>
   <nd ref="63659852"/>
   <nd ref="182683426"/>
   <tag k="highway" v="residential"/>
   <tag k="name" v="QuerstraÃe"/>
 </way>

Es gibt auch Nodes die Elemente von mehreren Wegen sind. Sie entstehen immer an Ein und Ausfahrten oder an Kreuzungen.

Parsing mit SAX

Da jetzt klar ist wie die Daten aussehen die aus dem OSM Export purzeln - können wir uns daran machen sie mithilfe des SAX parsors ein eine für das Routing geeignete Datenstreukur zu verwandeln. Eigentlich interessieren für das Routing später nur die Nodes die Element eines oder mehrere Wege sind. Mit Wegen meine ich einen <way> mit dem <tag k="highway" v="IrgendWas"/> den auch die Zugehörigkeit eines nodes zu einer Wiese oder einem Haus wird in OSM als way gespeichert. Leider liegt diese Information beim beginn noch nicht vor sodass erstmal alle Nodes eingelesen werden müssen. Und wir später dann die weg werfen die nicht zu einem Weg gehören.

Los geht es mit dem Parsen der Nodes: Da wir wie gesagt noch nicht wissen ob wir den node später noch brauchen oder nicht speichern wir ihn erst mal in der Datenbank (db) ab. Dabei hält das Node Opjekt alle wichtigen Informationen.


class node():
  def __init__(self,id,lat,lon):
     self.id = id
     self.connections = []
     self.tempconnections = []
     self.lat = lat
     self.lon = lon

Sind alle Nodes eingelesen geht es mit den Wegen (way) weiter. Leider ergibt sich auch hier ein kleines Problem. Denn der <tag> der uns sagt ob der Weg eine Straße eine Wise ein Haus ein Industriegebiet oder sonst etwas beschreibt steht erst relativ weit hinten. Sodass man erst mit erreichen des </way> mit sicherheit sagen kann ob man die Informationen braucht oder nicht. (Siehe: Landshut_Projekte#Wege_im_OSM_Export) Um später nicht hunderte unnötiger Verbindungen Zwischen Nodes zu haben die für das Routing absolut unerhelblich sind habe ich mir entschlossen das node Objekt mit einem temporären Speicher für Verbindungen zu anderen Nodes zu versehen (addConnection()). Über dessen Löschung (discardChanges()) oder permanenten Speicherung (saveConnections()) dann beim erreichen des </way> entschieden wird.


class node():
       def __init__(self,id,lat,lon):
               self.id = id
               self.connections = []
               self.tempconnections = []
               self.lat = lat
               self.lon = lon
               self.cameFrom = None
               self.distanceToDest = 0.0 #how the crow flys
               self.distanceFromStart = 0.0
               self.explored = False
               self.known = False
               print "new node with id: " + self.id + " created"
               print "lat: " + self.lat + " lon: " + self.lon
       def addConnection(self,connection):
               self.tempconnections.append(connection)
       def saveConnections(self):
               print "saving connection"
               self.connections.extend(self.tempconnections)
               #delete tmp elements
               self.tempconnections = []
       def discardChanges(self):
               print "removing connection from nonway"
               self.tempconnections = []

Die Verbindung zwischen zwei Nodes speichere ich dabei im Connection Objekt. Später könnte es noch dahingehend ausgebaut werden auch die Beschaffenheit der Verbindung (also die Straßen güte, erlaubte geschwindigkeit usw.) zu speichern um darüber das routing zu beeinflussen. Oder um Restriktionen Z.B. eine Einbahnstrasse abzubilden. Vorerst speichert es aber nur die Referenz der beiden Node Objekten (node1 und node2) zwischen denen die Verbindung besteht. Die Referenz auf das Connection Objekt ist auch in beiden Nodes (node1 und node2) hinterlegt damit jeder die Möglichkeit hat über das Connection Objekt den anderen zu finden.


class connection():
       def __init__(self,wayId,node1,node2):
               self.node1 = node1
               self.node2 = node2
               self.wayId = wayId
               node1.addConnection(self)
               node2.addConnection(self)
               print " Connection between: " + node1.id + " and " + node2.id + " created"
       def printConnection(self):
               print "Saved Connection between: " + self.node1.id + " and " + self.node2.id + "! "
               #print "<printing connection done>"
       def getOtherNode(self,node):
               if (node == self.node1):
                 return self.node2
               else:
                 return self.node1

Aufräumen der Datenbank

Sind alle Informationen erfasst - So kann man sich auf das aufräumen der nicht mehr benötigten Nodes machen. Jeder Node der zu diesem Zeitpunkt keine Verbindung zu einem anderen anderen besitzt ist für das Routing entbehrlich und kann gelöscht werden. Die Node DB basiert zum jetzigen Zeigepunkt noch auf auf einem python [dictionary] worauf sicher verzwichet werden könnte.

Routing via A*

Bis hier hin war es ein schweres Stück. Gleich vorweg sei gesagt dass der von mir zusammen geschusterte Algorithmus keine Meisterleistung ist und man sich deswegen auch keine Wunder erwarten sollte - es gibt etliche Restriktionen. Aber er funktioniert und veranschaulicht das Konzept. Bevor man hier weiter eintaucht empfehle ich die Lektüre zum [A*-Algorithmus]

Beim Routen arbeite ich mit 2 Listen:

Den knownNodes und den exploredNodes.

Liste der knownNodes

In der Liste der knownNodes sind alle Nodes gespeichert die noch für das finden einer möglichen Route zur Verfügung stehen.

- Ihre entfernung vom StartNode und die Entfernung zum Ziehlnode wurde schon ermittelt (raiseKnowledge())
- Ihre weiterführenden Verbindungen (conncections) wurden aber noch nicht untersucht
- Sind alle Connections des Nodes erfasst (in der Liste der KnownNodes giblt der Node als explored)

Liste der exploredNodes

In der Liste der exploedNodes sind alle Nodes gespeichert die bereits vollends erforscht sind. Ihre Connections sind entweder auch "explored" oder zumindest "known".

Bei meinem einfachen vorgehen ist es dem Routenfindungs Algorithmus der Einfachheit halber verboten einen knoten mehrfach anzusteuern.

Let there be Routing

Zu beginn sind beide Listen leer. Start und Ziel Node ID werden festgelegt.


   exploredNodes = []
   knownNodes = []
   tmpNodes = []
   startId = "1554790199"
   endId = "280095678"

aus der Datenbank holt man sich das zur Node id gehörende Node objekt. startNode = db.getNode(startId) der Start node ist der erste bekannte Node. Noch ist unbekannt wie weit er vom Ziel (Luftlinie) weg ist. Also darf er als erster in die liste der knownNodes.


   nowNode = startNode
   knownNodes.append(nowNode)

Und der Algorithmus kann gestartet werden. Er läuft solange bis das Ziel erreicht


(nowNode != endNode)

ist oder bis es keine Möglichkeiten mehr gibt einen Weg zu finden (was der fall ist wenn alle Nodes in der exploredNodes Liste sind und keine knownNodes mehr verfügbar sind).


(len(knownNodes) > 0)

Als erstes entfernt der Algorithmus den gerade aktuellen Node nodNode von den knownNodes und fügt ihn zu den exploredNodes hinzu. Dann wird der Node explored das heißt die Verbindungen von ihm zu weiteren Nodes werden gesucht. Dann wird überprüft ob diese Nodes bereits in der knownNodes oder in der exploredNodes Liste sind. Ist das nicht der Fall werden einige Berechnungen durchgeführt (raiseKnowledge()) und sie zum werden zur knownNodes Liste hinzugefügt. Bei der Durchführung der Berechnungen wird ermittelt:

wie weit ist es (Luftlinie) bis zum Ziel? (self.distanceToDest)
wie weit ist es zwischen nowNode und diesem neuen node? (distanceFromPrefNode )
welche Strecke wurde bis hier her zurückgelegt (= Die strecke vom nowNode bis zu diesem Node + die im NowNode als schon zurückgelegt gepeicherte Strecke). (self.distanceFromStart )
Zusätzlich speichert jeder Node eine Referenz auf den node über den er "known"

wurde. Dies dient dazu um am ende den Weg durch die Nodes zu finden. Die Funktion ist teil des Node Objekts:


def raiseKnowledge(self,prefNode,destNode):
   print "going to know more about: " + self.id + " Score: " + str(self.getScore()) + " prfNode was: " + prefNode.id
   distanceFromPrefNode = calcDistance(prefNode,self)
   print "\t distanceFromPrefNode: \t" + str(distanceFromPrefNode)
   self.distanceFromStart = prefNode.distanceFromStart + distanceFromPrefNode
   print "\t distanceFromStart: \t " + str(self.distanceFromStart)
   self.distanceToDest = calcDistance(self,destNode)
   print "\t distanceToDest: \t" + str(self.distanceToDest)
   self.cameFrom = prefNode
   self.known = True

Im nächsten schritt suchen wir aus der Liste der knownNodes den besten kandidaten heraus um ihn im nächsten Durchgang zu erforschen exploren.


nowNode = findTopNode(knownNodes)

Der beste node ist der Node der geschätzt die kürzeste Strecke bis zum Ziel hat. Diese setzt sich zusammen aus der schon (seit dem Startpunkt druch die anderen Nodes zurück gelegte) strecke + der Luftlinie bis zum Ziel. Um den wert zu ermitteln verfügt das Node objekt die getScore() Funktion.


def getScore(self):
   if self.known:
      return self.distanceFromStart + self.distanceToDest
   else:
      print "error: !!!NODE NOT KNOW!!!"
      return 0.0

Ist der neue beste Node gefunden Startet der Algorithmus mit ihm als nowNode und sucht nach weiteren Wegpunkten. Das ganze wiederholt sich bis eines der oben genannten abbruchkriterien erreicht wurde.

Ist der Algorithmus erfoglgreich durch laufen. Das heißt dass der ZielNode erreicht wurde. Schnappt man sich den letzen Node und hangelt sich durch die zuvor gespeicherten "self.cameFrom" referenzen durch bis zum Anfang.


   print "I came to " + nowNode.id
   while (nowNode.cameFrom != None):
     print " via " + nowNode.cameFrom.id + "\t Link: http://www.openstreetmap.org/node/"+nowNode.cameFrom.id
     nowNode = nowNode.cameFrom

Full Python Skript

Das ganze Python Skript könnt ihr gerne bei mir runter Laden. [Link Zum Skript]. Das skript erwartet als Parameter eine Datenquelle im OSM xml export Format.


./router.py StadtXY.xml

Es würde mich freuen wenn bei einer Wiederveröffentlichung einer ev. verbesserten Version das auch das Mini Tutorial hier verbessert oder ergänzt würde. Bitte haltet dabei die Sache hier so einfach wie möglich. Schließlich soll sie einen leichten einstieg bereiten.

Gruß Tobias

2014-03 FOSSGIS

Vier wirklich impulsive Tage mit knapp 600 Teilnehmern gaben reichlich Gedankenfutter zu allen möglichen Themen. Und obwohl das Wetter eigentlich blendend war, saßen wir von früh bis spät in muffligen Hörsälen wie zu Studienzeiten um uns die creme de la creme deutscher OSM'ler nicht entgehen zu lassen.

Peda und Tobi haben sich mächtig ins Zeug gelegt und gleich mehrere Vorträge geliefert, ich (Alex) hab auch ein wenig mitgemischt. Hier die Liste der Niederbayerischen Vorträge:

Alex, Tobi und Peda: [1]
Tobi: [2]
Peda: [3]

2014-03-14 Flyer

Unser neuer localized Flyer wurde gedruckt und hat auf der FOSSGIS die ersten Interessenten getroffen. Mehr Exemplare habe ich noch auf Vorrat.

2014-03-11 Fernsehproduktionen in IsarTV

Am 11.3.2014 haben uns Marco und Chris von IsarTV bei unserem Stammtisch besucht und einen netten Video-Clip erstellt:

Kurzfassung des Niederbayerischen OSM Stammtisch: [4]
Lange Version: [5]

2014-02 Zeitungsartikel

Um unsere erfolgreiche Arbeit in Landshut, v.a. bzgl. der Hausnummern etwas der Öffentlichkeit kundzutun, haben wir mit Sebastian Geiger von der Landshuter Zeitung Kontakt aufgenommen. Wir haben uns zu einem Interview-Termin in unserer Stammtisch-Lokalität zusammengefunden. Sebastian hat eifrig Notizen auf seinem kleinen Schreibblock gemacht und sich ganz offensichtlich (wie im Artikel zu erkennen ist) gewundert, was für ein seltsames Volk die OSM'ler doch sind.

Daraus ist ein sehr unterhaltsamer und informativer halbseitiger Artikel in der Landshuter Zeitung geworden. Die Publikation in unserem Wiki ist seitens der Redaktion ausdrücklich erwünscht unter Nennung der Quellenangabe:

Autor: Idowa - Landshuter Zeitung - OSM/OpenStreetMap - 'Vier Männer und die Hausnummern', von Sebastian Geiger 28.02.2014

(Noch besser wäre eigentlich gewesen: 'Männer, die auf Hausnummern starren' ;)

Link zur Kurzfassung auf der Website der LAZ

Und hier der komplette Artikel - Klick auf Bild (und dann links unten 'original file') zum Vergrößern:

Siehe auch die Listung in OSM in the media

2014-01 Rettungspunkte

Im 'Kasblatt' der Gemeinde wurde geschrieben, dass sog. Rettungstreffpunkte aufgestellt werden sollen. Schilder mit einem kurzen Code, der Landkreis und Rettungspunkt-Nummer beinhaltet, damit Verunglückte schnell Hilfe anfordern können. Zugang für Fahrzeuge und Hubschrauber sollen dabei garantiert sein, und gleichzeitig einen kurzen Weg in Waldgebiete ermöglichen. Halte ich für eine vernünftige Idee als Biker, also versucht Kontakt zu knüpfen.

Über die Gemeinde erhalte ich eine Verbindung zum Landshuter Forstmeister, der wiederum in Freising seine Niederlassung hat, die den groben Kreis Landshut verwaltet. Die Fortsverwaltung genehmigt uns die Übernahme der Daten in OSM. Weitere Ideen erstrecken sich auf eine Bayern- oder sogar Deutschland-weite Erfassung. Nachtrag 2020: leider erweisen sich diese Daten als durchaus fehlerbehaftet und geben nicht unbedingt die echte Lage vor Ort wieder. Daher sollten Rettungspunkte erneut kontrolliert und erfaßt werden.

Das bayerische Tagging-Schema sähe wie folgt aus, siehe auch unten das Proposal:

<tag k="highway" v="emergency_access_point">
<tag k="ref" v="<NUMMER_DES_RETTUNGSPUNKTES>">
<tag k='operator' v='Bayerische Staatsforsten'/>
<tag k='description:de' v='Ortsmitte in Oberweiler an der Kirche'/>

Wobei die Beschreibung ebenfalls von der Forstverwaltung stammt und der schnellen Orientierung dienen soll.

[Rettungspunkte Karte auf OSM Basis|http://www.rettungspunkte.info/RescuePointsMap.aspx?c=1]

[Diskussion auf der ML|http://forum.openstreetmap.org/viewtopic.php?id=8604]

[Anmeldung zum Download|http://www.baysf.de/de/home/unternehmen_wald/aktuelles/rettungstreffpunkte.html]

Proposal für das Tagging

Pressemitteilung

geplante Veröffentlichung bundesweiter Rettungspunkte am 24.01.2014

2014-01-22 innodatec

Ich hatte ein ausführliches Telefonat mit der Firma innodatec, die die Seite www.rettungspunkte.info betreibt. Deren - sehr ambitioniertes - Ziel ist es, europaweit die Rettungspunkte einheitlich zu erfassen. Dieses Bestreben gibt es derzeit auch von staatlicher Seite bzw. der Landesforsten, die dann wiederum unterscheiden müssen zwischen Staats-, Privat- und Landesforst.

innodatec bietet eine Dienstleistung an, d.h. der Förster geht mit seinem iPad an eine Rettungsstelle, macht dort ein Foto, nimmt die GPS Koordinaten auf und erstellt eine Beschreibung. Die Firma wiederum bietet diese Datenbank den Rettungsleitstellen als Web-Portal an. Letztere nutzen diesen Dienst kostenlos, die Forstämter müssen für diesen Dienst zahlen (ca 50 EUR einmalig für das Schild und 5 EUR pro Jahr für die Instandhaltung/Wartung/Garantie etc...).

Wie ich finde, eine nette Startup-Idee, verträgt sich leider nicht mit OSM, weder in der einen noch in der anderen Richtung: 'Wir' bekommen diese Daten nicht, da es ja sozusagen das Kapital der Firma ist, diese wiederum will die OSM Daten nicht verwenden, weil sie nicht zuverlässig genug sind und Haftungsfragen auftreten.

Interessant bei dem Gespräch war, dass die Rufnummer 112 gerade im grenznahen Bereich dazu führt, dass beispielsweise die Leitstelle in Belgien oder Holland erreicht wird, die wiederum mit den (Bundes-)Land-spezifischen Rettungspunkt Nummern überhaupt nichts anfangen können.

Dann habe ich erfahren, dass es beispielsweise in Bayern ca 10.000 Rettungspunkte gibt, wir haben von den bayerischen Landesforsten aber gerade mal 3.000 genannt bekommen. Da kocht also weiterhin jeder sein eigenes Süppchen, womit private Forstwirte, Landesforsten, Staatsforsten, kommerzielle Unternehmen, Rettungsleitstellen und schließlich wir als OSM community noch einige Zeit zu kämpfen haben werden, für einen eigentlich sehr wichtigen Beitrag zum Rettungssystem.

Dem entgegen steht, dass die Landesforsten ihre Daten der Öffentlichkeit zur Verfügung stellen wollen, in einer OSM-kompatiblen Lizenz. Die Qualität der Messpunkte ist jedoch eher mangelhaft zu bezeichnen. Also stellen jetzt wahrscheinlich unterschiedliche Einrichtungen jeweils ihre Schilder in den Wald und die Rettungsdienste müssen mit unterschiedlichen Datenanbietern zurechtkommen.

2013-09-02 Hausnummernliste Stadt Landshut

Ist Stand

Ende August 2013 erhielten wir von der Stadt Landshut eine Liste mit georeferenzierten Hausnummern. Die Georeferenz liegt in Form von Gauß-Krüger Koordinaten vor, die Hausnummern erfassen das Stadtgebiet von Landshut. Voraussetzung für den Erhalt ist/war die Zusage, die Daten in ihrer Rohform nicht zu veröffentlichen und nur für die Einpflege in OSM weiterzugeben. Uns wurde ein Update der Daten jedes Quartal versprochen.
als Ansprechpartner für die Stadt fungieren Gernot und Blutsauger

Details zu der Arbeit mit den Daten: Landshut/Adressdaten Vergleiche dazu auch verwandte Projekte in Passau/Adressdaten München...?

Nach ca 2 Monaten Arbeit zu viert waren gut 14.000 Adressen übertragen.Die Stadt Landshut nahm das Ergebnis positiv auf. Es sollte noch eine Veröffentlichung in der lokalen Presse erfolgen, um andere Gemeinden zu animieren. In der OSM community gab es bei Import-Themen die üblichen Nachfragen bzgl. der Lizenz. Dabei ist zu bemerken, dass Landshut ein eigenes Vermessungsamt hat, und damit die 'Hoheit' über die Daten. Umliegende kleinere Gemeinden unterliegen dem staatlichen Vermessungsamt, welches sich wohl weniger kooperativ zeigt.

Aussicht

Im Landshuter Umland verfügen eventuell auch andere über georeferenzierte Hausnummern. (Altdorf? Kumhausen?) Sobald das Hausnummern Projekt in Landshut einen vorzeigbaren Status erreicht hat, könnte man dies als Anreiz/Argumentationshilfe nutzen um auch hier Daten zu erhalten.

Vorgehensweise in JOSM

OSM Daten und Hausnummern in zwei getrennte Layer laden. Mit Shift+A <nummer> kann man den aktiven Edit-Layer umschalten. Und dann mit Ctrl-C und Ctrl+Shift+V die Attribute vom Node auf das Haus uebertragen.

--- zeitliche Reihenfolge umgekehrt --

2013-09-02 Von hier nach unten ist die Reihenfolge der Projekte: oben alt, unten neu.

Aus der Sicht eines blogs ist es aber wohl sinnvoller, immer das neueste oben zu haben...

Altstadtvermessung 28.08.2011

English summary

As GPS reception in our historic city centre is quite bad, we organized a geodetic survey of Landshut's Altstadt in August 2011. All points tagged with source_ref to this page were measured with a maximal deviation of 50cm. So please do not adjust those points against Bing or other images which are much less precise than our results!

Einführung

Da der GPS-Empfang in der Altstadt von Landshut sehr schlecht ist, haben wir eine Vermessung mit professionellem Equipment am 28.08.2011 organisiert.

Datenerfassung und Konvertierung

Die Daten wurden vor Ort mittels Tachymeter in Gauß-Krüger-Koordinaten (Streifen 4) erfasst.
Weiterhin wurden Fotos aller Häuser und Hausnummern angefertigt - zum Einen, um Zweifelsfälle zu klären und zum Anderen, um die Geschäfte mappen zu können.
Die Umwandlung in Weltkoordinaten erfolgte mittels des Java-Rechners des Bundesamt für Kartographie und Geodäsie. Dazu wurden zunächst alle Spalten außer Rechts- und Hochwert entfernt. Einstellungen:
- Ausgangssystem: GK4
- Zielsystem: GEO_WGS84
- Transformation: Verschiebungsgitter DHDN_WGS84_Beta2007
Dem Ergebnis-File wurden die entfernten Spalten manuell wieder hinzugefügt und das Ergebnis unter Linux mit folgendem Shell-Script in ein GPX-File konvertiert

declare -i i=0
while read nr lon lat typ; do
  echo "<wpt lat=\"$lat\" lon=\"$lon\">"
  echo "<name>$(printf %03i $i)-$typ-$nr</name>"
  echo "</wpt>"
  i=i+1
done < LA-altstadt-wgs84.txt > LA-altstadt-wgs84.gpx

Anschließend wurden Header und Footer von einem gültigen GPX-File von einem Garmin-Gerät übernommen.

Daten

Rohdaten der Vermessung
- Spalte 1: Punktname. Das linke Eck (von der Straße aus betrachtet) eines Hauses bekam die Hausnummer als Punktname. Folgt rechts daneben gleich ein weiteres Haus, so wird wieder dessen linkes Eck benannt. Folgt rechts eine Straße oder Durchgang, so wird das rechte Eck mit Hausnummer plus einer weiteren Ziffer ergänzt, um dies anzuzeigen (Beispiel: Häuser 70+71 stehen nebeneinander, rechts neben 71 ist ein Durchgang. Dann heißen die Punkte von links: 70, 71, 715). Für Kirchen wurden vierstellige Nummern vergeben. Die Datei enthält noch einige Punkte auf der Straße - diese waren zur Eichung des Gerätes erforderlich.
- Spalte 2: Rechtswert: Längengrad: sieben Stellen vor dem Komma, beginnt immer mit 4, 4 bezeichnet den Sektor in dem vermessen wurde, die anderen sechs Stellen sind im Prinzip eine Entfernungsangabe in Meter, wobei 500 000 der 12te Längengrad ist. 511 000,000 ist 11 000 Meter (11 km) östlich des 12ten Längengrades.
- Spalte 3: Hochwert: Breitengrad: sieben Stellen vor dem Komma, gibt die Entfernung zum Äquator an (geografische Breite).
- Spalte 4: Höhe über NN: 3 Stellen vor dem Komma, stimmt nicht, weil wir die Höhe des Prismas oft verstellt haben.
- Spalte 5: Punktcode: 3 stellig: 100 = alles Mögliche, 101 Hausecke, 300 Hausecke an einer Straße, 103 Eingang z.B. Martinskirche.
GPX-Datei mit Weltkoordinaten
- Die Punktnamen sind folgendermaßen aufgebaut: lfdNummer-Punktname-Punktcode. lfdNummer diente dabei zur Korrelation mit den Fotos. Punktname siehe Spalte 1 oben, Punktcode, siehe Spalte 5 oben.

Fotos

Auszug der Mapping-Fotos

Mapping

Das Mapping erfolgte in JOSM. Entsprechend dem geladenen GPX-File wurden die vermessenen Punkte entlang der Altstadt eingezeichnet und die restlichen Hausumrisse an Hand der Bing-Luftbilder ergänzt.
Geschäfte wurden an Hand der Fotos eingetragen. Diese wurden i.d.R. als Punkte gesetzt statt das komplette Gebäude entsprechend zu taggen, da die Häuser in der Altstadt i.A. zusätzlich zu den Geschäften im EG noch in den oberen Stockwerken bewohnt sind.

Ausrüstung

Trimble TODO

Beteiligte

Duck (Bereitstellung Equipment, Vermessung)
Czmartin (Organisation, Vermessung)
Gernot (Fotos, Datenkonvertierung)
F6F (Basisstation am Tachymeter, Öffentlichkeitsarbeit ;-) )

Nochmals herzlichen Dank an Duck für die Bereitstellung des Equipment!

ÖPNV

Die liste ist nur eine Hilfe und erhebt keinen Anspruch auf Vollständigkeit und beschränkt sich aufs erste auf Die Stadt- und Airport Linie. Express, Abend und Schüler Linie können meiner meinung nach später noch ergänzt werden. --F6F 09:51, 14 October 2010 (BST) (eine linie 13 such man auf dem Plan vergeblich sind wohl ein wenig abergläubisch die Jungs :-)

Übersicht der Buslinien

01_Altdorf/Preisenb

Farbe b3df5c

02_Altstadt/Ergolding

Farbe f68712

03_Auloh/Wolfgangsiedlung

Farbe b365b9

04_PiflaserWeg/LAWest_HBF

Farbe ec008c

05_EvAltenheim/Moniberg

Farbe 108449

06_Auwaldsiedlung/Eugenbach

Farbe 1a598c

07_Mitterwoehr/ObereAltstadt

Farbe 127bca

08_HBF_Altdorf/Eugenbach

Farbe fddd04

09_Altstadt/Guendlkoferau

Farbe 4dvd38

10_Lainerbuckel/Laendtorplatz_HBF

Farbe 8c2b99

11 ????

Farbe 9e7b65

12_Altstadt/Ergolding

Farbe 26b9f1

14_Wolfsteinerau/Altstadt

Farbe e4a230

Airport

Farbe 6ba3dc

Fehlende Haltestellen

Linie 1:

ort/haltestellen name

Altdorf / Im Kleinfeld
Kumhausen / Äußere Stelze
Kumhausen / Jahnpl.
Kumhausen / Ludwig-Thoma-Str.
Kumhausen / Kumhausen
Preisenberg / Preisenberg

Linie 4:

La / Regensburgerstraße
La / Pifflasser weg
La / Rothaler Straße

Linie 8:

ort/haltestellen name

Altdorf / Haschaerkeller
Karl-Holzer-Str.
Elisabethstr.
Franz-v-Kobell-Str.

Linie 7:

ort/haltestellen name

Hofberg / Kinderkrankenhaus
und weitere

Airport Linie: ort/haltestellen name

Landshut / Querstraße
Landshut / Münchnerau
Mosburg / Mosburg-Nord A92
Schwabing / Schwabing-Industriegbebiet
München Airport / München Airport Center
München Airport / Besucherpark

Open Issues

kleines Relationsproblem in der nähe des Landshuter Brauhauses
die Umstellung auf die neuen (http://wiki.openstreetmap.org/wiki/DE:%C3%96pnvkarte) ÖPNV tags steht noch aus

Recourcen

Ein Schematischer Verlauf der Linien ist hier einsehbar (PDF).

Details gibts hier: http://www.stadtwerke-landshut.de/fileadmin/files_stadtwerke/stadtbusse/stadtlinie/bilder/liniennetz-stadtlinie-geo.pdf Der Fortschritt in der Erfassung kann unter

http://www.öpnvkarte.de/?zoom=13&lat=48.54706&lon=12.15054&layers=BT oder unter

http://openptmap.org/?zoom=13&lat=48.54083&lon=12.14138&layers=B0000TFT

betrachtet (und bedauert) werden.

--F6F 12:49, 31 August 2011 (BST)

Historie

Projekte für die Zukunft

RBO Verbindungen im Umland

Fahrradkarte für Landshut

Andreas vom ADFC versucht seit Sommer 2011 ein Rendering für Fahrradwege in Landshut zu erstellen. Ziel ist es, eine druckbare Karte zu erhalten. Verschiedenen Renderer stehen zur Auswahl: Mapnik, TilesAtHome (Osmarender) und Maperitive.

Die aktuelle Maperitive Karte wird einmal pro Woche neu gerendert und ist hier als SlippyMap zu sehen.

Ein paar Diskussionen in der Mailingliste sind hier zu sehen: [6]

Hier eine Zusammenfassung der Zwischenergebnisse:

Ausgangspunkt war wohl die openfietsmap der Niederlande, die für das Garmin eine extra Karte aufbereiten: Homepage
Andreas' (aufgegebener) Versuch, einen eigenen osma-Renderer für Fahrradrouten in Landshut zu erstellen: HowTo (Als problematisch hat sich bei Osmarender gezeigt, dass die xsl-Stylesheets keine Möglichkeiten bieten, Linienversatz darzustellen, was insbesondere problematisch ist, wenn nur auf einer Straßenseite der Radweg versetzt zur Straße geführt wird. Mit Maperitive geht das, s.u.!)
Ausgangsbeispiel zum Selbermachen mit Maperitive Sourcecode
Lübecker Radel-Stadtplan, die ebenfalls Maperitive verwenden Wiki, SplippyMap Deren Einleitung zu Maperitive
- Das ist nicht ganz korrekt. Für den Lübecker Stadtplan wurden der Weg Overpass-Osmosis-Postgresql/Postgis-QuantumGis-Scribus benutzt, zuzüglich einem Haufen eigener Scripte. Der Kartograph
in Gegensatz zu den Lübeckern möchte ich die Routenempfehlungen über relations darstellen, meiner Meinung nach hat das nichts in den Way-Tags zu suchen. Relations für Radwegebeziehungen brauchen network=lcn (für LocalNeTwork), route=bicycle und type=route. Als Unterscheidung zwischen den beschilderten offiziellen Routen und unseren Empfehlungen vom KV Landshut hätte ich das Operator Tag verwendet. "Stadt Landshut" bzw. "ADFC Landshut".
Die erste Testroute ist eingerichtet und verläuft von der Altstadt zum Hauptbahnhof
Für JOSM-Anwender ist das hier vielleicht ein cooler Link: [7] Eine Vorlage mit der sich die Radwege und Radwegerelations sehr leicht eintragen bzw. verbessern lassen. Allerdings ein Wort der Warnung zu der Bezeichnung "linksseitig" / "rechtsseitig" bei den Straßenbegleitenden Radwegen: was bei einer Straße aus links bzw. rechts gilt aus Sicht des way-Vektors der Reihenfolge wie die Notes in JOSM erfasst wurden (hab ich das richtig und verständlich erklärt?)
Noch ein Link, wie man in JOSM Fahrradrouten-Relationen leichter editieren kann (Mail von czmartin am 4.11.11) [8]

Maperitive-Einstellungen (kurz Notiz)

// Gebiet auf Landshut einschränken, bei wenig Speicher, noch kleineren Ausschnitt wählen!

bounds-set 12.06,48.5109,12.25,48.5936
im Menü Map - Download OSM-Data auswählen um die aktuellen Daten vom Server zu holen
die Zeichenregeln müssen als Textdatei mit der Endung .mrules (ADFCLandshut.mrules Beispiel) ins Unterverzeichnis rules der Maperitive-Installation kopiert werden (einmaliger Schritt!)
die Zeichenregeln einbinden mit use-ruleset location=Rules/ADFCLandshut.mrules (einmalig, danach auch über das Menü auswählbar unter Map - Switch to Rules)
die Zeichenregeln ausführen lassen mit apply-ruleset
ggf. die Überlagernden OSM-Kacheln rechts unten bei den Layers abschalten, damit man das Ergebnis auch sieht.
Rendern der gewünschten Auflösungen für den Webserver mittels generate-tiles minzoom=1 maxzoom=17 tilesdir=\\psf\Home\Sites\Radlstadtplan_Landshut\website\Tiles
tilesdir ggf. auf den eigenen gewünschten Pfad anpassen.
fertige Tiles ggf. noch auf den richtigen Webspace hochladen (es würde auch ein direkter FTP-Upload gehen, hab ich aber noch nicht probiert)
Codebeispiel ADFC_mrules

ADFC Fahrradkarte Lübeck

11/2012 gabs in den Wochennotizen folgenden Link auf den ADFC in Lübeck, der ein vergleichbares Projekt umgesetzt hat: [9]

OpenStreetBugs numerieren und ausdrucken

Karlo hat ein Javascript Framework programmiert, mit dem es möglich ist, OpenstreetBugs mit numerierten roten Kreisen zu versehen und parallel dazu eine Liste der Fehlerbeschreibung zu erzeugen. Hat den Vorteil, dass man sich beides ausdrucken kann: [10]

Anleitung: Man muss zunaechst im OpenStreeBugs selbst den entsprechenden Bereich heranzoomen, dann den Link auf das GPX-File mit oder ohne closed bugs in die Zwischenablage kopieren, und diesen dann bei Karlo's Seite wieder einfuegen. Der Rest sollte selbsterklaerend sein.

3D Rendering

OSM 2 World

Wer Gebäude mit Dächern und Fenstern versehen möchte, kann die Tags fuer Osm2World verwenden.

Das ganze ist zum Einsteigen relativ einfach, Hilfe gibt's in der ndb Mailingliste (für die, die eilig haben;) - Danke an die Crew aus Passau!

Ein paar Links dazu.

Beispiel Passau: Kirche

Martinskirche LA: Martinskirche

Neu-Ulm: Kirche

'Offizielle' Tagliste

Von Tobias Knerr unterstuetzte Tagliste

Und erweiterte Dachformen

Tools und Skripte

open Buildingmodels

http://openbuildingmodels.uni-hd.de/ http://www.osm-3d.org/map.htm

osm Buildings

http://flyjs.com/buildings/

Plakate drucken

Im Herbst 2012 begann eine Diskussion, wie man Plakate von OSM Karten erstellen kann, z.B. Wanderkarten oder Mapnik-Karten, um sie z.B. an Freizeiteinrichtungen oder Gemeinden aufzuhängen.

Thread in der ML: [11]

Da gibt es auch Links zu Bildern, weiss aber nicht, wie lange die noch vorgehalten werden.

Ein paar Notizen dazu:

Lars Ligner hat für solche Zwecke einen eigenen Renderer aufgesetzt und kann DIN-A0 Bitmaps mit verschiedenen Styles erzeugen.

Das ganze kann man in einer Online-Druckerei (z.B. saxoprint) für ca. 30 EUR drucken lassen. Das Ergebnis steht derzeit (6.11.12) noch aus. Das Bild muss als pdf verschickt werden, am besten geht das mit OpenOffice Draw, dort Seitenformat DIN-A0 einstellen und das Bild einbinden und als PDF exportieren. Der Upload zu saxoprint gestaltete sich als etwas schwierig, weil zuerst nicht klar war, dass keine .png's erlaubt sind, und das .pdf file hat dann wohl die maximale Dateigröße deren Uploadmanagers überschritten, allerdings kam keine entsprechende Meldung. Ein Telefonanruf ermöglichte dann jedoch einen Upload per FTP, das hat schließlich geklappt.

Um dieses riesige Bitmap (ca 40MB) selber auszudrucken, habe ich ein shell-Script erstellt, das es auf 4x4 Kacheln verteilt, die kann man dann z.B. bequem unter Windows ausdrucken.

Das größte Problem derzeit sehe ich noch in der zu kleinen Schriftgröße. Alles ist wunderbar detailliert aufgelöst, aber der ferne Betrachter benötigt evtl. einen größeren Font für Straßen- und Ortsnamen. Weitere Erfahrungen folgen...

18.11.12 - Hier mein Ergebnis:

Das Plakat sieht super aus, hochglanz auf schwerem Karton und in exzellenter Auflösung. Es entspricht ungefähr Zoomlevel 16 oder 17 bei Mapnik, d.h. jede Parkbank und fast jeder Strassenname ist eingetragen. Wie aber schon vorher bei meinem Probedruck vermutet, ist die Schrift zu klein, und die 'Wichtigkeit' verschiedener Elemente muss fuer solche Zwecke wohl im Mapnik angepasst werden. Vor allem sind die von mir angedachten 'highway=track' und ähnliche Wege praktisch nicht zu erkennen. Also hängt die Karte jetzt bei mir im Flur und nicht bei der Gemeinde. Bis zum nächsten Versuch. Trotzdem danke Lars für die Unterstützung!

Alex.

Gemeindegrenzen Bayern

In den Wochennotizen vom 18.11. wurde bekannt gegeben, dass die Gemeindegrenzen in Bayern der OSM Community übergeben werden. Link zur Mail: [12] Link zum Download von Niederbayern, kann man direkt in JOSM laden: [13]

Fertige Grenzen

12.12.2012 - Nur für historische Zwecke:

Es gibt Leute, die haben anscheinend echt zuviel Zeit, denn die Bayernkarte ist inzwischen komplett importiert:

Wiki zu den einzelnen Kreisen

Die Bearbeitungsliste vom Kreis LA habe ich aus dem Wiki rausgenommen, ebenso die Anleitung von Dietmar - eine alternative Anleitung findet sich hinter dem obigen Link.

Siehe auch im Wikipedia die Liste der Städte, Gemeinden und Verwaltungsgemeinschaften von Landshut.

Was in diesem Zusammenhang noch wichtig wäre: Die Strassenlistenauswertung. Derzeit ragen noch einige Strassen über Gemeindegrenzen mit ihrem 'name' Tag hinaus, was die Auswertung erstens erschwert und zweitens auch bei der Navigation zu Problemen führen kann. Es gibt wohl ein neues Strassenlisten-Auswertungskonzept, weiss aber nicht genau, wo das zu finden ist.

Admin Levels

Kreisfreie Städte erhalten den Admin level 6 als Städte begrenzung

nicht Kreisfreie Städte so wie Deggendorf haben den level 8 und die zughörigen Städte des Kreises ebenfalls. Der Kreis erhält level 6

Rendering Projekte von Tobi und Alex

Um diese Seite nicht zu überfluten, sind die Dokumentation diverser Experimente zum eigenen Rendern v.a. für Printmedien auf eine andere Seite verlinkt...

Eigener Mapnik Server

25.12.2012

Tobi hat sich die Mühe gemacht, herauszufinden, wie man einen Mapnikserver aufsetzt. Wir haben bei mir (Alex) jetzt einen Server stehen mit debian-System, mit dem Ziel Karten für eigene Bedürfnisse zu rendern. Ziel ist es, interessierten Usern einen Zugang per ssh zu gewähren und selber rumzuspielen. Weitere News folgen.

Hier ein paar Links zu HowTo's

Erfahrungen beim ersten SetUp

1. osm2pgsql braucht den --slim Parameter, damit werden temporaere Daten in der SQL Datenbank zwischengespeichert. Ohne den Parameter braucht man wohl erheblich mehr Speicherplatz. Das hier ist ein Rechner mit 4GB RAM und 3.5GB Swap, 64 Bit, der hat das ohne --slim fuer die bayern.osm nicht geschluckt:

 time osm2pgsql ~/bayern.osm -d osm -U osm -H localhost -W --slim

2. Beim eigentlichen Rendern (nach dem Import) mit

 ~/mapnik-stylesheets$ ./generate_image.py

Trat der folgende Fehler auf:

 RuntimeError: ERROR:  column "generator:source" does not exist
 LINE 7:          or (power='generator' and ("generator:source"='wind...

Angeblich liegt das an einem veralteten default.style, das befindet sich unter /usr/share/osm2pgsql und kann z.B. hier runtergeladen werden:

https://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql/default.style

Siehe auch OSM-Help zu diesem Thema:

https://help.openstreetmap.org/questions/11542/error-column-generatorsource-does-not-exist

Posterdruck

Im eingerichteten mapnik-stylesheets befinden sich alle relevanten Informationen, um die verschiedenen Styles in den verschiedenen Zoomlevel anzupassen. Das ist relativ einfach zu verstehen. Einige Styles werden in einem separaten include ('inc') Verzeichnis verwaltet. Der Rest befindet sich im osm.xml.

Wie schon mal weiter oben beschrieben, eignet sich der Zoomlevel 17 nicht für den Posterdruck, weil die Schrift zu klein ist. Deshalb die Idee, eine DIN-A2 Seite zu rendern und diese dann auf DIN-A0 zu skalieren. Dafür braucht man aber einen .svg export und kein .png.

Die entscheidende Modifikation im generate_image.py sieht so aus (auskommentierte Zeilen sind original Code):

   # render the map to an image
   im = mapnik.Image(imgx,imgy)
   mapnik.render_to_file(m, "image.svg")
   #mapnik.render(m, im)
   #im.save(map_uri,'png')

Die Region, die gerendert werden soll, befindet sich im generate_image.py relativ weit oben, dort werden die Weltkoordinaten und Pixel des Zielformats angegeben.

   bounds = (12.02,48.54,12.15,48.6)
   imgx=1683
   imgy=1190

Die Koordinaten in 'bounds' muss man sich irgendwie raussuchen, z.B. openlinkmap zeigt die rechts unten an. Wichtig ist, dass das Seitenverhältnis möglichst genau dem Zielformat entspricht, sonst passt mapnik den Ausschnitt und Zoomlevel selber an.

Es gibt im generate_image.py/mapnik auch keine fixen Zoomlevel. Der Grad der Details, wieviel Beschriftung angezeigt wird usw. hängt von der Auflösung (imgx/y) ab und dem Kartenausschnitt (bounds). Um das gewünschte Ergebnis zu erhalten hilft meistens nur Ausprobieren.

Will man nach .svg rendern, hat man aber keine Pixel. Schaut man sich ein generiertes .svg file an, sieht man in der ersten Zeile etwas wie:

   ... width="1683pt" height="1190pt"

Die Angabe 'pt' sind Punkt, das ist 1/72 Zoll, also die Auflösung, die zur Umsetzung von Weltkoordinaten auf Drucker-Koordinaten verwendet wird.

generate_image.py interpretiert die imgx und imgy Werte je nach Ausgabeziel. Bei .png Dateien sind es Pixel, bei .svg Dateien sind es pt bzw. 'Punkt'.

NOTE: Man kann also nicht einfach die Zieldatei umswitchen und erwarten, dass ein gleichgrosses Bild herauskommt!

Jetzt kommt ein wenig Rechnerei ins Spiel (1 Zoll=25.4mm):

Eine DIN-A2 Seite hat die Ausmaße 594x420mm im Querformat. Die Breite: 594 mm / 25.4 Zoll * 72 = 1683 Punkt.

Damit zwingen wir die World-Boundingbox auf eine DIN-A2 Seite. Das generate_image.py Skript generiert das .svg Bild.

Nachbearbeitung in Inkscape

Die Beschreibung bezieht sich auf Inkscape Ver. 0.47. Ich habe auch eine ältere Version ausprobiert, da ist aber der Verhalten beim Transform und page-properties Ändern komplett anders!

Das Bild wird im Inkscape geladen und in beiden Achsen per 'Transform' Operation verdoppelt (könnte man sicher auch hübsch per Skript erledigen). Statt in etwa 2100x1500 Pixel sollte das Bild in inkscape dann 4200x3000 Pixel bz. Punkt groß sein. Das entspricht einer Skalierung um 2 DIN-A Größen. Um nur einen DIN-A Schritt zu skalieren, verwendet man den Faktor 1.41.

Um ein .png zu erzeugen:

'Export to Bitmap' und darauf achten, dass die DPI Zahl auf 360 steht (das ist so der untere Standard bei Druckereien), Womit wir bei einer Auflösung von ca. 16.800x12.000 Pixel im exportierten Bitmap wären.

generate_image.py errechnet aus dem Verhältnis zwischen World- und Pixel-Boundingbox den entsprechenden Zoomlevel, der ist in dem hier genannten DIN-A2->DIN-A4 Beispiel bei 14 (geschätzt) und zeichnet nur noch die größeren Ortsnamen, keine Straßen etc. Durch Modifikation der styles kann man Elemente hervorheben; u.a. hat es sich bewährt, die weisse Umrandung ('halo') aus den Ortsnamen zu entfernen, da diese sich durch das Hochskalieren dann überschneiden.

Icons (skalieren)

Sämtliche Icons von POI's und auch die Tafeln für offizielle Straßenbezeichnungen (z.B. A 92, B 299) sind als .png's hinterlegt. Da stellte sich ein Problem beim nachträglichen Hochskalieren im Inkscape heraus, weil dann Treppen-Artefakte entstehen. Jedoch ist es inzwischen möglich, auch svg's für diese Icons zu verwenden. Die muss man halt selber erstellen - ist aber nicht weiter schwer.

Z.B. findet sich im osm.xml folgender Eintrag:

   <ShieldSymbolizer size="10" fill="#fff" placement="line" 
   file="&symbols;/pri_shield[length].png" spacing="750" minimum-distance="30" fontset-name="bold-fonts">[ref]
   </ShieldSymbolizer>

Den ersetzt man durch

  <ShieldSymbolizer size="10" fill="#fff" placement="line" 
  file="&symbols;/pri_shield[length].svg" type="svg" spacing="750" minimum-distance="30" fontset-name="bold-fonts">[ref]
  </ShieldSymbolizer>

'pri_shield1.svg' wäre dann z.B. ein Schild mit nur einem Buchstaben, pri_shield2.svg eines mit 2 Buchstaben usw. Man muss halt so viele Schilder malen wie man braucht oder schon .pngs da sind.

Es gibt auch einige Icon-Sammlungen, die .svg anbieten. Ein guter Einsprung hierzu ist hier.

Noch ein Beispiel - DIN-A3

Mein nächster Versuch ist, eine DIN-A3 Seite von der Landshuter Innenstadt zu generieren. Folgende Boundigbox habe ich verwendet:

  bounds = (12.14819,48.53311,12.1563,48.54025)

Das entspricht ziemlich einem DIN-A Hochformat. Mit

 imgx=841
 imgy=1190

Generiert man direkt ein .svg file für DIN-A3 (29.7 x 42 cm): 29.7 / 2.54 * 72 = 841.

Die vom mapnik Renderer ausgewählten Detailstufen passen da schon ziemlich genau zu dem, was für eine druckbare Version der Karte notwendig ist. Angedacht sind Schreibtischunterlagen (A3) oder Blöcke (A4).

Hintergrundfarbe/Generell Farben ändern

Der Hintergrund der 'Kontinente', d.h. alles was kein landuse o.ä. hat wird hier festgelegt:

inc/layer-shapefiles.xml.inc:

<Style name="coast-poly">
    <Rule>
      &maxscale_zoom10;
      <PolygonSymbolizer fill="#f2efe9"/>
    </Rule>
</Style>

Will man die Farbe eines Objektes ändern, dessen tag man nicht kennt, hilft es oft, nach der Farbe zu suchen. Aber Vorsicht: Mapnik wandelt die RGBA Farbwerte aus den XML Dateien nicht 1:1 nach .svg um, so dass eine Farbdefinition im .xml file von z.B. fill='#f2efe9' in inkscape dann als '#f0eee8' erscheint (Rundungsfehler...)!

Eine Postgres DB

Mit dem eigenen MapnikServer und der eigenen Postgis Datenbank kommen auch schnell die ersten versuche mit einen Querys und der Wunsch bestimmte Elemente zu finden.

In meinen ersten Versuchen ging es mir erst mal darum, grundsätzlich ein paar Geschäfte oder Ähnliches zu finden.

Pure SQL

Zum Beispiel alle Spielplätze in Passau:

 SELECT DISTINCT -- ausdünnung doppelter ergenisse
 ST_X(ST_Transform(playground.way,4326)) AS long, --Umrechnung der long koardinate vom internen Datenbank Mapnik format nach GPS
 ST_Y(ST_Transform(playground.way,4326)) AS lat,  --Umrechnung der lat koardinate vom internen Datenbank Mapnik format nach GPS
 playground.name AS title -- nimmt das "datum" aus der spalte name
 FROM planet_osm_polygon AS city -- von der Tabelle planet_osm_polygion
 JOIN planet_osm_point AS playground
 ON ST_CONTAINS(city.way, playground.way) --checkt ob der punkt im city polygon liegt 
 WHERE city.name = 'Passau' -- wo der stadtname Passau ist
 AND playground.leisure = 'playground'; -- und die spalte des playground "datums" playground ist

PHP funn

Wenn man ein wenig weiter fortschreitet kann man so eine Suche dann auch über PHP machen ....

 $db = new PDO('pgsql:host=localhost;dbname=osm;', 'apache', 'apache');
 $request = $db->prepare("
       SELECT DISTINCT
       ST_X(ST_Transform(point.way,4326)) AS long,
       ST_Y(ST_Transform(point.way,4326)) AS lat,
       point.osm_id AS id,
       point.addr_postcode AS pc,
       city.admin_level AS adminlevel,
       point.shop AS shoptype,
       point.amenity AS amenity,
       point.name AS title
       FROM planet_osm_polygon AS city
       JOIN planet_osm_point AS point
       ON ST_CONTAINS(city.way, point.way)
       WHERE city.name = :town
       AND point.shop != ;");
 $request->bindParam(":town",$town);
 $stmt = $request->execute();
 $results = $request->fetchAll(PDO::FETCH_OBJ);
 //print_r($results);
 print ("table-html-tag");
 for ($lineNum = 0; $lineNum < $request->rowCount(); $lineNum++){
   $object = $results[$lineNum];
   $id = $object->id;
   $lat = $object-> lat;
   $lon = $object-> long;

   //hier ein wenig ausgabe :-)
 }

der Parameter Town kann wahlweise über über PHP get übergeben werden irgendwie so:

 $town = htmlspecialchars($_GET["town"]);

Die verwendung von PDO (php data objects) ist die Wahl der Stunde wenn man später galant sql injections vermeiden will :-D

slow to slow

Leider sind Punkte nur die halbe Miete... oft sind shops oder anderes auch auf Polygone gemappt welche natürlich nicht mit dem oben aufgeführten Join mit der Punkte Tabelle gefunden werden können. Hier ist eine Suche Polygon in Polygon nötig. Dummerweise ist eine solche Suche sehr teuer. Bei einer Fläche von Niederbayern können schon mal 18 Sekunden vergehen, ehe man alle Shops, die in Landshut sind, gefunden hat, was natürlich für jede Webanwendung viel zu langsam ist ... Eine lösung musste her

Rettung in der Not

Die Idee ... vor der Suche berechnen welche shops in welchem Polygon liegen und welche nicht. Den ersten Versuch habe ich dann mit einer Reihe Postleitzahlen-Polygone gemacht. Leider sind diese nicht per default in der von osm2postges erstellten postgis Datenbank was man mit einer leichte Anpassung des default.style dokument Skriptes beheben kann.

 node,way   access       text         linear
 node,way   addr:housename      text  linear
 node,way   addr:housenumber    text  linear
 node,way   addr:street         text  linear
 node,way   addr:streetname     text  linear
 node,way   addr:interpolation  text  linear
 node,way   addr:postcode       text  linear # angepasster import der PLZ
 node,way   addr:city           text  linear
 node,war   addr:country        text  linear 
 node,way   admin_level  text         linear

Das eintragen der PLZ in die shops habe ich dann mit einem zusammen geschusterten Perl Skript vorgenommen.

 use DBI;

 my $dbName="osm";
 my $userName="osm";
 my $passwd="osm";

       my $data1= "DBI:Pg:dbname=$dbName";

 my $dbh = DBI->connect($data1, $username, $passwd, { RaiseError => 1 }) || die("Kann DB   nicht öffnen!");

 $sth = $dbh->prepare("
   SELECT DISTINCT 
   plz.postal_code AS title 
   FROM planet_osm_polygon AS plz
   WHERE plz.postal_code !=;");
   $sth->execute();

   while (@row = $sth->fetchrow_array() ) {
       print "@row\n";
       my $shop = $dbh->prepare("        
       SELECT DISTINCT
       point.osm_id AS id
       --point.shop AS shoptype,
       --point.amenity AS amenity,
       --point.name AS title
       FROM planet_osm_polygon AS plz
       JOIN planet_osm_point AS point
       ON ST_CONTAINS(plz.way, point.way)
       WHERE plz.postal_code = '@row'
       AND point.shop != ;");
       $shop->execute();

       while (my @shrow = $shop->fetchrow_array() ) {
                 print "\t @shrow \n";
                 my $entry = $dbh->prepare("UPDATE planet_osm_point
                                            SET addr_postcode=?
                                            WHERE osm_id = '@shrow';");
                 $entry->bind_param(1, @row);
                 $entry->execute();
       }
  }

es besteht aus drei Teilen, suche alle PLZ polygone, merge sie mit allen shops, trage die PLZ in alle shops ein. Leider war es mir nicht möglich, in die Spalten addr:postcode zu schreiben, da ich keine Möglichkeit gefunden habe, im perl skipt den Doppelpunkt zu escapen. Die pragmatsiche Lösung bestand in der Umbenennung der entsprechenden Spalten.

Dank an dieser Stelle an Alex, der mir sehr dabei geholfen hat, meine ersten PHP Versuche in die richtige Richtung zu lenken ....

Stadtplan Landshut

Mitte April 2013 hat Gernot entdeckt, dass die Stadt Landshut anstelle einer statischen Grafik jetzt Slippy Maps mit teils Google, teils OSM Tiles verwendet: [14].

Erstellt wurde diese Seite von der Firma vianova. Neben der Karte gibt es noch eine beeindruckende Menge von Overlays, POIs, Busrouten etc., die alle aus verschiedenen Quellen kommen müssen. Als Kontaktperson für z.B. neue Einträge von Läden ist Hr. Baumann genannt. Den habe ich per email angeschrieben um uns (OSM LA) vorzustellen, und dass wir generell an einer Kontaktaufnahme interessiert wären.

Tatsächlich hat mich der Herr Baumann dann ein paar Tage später angerufen und es kam zu einem sehr ausgiebigem Gespräch. Insbesondere erfuhren wie gegenseitig von diversen Schwierigkeiten und dem Aufwand, solche Karten zu produzieren. Mir wurde klar, dass als Redaktionsleiter einer 40-köpfigen Mannschaft, die sich ausschließlich um die Internetpräsenz kümmert, wenig Zeit ist, sich um Detailfragen wie einzelner OSM Tags zu kümmern. Das ganze Geflecht bezieht dann auch noch die Stadtwerke mit ein (für die Busrouten), die DB AG (zu Anschlußzügen an Busterminals), diverse rechtliche Fragen zu Fotos und Infopoints, die wieder entfernt werden müssen usw usw...

Auf der anderen Seite fand sehr großen Anklang, dass 'wir von OSM' in der Lage sind, recht schmerzfrei die OSM Karte zu aktualisieren. Witzigerweise kamen die meisten Anfragen aus der Bevölkerung nach fehlenden Straßen oder dem eigenen Haus. Nach dem Motto 'in der Hans-Dampf Gasse 3a-5f ist die Dackelgarage für unsere Reihenhaussiedlung und die Zufahrt nicht eingezeichnet'.

Mein Angebot war dann, dass wie solche Anfragen gerne übernehmen und für einen zügigen Update der Karten sorgen können. Das stieß auf Aufmerksamkeit. Dann erwähnte ich, dass unser großes Problem z.B. die Hausnummern sind, sowie die Lage der Gebäude, die wir nur von Bing abzeichnen können oder selber vermessen.

Daraus entwickelte sich eine vage Idee. Die Stadt LA ist im Besitz (d.h. rechtliches Eigentum) von Vermessungsdaten, die nichts mit dem Katasteramt zu tun haben. Sie haben detaillierte Lagepläne von Gebäuden, eine Hausnummernliste mit Koordinaten, sowie einen weiteren Stadtplan für Printmedien, der zwar georeferenziert ist, aber teilweise etwas gröber aufgelöst (mehr dazu gleich).

In einem weiteren Telefonat mit Herrn Trost, der der Vorsitzende des Vermessungsamts ist, konnten wir etwas mehr in die Details gehen. Ansinnen des Vermessungsamtes ist es, bei Neubauten, Abrissen etc. sofort aktuelle Geodaten zur Verfügung zu haben. Beispielsweise für die Stadwerke um Strom, Wasser etc. verlegen zu können. Diese Daten (ich habe mal einen Screenshot erhalten), sind unglaublich detailliert. Mehr als wir in OSM haben wollen. Beispielsweise sind dort alle Parkplätze (also die einzelnen Fahrzeugnischen) in der Neustadt eingetragen. Schräge Trapeze, ca 5x3m, mit den entsprechenden Lücken, wo eine Hausdurchfahrt ein Parken nicht gestattet. Zudem sämtliche Überbauungen wie Vordächer, Hofdurchfahrten, großräumige Eingangsbereiche in Blocksiedlungen sind alle extra getagged.

Einerseits ein gefundenes Fressen für OSM, aber es erfordert unglaublich viel manuelle Sichtung, welche Datenelemente dann relevant sind.

Zum anderen gibt es noch den Stadtplan. Den habe ich als PDF vorliegen und wäre in etwas so groß wie ein DIN-A0 Blatt. Darin enthalten ist der Bereich zwischen Weihmichl und Adlkofen (W-O), sowie Altheim und Kumhausen (N-S). Der gesamt Bereich beinhaltet Layer wie Toiletten, Sehenswürdigkeiten, Infopoints etc. also alles, was wir auch in OSM als amenity etc. haben. Die Häuer in dem Plan sind zwar immer noch exakt georeferenziert, aber im shape vereinfacht. Damit entsteht nich so ein Liniengewirr auf der gedruckten Karte (eben das Problem, mit dem ich auch gerade kämpfe). Dieser Stadtplan wird bis auf den sync mit den georeferenzierten Daten komplett manuell gepflegt. Das ist eine wahnsinns Arbeit, aber dementsprechend beeindruckend ist auch das Ergebnis.

Der naechste Ansatz, um mal etwas konkret zu werden war, dass wir von der Stadt jeweils einen kleinen Ausschnitt aus verschiedenen Siedlungsbereichen erhalten, und zwar einmal aus den rohen Vermessungsdaten und einmal aus den vereinfachten Stadtplan Daten. Die Siedlung Auloh haben wir uns ausgesucht, weil es da in OSM noch recht dürftig aussieht. Sowie einen Teil der Altstadt oder Neustadt, wo die Häuser so extrem dicht stehen.

Unsere nächste Aufgabe wäre es dann zu versuchen, aus den bereitgestellten Daten irgendwie OSM Daten zu erhalten, die man z.B. in JOSM einlesen kann. Und dann ist immer noch jede Menge Handarbeit erforderlich, weil sich die Häuser und ggf. Hausnummer i.d.R. nicht einfach als Massenimport reinladen lassen werden.

Und ein weiterer Punkt, warum Landshut sich für OSM entschlossen hat, war: Die bisherigen Details hörten an der Stadtgrenze auf. Die OSM Daten in den Aussenbereichen sind aber inzwischen so gut, dass sie als Standardansicht punkten konnten. Die Firma vianova wäre wohl bereit gewesen, die fehlenden Häuser in LA (inzwischen fehlen sie ja auch nicht mehr ;))) nachzuzeichen oder zu importieren, aber für einen Haufen Geld.

Noch kurze technische Details:

Die Vermessungsdaten liegen als AutoCAD file vor. Ich denke, dass das AutoCAD Format noch relativ problemlos sich ins OSM Format wandeln lässt. Frage ist, wie die einzelnen Layer und Attribute gemapped werden.

Der Stadtplan wurde mit der Software 'Freehand' erstellt. Wohl irgendwie von Adobe abgestossen/zugekauft.... Über einen Import dieses Formats konnte ich auf die Schnelle nix finden. Evtl. gäbe es wohl aber eine Möglichkeit, in das AutoCAD Format zu exportieren.

26.04.2013

Von der Stadt erhalte ich zwei Ausschnitte, einmal aus der Innenstadt (hoche Häuserdichte) und einmal ein Siedlungsgebiet auf dem Land. Um die AutoCAD .dwg Daten nach .osm Dateien zu konvertieren, habe ich 2 Tools verwendet: 'DWG Converter' (anydwg.com) um .dwg->.dxf zu konvertieren, und 'dxf2gpx' von Detlef Nicko. Die generierten .osm Dateien ließen sich problemlos in JOSM einlesen und waren ohne Umrechnung von Koordinaten an der richtigen Stelle der Karte.

Weitere Details und Screenshots, die einige Probleme beim Import ausleuchten werden, folgen sobald die rechtlichen Fragen geklärt sind.

02.05.2013 PDF Importieren

Als weitere Datenquelle steht ein Stadtplan aus 'freehand' (einem CAD Tool) im PDF Format zur Verfügung. Die Freehand Daten lassen sich nicht in JOSM importieren. Wohl aber die PDF Daten, wenn auch mit etwas Aufwand.

Mit dem Tool pstoedit lässt sich ein PDF in ein .dxf konvertieren. Vgl [15]. pstoedit läßt sich i.d.R. über den Paketmanager installieren.

Es gibt auch ein pdfimport Plugin für JOSM, das habe ich aber nicht zum Laufen gebracht (Herunterladen im Plugin-Manager ja, aber es erscheint nicht im Tools Menü): [16]. Ausserdem kann auch Inkscape .pdf Dateien nach .dxf wandeln, allerdings streikte dann wiederum der dxf2gpx Konverter. Also folgender Weg:

 pstoedit -f "dxf: -ctl -mm" <infile>.pdf <outfile>.dxf

Die Angabe -mm bezieht sich darauf, den Maßstab in Millimeter anzugeben.

Die Angabe -ctl wandelt die Farb-Attribute in Layernamen um.

Mit dem oben genannten Tool dxf2gpx kann nun die generierte Datei nach .osm umgewandelt werden. Bei Anwahl der entsprechenden Option, werden Layer wiederum in 'name' Tags umgewandelt.

Die erzeugte .osm Datei ist im JOSM aber nicht georefenziert. Wie man das macht, weiss ich momentan auch noch nicht. Durch manuelle Anpassung (move&zoom) zeigt sich auserdem, dass die Punkte im Stadtplan bei weitem nicht an die Qualität von OSM herankommen, bzw. bewußt oder unbewußt ungenau gemacht wurden. Für einen Import scheidet diese Datenquelle damit aus.

08.05.13

In einem Telefonat berichtet Hr. Trost vom Vermessungsamt, dass sich die rechtlichen Fragen noch hinziehen und evtl. auf dem bayerischen Städtetag neue Erkenntnisse mit ähnlichen Projekten gewonnen werden können. Ein Kontakt zu Ansprechpersonen mit Erfahrung zu diesem Thema wäre hilfreich.

Auf eine Anfrage auf der Mailingliste zum Thema Erfahrung mit öffentlichen Imports erhalte ich einen Anruf von Joachim (Kast at openstreetmap de), der mir von ähnlichen Erfahrungen berichtet, nämlich dass zwar die Zusammenarbeit mit der 'technischen' Abteilung in den Verwaltungen i.d.R. gut funktioniert, aber sich gerne höher gestellte Abteilungen gegen solche Vorhaben zum Thema OSM querstellen. Deshalb sei immer ein wenig Diskretion angeraten. Als weiteren Ansprechpartner zum Thema Gauß-Grüger Transformation nennt er mir noch Sven (at geggus net), der sich ebenfalls schon mit Imports von Behördendaten auseinandergesetzt hat.

Link auf Mailinglist-Thread

Rostock Kooperation

Weitere Links zu anderen kommunalen Import-Projekten: [17] [18]

Stichworte: München, Bayerischer Städtetag, geoimage.at

11.05.2013 Mapathron Auloh

Nach ca 2h bing Mapping zu zweit haben wir (czmartin&blutsauger) Auloh erschlagen. Auloh war einer der Kritikpunkte von LA an OSM wegen der geringen Datendichte bei Gebäuden. Bittesehr! Lustig ist in diesem Zusammenhang auch das neue GeoChat Plugin in JOSM. Vorher/Nacher Bilder, Permalink:

19.05.2013 Mapathlon Landshut Neustadt

Mapping Session in LA Neustadt von Tobi und Alex. Es ist echt viel Arbeit, dann die ganzen Details in OSM einzutragen. Aber ein Spaß wars trotzdem. Hier die Details:

GPS Logger: 2 Smartphones, aber wegen der abgeschatteten Lage (Hemdtasche etc) war der Track viel zu ungenau. Und der Akku von meinem Linux Handy auch viel zu schnell leer. Probleme beim Ablesen zwengs Spiegeln.
Kamera unbedingt mitnehmen!
Kamera mit GPS Track in JOSM synchronisieren macht nur Sinn, wenn der GPS Track genau ist und die Zeitabstimmung exakt funktioniert. War bei uns eher weniger der Fall.
Mit der Kamera Details an Häusern aufzunehmen hat sich super bewährt (z.B. Öffnungszeiten, Namen etc).
Wir hätten mehr Aufnahmen aus der Distanz gebraucht; das Zuordnen von aus bing abgezeichneten Häusern zu den erfassten Daten erwies sich manchmal als schwierig, gerade wenn alles so dicht bebaut ist. Hilfreich ist z.b. eine Reihe von 3-4 Häusern, an denen man gerade noch die Hausnummer und den Ladenbetreiber erkennen kann.
Die Aufnahmen hatten 3456x2304 Pixel. Ich fand das erst zu viel, aber manchmal lohnt es sich, weil man ziemlich weit reinzoomen kann, um eben doch noch eine Telefonnummer abzulesen.
Ich hatte einen meiner A3 Ausdrucke von Altstadt+Neustadt dabei und dort reingekrizelt. Der Platz hat bei weitem nicht gereicht. Eine Straße wie die Herrngasse (vielleicht 300m) habe ich auf einem DIN-A4 Blockblatt eingezeichnet, das hat gerade gepasst.
-> Block und Stift unbedingt mitnehmen!
Weil der Martin geschwächelt hat, konnten wir die Vorteile seines Tablet-Loggers nicht austesten. Das nächste Mal dann!
Viele Passanten und Anwohner waren sehr neugierig aber freundlich. Es lohnt sich auf fragende Blicke direkt anzusprechen bevor man Misstrauen erntet.
Flyer haben wir vergessen, das war schlecht. Ausserdem kann man leicht Visitenkarten oder Tips von 'Einheimischen' einfangen.
Unbedingt bei schönem Wetter mappen! Es gibt etliche Lokalitäten die wir nicht gemapped hätten, wenn da nicht diesser permanente Durst gewesen wäre ;)

Wir waren ca. zwischen 14 und 18 Uhr unterwegs, mit einer kurzen und einer langen Pause. Etwas 500 Fotos hat Tobi gemacht, die eigentlich fast alle irgendwie brauchbar sind (auf den anderen Fotos kann man Alex bei der Arbeit sehen was sehr schön ist --F6F (talk) 10:42, 20 May 2013 (UTC)). Das rentiert sich auf jeden Fall. Die Ergebnisse einzutragen dauert dann je nach Detailgrad schon mehrere Stunden, ich schätze mal ein Arbeitstag geht dafür ungefährt drauf. Und da sind die Häuser schon von bing eingezeichnet gewesen, bis auf ein paar Detailfragen.

eine Auswahl von Bildern findet sich hier: http://www.open-landshut.de/osm/

Links

2013-05-22 Building Mapping

Eine kürzlich losgetretene Diskussion, weil das building=residential oder building=terrace ohne Rand gerendert wird und damit gerade in der Innenstadt, wo viele Gebäude aneinanderkleben, die Unterscheidung nicht mehr möglich ist.

Die Diskussion fächert sich über die üblichen Thmen aus, Mappen nicht für den Renderer, welche Gebäudetypen gibt es, wie wird die Nutzung vom Typ getrennt usw. Über Möglichkeiten des Renderers wird leider so gut wie nicht diskutiert; mapnik ist wohl die heilige aber kranke Kuh, von der man behauptet, sie jeden Tag umbringen zu können, sie aber doch jeden Tag melken muss...

Ein recht brauchbarer Kompromiss findet sich in Rostock 2009 Den würde ich auch für Landshut vorschlagen, wenngleich auch nicht in diesem Ausmaß, aber

building:use=residential
oder
building:type=row_house

kann damit die bereits erfassten Daten ohne Verluste beibehalten und die Freunde des Renderings sind auch glücklich.

MailingList Thread zur Diskussion: building=yes vs. building=residential

2013-06-01

Andreas Hippauf's Versuche, anhand des Landshut-Polygons die .osm Daten zu extrahieren auf seinem Blog