Verbesserungsvorschläge für ID Editor

Mag sein, dafür wirft iD auch nahezu 100% aller Fehler in die DB.

Ohne Dir besonders nahe treten zu wollen, aber der Vorschlag ist mindestens albern. Wenn nicht gar trollig. Der grösste Teil der hier von einem Neuling vorgetragenen Probleme steht teilweise seit Jahren in den Issues bei iD (oder hier im Forum oder anderen Diskussionskanälen). Passiert genau nix. Jetzt haben wie eine v2.0.1 mit über 200 issues. Hätte auch gern was von den Drogen.
iD muss m.E. in der Qualität nicht mal mit JOSM gleichziehen, es würde für den Anfang mal reichen, grundlegende Probleme zu beheben. (Beispiele siehe oben … oO)

Noch son schöner Hasspunkt. die Entwicklung findet auf github statt, wo viele Leute/Mapper verzweifeln, weil sie nicht damit klarkommen (ich hab auch sehr lang gebraucht und fühle mich da mittlerweile recht wohl) dann braucht man auch noch noch einen weiteren ACC bei Transifex. Ich kann nur jedem empfehlen: lohnt die Mühe nicht, macht nur schlechte Laune (also äquivalent zu den iD-issues auf github, sondern noch schlimmer). Nicht nur, dass genau wie bei github-issues Verbesserungen nicht im Code ankommen ist transifex noch 20 Ticken unstrukturierter.

Kurzfassung: Nix von dem was man bei Github an Verbesserungen abkippt kommt im Code an und bei tranisfex gar nix.

Das ist egtl. wieder eine ganz andere Geschichte. Das Problem hierbei ist, dass iD gegen den Willen der Community als “Standard”-web-editor durchgedrückt wurde. Potlatch ist klar die selbe Scheisse in grün, aber auf Kritik wurde zu keiner Zeit eingegangen. (Noob-)Webeditoren benötigen QA-Prüfungen, die gibt es aber nicht. Deswegen ist die DB auch voller Müll. Siehe Topic.

Es hat ein Suchfeld, was in den Daten sucht, ob eine “Schranke” im Gebiet ist. Aber eben nicht, wie etwas gemappt wird was unter den “Vorgaben” nicht enthalten ist. Da könnte man auch auf das WIKI verlinken und das diese Werte dann unter “+” eingetragen werden.

Aber ich werde erst auf eine “Startseite” geführt, die mir verschiedenes “Wichtiges” kurz nennt und verlinkt:

“Schlaumeierisch” ist vielleicht nicht immer richtig, aber bei Übersetzungen gilt in besonderem Maße “gut gemeint ist nicht immer gut gemacht”. Es gibt da immer ein paar Leute, die denken, “irgendeine Übersetzung ist besser als gar keine, weil der arme nicht englisch sprechende Mensch ja sonst total auf dem Trockenen sitzt, also schreib ich mal irgendwas hin, was mir halbwegs passend erscheint”, und diese Art von Eifer führt öfters zu Problemen - leider ist der Workflow irgendwie auch so, dass solche bescheuerten, ohne OSM-Kenntnisse gemachten Änderungen oft erst nach Wochen auffallen.

Danke, danke, danke, dass ich nicht der einzige bin, der das für sinnvoll hält.

Da hilft halt nur alle paar Wochen vorbeizuschauen. Mach ich wohl wieder öfters demnächst.
Bei der Übersetzung versuch ich mich am wiki zu orientieren, das hilft am ehesten weiter.

Hat es auch, aber ich meine die Suchfunktion, dass die Presets und Synonyme durchsucht:

und

Ansonsten ist es immer noch so, dass die Fehler mit den meisten Auswirkungen typischerweise immer noch mit JOSM gemacht werden.

Hi, Kreuzschnabel, dein Tutorial ist zu lang, ausführlich, unübersichtlich, aber für den ernsthaften Mapper sicherlich eine Fundgrube.
Ich meine das ganze so: Der Anfänger wird auf die Webseite klicken und dann zu diesem Webeditor kommen, dort ist zwar löblicherweise gleich beim Start ein Tutorial verlinkt, aber das hat mir nicht viel gebracht. Was wird ein Neuling wohl eintragen wollen? Wege, Kreuzungen und evtl. noch Kaufhäuser. Das wars, das wichtigste eben für den Ottonormalverbraucher. Und das sollte ihm OSM auch ermöglichen und zwar so, dass er nicht mehr als 15 Minuten aufwenden muss um mal gerade etwas abzuändern.
Ich beziehe mich hier nur auf www.openstreetmap.org der Hauptseite von OSM, was der Neuling auch als OSM identifiziert. Will er etwas ändern, wird er auf diese Seite gehen und dort auf Bearbeiten klicken.
“Feinheiten abbildet“ beißt sich irnkwan” schon klar, aber der Neuling hat an Feinheiten gar nicht so das Interesse, der will nur mal grobe Strukturen hinzufügen das wars. Evtl, könnte man einfach einen einfachen und einen erweiterten Modus benutzen. Und Relationen bleiben dann eben für den einfachen Modus gesperrt oder die Software schafft es irgendwie sie trotz Veränderung beizubehalten. Und evtl. könnte man gut und detailreich gemappte Bereiche einfach für Neulinge sperren? Die können ja immer noch einen Hinweis hinterlassen, oder evtl. nur eine richtige Bearbeitung, die jedoch nicht öffentlich eingetragen wird, sondern nur als Hinweis/Vorschlag.

@Gerioc der Wert “Alle” im Webeditor meint Jedermann! Ich hab es aber fälschlicherweise für den Ausschluss von den darunterliegenden Einträgen genommen. Ich hab die Wege falsch eingetragen, das sind öffentliche Wege wo jeder spazieren gehen darf. Wenn ich das auf no setze, dann darf da auch niemand mehr spazieren gehen, was totaler Blödsinn ist. Ich habe gedacht wenn ich Motorfahrzeuge auf no setze, dann muss ich “Alle” auch auf no setzen, weil die Motorfahrzeuge ja nicht mehr dabei sind.
Mit mehrere Wege auswählen meine ich: Es ist ein Waldweg, wenn ich auf den klicke, dann leuchtet immer nur ein kleines Stück Waldweg auf, wenn ich dann den Motorfahrzeugbetrieb verbieten möchte, dann muss ich mich durch die Teilstückchen des Waldweges klicken und muss jedes mal das Verbot erneut aussprechen. Das ist unsinnig für den Mapper.
“Er ist ein Anfänger,” Absolut richtig! :smiley:
" wo z.B. “Schranke” eingegeben " Das hab ich erst später entdeckt, ganz oben links ist so ein Feld, ich gebe Schranke ein und er leitet mich auf Schlagbaum um. Über dem Feld müsste „Objekt suchen“ stehen, nicht einfach nur ein Lupenbild.

@Hartmann: „wie bist du zu OSM gekommen“ Zuerst als Google Map Alternative, weil ich freie Programme bevorzuge, dann als Wanderkarte, anschließend als Karte fürs GPS und dann wollte ich auch etwas ausbessern.
„und diesen Weg und dessen Chronik“ Wenn ich auf den Link klicke, was muss ich tun, damit mir der alte Weg angezeigt wird? Weil bei mir kommt nur ein Rahmen um das Gebiet, aber der gelöschte Weg ist nicht zu sehen

@geow: „Kläglich?“ Nicht ganz, aber es hat schon noch Potential auszubauen. (Für mich als frischen Einsteiger)
„Weshalb? Der “Bearbeiten”-Button auf openstreetmap.de führt auch nur zu openstreetmap.org…“ genau, außerdem wird der Surfer direkt die Karte ansteuern, und von dort direkt versuchen zu editieren.
„du änderst den Thread-Titel“ Wurde scheinbar schon für mich erledigt.

@Forum, als ich meinen Post absenden wollte, meint das Forum ich sei nicht angemeldet und nach dem Login waren meine Eingaben weg, zum Glück hab ich die in Libreoffice getippt und nicht im Webfenster.

ps. wenn man kostenlose Arbeitszeit verschenkt dann kostet das. OSM ist darauf angewiesen, dass es geschenkte Arbeitszeit möglichst effizient nutzt.

Hallo geow,

Das war derselbe Übersetzer, der sich schon einmal an dem ungepflegten Feldweg (die Alten erinnern sich bestimmt noch daran ;-)) versucht hat. Ich habe ihm eine PN geschrieben und ihn auf Deine Kritik hingewiesen.

Aber die anderen Übersetzungen anderer Zeichenketten sind auch mehr als komisch:

Im Webinterface von Transifex steht ja neuerdings sogar, in welcher Objektvorlage (und für welches Tag) die Übersetzung Anwendung findet.

Viele Grüße

Michael

In der Tat, das kann auch die Hauptkarte nicht, wenn es sich um etwas gelöschtes handelt. Die Hauptkarte kann nur die letzte Version eines Objektes anzeigen und die letzten Version ist eben das Löschen gewesen.

Hierzu nimmt man sich z.B. das oben schon erwähnte achavi. Das zeigt zumindest in diesem Änderungssatz dann mit rot alles an, was gelöscht wurde.

scheint ja fast so, dass man hier einen übersetzungsbot hat laufen lassen, weil man eventuell nicht wollte, das nicht übersetze Texte (also englisch) nicht erscheinen?! :roll_eyes:

Weil ich hier Kritik an (meinen) Übersetzungen lese:
Bitte beteiligt Euch an der Übersetzungsaufgabe in transifex.
Je mehr Personen dort mitwirken, desto besser wird das Ergebnis.

Ich mache schon seit einiger Zeit transifex-Übersetzungen für iD und mir sind einige Fehler unterlaufen.
Mein auffälligser Fehler war der falsch übersetzten “Feldweg”, da habe ich noch nicht gewusst,
wie bei “Context” unter “Instructions” das zugrundeliegende Key=Value Pärchen angeführt wird.

Ich übersetze normalerweise zeitnahe, weil die Veröffentlichung einer neuen Version des iD-Editors nicht angekündigt wird
und ich möchte, dass möglichst alle Begriffe ins Deutsche übersetzt sind.
Nochmals meine Bitte: Beteiligt Euch an den transifex-Übersetzungen!

Hast Du da eine Quelle dazu?

Ich habe gerade eben ein paar Stichproben gemacht und da sieht es so aus, dass bei Ways die Quote etwa 50/50 ist (was mich überrascht), bei POIs bzw. Nodes allerdings 1/10 (josm/iD) Relationen hab ich nur halbherzig angeschaut, da sieht es so aus, dass Fehler jahrelang mitgeschleppt werden. Um da eindeutige Aussagen zu machen, müsste man teilweise die ganze History reverten um rauszufinden, wer Schuld is. Hinzu käme da, dass Relationen in aller Regel älter als iD sind, also schlecht zu vergleichen.

Du kannst einfach das Forum nehmen und die Beiträge zu den globalen OSM Katastrophen anschauen, die letzte ist nur 2 Wochen her https://www.openstreetmap.org/changeset/43343413 , schon vergessen?

In dem Falle meinst Du “grösste” Auswirkungen, nicht “meiste” (quantitativ). Der Unterschied zwischen beiden ist übrigens zusätzlich der, dass die “Grössten” (meist) schnell bemerkt werden und die “Meisten” mühsam aus QA-Tolls rausgeklaubt werden müssen. Imho ist das qualitativ ein grosser :slight_smile: Unterschied.

Nachtrag: Es ist übrigens auch ein Unterschied, ob man auf die JOSM-fehlermeldungen scheisst, oder ob man in iD überhaupt nichts von Fehlern mitbekommt. (Ja ich weiss, passt schlecht zu Deinem Beispiel, weil das in JOSM auch (noch) nicht angemeckert wurde.

Ein so großes Gebäude aus dem genannten changeset 43343413 wurde auch in der verwendeten version 10966 bereits sogar doppelt angemeckert: “zu großes gebäude” und “zu lange segmente”.

Die “zu großes gebäude” warnung wurde später in die Kategorie “Fehler” hochgestuft.

Manfred, danke für Rückmeldung und die PN. Schön, dass du bei Transifex und OSM zum Projekt beiträgst!

Bei den Lokalisierungen der Editoren wäre es vorteilhaft, möglichst nah an den Definitionen im Wiki bleiben, die ja auch in den Presets von JOSM und iD verlinkt werden. OSM-Tag-Definitionen sind oft nicht allzu “buchstäblich” zu nehmen und zu übersetzen. So ist z.B. highway=path ein Mehrzweck-Weg (vgl. bike path oder multi-use-path) und nicht nur ein Wanderweg. Jetzt aber bitte keine OT-Diskussionen zu duck tagging :wink:

Also vor einer Übersetzung ins Wiki schauen
https://wiki.openstreetmap.org/wiki/Map_Features
https://wiki.openstreetmap.org/wiki/DE:Map_Features

oder eine Suchmaschine fragen: osm + wiki + key

Gruß
geow

PS: Manfred, weißt du wie lange es ungefähr dauert, bis Änderungen in Transifex im iD-Editor ankommen?

Das wag ich auch stark zu bezweifeln.
Hab mich vorzugsweise aufs weltweite Forest-Fixen verlegt, und wenn irgendwo ein längerer outer-Waldrand gelöscht wurde und dann ein Jahr oder gar mehrere über zum Beispiel 200 qkm die ganzen inners invers angezeigt wurden, innen grün und außen weiß, dann steht da eher selten mal JOSM dabei. Viel öfter “iD” oder Potlatch.

Extrem beliebt seit iD-Einführung auch: fake inners in Flächen!
Diese Methode: beim Flächen-Malen führt man den way einfach nahtlos nach innen weiter zu einer Lichtung, fährt um die außenrum, trifft dann wieder auf die eben erzeugte “Nahtlinie” zum outer und fährt auf derselben wieder zurück, und dann wieder weiter ganz außenrum. Bis zur nächsten Lichtung. Oder gern auch mal innerhalb von Lichtung zu Lichtung hopsen, gibt da die verschachtelsten Konstruktionen. Die Nahtlinien erzeugen doppelte Segmente nur auf den Fehlercheck-Tools, aber im Editor und auf osm ist diese Nahtlinie komplett unsichtbar! Dadurch totale Verwirrung, wenn man mit der Maus auf die Aussenlinie clickt und alle inners leuchten plötzlich gleichzeitig mit auf, obwohl überhaupt nirgends mit angebunden - scheinbar. Hab vor einiger Zeit Gegenden gesehen, da ist diese inner-Erzeugung via iD offensichtlich die Standardmethode für Löcher in Flächen, massenhaft. Und jeder Neuling schaut sich die ortsüblichen Methoden natürlich erstmal von bereits vorhandenen Daten ab und macht es dann genauso. Toll, warum auch nicht, die Karten scheinen damit auch keinerlei Probleme zu haben.
War dann zum Schluss gekommen, das muss jetzt wohl wirklich eine neue offizielle Methode sein, und hab schleunigst die Flucht ergriffen. In so Gegenden sieht man mich so schnell nicht wieder, mit so Murks komm ich nicht klar. Falls diese Methode evt. doch nicht so toll sein sollte, müsste ein automatischer Mindest-Check beim Hochladen her, aber der muss sowieso dringendst für alle Edits her.

Die mal wo gelesene Behauptung, dass Checks zur Fehlervermeidung Newbies vertreiben würden, ist sowieso totaler Blödsinn. Wenn ICH von irgendwas keinen blanken Schimmer habe, und bei jedem Click eine Katastrophe befürchten muss, wahrscheinlich auch ruckzuck welche anrichte, DANN lass ich von sowas schleunigst wieder die Finger. Nicht umgekehrt. Würde sehr vermuten, das geht der Mehrheit so, aber zumindest Leuten mit einem Minimum an Qualitätsgewissen.

Und ein ganz neues iD-Problem, erst diesen Monat entdeckt:
Ein Mapper malt KEINE fake-inners, sondern erzeugt tatsächlich mit iD nun Relationen für Lichtungen in Wäldern. An sich sehr löblich. Klitzekleines Problem nur: für JEDE Zusatz-Lichtung wird eine NEUE, zusätzliche Relation erzeugt. Als Resultat gibts für einen Wald mit 5 inners dann 5 Relationen, die alle dasselbe outer und jede genau 1 inner haben. Als ich das kürzlich bemerkt hab und das in der Gegend immer der gleiche iD-Mapper war, hab ich ihn mal angeschrieben zwecks Hinweis. Er hat dann versucht, rauszukriegen wie das passiert und wie er das richtig machen könnte, aber nach ein paar Tagen gemeldet: Keine Chance. Er findet partout nicht raus, wie und was er anders machen muss. Und ich konnt es ihm auch nicht sagen mangels Ahnung. Zwar etwas rumgegoogelt nach iD+MP Anleitung, aber nix gefunden, und selber testen kann ich’s nicht.

Das geht schon seit langem nicht mehr in iD aus versehen (man muss zuerst explizit das Objekt aus der Relation herauslöschen).

Und was ist iD spezifisch an den zwei Fehlern? Nichts? Es sind, nicht sehr klassische, Anfängerfehler die auch locker mit JOSM gehen. Das einzige spezielle an iD in der Hinsicht ist, dass es versucht das die synthetischen Flächenobjekte immer gültige Flächen (sprich Polygone oder MPs) bleiben, dass ist manchmal etwas verwirrend, ist aber nicht “falsch”.

Dein Eintreten für iD in Ehren, aber:

In JOSM lässt sich so was im Zeichenmodus gar nicht zeichnen, weil JOSM einen Way abschließt, sobald er zum ersten Mal auf sich selbst trifft (hier: am Ende der ersten Lichtung). Das heißt: ich biege vom Outer nach innen ab, klicke um die erste Lichtung herum bis an ihren Anfang (hier schließt JOSM den Way ab), fahre mit der Maus wieder dahin, wo ich den outer verlassen habe, und setze diesen fort – aber jetzt fängt JOSM ab dem „Abknickpunkt“ am outer einen neuen Way an. Mache ich zwei Inseln und schließe dann den outer, habe ich drei Ways. Ich muss jetzt also drei Ways mit dem Flächenmerkmal taggen (schon das fällt auf), und die Darstellung dürfte ganz und gar nicht die gewünschte sein (spätestens dann weiß auch der Anfänger, dass es so nicht geht).

Andererseits kann man natürlich in JOSM erst den outer zeichnen und dann die Nodes so schieben, dass sie die Insel ergeben. Aber dann gibt JOSM bei der Prüfung vorm Hochladen die eindeutige Warnung „Linien, die sich selbst überschneiden“ aus.

iD aber zeichnet solche Konstrukte im Flächenmodus ohne jede Widerrede, und in der Editorvorschau sieht das Ergebnis auch „richtig“ aus (Fläche mit Insel) – ich hab’s nicht hochgeladen.

Da müsste tatsächlich eine Erkennung mit Warnhinweis für solche Fälle rein (z.B. dann getriggert, wenn ein Way zwei benachbarte Punkte an unterschiedlichen Positionen enthält).

–ks

Das Objekt, dass man mit dem Flächentool so kreiert ist aber nicht direkt falsch nach OSM Datenmodel, habe aber mal trotzdem ein Issue erstellt https://github.com/openstreetmap/iD/issues/3610

So lange ich darauf achte keine Knoten miteinander oder wieder mit dem Weg zu verbinden geht das übrigens auch locker mit JOSM in einem Zug, ganz ohne Warnung (auch wenn das Polygon sich selber überlappt, also optisch “richtig” aussieht).

Mit jedem Editor kann man Mist machen, da sind wir uns wohl einig. Und wenn mit iD besonders viel Mist anfallen sollte (was ich jetzt nicht nachprüfe), dann liegt das natürlich nicht nur an diesem Editor an sich, sondern auch daran, dass davor überproportional viele unerfahrene Anwender sitzen – an der unterschiedlichen Userprofilen scheitert da die Vergleichbarkeit.

Aber gerade deshalb wäre es schön, wenn iD eher nur Grundfunktionalität böte, aber dafür narrensicher wäre und bei Geometriefehlern dieser Art konsequent warnte. Beispielsweise könnte er bei solchen Fake-Inseln eine Mitteilung ausgeben, dass so was bei OSM anders gemacht wird und der User bitte Außen- und Innenumrisse als separate Polygone anlegen möge. Daraus kann iD intern ein MP erzeugen, von dem der User gar nichts erfahren muss. JOSM macht das automatisch, wenn ich alle Polygone selektiere und Strg-B drücke: ein MP wird erzeugt, outer und inner vergeben, und evtl. Tags vom outer werden an die Relation umgehängt. Code dafür gibt’s also.

Alternative: Nur vorgebildete Leute dürfen überhaupt mitmappen. Aber das bekommst du in so einem Projekt heute wirklich nicht mehr durch.

–ks