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, ...). Aber prinzipiell ein guter Ansatz. Man koennte sich auch durchaus verschiedene Ansichten vorstellen, je nachdem was einen interessiert, bis hin zum "fotorealistischen Rendern". > Aber man koennte sich doch die drei ways sparen, und das ganze genau so auf > einem way abbilden. Klar braucht man da eine Richtung, und drehen muss die > auch keiner. > > Dann hast Du das jetzige OSM. Was willst Du mir damit sagen? Das man > einfach die Tags drehen kann, das ist ja das Problem. Sie aber zu sperren > in irgendeiner Form ist eben aber auch keine Lösung, das hat der Thread > auch gezeigt. > 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. 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. Hmm, jetzt faellt mir noch was ein: Eigentlich wuerden in deinem Modell zwei ways fuer die beiden Seiten reichen. 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... > > Doch es ist nicht grundsätzlich gedacht, dass man Fahrspuren taggt, wo es > > vom Tagging her gar nicht nötig wäre. Und vom Tagging her ist es nur dann > > nötig, wenn Tags nur in einer Richtung gelten, oder sie sich Tag für die > > gleiche Richtung unterscheiden. (Beispiel: innere Spur der einen Richtung > > maxspeed=50, äußere Spur der gleichen Richtung maxsped=40, Gegernrichtung > > beide Spuren: maxspeed=80, also dort nur ein way und lanes=2) > > laesst sich alles als Attribut auf einem way abbilden. > > Ja, aber das Grundproblem, warum ich dieses konzept entwickelt habe ist > dennoch vorhanden: jemand dreht den way und jemand tagg danach nochmal was > richtugnsabhängiges ... Da ist mehr Chaos vorprogrammiert, als wenn alles > sauber auf seiner Fahrspur als normaler tag angelegt ist. Denn dann ist es > egal, wie der way (respektive die Way-Gruppe) gedreht ist. Denn der tag > ist auf der Spur, die es betrifft. fertig - ohne Zusatztag für die > Richtung, weil das ja dann hinfälllig ist, verstehst Du? > 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? > 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. > Aber egal wie man das auf der Datenbasis modelliert, letztendlich bleibt es > sowieso am Editor haengen, das entsprechen editierbar darzustellen. > > es muss in geeigneter Weise umgesetzt werden um auch Deinem berechtigten > Kritikpunkt der Wahrnehmung der Ausdehnung der Straße genüge zu tun. > Deshalb ja mein obiger Vorschlag zur Umsetzung im Editor. > gut, dass wir uns wenigstens hier einig sind ;-) > 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. > 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...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
