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

steffterra steffterra at me.com
Mo Jul 26 19:03:23 UTC 2010



Am 26. Jul 2010 um 20:25 schrieb Guenther Meyer <d.s.e at sordidmusic.com>:

Am Montag 26 Juli 2010, 17:29:22 schrieb steffterra:
> Was meinst du mit "Linien"-Chaos - Es sind doch nur drei Linien in JOSM
> (und eine Linie im Renderer): 1. Linie (way): die eine Fahrtrichtung:
> hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden
> ist. 2. Linie (way: der daten-way: hier wird alles draufgetaggt, was
> _nicht_ richtungsabhängig ist, wie z.b. name + ref-Tag 3. Linie (way): die
> entgegen gesetzte Fahrtrichtung: hier wird alles draufgetaggt, was _nur in
> dieser Fahrtrichtung_ vorhanden ist.
> 

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. 

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.

> 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.

> 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?

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?

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.

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!

> > Genau diese Probleme will die Gruppierung ja verhindern, weil so genau
> > festgelegt wird, an welchem way, also auf welcher Straßenseite welche
> > Dinge vorhanden sind. Wie z.b. Radweg, usw. (Das ist übrigens der
> > Unterschied zum wesentlich komplizierter zu zeichnenden Linienbündel, da
> > wir ausreichend tags haben, um alle Arten von Radwegen, Parkständen, etc.
> > am way zu taggen. Das einzige Problem hierbei ist aber durch die
> > Gruppierung nicht mehr vorhanden und damit das Ziel derer errreicht: die
> > richtugnsabhängigen Unterschiede liegen nun auf den einzelnen ways der
> > Straßenseite, wo in Wirklichkeit vorhanden sind.
> 

Besser als die urspruengliche Idee des Linienbuendels ist dein Vorschlag 
allemal ;-)
 
Na Danke. Das ist doch mal ne Ansage.

> Sorry, aber lies meine erste Mail zu dem Thema nochmal in Ruhe durch. Dann
> weisst Du, was ich möchte. Danke vielmals für die Aufmerksamkeit ;-) Ich
> denke mir shcon die ganze Zeit, dass Du es komplett nicht verstanden hast,
> was die Gruppierung möchte. Gerne erkläre ich es dfir aber auch mal
> seperat per email, dass wir den Thread nciht unnötig zumüllen, weil es
> andere längst verstanden haben. Kann ja vorkommen, kein Problem, aber dann
> nicht hier nochmal alles von vorne durchkauen bitte, wenn man es im ersten
> Post nachlesen kann.

Eigentlich macht die Mail es relativ klar.
 
Danke. Meine Rede :-)
 
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

steffterra
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20100726/2d348958/attachment.htm>


Mehr Informationen über die Mailingliste Talk-de