Die neue OSM-Wochennotiz Nr. 30

Hallo,

die Wochennotiz mit Neuigkeiten aus dem OpenStreetMap-Universum ist da:

http://blog.openstreetmap.de/2011/02/osm-wochennotiz-nr-30/

Viel Spaß beim Lesen wünscht das gesamte Redaktionsteam! :slight_smile:

Stephan

Die Bachelor Arbeit mit dem neuen Kartenstil klingt recht interessant, gibt es darüber mehr zu lesen.

Leider scheint der neue Stil nicht nur Vorteile zu haben.
Autobahnen sind bei höherer Auflösung schlecht von highway=primary zu unterscheiden, beide haben fast den gleichen Orange-Ton.
Flüsse sind immer noch zu undeutlich, das zarte blaugrün ist schlechter zu erkennen als ein stärkerer Blauton.

Schade, bei so einer Arbeit hätte eigentlich mehr herausschauen können.
Hoffentlich findet sich bald ein weiterer Student, der die Arbeit fortsetzt.
Es gäbe sicherlich noch genügend Potential zur Verbesserung.

Ein “deutscher Stil” könnte z.B. auch die TAGs name:de auswerten,
damit die Orte in Bulgarien, Griechenland, … einmal besser lesbar wären.

Walter

Hi,

in der Wochennotiz #25 wurde vom Podcast “Raumzeit” (Erdbeobachtung) berichtet. Es gibt jetzt eine neue Folge
Satellitennavigation (GPS und Co.)

Ciao,
Frank

Das Flussdiagramm für Rollstuhlgerechtigkeit ist ganz nett, allerdings meiner Meinung nach viel zu simpel und pauschal, um wirklich zu entscheiden, ob ein Ort rollstuhlgerecht ist oder nicht. Dafür sind viele andere Faktoren wichtig und nicht nur die Höhe der Eingangsschwelle und die Existenz einer (behindertengerechten) Toilette:

  • Wie breit ist die Eingangstür bzw. weitere zu passierende Türen?

  • Wenn Rampen zu überwinden sind - wie breit und wie steil sind diese?

  • Wie ist die Bodenbeschaffenheit? Gibt es Schotter / Sand etc. zu überwinden?

Auch der Wert 7cm für die Schwellenhöhe kann höchstens ein sehr grober Richtwert sein - welche Höhe ein Rollstuhlfahrer überwinden kann, ist immer personenabhängig.

Ähm, es mag nur ein Richtwert sein, aber auf irgendwas muss man sich doch einigen. Es gibt Menschen die können zwei Treppen laufen und es gibt Menschen die schaffen eine Treppe nicht mehr. Es gibt denke ich eine Festlegung die auch für den ÖPNV zu trifft. Dort sind maximale Restdifferenzen der Einstiegshöhe und Spaltmaße vorgeschrieben. Aber wir können nicht für jeden einzelnen Rohlstuhlfahrer entscheiden ja/nein. Ich habe neulich einen gesehen, welcher geschickt ohne Hilfe über 2 Treppenstufen nach oben gelangt ist. Da war noch nicht einmal eine Rampe.

Die genauen Anforderungen imo aus den deutschen Bauvorschriften stehen hier:
http://wiki.openstreetmap.org/wiki/DE:Wheelchair_routing#Anforderungen_an_rollstuhlgeeignete_Wege

Ich find die nur nicht so gut und leicht zu merken.

Stimmt natürlich, ich wollte nur darauf hinweisen, dass sowas ziemlich pauschal ist und so eine einzelne Zahl eigentlich gar nichts darüber aussagt, wie rollstuhlgerecht ein Ort wirklich ist. Deshalb kann die Angabe wheelchair=yes/limited/no immer nur ein grober Hinweis sein. Um wirklich entscheiden zu können, wie gut ein bestimmter Rollstuhlfahrer eine Strecke meistern kann, bräuchte man deutlich mehr Details.

Sicher, diese DIN-Vorschriften sind deutlich unhandlicher. Aber wenn man schon ein Flussdiagramm hat, das man auf eine DIN A4 Seite ausdrucken kann, dann kann man auch gleich die ganze Liste mit den DIN-Vorschriften ausdrucken und mitnehmen und muss sie sich nicht merken… Damit hat man dann gleich die anderen Eigenschaften wie z.B. Rampen berücksichtigt und nicht nur die Höhe der Eingangsschwelle.

die von der wheelmap sollten sich erstmal um paar handfeste Dinge kümmern, nämlich die Auswertung von Tags die sich an einem Weg, d.h. Gebäude, befinden. Leider musste ich schon feststellen, dass diese Map Leute in großem Maßstab dazu verleitet, Geschäfte doppelt einzutragen oder die Tags unnötigerweise eben nicht an das Gebäude zu packen.

Also das Problem ist nicht trivial, da scheitern z.Z. viele Projekte dran:

Du kriegst die Wege nämlich erst nachdem du alle Knoten gelesen hast. Und da du vorher noch nicht weißt, welche Knoten du mal brauchst musst du eigentlich alle erst mal im RAM speichern. Tja und das geht halt nicht :wink: Also brauchts da Strategien und die wollen gut durchdacht sein.

Ich finde es deshalb ein wenig unfair zu sagen “die sollen mal machen!” :wink:

Müsste doch recht trivial sein beim DB-erstellen
Zusätzlich zu den Nodes alle Wege nach dem interessanten Zeug durchsuchen, also Flächen-Tag + interessierendes Merkmal und für diese dann entweder einen Node des Weges nehmen oder den Schwerpunkt berechnen und dort einen Node setzen oder sich nen Wolf rechnen und da den Node hinsetzen :wink: Anschließend die Tags vom Weg an den Node oder direkt in die DB.

WEr soll es denn sonst machen, wenn nicht die, die es auswerten wollen. Es ist jedenfalls keine Lösung, Dinge doppelt einzutragen oder aber einem Node infos zugeben, die egtl. die Flächen betreffen.

hi,
von welchem der verschiedenen Verfahren, aus Osm-Daten Karten zu machen, sprichst du hier denn?
Mir erscheint die Aussage (“es geht nur soundso”) ziemlich pauschal.

Gruss
Walter

@aighes nun ich finde sie bringen Stück für Stück eine sehr nützliche Anwendung für OSM. Das da nicht alles glatt geht ist natürlich ärgerlich, aber man kann ja nicht immer alles auf einmal haben :slight_smile:

@wambacher
Das stimmt viele Wege führen nach Rom. Nur sind das die Einschränkungen, die durch das OSM XML Format und die Pipelining Funktionalität der Werkzeuge meiner Meinung nach vorgegeben sind. Vielleicht irre ich mich da auch aber so ist mein Kenntnisstand :slight_smile:

Klar kann man das mit einem 2pass Verfahren lösen, indem man erst alle Knoten in Wegen ermittelt und dann nochmals deren Koordinaten bestimmt aber das frisst natürlich trotzdem noch immens Resourcen. Eine andere Lösung wäre bei den Diffs immer Boundingboxen neu zu berechnen aber auch da ist der Sync gar nicht so einfach zu halten.

ne ne, das stimmt leider.
Wenn du mit den Osm-Files im xml-Format arbeitest, hast du keine andere Möglichkeiten: alles auf Verdacht in den Speicher oder mehrfach scannen.
Selbst wenn du einen vernünftigen XML-Parser einsetzen würdest, macht der auch nix anderes. :frowning:

Ich hatte ja auch nur nachgefragt um zu wissen, welchen Weg nach Rom du gehtst.
Gruss
Walter

Matthias, ich sag ja nicht, dass diese Auswerter das so machen müssen. Nur darf es eben nicht dazu kommen, dass man Dinge doppelt einträgt oder Informationen an verschiedene Objekte verteilt, obwohl sie egtl. zu einem Objekt gehören.

Im einfachsten Fall muss man erst einmal durch alle ways. Von den interessanten jeweils eine Node-ID in den Speicher. Anschließend durch alle Nodes. Für Multipolygone muss man dann vorher noch einmal die Relationen durch. Also im Prinzip muss man dem Parser nur beibringen, dass er von hinten nach vorne die osm-xml-Datei analysiert.

Für Schwerpunktberechnung muss man allerdings mehrfach durch. Da führt dann kein Weg dran vorbei.

Und genau das geht leider nicht, ohne die Pipelining Funktionalität zu verlieren. Dadurch würde ein on-the-fly entpacken ebenfalls nicht mehr funktionieren :frowning: Was aber gehen würde wären 2 Durchgänge, das stimmt.

Bitte nicht falsch verstehen, ich will hier keinen auf Neunmalklug machen. Es ist nur so, dass ich mich mit Frederik und Jochen da auch schon sehr lange in den Haaren hatte :wink:

Naja aighes und meiner Meinung nach muss man erst mal anfangen mit einem Projekt, sonst verrennt man sich sehr schnell in hätte wenn und aber Diskussionen. Aber klar sonderlich schön ist der jetzige Zustand für uns nicht :confused:

Habt ihr mal über eine Datenbank nachgedacht? SQlite vielleicht? Firefox arbeitet ja seit einer geraumen Zeit damit um seine Sachen zu sortieren.

Was meinst du genau viw?

Naja ihr unterhaltet Euch hier über Probleme, welche man mit einer einfachen Datenbank lösen könnte. So ist es dann nicht notwendig zweimal oder dreimal die Datei zu lesen.
Und da fiel mir SQlite ein, da es eine Datenbank ohne Installation ist. Wenn man also die Datei in die Datenbank einliest, ergeben sich die Abhängigkeiten von selbst.

Übrigens ganz interessant: http://chaosradio.ccc.de/cre168.html Wheelmap
Da wird auch gesagt, dass sie für die Wheelmap eine lokale Datenbank vorhalten.

Nun Viw in aller Regel wird das ja bereits über PostGresSQL Datenbanken gemacht. Nur die müssen eben irgendwie gefüllt werden. Und das importieren der Daten von ganz Europa dauert leider :confused: