[Talk-de] Weg vom Way, hin zur Nodes-Relation

[Bernd Raichle]

On Monday, 22 June 2009 12:26:57 +0200,
Frederik Ramm <frederik at remote.org> writes:
 > Andreas Pothe wrote:
 > > Ich denke, man koennte es noch wuppen, da mit der API 0.6 alle
 > > Basisvoraussetzungen vorhanden sind, die wir braeuchten. Man muesste
 > > sich lediglich darauf einigen, dass man keine Ways mehr in die
 > > Relationen packt, sondern nur noch Nodes. Die Verbindung dieser Nodes
 > > wird dann ueber die Wegteile, die dazwischenliegen, automatisch
 > > vorgenommen.

Alternativ koennte man auch den GDF-Ansatz waehlen: Knoten werden
unterschieden in Verbindungs- bzw. Kreuzungsknoten und inneren
Wege-Knoten (sog. Shape node).  Wege gehen nur von einem Anfangs-
ueber null oder mehr innere Knoten zu einem Endknoten, d.h. nur von
Kreuzung zu Kreuzung.  Aendert sich auf einem Wegestueck ein Attribut,
so wird der Weg an dieser Stelle aufgeteilt.  Ausserdem hat ein Weg
eine _Richtung_, die sogenannte "Digitalisierungsrichtung", so dass
man sich bei allen richtungsabhaengigenn Attributen (und Relationen)
auf diese beziehen kann.


 > Du meinst sowas wie das hier:
 > 
 > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Segmented_Tag
 > 
 > Das gabs sogar schon vor API 0.6.

Der Vorschlag stammt von mir und versucht mehrere Probleme oder
Anforderungen zu loesen:

 1. Ein Weg hat keine Richtung bzw. man soll die Richtung nicht
    verwenden, da sich u.a. beim Zusammenfuegen mehrerer Wege zu einem
    Weg die Richtung veraendert werden kann und die Editoren dies
    (damals) nicht korrigiert haben.

    Daher kann man mit dem Vorschlag durch explizite Angabe eines
    Anfangs- und eines Endknotens eine Richtung mitgeben, die sich
    auch beim Umdrehen des Ways nicht aendert.

    Mittlerweile kann JOSM richtungsabhaengige Attribute
    (bspw. "key:left=value") mit umdrehen (=> "key:right=value"), so
    dass dieses Problem nicht mehr vorhanden sein sollte ... oder?

 2. Ein Attribut laesst sich nicht fuer einen Wegteil angeben.  Will
    man wegen Bruecken, Tunnel etc. Wege nicht aufsplitten, muss man
    den Anfang und das Ende der Attributgueltigkeit mitgeben.

 3. Eine Attribut-Menge, die zusammengehoert, kann nur einmal an einen
    Weg gehaengt werden.

    Bsp: maxspeed=100 fuer Pkw, maxspeed=80 fuer Pkw von 22:00 bis
    6:00 Uhr, maxspeed=60 fuer Lkw kann man nicht so einfach taggen.

    Bislang geht dies nur mit "maxspeed=100" direkt an den Weg und
    zwei Relationen an den Weg mit beispielsweise in der 1. Relation
    "maxspeed=80", "validity_period=22.00-06.00" und in der
    2. Relation "maxspeed=60", "vehicle_type=hgv", wofuer man auch
    diese "Segmented_Tag" verwenden kann.  Alternativ gibt es auch
    Vorschlaege a la "maxspeed[22.00-06.00]=80" und
    "maxspeed[hgv]=60", die sich meist auf Gewichts-, Hoehen- und
    Zeitbeschraenkungen beziehen.

    Ein vielleicht besserer Weg (fuer API 0.7) waere das, was in GDF
    als "Composite Attributes" verfuegbar ist, also aus mehreren
    Attributen zusammengesetzte Attribute.  Wenn man in der API Tags
    mehrfach verwenden koennte (was prinzipiell jetzt schon moeglich
    ist) und diese auch explizit gruppieren koennte (dies ist nicht
    oder nur ueber Klimmzuege moeglich), waere vielleicht fuer diese
    Dinge ein einfaches Tagging-Schema festlegbar?



 > > Eine Umstellung des bisherigen Schemas waere gar nicht so aufwaendig,
 > > wenn ich sehe, wie viele Robots schon herumschwirren, duerfte sich
 > > sicherlich jemand finden, der auch hierfuer einen Robot schreibt.
 >
 > Robots schreiben ist der einfache Teil. 100.000 Nutzer gleichzeitig 
 > "umzuerziehen" und die Editoren und Renderer anzupassen, waere der 
 > schwierigere Teil.

Zur Umstellung benoetigt man keinen Robot, das wuerde und muesste wie
bei der letzten Umstellung von 0.5 auf 0.6 auf dem Server erfolgen.
Das Hauptproblem sind die Nutzer, denn ein "Normal-Mapper" faengt mit
dem Begriff "Way" deutlich mehr an als mit "Relation" ... so dass wir
entweder viele potentielle Mapper verlieren oder abschrecken werden
oder diesen andere Begriffe in den Editoren anbieten muessten.


 > Es ist zu bedenken, dass dieses Proposal bei weitem auch nicht alle 
 > Probleme loest, denn in letzter Konsequenz muessten so, wie Du es 
 > formuliert hast, ja fuer eine simple Landstrasse, die heute als einziger 
 > Way mit 5 Tags existiert, ploetzlich 5 Relationen angelegt werden. Auch 
 > nicht gerade schmackhaft fuer Otto Normalmapper.

... erst recht nicht mit den momentanen Relation-Editorfunktionen :-(


 > Oder deutlicher gesagt, eine spontane Umstellung vom einen auf das 
 > andere waere sicherlich nicht moeglich, aber man koennte die 
 > segmentierten Tags als Zusatzoption einfuehren, eventuell zunaechst 
 > verstaerkt in einem Teilgebiet wie Tempolimits o.ae. einsetzen, und dann 
 > schauen, ob sich das bewaehrt und es ggf. auf andere Gebiete ausweiten.

... so war mein Vorschlag auch gedacht.


Gruss,
  -bernd