Vom Grundsatz ist HOT ja eine tolle Angelegenheit, aber die Qualität der Daten lässt doch häufig sehr zu wünschen übrig.
Ich habe in den letzten Tagen mal wieder ein wenig QS betrieben und weltweit viele Fehler behoben. Ein nicht unerheblicher Teil ist auf HOT-Aktivitäten zurückzuführen.
Windschiefe Gebäude sind eher ein Schönheitsfehler, mehrfach übereinander eingezeichnete Gebäude sind schon ein Ärgernis, aber mehrfach eingezeichnete und unverbundene Straßen sind einfach nur Müll! HOT ist eine große Organisation, wahrscheinlich größer als die OSMF. Auf jeden Fall haben die reichlich Sponsoren. Da sollten die Zuständigen doch mal in der Lage sein, ihren Freiwilligen die grundlegensten Mappingregeln beizubringen. Außerdem könnten die auch mal selbst Qualitätssicherung betreiben und den Müll bereinigen.
Wenn HOT weiterhin so viel Datenmüll produziert, leidet das ganze Projekt.
Ja ärgerlich… aber noch relativ einfach zu korrigieren
… der Relations-Datenmüll von teils erfahrenen Mapper ist schlimmer diese komplexen Monster zu verstehen oder aufzulösen… Gestern über eine Stunde für eine relativ einfache Sache damit verbracht… da waren aber keine HOT-Mapper unterwegs
Unverbundene Straßen aus HOT Aktivitäten sind ein reales Problem, funktionierende Relationen hingegen nicht. Lieber miche101, Du beschreibst eine Privat Initiative, eine Aktivität welche im Rel. Proposal explizit nicht empfohlen wird.
Die Balance zwischen einem barrierefreiem Mapping Zugang, und Schutz vor leichtfertigen Verunstaltungen zu finden.
Ich plädiere zum Einführen eines Sichtungs- System, welches auf KI basiert. Also problematische Edits wie unverbundene Straßen, automatisiert einer Sichtung vor Freigabe unterwirft.
Bitte beim Thema bleiben und die MP-Diskussion nicht in jeden anderen Thread exportieren.
Überkomplexe MPs sind von seiten vieler Mapper aus Wartungsgründen unerwünscht, sie beeinträchtigen aber nicht die Funktion der Daten. Unverbundene Straßen sind kaputt und beeinträchtigen die Nutzbarkeit erheblich. Das ist ja wohl eine andere Baustelle.
nicht destotrotz sind das simple Fehler die leicht zu finden und zu beheben sind…
Und das was ich angesprochen habe… wurden 4 Firmen neu errichtet welche noch nicht eingezeichnet waren… und weitere Gebäude gebaut… das nächste mal lass ich es euch machen, ich schreib euch dann
Aus meiner Sicht machen die HOT Projekte in ihrer jetzigen Form wenig Sinn. Ich kann das allerdings nur anhand der Ergebnisse beurteilen.
Da wird anscheinend irgendein Projekt definiert, dann machen sich diverse unerfahrene Mapper dran, irgendwas zu erfassen und anschließend wird das nächste Projekt angestoßen. Was dabei oft total fehlt ist die Nachhaltigkeit, anscheinend wird nur auf “möglichst schnell, möglichst viel” Wert gelegt. Auf CS-Kommentare erfolgt fast nie eine Reaktion.
Da könnte man auch gleich eine KI die Daten ohne weitere Prüfung erfassen lassen und dann später versuchen, die Fehler zu beseitigen.
Was mich mal interessieren würde: Stellt HOT die Hardware zum Mappen zur Verfügung oder wie läuft das? Ich begegne manchen Tippfehlern
wie z.B. highway=unclassfied (1. i fehlt) immer wieder, aber von verschiedenen HOT Mappern. Wie bekommt man das hin? In JOSM ist es ja normalerweise nicht nötig, das vollständig zu schreiben.
Im Sommer hab ich mich einmal bei HOT beteiligt, als es darum ging für die Bekämpfung Waldbrände in Schweden bessere Karten bereitzustellen. Die polnischen Feuerwehren, die dort Hilfe leisteten, arbeiten wohl stark mit OSM-Material. Die Erfahrung war mittelmäßig.
Das Projekt war schnell aufgesetzt und es haben sich zahlhreiche Mapper zusammengefunden (auch über die schwedische Mailingliste), die das bearbeitet haben. Aber dann kam nichts mehr. Es gab Gerüchte die Feuer in der betroffenen Gegend wären schon gelöscht, die polnischen Feuerwehren wären jetzt in einem anderen Einsatzgebiet, aber niemand vom HOT-Team hat das Projekt beendet oder die Gerüchte kommentiert. Kommentare mit Fragen zum Mapping wurden kaum beantwortet, obwohl dafür extra eine Funktion bereitsteht. An diesem Projekt waren meiner Einschätzung nach hauptsächlich mindestens leichterfahrene Mapper beteiligt. Was da passiert, wenn Neulinge rekrutiert werden, will ich auch besser nicht wissen.
Das kommt, glaube ich, daher, dass manche Editoren typische Schlüsselwerte aus der Umgebung scannen und damit die Felder vorbelegen. Kommt ein hw=unclassfied schon ein, zwei mal vor, wird es in der Liste aufgeführt. Bei iD sollte das aber weniger ein Problem sein, da es ja viel stärker auf Presets setzt. Ich vermute also mal, dass da eher schon erfahrenere Mapper hier die Übeltäter sind, die die falsche Vorbelegung unbemerkt übernehmen.
Hallo, meiner Meinung nach, macht es die Menge an Daten die je nach Aufgabe innerhalb “paar” Minuten erfast werden sollen. Wenn man in einer Aufgabe “Straßen”, Gebäude, erfassen soll, und in der ausgewählten Kachel - die nicht weiter verkleinert werden kann - und je nach Qualität der Luftbilder, man teilweise 'ne 1/4 Stunde davor sitzt in dieser Kachel, was will man machen?
Man bekommt nicht mit, das in der Nachbarkachel es gerade kachelt, nur weil wer ‘n paar Straßen einfügt und nicht in mein “Revier” reinzeichnet, somit ist doch vorprogrammiert, weil man halt in seiner Kachel bleiben soll, das es zu Ungenauigkeiten es kommt (jeder kann bei den Aktiviäten einfach in die Nachbarkacheln hineingreifen ohne das man es merkt - ist mir ein paar mal passiert). Neulingen sollte man ne Möglichkeit geben sich auszutoben, wo soll’n sie sonst anfangen wenn nicht gerade vor unsrer Türe wo mittlerweile ne Menge erfast wurde was sich zum Teil sehen lassen kann.
Bei der Benutzung des ID-Editor können Übertragungsfehler entstehen.
In den jeweiligen genutzen Lufbilder sind Versätze drin, die man zu berücksichtigen hat. Wenn man Drohnenluftbilder zu Verfügung hat ala’ MetropoleRuhrLuftbilder, kann man durch aus einiges mehr erreichen.
Das gesagt wird, das GPX-Routen mit Lufbilder in ihrer Lagegenauigkeit angepast werden sollen, ist auch so eine Sache, weil nicht hinterlegt ist der Bildversatz mit dem wer gearbeiet hat …
In OSM ist schon einiges entstanden (und einige"große" Firmen greifen darauf zu), doch es gibt halt gewisse Baustellen im Hintergrund die mal vor Jahren angefangen wurden und nicht weiter fortgesetzt wurden, weil’s zum Teil in ein Datenmonster unsere Daten am enden sind.
Kleinvieh macht Mist…
Dies meinerseits dazu,
Rüdiger
Nein, Editor ist JOSM und die Mapper hatten nur wenige CS. Bei mir schlägt JOSM nur dann falsche Werte vor, wenn ich sie vorher selbst eingegeben habe. Diese Eingaben werden in den Preferences gespeichert (properties.recent-tags). Meine Vermutung ist, dass hier für neue Mapper die preferences des vorherigen Mappers verwendet werden. Bei plugins macht das auch Sinn, muss ja nicht jeder Laide mühsam die sinnvollen Plugins rausfinden. Bei Eingaben ist es aber eher problematisch.
ich bin kein großer Freund von HOT, da ich oft das Gefühl habe, die Aktivitäten dienen eher zur Profilierung als einem humanitärem Zweck. Allerdings würde ich gerne zwei Infos weitergeben. Ich hatte mich auch gefragt, warum HOT so scharf darauf ist, so viele schiefe Häuser zu mappen. In einem Gespräch sagte mir jemand, dass es oft gar nicht darauf ankommt, dass die Gebäude sauber gemappt werden, da einfach anhand der Anzahl der Gebäude, egal ob schief, doppelt oder sonstwie falsch, die Bevölkerung in einem Gebiet geschätzt werden kann. Fand ich logisch, macht es aber für OSM nicht besser.
Der zweite Punkt ist, dass HOT daran arbeitet, diese Probleme anzugehen. Es gibt im HOT Tasking Manager jetzt Data Validation Tools und das Thema Datenqualität generell ist bei HOT jetzt öfter ein Thema…wobei das vermutlich nicht ganz freiwillig passiert
Insofern hoffe ich auf Besserung. Bei der Wheelmap hat es auch lange gedauert, bis deren Editor keine problematischen/falschen/doppelten Daten in OSM abgeladen hat.
diese komplexen Monster zu verstehen oder aufzulösen… Gestern über eine Stunde für eine relativ einfache Sache damit verbracht… da waren aber keine HOT-Mapper unterwegs 
