[Talk-de] Einzelspurmapping (war: Fahrspuren die 315.)

[Christian Müller]

Hi,


Am 09.03.2012 23:27, schrieb Stephan Wolff:
> Moin!
>
> Am 09.03.2012 02:00, schrieb Christian Müller:
>> Stephan Wolff<s.wolff at web.de>  schrieb:
>>
>>>> Das empfinde ich eigentlich als nachrangig.  Wenn das Modell gut ist,
>>>> lässt sich der Renderer so anpassen, dass der Output erzeugt wird,
>>>> den man will/braucht.
>>>
>>> Kein Datenmodell beschreibt die reale Situation vollständig.
>>
>> Das habe ich auch nicht behauptet!
>
> Für jede Anwendung ist ein anderes Datenmodell ideal. Ein gutes 
> Modell, das jedes Renderergebnis liefern kann, gibt es nicht.

Auch das habe ich nicht behauptet, aber Du wirst doch einsehen, dass es 
Modelle gibt, die es einfach machen, verschiedene Varianten an 
Renderoutput zu erzeugen/zu errechnen, wohingegen andere, weniger 
universelle Modelle es Dir schwerer machen, das zu erreichen.  Der 
Erfolg von OSM an sich beruht ja schon darauf, im Grunde kein starres 
Tagging-Schema für die Basisgeometrie zu fordern (gefordert zu haben?), 
bis auf den generischen Zwang, Informationen in key-value-pairs abzulegen.


>>>> auftaucht..  "nebeneinander existieren" klingt nach Redundanz..
>>>
>>> Es klingt nur so. Zudem wäre Redundanz nur ein Schönheitsfehler aber
>>> kein Ausschlußgrund für eine Koexistenz.
>>
>> Komischerweise sieht man das im Falle von nebeneinandergezeichneten
>> secondaries aber offenbar nicht so.  Lustig.
>
> Hat jemand kritisiert, dass die Wege redundant sind? Das sind sie nicht.

Doch das sind sie.


> Sie widersprechen der üblichen "highway"-Definition.

Das wurde hier behauptet und es ist Unsinn, weil es, orientiert man sich 
an den Angaben im Wiki, nicht stimmt.

http://wiki.openstreetmap.org/wiki/Key:highway

The *highway tag* is the primary tag used for highways.


Nun, ich tagge Straßen, keine Häuser, keine Grünanlagen mit dem 
Highwaytag und selbst wenn es jemandem, der sich für Spuren und die 
Details nicht interessiert, komisch vorkommen mag, dass ein und die 
gleiche Straße mehrfach beschrieben wird.

Wenn ich die Straße (wieder im Blicke derer, die sich nicht für Spuren 
interessieren) mehrfach beschreibe, bezeichnet man das gemeinhin als 
Redundanz.  Die ist nicht unbedingt erstrebenswert, aber auch nicht 
verboten.  Sie wird in OSM bereits an X Stellen verwendet - entweder aus 
Bequemlichkeitsgründen oder um Kompatibilität abzubilden, z.B. auch im 
ÖPNV-Schema, wo Doppelinfos in stop_position, platform, stop_area, etc. 
erlaubt sind.

Du verwendest in deiner Variante vom Januar die Krücke "detail_exists", 
ich tagge eben die Infos, die der Straße gemein sind, mehrfach - so 
what?  Das wiederspricht keiner üblichen Definition - es ist kompatibel.


>
>>> Relationen erfordern immer eine Sonderbehandlung. Ein Modell mit exakt
>>> zwei Spuren pro Relation wäre für den Router noch recht einfach, aber
>>> für die Mapper sehr aufwändig. Ein Modell, das alle
>>> nebeneinanderliegenden Fahrspuren zusammenfasst, wäre ungünstig für den
>>> Router.
>>
>> Das braucht man gar nicht und ich weiß jetzt auch nicht, wie Du in 
>> dem Zshg.
>> darauf gekommen bist.  Es gibt eine Relation pro Spur - das ist ja 
>> das Schöne.
>> Und turn_restriction dürfte mittlerweile schon recht lange von den 
>> Routern
>> gehandhabt werden..  In gosmore z.B. schon mind. 4 Jahre..
>
> Ich sprach von einem Spurwechsel vor der Ampel. Eine turn_restriction
> Relation hat damit nichts zu tun.

Wovon Du sprachst, steht noch im Quote, siehe oben.  Ich habe das 
Gefühl, dass wir aneinander vorbeireden.  Ich habe den falschen 
Unterstellungen zu meinem Konzept, in den letzten mails genügend 
entgegengesetzt, um die meisten Kritikpunkte zu entkräften - wenn man 
sich damit nicht beschäftigen will und weiterhin Tunnelblick fährt, kann 
ich das nicht ändern.  Speziell zum Spurwechsel vor der Ampel habe ich 
mittlerweile ganze 3! Methoden aufgezeigt, wie Spurwechselinfos erhalten 
werden können, ohne Geisterwege (Querstraßen) einzuzeichnen, die auch 
wieder Aufwand bedeuten würden und Newbies abhalten, Dinge zu ändern:

1) Zusammenhang ist über den Kreuzungspunkt herstellbar, einen 
Algorithmus zum finden der Spuren, in die es erlaubt ist zur Fahrzeit zu 
wechseln, habe ich in einer der letzten mails zum Thema angegeben

2) und 3)  sind auf der Wiki-Seite zum Konzept zu finden  (lane_group 
relation, um diese Infos direkt zu erfassen,  oder Erfassen der area 
aller lanes, um dann mit IS_IN zu arbeiten)

Aus der Unkonkretheit deiner Mail ("Relationen erfordern immer eine 
Sonderbehandlung") ließ sich leider nicht darauf schließen, welches Ziel 
deine Kritik genau hatte.  Deshalb habe ich Dir ebenso unkonkret und 
allgemein nochmal beschrieben, mit welcher Einfachheit das Konzept 
daherkommt:

     eine Spur mappen
     TR erstellen und Abbiegebeschränkung erfassen

     die Summe aller Spuren und TRs enthält präzise Informationen über 
die Kreuzung und Layout

Je nachdem, was der Anwender konkret wissen will, lassen sich mittels 
gezielter Suche und Selektion in diesen Informationen wesentlich mehr 
Anfragen beantworten, als die Kritiken der letzten mails dazu dies in 
oberflächlicher Art und Weise behauptet haben.


> Christian, bitte berücksichtige die von vielen Teilnehmern geäußerten 
> Kritikpunkte. Es wird dir nicht gelingen, die wichtigsten Tag und
> Relationen umzudefinieren.

Bitte sprich für Dich selbst und nicht für eine imaginäre Masse.  
Vielleicht hast Du ja in deiner eigenen Überzeugung sogar die mails 
überlesen, in denen Zustimmung zum Einzelspurmapping signalisiert wurde 
und meinen Konsens dazu, bessere highway-values für Spuren zu finden 
ignoriert.  An letzterem Punkt reiben sich viele auf, ohne zu sehen, 
dass es momentan keine Alternativen gibt.  Sie wollen nicht verstehen, 
dass der Prozess der Veränderung es durchaus erlaubt,  ein 
highway=secondary_link  in ein  highway=secondary_lane  zu wandeln, wenn 
die Zeit dafür reif ist.  Momentan würde das bestehende Router vor 
unlösbare Aufgaben stellen.  Der Finalismus in den meisten Kritiken ist 
das fatale, als wenn etwas in OSM endgültig wäre.


Gruß