Ortsumriss ist wiederhergestellt (changeset).
Franz
Der Ortsumriss ist vom Kreis zu seiner ursprünglichen, fast rechteckigen Form zurückgekehrt.
Franz
@ FvGordon
Vielen Dank!
Gruß
ARWIE
In diesem Changeset habe ich etliche Ungereimtheiten aus mehreren iD-Changesets revertiert. Den prä-revert-Zustand (.osm.gz) kann man hier herunterladen.
Sind zwar keine verunstalteten Landflächen, aber hier habe ich etliche 1-node-ways gefunden, die mit iD erstellt wurden, an einer Stelle fünf mit der selben Koordinate. Einer der Wege, falls das jemand zwischenzeitlich aufgeräumt haben sollte.
Mit iD 1.3.2 passiert es wohl auch noch gelegentlich: Könnte sich jemand um die Wiederherstellung von Mühlhausen kümmern? Da da in OWL Linien mit rechten Winkel durchlaufen könnte es mehr als nur ein “Entlöschen” erfordern.
Habe den Umriss reverted (Ortsfläche ist wieder da)
Franz
Danke!
Ich hab’ schon den nächsten gefunden: Der nördliche Teil von Heidelberg (Neuenheim/Handschuhsheim). War vermutlich erst vor ein paar Stunden, finde aber den Schuldigen nicht…
Hallo,
da es ein iD-Problem ist, hänge ich es mal an diesen Thread an.
Seit mehreren Wochen beobachte ich, dass Neulinge des Öfteren, beim Eintragen von Adressen (Straße, Hausnummer, PLZ, …) das Feld addr:housename ausfüllen. Das geschieht dann, wenn sie einen POI (z.B. Feuerwehrgerätehaus) eintragen. Sie tragen dann meistens den Namen des POIs, der auch im name-Tag steht, nochmal in addr:housename ein. Das ist eigentlich falsch, da addr:housename für postalische Hausnamen vorgesehen ist. In all den Fällen, die mir bisher untergekommen sind, war das falsch.
Ich habe mir das in ID jetzt mal selber angeschaut. Dort steht im Feld für addr:housename “Hausname”. Das finde ich für Neulinge irreführend. Ich schlage vor, in der deutschen Übersetzung das durch “postalischer Hausname” zu ersetzen. Da das schon recht kompliziert/hoch trabend klingt, werden die meisten Newbies dieses Feld dann wegen mangeldem Verständnis leer lassen, was im deutschsprachigen Raum fast immer richtig ist.
Wo wird denn iD eigentlich übersetzt? Lege ich da am besten einen Bugreport auf Github an oder gibt es da ein Übersetzungstool?
Viele Grüße
Michael
War mir jetzt noch nicht so stark aufgefallen. Ich hätte jetzt gedacht, dass das auch schon mit Potlatch2 so war (zeigt “Building Name” im “Address”-Tab an). Übrigens würde ich tendenziell vorschlagen diesen Thread dabei zu belassen, wie er auch betitelt ist. Ist ja eh schon mehr als genug drin hier. Aber ich bin ja noch nicht so lange hier “dabei”.
Die Wikiseite zu iD hilft weiter (suche dort und auf den Folgeseiten nach “transl”).
In Hanau wurden einige Gebäude ziemlich heftig zerstört. Schuld scheint dieses Changeset zu sein - wie zu erwarten, mit iD. Was tun?
Changeset 19918651 hat aus einem landuse=residential einen Kreis von 7,5km Umfang erzeugt.
“Glücklicherweise” wurden genug Häuser und Wege an das landuse gepappt, dass es einem User recht schnell auffiel und der Fehler behoben wurde.
(unspektakuläre) Screenshots gern auf An-/Nachfrage.
PS: Grad noch einen Gebäudeumriss gefunden und repariert.
Ich hab’ mal wieder sowas: w111832717 (Mannheim-Neckarau). Sollten die entsprechenden Fehler nicht solangsam behoben sein? 
Moin,
Gehirnchirurgisch oder medikamentös?
Bedienfehler lassen sich nunmal nur erschweren (was aber nach Aussage der ID-Entwickler ‘nicht im Sinne von ID sei’) - aber nie beheben.
Gruß
Georg
Hallo,
Ich habe den Änderungssatz Nr. 20246372 im Rahmen von Änderungssatz Nr. 20286376 revertiert. Begründung siehe Änderungssatz-Kommentar.
Schreibst du dem User bitte noch einen freundlichen Nachricht?
Viele Grüße
Michael
Wenn die Bedienphilosophie aber dergestalt ist, dass nicht sicher ist, ob mit diesem Werkzeug mehr Information vernichtet/verhunzt als sinnvoll erzeugt wird, sollte die Frage erlaubt sein, ob das die richtige Philosophie für das Default-Werkzeug ist.
Vielleicht gilt aber auch die Devise: “Einem geschenkten Gaul …”
Vielen Dank, ist erledigt.
Genau das meinte ich: Wir haben hier einen Anfänger-Editor, mit dem man auch als erfahrener Benutzer sehr leicht Dinge kaputt machen kann und der auch nicht anfängertauglich sein will, obwohl er sich an Anfänger richtet.
Als Alternativen gibt es einen veralteten Editor, bei dem man auch teilweise mehr aufpassen muss und Adobe Flash Player braucht, und einen Editor, der etwas mehr Start-Aufwand und eine JRE benötigt, auf den es relativ wenig Hinweise gibt (und natürlich einige weitere weniger verbreitete Editoren). Bei welchem davon die Nachteile am geringsten sind finde ich relativ klar.
Wobei ich mir nicht so sicher bin, daß Anfänger wesentlich weniger kaputtmachen würden, wenn ihnen JOSM als Standardeditor vorgegeben würde. Klar, JOSM warnt bei bestimmten Dummheiten, zeigt vor dem Hochladen eine klare Änderungsübersicht an und hat den eingebauten Validator (sowie etliche weitere Vorteile, die hier den Rahmen sprengen würden). Bloß ob all diese Sicherungen einem Anfänger nutzen würden ist fraglich - es bedarf einer gewissen Erfahrung im Umgang mit den OSM-Daten, um etwa die Warnungen des Validator zu verstehen. Manche Mapper schaffen dies selbst nach mehreren Jahren noch nicht.
Bei der Feststellung, daß mit iD (relativ zu den Bearbeitungen) bestimmte Fehler häufiger gemacht werden, ist ein Auswahleffekt zu beachten. iD-Nutzer sind überwiegend Anfänger, die mit jedem Editor überproportional viele Fehler machen würden. JOSM-Nutzer haben tendentiell mehr Erfahrung, würden also auch mit iD oder anderen Spielzeugen weniger kaputt machen. Insofern liegen die Probleme nur teilweise wirklich beim Editor, teilweise sind sie inhärent in dessen jeweiliger Zielgruppe (und unvermeidlich, wenn wir nicht OSM für neue Mitstreiter schließen wollen). Wer erst nach einer gewissen Zeit mit einem der “Editoren für kleine Hände” zu JOSM kommt, hat schon manches über OSM gelernt und macht dann weniger Fehler als er begangen hätte, wenn er direkt mit JOSM losgelegt hätte.
Ich neige inzwischen dazu, iD im Vergleich zu dem veralteten Flash-basierten Editor als das kleinere Übel zu sehen. iD wird immerhin noch weiter entwickelt (wenngleich ich die Prioritäten der Entwickler häufig nicht teile), P2 wird faktisch seit mindestens zwei Jahren nicht mehr gepflegt (und erzeugt immer noch dieselben Datendefekte wie sie von P1 bereits 2009 bekannt waren, vgl. Ticket 2501). Und der klassische Potlatch-Anfängerfehler unverbundener Wege ist mit iD beinahe ausgestorben. Die hier häufig berichteten Fehler wie große rund und eckig gemachte Flächen sind mit JOSM genauso möglich - der Unterschied ist “nur”, daß iD die unbeabsichtigte Auswahl des falschen Objektes fördert und man in JOSM aufgrund der übersichtlicheren Darstellung eine größere Chance hat, seinen Fehler zu erkennen (oder indirekt vom Validator darauf hingewiesen wird).
Anderes Beispiel zur Illustration, wie schwer sich die Anteile von Editor und Nutzern trennen lassen: bei fehlerhaften Adressen und name-Tags wie “behindertengerechte Toilette” ist auch die Wheelmap ziemlich gut dabei. In dem Fall liegt es wohl auch nicht ausschließlich am Editor, sondern teilweise an den Nutzern, die häufig gar nicht realisieren, daß sie etwas bei OSM (und nicht etwa nur in die Wheelmap) eintragen (was dann wiederum ein Vermittlungsdefizit der Wheelmap ist) oder als Anfänger von den Tagging-Gepflogenheiten bei OSM nicht die leiseste Ahnung haben.
Hallo, wieder ein Fall:
http://www.openstreetmap.org/changeset/20297156#map=16/52.1094/13.7645&layers=N
Ich weiß jetzt nicht, welches Changeset es ist, vermutlich das erste in der Liste:
http://www.openstreetmap.org/changeset/20297059
http://www.openstreetmap.org/changeset/20297107
http://www.openstreetmap.org/changeset/20297141
http://www.openstreetmap.org/changeset/20297146
Sven