Am 29.06.2013 18:10, schrieb Peter Wendorff: > Am 29.06.2013 16:16, schrieb 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. > Das ist mir klar, aber trotzdem ein Problem, was aus deiner Forderung > folgt, denn wie soll ein Editor - erkennen, dass es eine Sammelrelation ist? > Wenn das aber nicht automatisch erkennbar ist, dann wird ja das > Bearbeiten der Relation durch den Editor deiner Vorstellung nach > blockiert, und da Relationen nicht unterstützt werden, kann der > betroffene Nutzer die Relation auch nicht löschen.
Dann muß mensch halt in solchen Fällen über den Graben springen und anfangen zu kommunizieren. * Ein(e) erfahrene(n) lokale(n) Mapper_in persönlich kontaktieren. * Eine Mail an eine Mailingliste schreiben * ein neues Objekt mit fixme=* und note/description=* erstellen * eine neue "Note" erstellen * einen besseren Editor kennen lernen (vielleicht mit persönlich Anleitung (mail)) * Kontakt zu den Entwickler_innen der Software aufnehmen Das Problem sollte somit nicht lange bestehen und beim nächsten Mal kann sich der/die Betroffene vielleicht schon selber helfen bzw sogar anderen helfen und hat selber auf jeden Fall dazugelernt. Kommunikation ist in unser Gemeinschaft ja definitiv begrüßenswert. >> [...] >> >> 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. > Wie denn? > Jetzt verlangst du auch noch, dass Editoren alle Tags interpretieren > können, einschließlich neuer Tags, denn um sowas sinnvoll zu > unterbinden, müsste eine Bedeutungsänderung durch die Änderung von Tags > stattfindet. Wie aber sollte das z.B. bei einem neuen ÖPNV-Schema > passieren? > Insbesondere darf damit nicht verhindert werden, dass eine > Bedeutungänderung da vorgenommen wird, wo sie in der Realität aber > stattgefunden hat. Wenn also eine Kirche zur Disco wird (schon > vorgekommen), dann muss ich das auch entsprechend in OSM anpassen können. > Wenn ich dabei gleichzeitig die Position korrigiere, weil die Kirche > immer schon 10 Meter zu weit westlich stand - dann ist auch das korrekt. > Verrat mir mal, wie eine Software das erkennen und unterscheiden können > soll. Um mal wieder zum Thema zurückzukehren: Bei einer associatedStreet-Relation wären solche Änderungen kein Problem. Beim Verschieben kenne ich so einige passierte Anwenderfehler. Ist mir selbst auch schon mit JOSM passiert, obwohl ich eher vorsichtig unterwegs bin und lieber doppelt checke. Wobei ~50 Meter vielleicht eine ansprechende Grenze für Punkte sind, wenn auch wohl die Punktdichte (Wolke) eine Rolle spielt. Richtlinien/-werte könnte mensch erarbeiten zB: * Keine totalen Sinn Veränderungen: * highway=* sollte highway= bleiben * austauschbare Tags für Gebäude (amenity,shop,craft,leisure?) * grobe Geometrieerhaltung (normale Linie bleibt normale Linie, Area bleibt Area) .... Deutlich weiter ausführbar ! >> 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. > Beim Verschieben über größere Entfernungen gebe ich dir recht, dass das > normalerweise nicht vorkommen sollte, aber ausschließen würd ich's > nicht, und ob das aus versehen passiert, bezweifle ich (wenn die > Software nicht einen Bug hat - lat/lon vertauscht, negiert oder > koordinaten vergessen und auf 0 gesetzt). Ja, solche Fälle bleiben leider immer an der Gemeinschaft hängen, wobei Deine Beispiele leider ein wenig einseitig gewählt sind und zumindest bei Potlatsch2 tickets mit so gravierenden Fehlern leider wesentlich länger brauchen um geschlossen zu werden, als bei JOSM. Leider achten JOSM-Benutzer_innen auch viel zu selten auf den Inhalt der Dialoge beim/vorm Hochladen, aber weder Potlatsch2 noch iD bieten überhaupt eine solche Übersicht + Fehlerhinweis an. >>> 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. > Wenn Du forderst, ein Editor sollte Relationen unterstützen: Ja, das > sollte jeder Editor. Aber wenn das der Punkt ist, dann reden wir hier > nicht darüber, was ein Editor können sollte, sondern darüber, wann > Editoren verboten/geblockt werden sollten. +10 Neuer Thread ? >> [...] >>> 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. > Dann sind wir uns ja quasi einig: Ein Editor, der sich nicht extrem > stark beschränkt (z.B. auf einzelne Tags an bestehenden Objekten) ist > ohne Unterstützung von Relationen unbrauchbar. +10 > Das wollte ich auch nicht bestreiten, sondern deine Forderung, die > versehentliche Bearbeitung/Zerstörung von Relationen zu verhindern als > nicht realisierbar herausstellen, wenn Relationen nicht generell vom > Editor mit unterstützt werden. Ja, außer das erstellen von neuen POIs (nodes) bleibt dann wohl nichts mehr übrig und selbst das führt zu Duplikaten. >> >>>> 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. > Und es muss eine Möglichkeit geben, eine solche Erklärung zu liefern. > Das zu implementieren dürfte wieder schwierig sein. Aber genau so ein Konzept sollte verlangt werden, bevor ein neuer Editor auf die main API losgelassen wird. Gibt es dafür eigentlich irgendwelche Richtlinie/Vereinbarungen und auch wichtig genug geübte Mapper_innen als Tester_in ? Sonst programmiere ich mit meine sehr dürftigen Kenntnissen vielleicht auch einfach mal einen völlig kaputten Editor und fange an Hochzuladen. Einfach "iD" als Editorkennung in den Upload und los gehts. (Scherz) Grüße fly _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
