On 26.06.2013 21:36, Peter Wendorff wrote: > Am 26.06.2013 17:08, schrieb fly: >> Am 26.06.2013 09:07, schrieb Tobias Knerr: >>> Am 26.06.2013 02:05, schrieb fly: >>>> On 26.06.2013 01:42, Tirkon wrote: >>>>> Die große Mehrheit der Mapper wird sie überhaupt nicht kennen. >>>> >>>> Woran das wohl wieder einmal liegt ? Fehlende Relationsunterstützung der >>>> Editor-Software ? >>> >>> Prinzipielle Eigenschaften des Konzepts "Relation", die es schwer >>> machen, einfach nutzbare Bedienoberflächen zum Bearbeiten von Relationen >>> anzubieten. >> >> Ich denke da eher an eine Mehrheit, welche sich häufig gegen Relationen >> ausspricht, anstatt sich Gedanken über diese Oberflächen zu machen. >> Siehe zB auch: >> https://josm.openstreetmap.de/ticket/8336
Als erstes halte ich nichts von verbergen! Somit sollten nicht nur alle Tags ersichtlich sein sondern auch Mitgliedschaften. Wenn keine Relationsunterstützung vorhanden ist, müssen alle Änderungen welche Relationen beeinflussen können, nicht möglich sein. Als nächstes kommen dann wohl Änderungen bei denen es automatisch möglich ist die Relationen zu erhalten/ergänzen. Dazu muß aber schon einiges beachtet (Reihenfolge,Rollen etc) werden und man muß jeden Typ einzeln betrachten und verstanden haben. > Hast Du denn gute Ideen für die Oberfläche? > Vielleicht eine, die sich halbwegs konsistent über Relationentypen > hinweg implementieren ließe? > Multipolygone sind mittlerweile in den großen Editoren als solche > angezeigt normalerweise; für Routen gibt es IMHO Stile, aber schon die > Frage, wie man dann 10 Buslinien auf der gleichen Straße anzeigen soll, > ist nicht mehr einfach zu beantworten - und vom Bearbeiten der > Relationen haben wir dabei noch gar nicht gesprochen. > > Wenn Du aber die "einfach nutzbare Bedienoberfläche zum Bearbeiten von > Relationen" im Allgemeinen meinst, und nicht die zig einfach zu > nutzenden UIs zum Bearbeiten einzelner Relationstypen", dann wird es > eben schon recht schwierig. > > Relationen als generisches Konzept sind relativ abstrakt. Ja: Routen, > Abbiegebeschränkungen und so weiter jeweils einzeln betrachtet sind > konkret, aber das setzt dann eben auch voraus, dass diese Dinge einzeln > implementiert werden müssten: Ein UI-Konzept für Routen, ein UI-Konzept > für Abbiegebeschränkungen, ein UI-Konzept für Multipolygone.... Da werden wir wohl nicht drumherum kommen. Da Relationen untereinander sehr verschieden sind, muss man jede einzeln betrachten. > Ich glaube schon, dass sich Menschen darüber Gedanken gemacht haben, wie > generische Relationenbearbeitung aussehen könnte - aber ob dabei > wirklich gute Ideen rausgekommen sind, ist eine andere Frage. > >> Auch ein bisschen Naivität der Entwickler, wie komplex das System >> generell ist, spielt wohl mit. > Wieso wirfst Du jetzt irgendwelche Entwicklern Naivität vor? > Naiv, weil sie sich nicht rangetraut haben? Irgendwie falsch. > Naiv, weil sie sich das Thema vorgenommen haben, aber daran gescheitert > sind? Wer sagt das? Der JOSM-Relationeneditor ist sehr technisch, nicht > in allen Belangen klasse, aber er funktioniert. Eine einfache Oberfläche > gibt es vielleicht einfach nicht, weil eben keiner eine gute Idee dafür > hatte - und das, alles andere als naiv, vielleicht auch erkannt hat. Ich meinte eigentlich eher, dass da leider oft nicht alles beachtet wird und anstatt dann erst mal Änderungen zu verweigern einfach über die Fehler hinweggegangen wird. >> Und wenigstens anzeigen sollten alle Oberflächen solche Relationen somit >> kann sie auch jeder Mapper kennen. Wie gesagt: ich meinte nicht verbergen sondern Mitgliedschaften wie Tags anzeigen. Eine geeignete Visualisierung in der Datenebene ist eine andere Baustelle. > Und wie? > JOSM, iD und soweit ich weiß auch Potlatch benutzen für die Darstellung > der OSM-Daten mittlerweile Styling-Sprachen, JOSM-Stile kann man ohne > tiefere Programmierkenntnisse auch selbst entwerfen. > Wie würdest Du denn eine Relation darstellen? > Einzelne Stile gibt es übrigens mittlerweile durchaus - zumindest für > Radnetze und deren Routen, Wandernetze und deren Routen sowie Buslinien. > > Für Abbiegebeschränkungen gibt es ein eigenes UI als Plugin: > http://wiki.openstreetmap.org/wiki/DE:JOSM/Plugins/Turnrestrictions, und > ich meine mich zu erinnern, dass ich dazu auch 'nen Stil mal hatte. Generell hat JOSM einiges dazugelernt. Zum Beispiel das automatische setzten von Rollen bei associatedStreet bzw Street. > Alles gleichzeitig anzuzeigen ist aber ganz schön schwierig, und macht > das auch nicht unbedingt besser. Das muss ja auch nicht sein. Da kann man filtern bzw ein-/ausblenden. >>> Kann ich den zweiten Teil so verstehen, dass du associatedStreet wegen >>> eines fehlenden Features (tabellarische Ansicht der aktuellen Auswahl >>> mit sortierbaren Spalten für die Werte) in den Editoren nutzt? >> >> Nein, Ich bin eher ein logisch veranlagter Mensch und habe kein Problem >> mit Relationen. Außerdem bin ich schreib faul und stupides kopieren ist >> fehleranfällig. Mein erster Edit war schon mit JOSM und dann bin ich >> dabei geblieben. > Gegen Schreibfaulheit bietet JOSM ja eine recht gute > Autovervollständigung von Tags ;) Versagt leider bei PLZs und ähnlichen Straßennamen, da ist addr:* genau ein gutes Beispiel. Nein, ich habe im Moment auch kein wirkliches Konzept, habe mir aber auch noch keine Gedanken gemacht. Im Allgemeinen ist unsere Welt halt komplex und das kann man auch nur für einen gewissen Grad vereinfachen. Vielleicht kann man ja auch über eine Integration von "Notes" nachdenken, damit nicht so geübte Mapper im Zweifelsfall eher "Notes" als Punkte setzten und andere dann die Relationen bearbeiten können. Grüße fly _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
