Am 26. Jul 2010 um 21:33 schrieb Guenther Meyer <d....@sordidmusic.com>:
Am Montag 26 Juli 2010, 21:03:23 schrieb steffterra:
> ok, so kannst du dir natuerlich die Richtung sparen.
> Nur hast du damit im Editor durch die drei ways auch automatisch eine
> Ausdehnung, die nicht unbedingt der Realitaet enspricht (tut sie sowieso
> nicht, aber eine schmale Strasse bringst du dann evtl nicht mehr zwischen
> den angrenzenden Haeusern/POIs durch.
>
> Daran habe ich auch gedacht. In JOSM sollte erstmal nur der Datenway zuu
> sehen sein. Und nur, wenn man auf ihn klickt, dann gehen die beiden ways
> links und rechts davon "auf". Wenn man wieder woanders hinklickt, geht es
> wieder "zu" bzw. zurück. Da es nur für Straßen gedacht ist, diue
> richtungsabhängige Tags benötigen (und das ist sicher nicht die Masse),
> könnte man auf diese Weise an die Stellen "hineinschauen", die einen
> interessieren.
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.
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.
natuerlich kann man das drehen nicht sperren. Aber man muss es in der Software
auch nicht anbieten, nicht mal anzeigen. Denn es gibt keinen Grund, die
Richtung ueberhaupt zu drehen.
Das Problem entsteht doch nur dadurch, weil die Richtung einerseits als
Referenz fuer diverse Tags genutzt wird, andererseits aber auch direkt z.B.
die Richtung einer Einbahnstrasse darstellt. Und genau letzteres muss getrennt
werden.
Ich sehe die Richtung als Referenzeigenschaft des ways, genauso wie du das
durch drei getrennte ways darzustellen versuchst.
ja, ich verstehe es "ausserhalb meines Models" auch so.
Um beim Beispiel Einbahnstrasse zu bleiben:
Wenn die Fahrtrichtung aus irgendwelchen Gruenden gedreht werden muss, dann
wird nur das entsprechende oneway-Attribut gedreht, sonst nichts. Einfacher
geht's doch kaum...
> > Wo ist Dein Problem? Man muss ja nicht jede Fahrspur abbilden, man könnte
> > es aber, falls nötig. Nötig wäre es nur, wenn sich die Fahrspuren _einer
> > Richtung_ vom tagging her unterscheiden, z.B. bei einer abbiegenden
> > äußeren Fahrspur udn der gerade aus weiter führenden Fahrspur.
>
> muss man nicht.
> Ausserdem hast du dann wieder eine Mischloesung...
>
> Nein, was ist denn gemischt? richtungsabhängige tags gibt es dann offiziell
> nicht mehr, weil dann die Gruppierten ways für die Richtungsabbildung
> zuständig ist, die das viel besser maschinen- udn menschenlesbar abbildet.
>
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.
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.
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.
... 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?
> Aber davon abgesehen, was wäre denn Deine Lösung, oder ist Deine
> Diskussionsgrundlage, dass es nichts zu diskutieren gibt, weil du mit
> backward/forward und left/right keine Probleme siehst wie ich?
>
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?
> Rendern laesst sich sowas vielleicht noch, aber spaetestens bei der
> Graphenbildung fuer's Routing wird's komplex wuerde ich vermuten...
>
> Schön, dass Du aufs Routing zu sprechen kommst. Routing kann diese
> Datenbsasis ideal zum fahrspurgenauen Routen z.B. an neuraligschen Stellen
> nutzen. Das ist ein sehr postitiver Nebeneffekt und keineswegs ein
> Nachteil. Ganz im Gegenteil!
>
wie gesagt, das ist nur eine Vermutung. Prinzipiell kann man wahrscheinlich
aus jeden der Modelle was sinnvolles rausziehn.
sonst gäbe es ja deren Daseinsberechtigung nicht, oder? ;-)
> 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.
steffterra
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
