[Talk-de] landuse=road War:[viel Text zu landuse-handling..]

[Christian Müller]

Am 19.09.2011 20:16, schrieb Martin Koppenhoefer:
> Am 19. September 2011 19:34 schrieb Christian Müller<cmue81 at gmx.de>:
>> Am 16.09.2011 11:16, schrieb Martin Koppenhoefer:
>>> Du täuschst Dich hier. Siedlungsstellen lassen sich nicht automatisch
>>> errechnen, weil die Informationen dazu fehlen. Bei den landuses - so
>>> man sie alle erfasst hat - sind die benötigten Informationen hingegen
>>> vorhanden. Daher geht es da.
>> -1  Das ist, sorry, absoluter Unfug.
>>
>> /Erstens/ sind die benötigten Informationen für die Siedlungsstellen
>> existent, wenn landuses komplett erfasst sind.
> Du willst es nicht verstehen. Es ist nicht klar, zu _welcher_
> menschlichen Siedlung sie gehören. Das ist das Problem, nicht, ob sie
> besiedelt sind.

Natürlich ist das klar - anhand der Gemeinde, bzw. Gemarkungsgrenze, 
innerhalb derer die landuses liegen.  Im allgemeinen umfassen politische 
Grenzen einer Gemeinde einen größeren Bereich, mindestens aber den 
Bereich der Siedlung.

Selbst wenn eine politische Grenze aktuell nicht mehr zu finden ist, 
wird es eine historische geben, die für die Ermittlung benutzt werden kann.

Die Information einer Siedlungsflächengrenze ist damit klar redundant 
[[denn es gibt Regeln, mittels derer sie sich ausrechnen lässt]].  Ich 
vertrete aber die Auffassung, dass diese Regeln nicht außerhalb der DB 
stehen sollten.

Schließlich ist sie über eine Relation innerhalb OSM effizient pro Fall 
abbildbar.  In gewisser Weise steckt Redundanz dann nur dadurch in der 
DB, dass die Regel mehrmals angewandt wird.  Das hat aber eben auch den 
Vorteil, dass Ausnahmen ohne weiteres abbildbar sind.

Bisher standen dazu in unserer Debatte zwei Realisierungen zur Auswahl:  
a) Erfassung über (wiederbenutzte) Flächengrenzen  b) Erfassung über 
Sammelrelation aller Teilflächen der Siedlungsfläche.  b) hat klare 
Nachteile gegenüber a), siehe Datenhaltungsmail.

Das ist alles nur Wiederholung, siehe frühere mails..


>> /Zweitens/, kannst Du aus einem Netz MICROgemappter Flächen _nicht_ oder nur
>> mit sehr hohem Aufwand (sprich komplexe, regelbasierte Algorithmen) sinnvoll
>> auf ein Netz grobgranularer Flächen schließen.
>
> So kompliziert ist das nicht.

Du lehnst Dich hier viel zu weit aus dem Fenster.  /Wie/ kompliziert das 
werden kann, überblickst Du gar nicht.  Ich überblicke das auch nicht, 
behaupte aber auch nicht, dass ich das könnte.


> Der immense Vorteil ist aber dabei, dass
> alle Informationen vorliegen und ich selbst entscheide, was für mich
> unwesentlich ist, und was nicht.

Ich lese nur /ich/ in deinen Sätzen.  So funktioniert OSM nicht.  Um 
/als Datennutzer/ entscheiden zu können, was für mich wesentlich ist, 
muss ich aus einem Angebot /wählen/ können.  /Du/ bist hier gerade 
derjenige der einem dieses Angebot vorschreiben will, weil /Du/ der 
Meinung bist, dass ein Salat aus MICROgemappten Flächen ausreiche, um 
sich alle erdenklichen gröberen Fälle auszurechnen.

Umgekehrt muss ich /als Mapper/ /wählen/ können, auf welcher Ebene ich 
Informationen zum Projekt hinzufüge.  Nicht jeder hat die Muse, deinen 
Vorstellungen von Größen, die "nicht weiter teilbar" sind, 
nachzukommen.  Solche Leute dürfen dann keine Flächennutzung mehr 
erfassen, oder wie?  Und der nächste MICROmapper, der kommt, und das 
Gebiet der Forstwirtschaft dann "parzelliert" zerstört die Arbeit des 
MACROmappers - weil eben das Gebiet der Forstwirtschaft _nicht_ 
notwendigerweise, wie Du schreibst, aus Mini-Parzellen zusammensetzbar ist.

Ich bin der Meinung, dass Du immer noch nicht durchdacht hast, welche 
wirklichen Konsequenzen deine Streichung von "überwiegend" aus der 
Definition zur Flächennutzung hat.  Nochmal, wenn Du die "reine" statt 
überwiegende Flächennutzung erfasst, heißt das für Dich und alle, die Du 
damit begeistern willst:

     a) Erfassung aller erdenklichen Flächennutzungen einer Fläche
     b) Unterteilung der vorhandenen Fläche in kleinste Einheiten, die 
eine __eindeutige__ Erfassung der Flächennutzung ermöglichen

Ich bitte Dich nochmals, mitzudenken:  Eine Fläche beliebiger Größe kann 
_immer_ nochmal geteilt werden, um die Flächennutzung genauer zu 
erfassen:  Selbst für einen Acker funktioniert das:  linienschmale 
Flächen werden z.B. als Furche des Ackers genutzt.

Bist Du allen Ernstes der Aufassung, dass aus diesen kleinsten, 
MICROgemappten landuses, sich _jeder_ diese gröberen Gebiete aus einem 
komplexen Regelset "zusammenbauen" will?  Die Regel für den Acker wäre dann:

     Gruppiere alle Furchen, um das Gebiet des Ackers zu erhalten.  
(Total einfach!  Da braucht man doch die überweigende Nutzung der 
Gesamtfläche als Acker gar nicht erfassen..)

Ganze Softwareprojekte würden sich dann damit beschäftigen, Regelwerke 
zu pflegen, weil /Du/ der Auffassung warst, dass die Gruppierung 
feingranularer Strukturen in "gröbere" ja ein Kinderspiel sei (es aber 
schon für die Berechnung der Siedlungsflächengrenze verneinst!).


>   Es geht nämlich nicht nur um die
> Flächengröße sondern auch um die Art der Nutzung. Eine kleine aber
> extreme Nutzung ist für bestimmte Fragestellungen interessant. Wenn
> man alles vermanscht, fehlen die Infos nachher.

Gerade ein Flächennetzwerk erlaubt, was jetzt nicht möglich ist:  
Extreme Nutzungsänderungen für kleine Gebiete zu erfassen, ohne dabei 
das gröbere Gebiet zu zerstören.  /Ob/ die extreme Nutzungsänderung 
interessiert oder nicht, bestimmt

     bei der Erfassung:  der/die MapperIn
     bei der Nutzung:  der Datennutzer

und nicht /eine/ /einzige/ Person.   Momentan gibt es kein 
Flächennetzwerk der Bodennutzung und wenn es existiert, dann an lokalen 
Stellen, wo Mapper das Problem erkannt, aber dessen Lösung nicht 
publiziert haben (Wiki, Mailingliste).  Das bedeutet:

     MICROmapper  X  kommt, mappt die grob erfasste Bodennutzung von 
MACROmapper Y neu und die (sinnvolle!) Gruppierungsinformation ist 
verloren.  Y kann sich ja sein Zeug, aus den neuen Flächen schon 
irgendwie errechnen --> Super Einstellung, so macht zusammenleben und 
-mappen Spaß..

Dann sollten wir das aber auch für die Siedlungsfläche so handhaben.  
Schließlich kann sich auch Mapper Martin aus den MICRO-landuses  
innerhalb irgendeiner politischen Grenze den landuse=settlement 
zusammenrechnen..  Oder wollen wir für manche gröbere landuses ein paar 
Ausnahmen schaffen?

Das ist alles vergebene Liebesmüh, denn wir haben schon festgestellt:

     Der Mapper bestimmt, /was/ /wie/ gemappt wird.
     Der Nutzer bestimmt, /was/ er davon haben will.

Ohne irgendwelche Verbote, kann OSM elegant beides bedienen, indem 
einfach der Fakt anerkannt wird, dass auch bei der "überwiegenden realen 
Bodennutzung" Beziehungen zwischen den Einzelflächen bestehen und sich 
Bodennutzungsflächen durchaus überlappen können.  Die Erfassung der 
Bodennutzung muss nicht disjunkt erfolgen, das wäre eine Forderung nach 
_unmöglicher_ Pedanterie.

Beispiele:  Ein Gebiet wird überwiegend für das Wohnen verwendet, wir 
erfassen es als landuse=residential.  Außerdem gibt es eine kleine 
Stelle innerhalb des Wohngebietes, wo die Flächennutzung "extrem" (was 
extrem ist, ist auch Ansichtssache) schwankt, wir erfassen also 
landuse=residential.

Was bedeutet das?  Ich habe eine Information, mit der ich ein großes 
Gebiet klassifizieren kann "_überwiegend zum wohnen verwendet_".  Wenn 
mich nur dieses Gebiet interessiert, interessiert es mich nicht, ob und 
wieviele extreme Nutzungsänderungen innerhalb winziger Teilflächen 
dieses Gebietes stattfinden.  Gleichfalls muss ich den Fakt anerkennen, 
dass sich andere evtl. für eine detailierte Flächennutzungsaufteilung 
interessieren.  Gleichfalls müssen die, welche die detailierte 
Flächennutzungsaufteilung interessiert, anerkennen, dass es Leute gibt, 
die sich für gröbere Strukturen interessieren, für die es also 
vernachlässigbar ist, dass es extreme Nutzungsänderungen innerhalb eines 
Gebietes gibt.

OSM kann beide Welten problemlos verbinden, indem Flächengrenzen als 
/way/ und Flächen als /multipolygon/ erfasst werden.  Dann lassen sich 
Flächen beliebiger Strukturgröße nach bestem Wissen und Gewissen durch 
Mapper bilden, ohne dass ein Mapper einem anderen Mapper /seine/ 
Vorstellung von "einer" "wahren" Flächengröße aufdrücken muss.  Es gibt 
nicht die "wahre" Flächen, bzw. Strukturgröße, auf der Daten erfasst 
werden, sondern ein Spektrum, dass von der Größe eines Kontinents bis 
zur Größe eines Wegweisers reicht.

Solange Du behauptest, dass man "nur" Bodennutzungen MICROmappen müsste, 
um alle glücklich zu werden, verschiebst Du die Diskussion, die wir 
/hier/ führen, einfach nur in einen /anderen/ Größenbereich, um sie dort 
zu wiederholen.

==>  Eventuell triffst Du dort dann NANOmapper, der Dir erklärt, dass es 
Unfug ist, landuse=* MICRO zu mappen, weil MICROgemappte landuses ja 
ohne Probleme aus NANOgemappten errechenbar seien..


>> Natürlich kann ich nur politische Gemeindegrenzen innerhalb der DB pflegen
>> und dann extern die Bundesgrenze ausrechnen.  Das machen wir aber eben
>> nicht, weil die Vorteile einer expliziten Erfassung innerhalb der DB (mit
>> Bezügen der Grenzen untereinander) klar überwiegen!
>
> +1
> daher sind Siedlungen auch besser nicht die Summe verschiedener
> Landuses sondern ein extra Polygon.

Genau hier musst Du weiterdenken..  Das ist nicht die ganze Wahrheit, 
denn die _gleiche_ Argumentationsweise, die Du verwendest, um Dich gegen 
die automatische Errechenbarkeit einer Siedlungsflächengrenze zu wehren, 
zählt auch, wenn ich behaupte, dass der landuse=* eines 
Forstwirtschaftsgebiet aus seinen MICRO oder NANOgemappten Teilnutzungen 
_nicht_ errechenbar ist, sondern über "ein extra Polygon" (multipolygon) 
erfasst werden soll.

Egal ob das gröbere Gebiet nun eine Siedlung darstellt, oder ein 
Forstwirtschaftsgebiet - weshalb sollten gröbere Gebiete jedes Mal, wenn 
ein Nutzer sie braucht, berechnet werden?

Wenn ich weiß, welche Wege zu einer Radroute gehören, kann ich mir das 
auch jedes Mal aus OSM-Daten ausrechnen.  Das brauche ich aber nicht, 
denn das Ergebnis dieser Rechnung ist Teil der Realität und damit Teil 
von OSM  (vorgehalten durch eine type=route Relation).

Falls man das Argument der Errechenbarkeit zu Ende denkt, kommt man 
darauf, dass es eigentlich reicht, nur die nodes zu erfassen.  Alles 
andere lässt sich doch, entsprechendes externes Wissen vorrausgesetzt, 
auch extern ausrechnen..


>> Betrachte bitte die Relationen in OSM.  Beziehungen zwischen den Daten sind
>> nicht immanent und einfach so da!
>
> doch, die Lage ist einfach so da, genauso wie die Größe einer Fläche,
> oder was innerhalb und ausserhalb einer Fläche liegt, bzw. welche
> Flächen sich schneiden. Da musst Du z.B. nicht noch die Flächengröße
> dazuschreiben, auch wenn manche das trotzdem machen.

Ja, was denkst Du wohl, weshalb einige die Flächengröße dranschreiben?  
Weil die Ermittlung des Ergebnisses wesentlich aufwendiger sein kann, 
als einfach diesen Wert nachzuschlagen.

Die Lagebeziehung zwischen zwei Flächen ist _nicht_ einfach so da!  DU, 
als Mensch, kannst zwei Polygone zeichnen und dann sagen, das eine liegt 
innerhalb des anderen  oder  meinetwegen auch, die beiden Polygone 
schneiden sich.  Das kannst DU, als Mensch, recht schnell für kleinere 
Polygone tun, aber auch nur dann, wenn Du eine visuelle Darstellung der 
beiden Polygone vor Dir hast.

Für eine Maschine ist die Lagebeziehung der beiden Polygone solange 
nicht gegeben, wie Du sie nicht explizit angibst (in Bezug setzt, eine 
Relation erstellst) __oder__ durch ihre Koordinaten errechnest.  Das 
kann, in Abhängigkeit der Menge der Polygone, die in Bezug zu setzen 
sind, und ihrer einzelnen Größen sehr schnell sehr aufwendig werden.

Deine Aussage, dass irgend zwei "closed ways" automatisch eine immanente 
Beziehung zueinander in der DB hätten, ist also schlichtweg falsch.  Die 
Beziehung ist nicht immanent, sonder maximal "ermittelbar".

Beziehungen zwischen Objekten innerhalb einer DB sind _nicht_ einfach so 
da.  Sie müssen definiert werden  (entweder durch Algorithmen, die 
Bezüge ermitteln, oder durch Datenstrukturen, die Bezüge 
speichern/vorhalten).

Immanent in der DB sind grundsätzlich ersteinmal nur die Beziehungen 
zwischen

     node - lat,lon pair
     way - node list
     relation - way or node
     relation - relation

Eventuell noch, aber da wird es schon wackelig:  closed way - area   
Eine echte area (Flächentyp) kennt die DB überhaupt nicht!  Wie willst 
Du da behaupten, dass Flächenbeziehungen untereinander immanent wären?

Einem multipolygon z.B. sind die Beziehungen zwischen seinen 
innliegenden Polygonen und dem außenliegenden Polygon "immanent".  Das 
ist aber gerade, wovon ich rede:  Generell Flächen als multipolygon zu 
erfassen, weil damit (einige) Flächenbeziehungen immanent gegeben 
wären.  Das ist bis jetzt keine durchgängig angewandte Praxis (von 
politischen Grenzen, auf die Du dich _nicht_ beschränkt hast, einmal 
abgesehen).


>> Was aber nicht passieren darf (!), ist, dass sich unter den Render-Regeln,
>> Regeln befinden, wie Daten der Realität gruppiert werden, die schon in der
>> Realität gruppiert werden.
> Die Renderregeln leisten das: Daten selektieren und ggf. gruppieren.

Der letzte Teilsatz war wichtig - ich schrieb ihn nicht zum Spaß.  ", 
die schon in der Realität gruppiert werden."

Das schließt eine ganze Menge an Renderregeln aus.

/Falls/  Renderregeln   Daten der Realität   auf eine Art und Weise 
gruppieren, so dass die Selektion, die der Renderer da tätigt, einer 
Selektion/Gruppierung gleicht, die bereits Teil der Realität ist, dann 
hat diese Gruppierungsregel _nichts_ in den Renderregeln verloren.

Das Ergebnis der Gruppe sollte _dann_ stattdessen als Relation innerhalb 
der OSM-DB existieren.  Idealerweise sind Renderregeln reine 
Layout-Regeln, es wird also nur des Layouts wegen gruppiert und nicht, 
wenn Daten schon in der Realität gruppiert (lies: in Beziehung gesetzt) 
werden.  Letzteres ist Teil von OSM.  Beispiel:

     Es gibt mehrere Buslinien innerhalb eines Netzwerks.
     Der Renderer gruppiert sich diese Buslinien anhand des 
network-Tags, um dann einen Stil zu definieren.
     Diese Gruppierung gibt es aber schon in der Realität, es wäre also 
besser, das Netzwerk in OSM abzubilden:
         Relation type=network ...  mit den Buslinien als Mitglieder.
     .. und als Renderregel den Stil für das network festzulegen.

Als Richtlinie kann man sich evtl. merken:  Solange eine Renderregel 
/selektiert/, ist alles in Ordnung.  Sobald eine Renderregel 
/gruppiert/, muss man sich als Layouter die Frage stellen, ob die 
Gruppierung _wirklich nur_ für Layoutzwecke stattfindet,  _oder_ nicht 
evtl. ein Workaround um eine fehlende Relation in OSM ist.


>> folgendes:
>>     - ein Renderer gruppiert sich die Elbe-Radroute aus den Wegen der DB auf
>> die eine Art
>>     - der nächste auf eine leicht andere Art
> sorry, aber irgendwo haben Vergleiche auch ein Ende, und ein linearer
> Radweg ist schlecht mit dem Problem hier vergleichbar.

Ich seh' schon - Du bist jemand, der nicht zwischen Radweg und Radroute 
unterscheidet.  Dann trifft der Vergleich natürlich auch nicht ins Schwarze.

Und nein, Vergleiche müssen nicht /irgendwo/ ein Ende haben, sondern 
dort, wo sie nicht mehr zutreffen.

         Eine Radroute aus /ways/ in den Rollen 'Teilabschnitt' zu bilden.
ist vergleichbar mit
         Eine Fläche aus /ways/ in den Rollen 'Flächengrenze' zu bilden.

Wenn die Radroute ein Rundkurs ist, werden beide Sachverhalte sogar auf 
identische Weise abgebildet:

         Die Relation enthält dann in beiden Fällen 
aneinandergeschlossene Wegsegmente.
         Es nehmen nur solche Wegsegmente Teil, deren Endpunkte auch 
Anfangspunkte eines anderen teilnehmenden Wegsegmentes sind.

Ob das ganze als Route  oder  Fläche interpretiert wird, entscheiden 
dann nur noch die Relations-Tags..


>> "richtig" im Sinne der Frage, ob die entstehende Gruppierung eine Abbildung
>> der Realität ist [...]
> wie Frederik schon treffend sagte: um richtig und falsch geht es
> nicht, in jedem Fall machen wir hier ein Modell der Welt, das man
> nicht mit der Welt verwechseln sollte.

+1    "richtig im Sinne der Frage, ob [...] eine Abbildung der Realität ist"

"richtig" beschäftigt sich mit der Realitätstreue des Modells..  Ist die 
Abbildung gut oder wird unzulässig abstrahiert, etc.

Wenn ein Sachverhalt im Bezug auf das Modell "falsch" ist, aber in der 
Realität existent, stellt sich die Frage, inwieweit das Modell angepasst 
werden muss...


>   M.E. geht es in der Diskussion
> hier darum, herauszufinden, wie unser Modell am besten abbilden
> sollte, dass:
>
> - es Verwaltungseinheiten und dazugehörige Verwaltungsgrenzen gibt,
> - es davon unabhängig Siedlungen und Teile davon gibt,
> - dass jedes Stück Land irgendwie genutzt wird, oder eben nicht

+1  Wenn Du aber dogmenartig am "Modell" hängst, wird daraus Mist.

Du musst nicht nur herausfinden, wie die Realität in das Modell passt.  
Du musst auch prüfen, ob das Modell überhaupt geeignet ist, deine 
genannten Aspekte der Realität zu erfassen.  Das ist eine Arbeit von 
zwei Seiten.  OSM nutzt ein evolutionäres Datenmodell, sprich, ein 
Datenmodell, das sich fortentwickelt.  Es ist keine Vorschrift des 
Projektes, dass der _jetzige_ Stand des Datenmodells für immer und ewig 
aktueller Stand bleibt.

Es gibt viele Stellen, an denen sich das Datenmodell bewiesen hat (true 
and tested).  An denen ist es schwer Argumente für eine Änderung zu 
finden, weil die Argumente ja aufzeigen müssten, wie etwas, dass sich 
bewiesen hat, noch besser geht.  Es gibt aber auch (nicht wenige) 
Stellen, an denen es einfach nur Mist ist, weil Struktur fehlt, weil 
Dinge vermischt werden, die in der Realität ausdifferenzierbar sind, etc.

OSM kann die Realität nicht abbilden, ohne zu strukturieren.  Es ist ein 
klares Strukturierungsprojekt.  Mischmasch, Brei und Chaos sind auch 
Teile der Realität, die werden in OSM durch die Änderungsrate eines 
Gebietes abgebildet:  Ein Mapper, der mit der bestehenden 
Ausdifferenzierung eines Gebietes nicht zufrieden ist, "strukturiert das 
Gebiet um".  I.d.R. erhöht er dabei Genauigkeits-, Detail- und 
Strukturierungsgrad.  Die Änderungsrate eines Gebietes erfasst in OSM 
auch jenes Chaos der Realität, welches durch permanente 
Gebietsumgestaltungen des Raumes (etwa in Städten) entsteht.


> weiterhin wären noch jede Menge andere Betrachtungsweisen denkbar
> (aber nicht alle sinnvoll in OSM aufgehoben), z.B. die Bodenbedeckung,
> die Vegetation, der Feuchtigkeitsgehalt des Bodens, das Klima, der
> geologische Untergrund, die Bebauungstypologie, die Einwohnerdichte

+1  genau.  OSM lässt sich für diese Anwendungsfelder öffnen.  Das ist 
aber m.E. erst dann sinnvoll, wenn die Grundlage stimmt:

     Bessere Unterstützung für Flächenerfassung in Editoren
     Multipolygone für die Zusammenarbeit von Makro-, Micro- und 
Nanomappern (Flächennetzwerk..)
     Dokumentation und schlüssige Definition im Wiki, wie Tags 
Verwendung finden

=Zukunftsmusik===========
Damit kann dann auch eine echte Zusammenarbeit zwischen Laie und 
Spezialist klappen, ohne dass sich beide gegenseitig die Arbeit 
zerstören, oder ein Disput enststeht, wo eine Fläche erfasst werden 
"darf" und wo nicht.  Die Chancen sind groß, dass damit auch die 
bestehende Datenqualität erhöht wird und OSM zu dem Wiki ortsbezogener 
Information wird.

Es ist dann z.B. auch echt diskutierbar, /welche/ Flächengrenzen 
zusammenfallen und welche nicht.  Man unterhält sich dann also nicht 
mehr über die Datenhaltung, ob Flächen zusammengepappt werden dürfen, 
oder an Wege geklebt, oder sonstwas, sondern um echte fachliche Fragen - 
welche Spezialgebiete brauchen ein eigenes Flächennetzwerk, welche 
können sich eins mit anderen Spezialgebieten teilen.  Welche Beziehungen 
gibt es zwischen diesen entstehenden Flächennetzwerken, etc.  Auf diesem 
Wege kann OSM helfen Zusammenhänge zu entdecken, die bisher nicht 
entdeckt werden, weil die Datenbasen von Spezialisten getrennt 
voneinander gepflegt werden.
=Ende Zukunftsmusik===========

Momentan würde ich mich auf den Bodennutzungsaspekt beschränken.  Wenn 
es dafür nicht gelingt, alle Ansprüche unter einen Hut zu bringen, 
braucht man nicht weiter träumen.  Ohne irgendeinen Bezug (und damit die 
Möglichkeit der Zusammenarbeit untereinander) zwischen Flächen wird es 
nicht gehen.  Wenn wir da weiter mit "closed ways", "overlapping ways", 
geklebten ways, dicht nebeneinanderliegenden doppelten ways, etc. 
rummanschen und jeder sein eigenes Süppchen kocht, bleiben 
Sinnzusammenhänge der Daten für/in OSM verborgen.  Diese dann 
herzustellen, bleibt individuelle Aufgabe für clevere 
Algorithmenschreiber, die aus dem Rausch-Salat ein bisschen Signal 
herausholen.

Ich komme nochmal auf die Radrouten-Analogie zurück:

Aus dem Schatz _aller_ Wege innerhalb OSM (abzüglich derer, wo das 
Radfahren verboten ist), können Wege ausgewählt werden, um eine Route zu 
bilden.  (Route - Relation mit type=route)

Die Analogie für Flächen dazu:  Aus dem Schatz _aller_ Wege innerhalb 
OSM, können die Wege ausgewählt werden, die eine Fläche begrenzen.  
(Multipolygon - Relation mit type=multipolygon)


Späten Gruß
Christian