[Talk-de] Wie Adressen richtig richtig mappen?

[fly]

Am 29.06.2013 11:32, schrieb Peter Wendorff:
> Am 29.06.2013 02:40, schrieb fly:
>> Wenn keine Relationsunterstützung vorhanden ist, müssen alle Änderungen
>> welche Relationen beeinflussen können, nicht möglich sein.
> Dann kommt der RelationMapper vorbei und meint, eine Relation "Hessen"
> anlegen zu müssen, die alle Elemente Hessens enthält. Ja, das ist nicht
> gewollt, ja, das wird hoffentlich schnellstens von anderen korrigiert,
> aber darum geht es hier ja gerade: Bis es jemand korrigiert - und machen
> wir uns nichts vor, im zweifelsfall dauert das schon ein paar Stunden -
> wäre in einem solchen Fall kein Bearbeiten mehr möglich durch Editoren,
> die keine Relationsunterstützung haben, denn wenn ich einen Node
> bearbeite, kann ich aus einer Adresse eine Straßenlaterne machen und die
> auch noch ans andere Ende der Stadt schieben - auf einmal ist eine
> Straßenlaterne in 'ner associated_Street-Relation - Relation kaputt.

Jetzt wirfst Du aber einiges zusammen !

Solche Sammel-Relation werden leider immer noch zu sehr geduldet,
gehören aber gelöscht. Dafür gibt es wahrlich andere Methoden. JOSM kann
zB mit externen Listen umgehen

Leider werden sehr selten existierende Objekte wiederverwendet und die
Editoren sind auch oft nicht hilfreich, allerdings eine Adresse in eine
Straßenlaterne zu verwandelt ist wohl nicht empfehlendswert und sollte
von einfachen Editoren verhindert werden. Auch das Verschieben über
große Entfernungen ist problematisch und sollte mit einfachen Editoren
nicht möglich sein oder kennen die sowas wie "incomplete". In meiner
Mapperkarriere musste ich bisher nur drei Mal so einen Edit
bewerkstelligen, weiß allerdings nicht wie ich das mit iD oder Potlatch2
machen kann ohne eine halbe Großstadt runterzuladen.

> Einen Weg aufsplitten: unmöglich für viele Wege, über die Buslinien
> etc. verlaufen.

Genau das sollte der Editor aber automatisch können oder es ganz bleiben
lassen, wobei splitten noch einfach ist.
Wie sieht das denn beim "unglue" von iD und Potlatch2 aus ? Wird da
drauf hingewiesen, dass mensch gerade Relationen zerpfückt ?

> Zwei Wege mergen: genauso unmöglich, gleiche Begründung.

Das selbe wie splitten, aber häufig eh nicht möglich.

> Wenn deine Forderung also eingehalten würden, wären Editoren ohne
> Relationsunterstützung streng genommen nicht nutzbar.

Ja, schon ein POI-Editor sollte mit Multipolygonen umgehen können und
diese zumindest sichtbar machen. s.u.

>> [...]
>>> Hast Du denn gute Ideen für die Oberfläche?
>>> Vielleicht eine, die sich halbwegs konsistent über Relationentypen
>>> hinweg implementieren ließe? [...]
>>
>> Da werden wir wohl nicht drumherum kommen. Da Relationen untereinander
>> sehr verschieden sind, muss man jede einzeln betrachten.
>>
>>> [...]
>>>> 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.
> Die strenge Haltung dazu:
> "Jede Änderung an Objekten, die Teil von Relationen sind, ist zu
> verweigern."
> Wie oben bereits begründet funktioniert das nicht, weil es Editoren
> unbrauchbar machen würde.

Sorry, aber dann sind die Editoren unbrauchbar und für mich nicht
akzeptabel. Entweder der Editor verhindert das Verändern oder kann
automatisch mit Relationen um gehen oder gibt Warnungen heraus und
ermöglicht das manuelle Editieren der Relationen.

Die/Der Benutzer_in kann sich dann immer noch entscheiden welchen sie/er
verwenden will bzw ob mensch sich die Änderung der Relation zutraut.

Deshalb meinte ich auch, dass manche Entwickler_innen in dieser Sache
sehr naiv waren/sind. Relationen sind ein Objekttyp und ohne alle Typen
zu unterstützen wird es schwierig. Das sieht mensch auch gut and den
POI-Editoren. Ohne geschlossene Linien zu unterstützen wird es schwierig
und eigentlich müssten auch Multipolygon beachtet werden.

> Wenn die aber nicht gemeint ist: Was sollte dann erlaubt sein und was nicht?
> 
>>> [...]
>>> 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.
> Doch, das muss sein, wenn Du willst, dass man Relationen nicht
> kaputtmachen kann.
> Das muss nicht immer sein - insofern hast Du recht, aber wenn Relationen
> sichtbar sein sollten, müssten sie per default erstmal alle erkennbar
> sein, insofern auch alle eingeblendet werden, und auch dann muss es noch
> halbwegs sinnvoll sein, was man als Nutzer vor sich sieht.

Man kann sie ja erst mal wie alle Tags anzeigen und nur bei Problemen
visualisieren.

Mir wäre es lieber, wenn mensch sich erklären lässt warum die Änderungen
nicht akzeptiert werden und wie man mit Relationen umgeht, anstatt
einfach darüberwegzugehen, allerdings muss mensch dann erst einmal auf
Problem hingewiesen werden und ihr/ihm nicht ein fundamentales Element
der Materie vorenthalten werden.

cu
fly