[Talk-de] das Problem mit backward-forward und left-right - neues Datenmodell nötig!?

[Tobias Knerr]

Am 20.07.2010 21:18, schrieb steffterra:
> Ich möchte mal ganz wertfrei und ohne Vorbehalte darüber schreiben, was hier zu beobachten ist:
> Das "Problem der drehenden Wege" bei Verwendung von backward-forward und left-right für die unterschiedlichsten Zwecke muss irgendwie grundlegend angepackt werden.

Du schreibst im Folgenden über das Linienbündel-Problem, nicht wirklich
über richtungsabhängige Tags.

Es stimmt zwar, dass das Linienbündel-Problem auch einige
richtungsabhängige Informationen abdeckt, aber Dinge wie Steigungen oder
die Richtung eines Flusses sind davon völlig unabhängige Infos.

Freut mich also, wenn du dich der Linienbündel annehmen willst, aber das
Thema bitte gedanklich ein wenig von richtungsabhängigen Informationen
trennen - damit hat es nur am Rand zu tun.

> Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von "Linienbündeln" und "Fahrspurtagging" gelesen.
> 
> Doch welche Konzepte gibt es bisher? 

http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group

http://wiki.openstreetmap.org/wiki/User:%C3%96mmes/Wayparts

http://wiki.openstreetmap.org/wiki/Users:cmuelle8/multiple_way_tagging_on_single_geometry

http://wiki.openstreetmap.org/index.php/WikiProject_Germany/Workshops/Linienbündel

Gibt noch mehr in verschiedenen Diskussionen etc., aber die gängigen
Ideen dürften damit abgedeckt sein...

> Wie weit sind wir dahin?

Es gibt mehrere Konzepte, die theoretisch alle denkbaren Situationen
entlang eines Wegs beschreiben könnten. Das ist auch der "leichte" Teil.

Auf einige Details, wie etwa die Darstellung von Kreuzungen, gehen die
Konzepte meist nicht ein. Das ist m.E. der gängigste konzeptionelle Mangel.

Bei den o.g. Konzepten gibt es außerdem keine fertige
Editor-Unterstützung, keine Rendering- oder Routing-Unterstützung, und
keine nennenswerte Verbreitung. Das sind die praktischen Mängel.

> Steckt OSM da derzeit fest? Warum gehts nicht weiter?

Weil es viel Arbeit ist, so etwas komplett durchzuziehen. Bisher hat
noch jeder nach dem Abliefern der ersten Ideen und halbfertiger Konzepte
keine Lust mehr gehabt.

Ich übrigens damals auch. ;)


So, jetzt aber zu deinem Vorschlag:

> a) Einzeichnen zusätzlicher paralleler ways, die _nicht_ extra durch eine Relation oder einen Tag als zum gleichen way =ohne bauliche Trennung, gehörig verbunden werden müssen. Das sollte durch eine neue Datenart ermöglicht werden.

Wenn ich so die Eigenschaften deiner Ways durchlese, dann sind das durch
eine Relation verbundene Ways.

Ja, ich weiß: Du willst, dass man sie nicht manuell in eine Relation
zusammenfassen muss, der Editor sie automatisch parallel ausrichtet, auf
höheren Zoomstufen ausblendet etc. Aber das kann der Editor prinzipiell
alles auch mit Ways in einer Relation machen; muss man ihm nur
beibringen - das ist nicht schwerer, als die entsprechenden Funktionen
für einen neuen Datentyp zu bauen, und ließe sich später leicht anpassen.

Vorteil: Um ein Editor-Plugin (und/oder ein Beispiel-Rendering) zu
schreiben, das dein Konzept intern mit Relationen nachbaut, musst du
niemanden überzeugen. Das kannst du ohne die Zustimmung einer zentralen
Autorität veröffentlichen. Das beweist dann, dass deine Idee in der
Praxis funktionieren kann, und die Leute werden dein Konzept mit eigenen
Händen ausprobieren.

Nachteil: Du hast vermutlich mehr oder weniger darauf spekuliert, dass
eine API-Änderung dazu führen würde, dass sich "jemand anderes" um die
eigentliche Arbeit, nämlich die Editoren und Renderer, kümmert - und du
nur die Ideen liefern musst.
So hätte ich jedenfalls gedacht. *g*

> e) was tun bei drei Fahrspuren? Der datenway wird zwischen beide Fahrtrichtungen gelegt und ist dann insgesamt gesehen der vierte way.

Es gibt keine klare Grenze zwischen zwei Fahrtrichtungen - zumindest,
wenn wir nicht nur über Autos reden. Beispielsweise kann ein Radweg
sowohl nur für eine als auch für beide Richtungen zugelassen sein; er
wird sich dennoch ganz klar entweder links oder rechts deines Datenways
befinden.

Allerdings scheinst du bis jetzt ja wirklich primär an Autofahrspuren
gedacht zu haben:

> 8. Fahrbahnbegleitende Radwege, etc. werden nach wie vor am highway getaggt, nun jedoch auf der jeweiligen Fahrspur für die jeweilige Richtung. 
>
> 9. Parkstände entlang von Fahrspuren: Auch parking:lane ist nun klar,
> und muss nicht mehr mit right/ left getaggt werden, sondern einfach
> auf der Fahrspur, die es betrifft.

Einer der Vorzüge eines Linienbündels ist doch, dass man Radwege,
Parkstreifen und Gehwege als eigene Spur darstellen kann!

Sonst hast du viele der der Probleme, für die sich die Einführung von
Linienbündeln lohnen würde, gar nicht gelöst:
* ist der Radweg jetzt innerhalb oder außerhalb des Parkstreifens?
* wie kann ich bewährte Tags wie surface oder width direkt für einen der
Radwege setzen?

> -> "jemand" müsste das in die DB einbauen und auch stufenweise in die populären Editoren.

Wie schon mal angedeutet: Das Fehlen dieses "jemand" ist das eigentliche
Problem.

Da eine DB-Änderung an sich nicht zwingend ist, gibt es eigentlich keine
Ausrede, nicht schon mal mit den Editoren anzufangen. ;)

Tobias Knerr