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

steffterra steffterra at me.com
So Jul 25 22:28:23 UTC 2010


Am 25.07.2010 um 23:39 schrieb Frederik Ramm:

> Hallo,
> 
> steffterra wrote:
>> 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.
> 
> Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass es zu frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten im Projekt sind noch lange nicht an dem Punkt, wo sie sich um solche Dinge Sorgen machen. Andrerseits kann es natuerlich nie schaden, mal ein bisschen vorauszudenken.
> 
> Was ich nicht so recht verstehe, ist: Wieso meinst Du, dass eine neue Art von Objekt erforderlich ist? Die Editoren muessen eh angepasst werden, um Dein Konzept zu "verstehen", also koennte man sie auch derart anpassen, dass statt Deiner "neuartigen Way-Gruppierung" eine ganz gewoehnliche Relation eingesetzt werden kann - in einer fuer den Benutzer nicht unterscheidbaren Art und Weise.

Ich glaube zu verstehen, was Du meinst. Die Gruppierung in einer ID wäre wesentlich flexibler als vom User manuell zu setzende Relationen. Ich denke auch, dass Relationen ein guten Mittel für verschiedene Zwecke sein kann. Aber hier Relationen einzusetzen wäre overkill. Zumal auch mehr kb anfallen würden, als wenn jeder way, der zu einer Gruppe gehört die gleiche Gruppen-ID hätte. Es wäre schon deshalb felxibler, weil das im Hintergrund passieren könnte, also ohne dass sich der User darum kümmern muss, ausser die ways zu markieren und dann im Menü "Gruppieren" zu klicken. Dann schaltet JOSM die gemeinsame Hintergrundfarbe für diese Gruppe und es ist auch von der Wahrnehmung her zu einer Straße geworden. Im Hintergrund hat JOSM die ID vergeben und FRenderer können diese nutzen, um die ways entsprechend darzustellen.

> Die Latte fuer "neuen Objekttyp in der zentralen Datenbank einfuehren" haengt wesentlich hoeher als die fuer "neue Art von Relationsnutzung erfinden und Editor-Support dafuer entwickeln". Fuer das erstgenannte musst Du wesentlich mehr Leute davon ueberzeugen, dass das, was Du vorhast, gut ist. Das wiederum fuehrt zu meiner einleitenden Anmerkung zurueck - solange 99% der Leute im Projekt das Problem, das Du loesen moechtest, noch gar nicht selber hatten, werden sie vermutlich mit einem gewissen Unverstaendnis reagieren. Vielleicht ist das in 2-3 Jahren anders.

das Problem mit foreward/backward besteht jetzt bereits. Dort wo kein Bedarf besteht, dass dies eingesetzt würde, muss man ja nicht gruppieren. Das ist ja der Vorteil des Konzepts. Es ist abwärtskompatibel, weil eben nciht alles darauf umgestellt werden muss. Man kann es nur dort einsetzen, wo es das taggen vereinfacht oder Fahrspurtagging sinnvoll wäre.

> Ich sehe auch noch eine gewisse Schwaeche bei der Frage, wie man Ways aufsplittet und verbindet - da muessen ja dann alle Teil-Ways immer mitgesplittet werden, aber wo?

Die Tags müssten natürlich genauso kopiert werden, wie bisher auch, alles die gleichen Regeln. Das Teilen/Splitten selbst kann durch mehrfachmarlkieren aller Nodes auf allen an der Gruppe beteiligten ways geschehen. So viele sind das ja meist nicht. Denn 8-spuriges Autobahntaggen ist ja nicht nötig ;-) Es kann ja auch jeder way einer Gruppe nach wie vor mit lanes=4 getaggt werden. Kein Problem. Das ist ja das schöne an der Felxibilität. Also einfach alle drei ways (beide Fahrrichtungsways und der datenway) mit nodes versehen, an denen man die Straße aufteilen möchte und den Befehl anwenden. Es sollte aber aus Sicherheitsgründen eine Nachfrage kommen, falls man einen node auf einem way nicht mitmarkiert hat. Könnte aber auch noch nachgeholt werden, falls man den way doch nicht abzweigen lassen möchte - z.B. als abzweigende Fahrspur.

> Die Bearbeitung von Kreuzungen stelle ich mir sehr schwierig vor, aber vielleicht ist das nur eine Frage des Benutzerinterfaces.

Kreuzung werden sogar einfacher, das man nur die Schnittstellen mit gemeinsamen Nodes versieht, wo tatsächlich eine Kreuzung vorhanden ist. Abbiegespuren, die z.B. gar nicht kreuzen sidn so noch einfacher umzusetzen. Ansonsten gilt für jeden Richtugnsway/Abbiegespur die ganz normalen Abbiege-Relationen. Es bleiben ja ways mit nodes, auf diese man die Relationen anwenden kann. Absolut abwärtskompatibel.

> Ausserdem muss man natuerlich immer damit rechnen, dass es Software und Benutzer gibt, die das ganze nicht verstehen.

Dazu könnte man eine sehr schöne Anleitung/HOWTO schreiben mit Bildbeispielen, wie ich sie mir auch für das Proposal vorstelle und für absolut nötig halte. In der heutigen Zeit könnte man auch einen Screencast erstellen, der erklärt, wie es funktioniert.

> Wir haben in OSM keine Software-Zertifizierungsstelle, die entscheidet, welche Software auf unsere Daten losgelassen werden darf und welche nicht (und mit Benutzern ist es ebenso). Leute werden den Datenway aufsplitten und die Spur-Ways unveraendert lassen, oder umgekehrt;

Wovor hast Du Angst - Du vergisst die Abwärtskompatibilität, da es alles nodes und ways sind, wie vorher auch. Der datenway ist natürlich etwas besonderes. Das muss der Editor leisten, dass hier eine Warnung kommt wie "Sind sie sicher, dass sie den Daten-way aus der Gruppe der Straße löschen/teilen/trennen möchten? Ähnliches gibt es jetzt schon, wenn der way teil einer Relation ist.

> Leute werden einen Name-Tag an einen Spur-Way anfuegen,

Doppeltagging ist unnötig macht aber keine Fehler. Doch aufgrund der Redundanz und unterschiedlicher Schreibweisen/Tippfehlern könnte der Editor hier eine Warnung ausgeben wie "Dieser Tag wird schon am daten-way genutzt und kann/muss hier nicht gesetzt werden." Falls die Gruppe noch nicht besteht, aber schon alle ways getaggt sein sollten (empfohlen wird der umgekehrte Vorgang) sollte so vorgegangen werden können:

Ways zu einer Straße gruppieren:
- beteiligte ways markieren
- Befehl "Gruppieren" im Menü auswählen
- Auflistung aller Tags aller markierten ways
- Auswahl der Tags, die auf den daten-way kommen müssen (auch hier könnte der Editor standardmäßig den namen-tag und ref etc. vorauswählen.)
- falls Tags doppelt vorkommen, sollte nur einer der gleichlautenden Tags ausgewählt werden können, alle anderen gleichlautenden Tags werden bei der Gruppierung ignoriert. Z.B. wenn auf jedem Richtugnsway der name-Tag angewand wurde.
- nach der Gruppierung sind alle tags dort, wo sie getaggt wurden, nur die tags, die auf den daten-way gekommen sind sind auf den anderen ways gelöscht worden.

> sie werden Kreuzungen zwischen Objekten einbauen, die sich nicht kreuzen sollten,

Das Problem besteht jetzt tauch schon. Man darf nichts verbinden ,was in Wirklichkeit auch keine Verbindung hat. Falls Du Verbindungen zwischen den ways meinst, so sollte das nur am Anfang und am Ende einer Gruppe möglich sein, weil sich dort jeweils zwei Richtungsfahrspuren mit einem einzigen (bisherigen) way verbinden, auf dm kein Richtungsabhängiges Tagging oder Fahrspurtagging nötig ist.
Zusätzlich sollten sich nur solche ways Gruppieren lassen, bzw. deren Gruppierung erhalten bleiben, falls vor dem tagging gruppiert), die richtungsabhängige Tags verwenden.

> undsoweiter. Es ist extrem unwahrscheinlich, dass die API so geaendert wuerde, dass sie solche logisch "ungueltigen" Edits zurueckweist.

Das muss vom Editor wie in den Beispielen geleistet werden, aber auch eine Doku sollte natürlich reichen. Diese Editor-überprüfungsfunktionen sind nur eine Sicherheitsmaßnahmen für Neuuser, wie bei der Teilung von Relationen schon jetzt auch.

> Ich frage mich, ob unter solchen Bedingungen nicht manchmal mehr Redundanz besser ist; dann hat man wenigstens eine Chance, rauszufinden, wenn irgendwas nicht passt.

Mit Redundanz löst Du aber das Problem der fahrtrichtugnsabhängigen keys/tags nicht ;-)

Danke für Deine Gedankenanstöße. Es waren wertvolle Fragen dabei, wie ich finde.

steffterra






Mehr Informationen über die Mailingliste Talk-de