[Talk-de] Grünflächen in Orten: Buschwerk und landuse != village_green

qbert biker qbert1 at gmx.de
Do Jun 19 17:47:10 UTC 2008


-------- Original-Nachricht --------
> Datum: Thu, 19 Jun 2008 18:05:45 +0200
> Von: "Marc Schütz" <schuetzm at gmx.net>
> An: Openstreetmap allgemeines in Deutsch <talk-de at openstreetmap.org>
> Betreff: Re: [Talk-de] Grünflächen in Orten: Buschwerk und landuse != village_green

> Das muss er auch nicht; es reicht, wenn er die Sorten von Wegen
> rausfiltert, 
> mit denen er umgehen kann, und alle anderen einfach als nicht vorhanden 
> ignoriert. Das kann man sogar machen, bevor man überhaupt anfängt, sich
> mit 
> dem Graphen an sich zu beschäftigen.

Die Betonung liegt auf 'alle Arten von Wegen'. Noch funktioniert der
Basisschalter 'highway', aber das ist keine explizite Vereinbarung.
(OTon Wiki: Verwende highway, wenn du willst, dass die Renderer
das Ding darstellen).

Derzeit verarbeite ich die Daten vor der Filterung um Fehler zu finden,
die den anderen Filtern verborgen bleiben. Aber du hast natürlich
recht, man kann das auch drehen. 

Aber das löst die Probleme nicht, denn viele Dinge passieren im
Verborgenen. Das mit dem falsch vergebenen highway-Attribut ist
ja keine Erfindung, sondern mir real untergekommen. Die Renderer
haben das sehr unscheinbar dargestellt. Aber viel häufiger ist mir
ein Fehlertyp untergekommen, der noch schwieriger zu finden ist.
Es gibt Leute/Algos, die über bestehende 'highways' neue ways
mit konkurrierendem highway tag drüberbügeln. Hier entstehen
ganze Netze mit netten Seiteneffekten. Wenn unter einem 
korrekt gesetzten oneway ein durchkontaktierter way ohne oneway
liegt, ist erstmal jeder Filter und Router am Ende und produziert 
Unsinn.

Die übliche Lösung wäre, das Stapeln komplett zu unterbinden, denn
viel Sinniges kommt beim Stapeln eh nicht raus. Meist sind das 
nur Verarbeitungsleichen oder unnötige Verknüpfungen zwischen
Flächen und Strecken. Leider wird das Stapeln in OSM explizit von
josm und der Diskussionsrunde hier gefördert, so dass das 
automatische Auffinden und Eliminieren von Fehlern nicht gerade 
einfacher wird.
 
> Was als Teil des Graphen aufgefasst wird oder nicht hängt sehr von der 
> Anwendung ab. Für Fußgängerrouting möchte ich z.B. keine Autobahnen
> drin 
> haben, und umgekehrt für Autos keine Fußwege. Es gibt also sowieso nur
> eine 
> endliche Menge von Tags/Tag-Kombinationen, die der Router benötigt. Was 
> spricht dagegen, nach diesen zu filtern?

Fußgängerrouting und Graphen sind ein schwieriges Thema, zumal
das Thema auch in OSM mehr geisterhaft rumschwirrt, denn real
existent ist. Ich sehe das so: Im mittel- bis grossräumigen Bereich 
ist Fußgänger/Radfahrer/Skifahrer- oder wasauchimmer-Routing nur
ein Spezialfall des Klassikers fürs Auto. Man bildet also graphentechnisch
ab, wie man sich mit welchen Gerät in welcher Umgebung bewegen
kann. Damit bekomme ich z.B. die vielen kleinen Durchlässe in den 
Griff, die mich als Fußgänger in der Stadt interessieren, aber für Autos
gesperrt sind (und die ich mit Vorliebe erfasse *g*). Auch für eine 
Bergwanderung reicht ein Graph.

Unter kleinräumiges Fußgängerrouting verstehe ich die freie
Bewegung auf der Fläche und da hakts an allen Ecken und Enden.
Angefangen von der Modellvorstellung bis hin zur entsprechend 
genauen Auflösung (ca. <1m) bei der Erfassung. Aber sogar da gehen
meine Ansätze zu einem Graphen, der dann anhand Ausgangspunkt/
Ziel/Bewegung on request temporär erstellt wird. Die ganze komische
Diskussion, dass man sich mit dem klassischem Routing den Weg
zum Fußgängerrouting verbauen könnte, ist mir schon immer
schleierhaft gewesen. 

Grüsse Hubert
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer




Mehr Informationen über die Mailingliste Talk-de