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 _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de