Talk:Germany/Workshops/Linienbündel

Wieso nicht einfach Relationen für die einzelnen Wege erstellen, und diese Relationen der Straße zuordnen? --TEL0000 19:21, 16 September 2008 (UTC)

Wenn ich das richtig verstehe, willst du eine Relation erstellen mit den Tags, die die Spur (bzw. den Radweg etc.) beschreiben, und dieser dann als Member den Straßen-Way zuordnen? Prinzipiell finde ich den Gedanken, Relationen für die Spuren zu verwenden, nicht schlecht. Hast du schon Idee, wie/ob man dann die Anordnung/Reihenfolge der Spuren angeben könnte? --Tordanik 20:53, 16 September 2008 (UTC)

Richtig. Damit wären einige Nachteile von Lösungsansatz 2 beseitigt. Z.B. wäre richtungsabhängiges Tagging möglich, indem man der Relation als Role ein "backward" oder "forward" angibt. Außerdem wär es möglich den Unterwegen verschiedene Attribute zu geben. Für die Anordnung/Reihenfolge hab ich aber noch keine Idee. --TEL0000 22:58, 17 September 2008 (UTC)

Richtungsabhängigkeiten könnte man doch mit Variante 3 auch einfach lösen? --Cbm 09:32, 4 October 2008 (UTC)

• Ich finde Variante 3 eigentlich sehr gut. Denn als Vorteil könnte man aufführen, dass man alle Attribute eines komplexen Ways (oder zumindest einem Teilstück) auf einen Blick sehen kann, und nicht Attribute sich in Relations (die ja ggf. auch Teil weiterer Relations sind) 'verstecken'. Das ermöglicht dann das editieren komplexer Wege auch im einfachsten (nicht Relation-fähigen) Editor. --Cbm 06:46, 3 October 2008 (UTC)

Einzelne Lanes würde ich allerdings nicht in ways splitten sondern den Ways noch eine weitere Ebene geben.z.B.: way.1.lane.1:hgv=no --Cbm 06:46, 3 October 2008 (UTC)

• Mit der weiteren Ebene hast du Recht, das sollte man bei jeder Lösungsmöglichkeit umzusetzen versuchen – schon deshalb, weil man viele Attribute (maxspeed, access) dann eventuell von der oberen Ebene „vererben“ könnte, aber auch, weil wohl viele Anwendungsprogramme Spuren einer Straße nicht gleich behandeln werden wie Wege neben der Fahrbahn, die Unterscheidung sollte also möglich sein.

Die Vermeidung von Relations halte ich allerdings für unangebracht. Ja, sie stellen höhere Anforderungen an den Editor, aber werden schon jetzt für so viele verschiedene Dinge verwendet – und in Zukunft vermutlich für noch mehr –, dass man nicht wirklich auf sie verzichten sollte. Relations sind ein Grunddatentyp von OSM, deshalb sollte man sie eigentlich in Editoren, die sich OSM-kompatibel nennen, erwarten können.

In diesem Fall brächten einem Relations einige Vorteile: Das Einfügen von Wegen würde einfacher und weniger fehleranfällig, da man nur für eine Relation, nicht aber für jedes Attribut die Positionsnummer ändern müsste. Relations kommen außerdem mit einer natürlichen Hierarchisierbarkeit. Ich halte Relations übrigens auch für leichter auswertbar, da sie direkt in programminterne Referenzen umgesetzt werden können. Das wird aber von Software zu Software sehr unterschiedlich sein.

Ich schreibe wohl am besten bei Gelegenheit mal einen „Lösungsansatz 4“ mit hin.

--Tordanik 07:34, 3 October 2008 (UTC)

• ich wollte damit auch nicht sagen, dass man Relations auf jeden Fall zu vermeiden hat. Aber man brauchts auch nicht zu übertreiben, sonst können wir direkt wieder "ways" streichen und nur "Segmente" nutzen und alles mit Realtions abbilden ;)

Ich würde behaupten, dass der Großteil der zu erfassenden Wege mit einer Variante 3 (natürlich in Kombination mit Variante 1) schneller und einfacher für den User zu erfassen (und zu prüfen) sind, als mit übermäßiger Nutzung von Relations. --Cbm 08:09, 3 October 2008 (UTC)

Variante 3 würde auf jeden Fall eine Einigung zum Thema "Hirarchische Schlüssel" erfordern (http://forum.openstreetmap.org/viewtopic.php?id=1284) Sämtliche Software müsste ja erstmal mit den dynamischen Schlüsseln umgehen lernen ... Was die Relationen angeht würde ich es glatt für sinnvoll halten alle Tags in Relationen zu verpacken, und die eigentlichen Wege nur als "Segmente" zu nutzen, aber das ist eher ein anderes Thema ... Und wie Tordanik schon sagte, erlauben Relationen von sich aus ja schon hirarchien ... --TEL0000 22:48, 7 October 2008 (UTC)

Relation-basiertes Konzept

So, inspiriert durch die bisherige Diskussion habe ich jetzt mal einen massiv Relation-basierten Ansatz dargestellt. Was ich daran sympathisch finde, ist: Er ist sehr zukunftssicher. Jemand will Infos zum Einordnen bei Autobahnkreuzen? Lässt sich machen (per spurweiser Abbiege-Restriction). Der nächste will die einzelnen Spuren als Flächen einzeichnen? Kein Problem (ungetaggte Ways als Member an die unteren Hierarchieebenen – fertig). Richtungsabhängige maxspeeds? Die Möglichkeit fällt bei mehreren Spuren schon als Nebenprodukt ab.
Offensichtlichster Nachteil ist natürlich erst einmal: Ohne Editorverbesserungen macht das Eingeben von so etwas definitiv keinen Spaß. (Dies gilt m.E. aber auch schon für #3.) Das ließe sich mit einem geeigneten Tool aber ganz gut lösen, denke ich. Ist der Weg ansonsten gangbar, habe ich Schwierigkeiten übersehen? Ich bitte um vernichtende Kritik. ;) --Tordanik 23:18, 11 October 2008 (UTC)

Schaut logisch und durchdacht aus. Wenn jetzt noch ein EasyEdit-Tool für JOSM kommt würde ich sofort der Sache zustimmen. Wir sollten diesen Vorschlag auch mal in englisch in ein Proposal packen, damit mehr Leute mitdiskutieren. --Cbm 10:05, 22 October 2008 (UTC)

Würde es vielleicht Sinn machen Standard-Relations zu erstellen? Oder is das eher ein Fall für Presets beim Erstellen der Hirarchie?--Cbm 10:08, 22 October 2008 (UTC)

Es sollte definitiv auch mal auf Englisch präsentiert werden, ich hatte bis jetzt erst mal vor, zumindest einen Prototypen für ein JOSM-Plugin zu erstellen, um mich selbst von der praktischen Verwendbarkeit des Konzepts zu überzeugen. Bin nur nicht dazugekommen bisher. :-/

Was genau meinst du mit Standard-Relations? So etwas wie Presets, die eine komplette Relation-Hierarchie erstellen („Straße mit 2 Radwegen“, „dreispurige Autobahn“)? Da gibts wohl zu viele Kombinationsmöglichkeiten, fürchte ich – lasse mich aber gerne vom Gegenteil überzeugen. Für die Lanes selber sollte es dergleichen m.E. aber auf jeden Fall geben. --Tordanik 23:33, 25 October 2008 (UTC)

Ok, ich habe zu dem Thema mal einen Plugin-Prototypen erstellt -- Erkenntnis daraus ist für mich: Es ist prinzipiell ohne großen Aufwand möglich, einen Editor mit einem Tool auszustatten, das jeden der vorgeschlagenen Ansätze für den Mapper handhabbar macht. Was vor allem beim Relation-basierten Ansatz noch fehlen würde, wären Konzepte zu einem Set von möglichen Lanes-Typen, falls man so etwas überhaupt vorgeben will. Ansonsten gibt es natürlich noch haufenweise Dinge, die man mit einbauen könnte. Von dividers bis zu Abbiegespuren ... --Tordanik 22:25, 4 November 2008 (UTC)

für welche Situation hast du sublane entworfen? theoretish kann man doch immer auf unterster ebene bleiben, weil jede lane wieder links und rechts was haben kann und die direction ja auch frei für jede Lane setzbar is? Ich finde das Plugin im übrigen SEHR brauchbar! :) --Cbm 12:36, 10 November 2008 (UTC)

Danke für die positive Rückmeldung. Hintergrund der hierarchischen Lanes mit Sublanes etc. war vor allem, dass man oft viele Lanes hat, die gemeinsame Eigenschaften teilen (seien es jetzt access-Rechte, surface, ...), so dass man diese Informationen eher nur einmal setzen möchte -- eben auf der höchstrangigen Lane, die diese Eigenschaften hat. Mindestens eine Hierarchieebene braucht das vorliegende Modell natürlich schon deshalb, damit man die Reihenfolge festlegen kann, denn die steht schließlich als Member-Rollen in der Relation. Wenn dieses Problem anderweitig zufriedenstellend gelöst werden kann, wäre selbstverständlich auch ein "flaches" (und damit vielleicht einfacheres) Modell denkbar. --Tordanik 22:21, 10 November 2008 (UTC)

jetzt welchen nur noch ein paar mehr presets - z.B: bus_lane und divider - und man könnte loslegen :)--Cbm 11:47, 12 November 2008 (UTC)

das ist eben ein Themenfeld, wo ich noch Diskussionsbedarf sehe: Was ist eigentlich alles nötig? Dann natürlich noch ein paar grundlegende Fragen: Sind divider lanes oder ein eigener "Datentyp"? Und sollten das alles eigene Tags oder eben nur "Presets" (vorgefertigte Tag-Kombinationen) sein? --Tordanik 15:25, 12 November 2008 (UTC)

Habe mir auch ein paar Gedanken dazu gemacht und einige Punkte verschiedener Ansätze zusammengewürfelt: DE:User:Ömmes/Wayparts. Habe dafür auch ein JOSM-Plugin verlinkt, das allerdings (noch) nicht für die Erfassung der Spuren genutzt werden kann, sondern erstmal die angelegten Spuren entlang der Ways anzeigt. Ein Beispiel ist dort auch zu finden. --Ömmes 21:17, 18 December 2009 (UTC)

vielleicht sollten wir mir diesem Entwurf folgendes Proposal nochmal beleben: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Lane --Cbm 13:06, 2 December 2008 (UTC)

Resultat

 Im Rahmen des Workshops gelang es nicht, eine definitive Empfehlung zum Tagging von Linienbündeln auszuarbeiten. Es bestand am Ende weitgehende Einigkeit unter den Teilnehmern, dass es möglich sein müsse, bei entsprechenden lokalen Gegebenheiten auch nichtparallele Linienverläufe einzuzeichnen.

absolut nachvollziehbar und IMHO auch richtig. Sonderfälle und "abnorme" Konstellationen lassen sich so am Schnellsten und Besten erfassen. --Cbm 07:36, 3 December 2008 (UTC)

 Den meisten Anklang fand ein Konzept, die Linien als eigene Ways zu taggen und mit einer geeigneten Relation an die eigentliche Straße zu binden. Die Linien würden dabei mit beschreibenden Tags analog zu Straßen versehen (access etc.), als Haupt-Tag für die zusätzlichen Ways würde zur Unterscheidung von Straßen jedoch nicht highway=*, sondern etwa lane=*, mit möglicherweise eigenen Values, zum Einsatz kommen.

als Nicht-Teilnehmer ist das gerade sehr unverständlich. Anstatt also einen Weg einzuzeichnen und ihn entweder über ein komplexeres-Taggingsystem oder - mein persönlicher Favorit da hierarschisch - ihn über lane-Relations mehr Inhalt zu geben, soll es also effizienter sein neben einem highWay noch 4,6,8 (und mehr?) LaneWays einzuzeichnen wobei diese nachher eh wieder durch eine Relation miteinander verbunden werden müssen? Hört sich für mich eher nach vielfach mehr Arbeit - sowohl im erstellen und ich darf garnicht ans spätere Pflegen denken - für ein ähnliches - in meinen Augen sogar eher schlechteres - Ergebnis an. Denn nur weil wir plötzlich 8 Linien im 2m Abstand nebeneinander liegen wirds dadurch ja nicht genauer, sondern eher unübersichtlich ;) --Cbm 07:36, 3 December 2008 (UTC)

Ich war zwar auch nicht dabei, sehe das aber genauso wie Cbm. Eine Relation mit den entsprechenden Tags zu machen ist doch einfacher, als einen neuen way + tags + relation... --TEL0000 18:29, 8 December 2008 (UTC)

 Disclaimer: Dies ist kein offizielles Fazit, sondern der Gesamteindruck von User:Tordanik.

ich hoffe dein Eindruck ist falsch ;) --Cbm 07:36, 3 December 2008 (UTC)

Nicht befahrbare oder begehbare Streifen

Hi,

ich weiß, das geht ins Micro-Mapping, aber früher oder später kommen wir dort eh hin, dann können wir auch gleich an noch ein Detail denken: Für blinde Fußgänger-Navigations-Benutzer ist es wichtig zu wissen, ob z.B. zwischen dem Radweg und der Fahrbahn noch ein Grünstreifen ist, und ob der begehbar (Gras) oder nicht begehbar (Gebüsch, Schutzplanke etc.) ist. Ich bitte um Vorschläge, wie man eine solche Spur einzeichnen sollte. Danke!

Lulu-Ann

Eine denkbare Methode wäre, Proposed_features/Divider so anzupassen, dass man es im Kontext von Linienbündeln nutzen kann. Das Proposal dort sah ursprünglich mal vor, Dinge wie divider=grass_strip an eine Straße zu hängen. Das ist natürlich unzureichend, weil man damit nur einen Streifen pro Straße erfassen kann. Wenn wir allerdings im Sinne der Linienbündel diese Tags (z.B. divider=grass_strip) stattdessen an eigene Ways/Relations hängen und diese an geeigneter Stelle in die verbindende Relation einsortieren, sollte es funktionieren. Man kann die "divider" dann auch ohne Probleme mit Zusatzinfos wie einer Breite versehen. --Tordanik 20:25, 24 March 2009 (UTC)

Klingt gut. Wir bräuchten an Zusatzinfos sowas wie

1. Gras, begehbar
2. Gras, nicht begehbar (Die schönen Osterglocken...!)
3. Gras, nicht begehbar (Hund-Kot-Tüten-Spender-Automat steht zurecht in der Nähe)
4. Gebüsch
5. Parkstreifen befestigt / unbefestigt
6. Leitplanke
7. Geländer (z.B. wenn der Fußweg deutlich höher liegt als die Straße)
8. Allee (Gras oder Ähnliches und immer wieder Bäume)
9. ...

Lulu-Ann

Kann man natürlich alles definieren (erfordert im Wesentlichen ja nur passende englische Begriffe, ggf. Zusatztags) -- mach einen Proposal-Entwurf auf, wenn du willst, und verlink ihn z.B. dort. Ein Problem ist, dass die Leute i.d.R. noch nicht mal Spuren als Linienbündel eintragen, so dass die Voraussetzungen im Sinne von Softwareunterstützung und konzeptioneller Akzeptanz bis jetzt nicht grade zum Besten stehen. --Tordanik 13:12, 25 March 2009 (UTC)

Klar, das wird dauern, aber wenn wir nicht rechtzeitig definieren, wie's am besten geht, muß nachher zu viel geändert werden. Ich denk mir was aus sobald meine derzeit laufenden Proposals durch sind. Lulu-Ann