[Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)

Guenther Meyer d.s.e at sordidmusic.com
Mo Jul 26 21:43:03 UTC 2010


Am Montag 26 Juli 2010, 23:02:27 schrieb steffterra:
> spaetestens wenn du Fahrspuren mit abbilden willst, hast du zumindest in
> groesseren Staedten staendig richtungsabhaengige Attribute.
> Dasselbe gilt fuer viele Landstrassen (Ueberholverbote,
> Geschwindigkeitsbeschraenkungen, ...).
>  
> Die habe ich auch so, nur das ich sie dann an der Spur taggen kann , die es
> betriff und muss es nicht über ein kompliziertes Tagging-Schema an den
> einen way hängen.
> 

komplizierter ist das auch nicht, nur anders.


> Aber prinzipiell ein guter Ansatz. Man koennte sich auch durchaus
> verschiedene Ansichten vorstellen, je nachdem was einen interessiert, bis
> hin zum "fotorealistischen Rendern".
>  
> Rendern ist aber Rendern und meint nicht die Darstellung im Editor, die ich
> oben beschrieb. 'Für die Renderer habe ich mir ja auch etwas ausgedacht,
> wie z.b. für Kreuzungen. So eine Art Lupenfunktion, aber keinen weiteren
> Zoomlevel für dei ganze Seite. Also eher einen Zoomlevel für ein
> definiertes Rechteck, das dann daneben noch einmal groß gerendert wird.
> 

Ich dachte auch eher an eine Darstellung im Editor, die eher wie eine 
Draufsicht einer echten Strasse aussieht, um's den Mappern einfacher zu 
machen. Auch ein Editor muss seine Ansicht irgendwie rendern. Bei Merkaartor 
z.B. wuerde ich die Darstellung durchau so nennen.


> du hast dann einerseits deinen Wegtripel, andererseits im schlimmsten Fall
> noch mehrere ways, die die einzelnen Fahrspuren kennzeichnen, wenn ich dich
> richtig verstanden habe.
>  
> 
> Nunja. Sehe es es. Man kann den way flexibel einsetzen. Entweder 
> a) so wie jetzt auch mit einem way (für die Strecken ohne
> richtungsabhängige tags
> 
> b) mein Model, das zwei ways für jede Fahrtrichtung vorsieht und einen
> daten-way dazwischen, der von einem neuen Renderer nicht gerendert wird,
> aber von einem älteren Renderer genutzt wird, weil dieser die anderen
> Fahrrichtungsways nicht nutzen kann. Bei mehreren Fahrspuren pro Richtung
> könnte dann auch da der lanes-tag eingesetzt werden
> 
> c) mein Model mit genmutzter Möglichkeit neben dem daten-way links und
> rechts davon mehrere Fahrspuren-ways zu zeichnen, wenn es denn nötig ist,
> wie z.b. an komplizierten Kreuzungen, oder wenn es verschiedene
> maxspeed-tags auf jeder Fahrspur gibt, etc. Dann gibt es da halt kein
> lanes=2, sondern eben zwei ways, die dann zusammen mit dem Rest in einer
> Gruppe die Straße im gesamten darstellen.
> 
> Der Vorteil ist die Flexibilität ohne dabei neue Redundanz zu bilden,
> gleichzeitig ist das ganze abwärtskompatibel. Das ist sogar der wichtigste
> Punkt an der ganzen Geschichte.
> 

viele verschiedene Moeglichkeiten, die dann auch jeder Renderer und Editor 
beruecksichtigen muesste. DAS wird komplex.

gut, auf a) kann man erst mal wegen der abwaertskompatibilitaet nicht 
verzichten, aber c) wuerde ich vermeiden...


> Hmm, jetzt faellt mir noch was ein:
> Eigentlich wuerden in deinem Modell zwei ways fuer die beiden Seiten
> reichen. 
> eigentlich ja - doch ich wollte vermeiden, dass z.B. der name-tag an beiden
> ways getaggt wird, was wieder zu unnötiger Redundanz führen würde, so wie
> im Linienbündel-Model, das ich nicht so mag.
> 

wer sagt dir, dass die Tags nicht an alle drei ways gehaengt werden?


> Da diese sowieso in einem uebergeordneten Objekt zusammengefasst werden
> muessen, kann man doch die allgemeingueltigen Tags gleich da dran haengen;
> das Einzeichnen des Mittelweges kann man sich dann sparen...
>  
> Das "da dran hängen" ist ein Problem, das Du wie lösen würdest? Ich bin
> gespannt, da ich gerne auf den daten-way verzichten würde. Aber bitte
> führe jetzt nicht die Relation als Lösung an, den die wollte ich
> vermeiden. Sonst könnte man gleich beide Fahrtrichtungen mit Relationen
> erfassen und alle richtungsabhängigen tags da dran pappen.
> 

im Prinzip ist das Ganze sowieso nichts anderes als eine Art von Relation.
Du hast ein Hauptelement, das fuer das Strassenobjekt selbst steht und sowohl 
die allgemeinen Tags enthaelt, als auch die ways miteinander verbindet.
Dieses Element jetzt auch noch als way separat in die Mitte reinzumalen, ist 
total ueberfluessig.


> ... schon klar.
> Im Prinzip laeuft alles auf das fehlerhafte Drehen eines ways zurueck.
> Aber warum was neues gross und aufwendig ausarbeiten, wenn man genausogut
> die Ursache des Uebels anpacken kann?
>  
> Und wie?
> 

> wie bereits gesagt: ein way bekommt beim Anlegen eine Richtung, und die
> bleibt unveraenderlich so wie sie ist.
> Wenn die Editoren diese Referenzrichtung und das Drehen des Weges gar nicht
> erst anzeigen/anbieten, dreht die auch keiner.
>  

> Und wenn sich die Richtung einer Einbahnstraße ändert, oder man überhaupt
> erst eine taggen möchten, owowohl es vorher keine war? 
> 

ganz einfach, indem man in der Darstellung der Strasse im Editor diese 
selektiert, die Eigenschaft "Einbahnstrasse" waehlt, und dann die Richtung 
"von hier nach da" angibt. Der Editor setzt dann automatisch das richtige Tag 
(irgendwas mit oneway:forward oder oneway:backward, je nachdem wie die 
Referenzrichtung ist). Was letztendlich getaggt wird, kann dem User egal sein, 
er sieht ja in der Darstellung, in welche Richtung es geht.


> > Wie waer's wenn du mal ein Beispiel anhand einer typischen Strasse
> > einfach mal modellierst und als OSM-Datei zur Verfuegung stellst?
> > 
> > Kann ich machen Komme aber erst gegen Mitte der Woche dazu. Danke für den
> > Vorschlag
> 
> sehr schoen. ich bin gespannt...
>  
> 
> Mal sehen, wie ich das machen kann, Sachen abzubilden, die es noch nicht
> gibt. Ich versuche auch die kritischen Dinge wie Kreuzungen und
> Kreisverkehre hinzubekommen. Aber ganz ohne manuellem Zeichnen wird es
> nicht gehen. Mal sehen.
> 
ich denke mit josm laesst sich das recht gut machen.


noch was: ist es eigentlich Absicht, dass dein Mailclient kein Quoting macht? 
Das macht deine Posts stellenweise etwas schwer lesbar...

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 198 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20100726/02ee7299/attachment.sig>


Mehr Informationen über die Mailingliste Talk-de