Developmentseed beschäftigt sich in letzter Zeit zunehmend mit OpenStreetMap, liefert u.a. auch die Kacheln für foursquare.com nach deren Wechsel von Google Maps zu OSM. Mit Mapbox entwickeln sie innovative Sachen wie Tilemill oder Tilestream und suchen momentan wohl Kapital (knapp 1 Mio $) für weitere Entwicklungen. U.a arbeiten auch die Mapnik Entwickler Artem Pavlenko und Dane Springmeyer für die in Washington angesiedelte Firma DevelopmendSeed.
Also ich persönlich wünsche mir einen intuitiv zu bedienenden Online-Editor.
Über unterschiedliche Profile “Einsteiger, Fortgeschrittener, Experte” sollten
jeweils nur die Funktionen zur Verfügung stehen, die auch zum Wissensstand passen.
“Kompliziert kann jeder - Einfach ist die Herausforderung”
Man sollte sich auch bei Zeiten von dem Anspruch trennen, daß der Online-Editor “alles” können muß.
Vielleicht ist es besser sich auf z.B. 80% zu beschränken - diese dann aber perfekt zu beherrschen.
Die Kunst ist wohl einen DAU-festen und trotzdem noch leistungsfähigen, d.h. nicht künstlich funktionsbeschränkten, Editor zu schreiben, mit dem sich auf einfache Weise ein notwenigerweise komplexer werdendes Datenmodell flexibel (also u.a. auch erweiterbar) erfassen läßt. Weil besonders unter Windows ist “einfach” in der der Regel gleichbedeutend mit “funktionell bis zur Unkenntlichkeit eingeschränkt”.
Was ich sinnvoll finden würde, wenn man in Navi-Apps eine Funktion integriert, dass der Nutzer unterwegs freiwillig Verbesserungen eintragen kann bzw. Daten auf Aktualität prüfen kann. Bspw. wenn er an einem Supermarkt vorbei kommt: Ist hier ein Aldi? Oder bei building-Polygonen ohne zuortbare Hausnummer: Welche Hausnummer hat das Gebäude?
Ich denke, dass viele Nutzer mit sowas keine Probleme hätten und so recht einfach zur Datenqualität beitragen können. Dadurch, dass man es freiwillig macht, dürften sich auch absichtliche Falschmeldungen in Grenzen halten.
DAS KO-Kriterium für einen Editor ist natürlich, dass er keine systematischen Fehler produziert.
Ich denke darüber das ein “einer für alles Editor” wie JOSM schon einen langen Weg hinter sich hat und man deswegen weiter an diesem feilen sollte statt einen neuen Editor vom Stapel zu lassen. Ggf. mit verschiedenen Skins/Presets je nach Anwendungszweck. Also nicht in Beginner/Expert Mode gedacht. In sofern sehe ich dennoch z.B. die wheelmap als einen spezialisierten Editor außerhalb JOSM durchaus für eine sinnvolle Ergänzung wenn man eben so einen mehr an “input” für OSM generriert der anders nicht entstehen würde, selbst wenn man einen ebenso einfach zu bedienen “wheelmap-mode” in JOSM hätte. Hätte dann nur den Vorteil des offline editierens. Je nachdem wären eben solche auf einen bestimmten Anwendungszweck hin optimierten Tools, ich will nicht direkt von Editor sprechen, durchaus als Ergänzung sinnvoll. Ein zweiter “einer für alles” wie JOSM halte wui eingangs schon geschrieben nicht für sinnvoll da man dann die Arbeit lieber direkt in JOSM stecken sollte um ihn noch “besser” zu machen bzw. eine Anpassung/simplifizierung für Spezialfälle zu ermöglichen. Aber auch im “einer für alles mode” darf er natürlich unkomplizierter werden.
JOSM ist für ProfiS TOP. Aber er ist alles andere als einfach zu bedienen.
Browser-Plugins halte ich prinzipiell für schwierig. Erstmal geht häufig die rechte Maustaste nicht (Abgeschaltet im Browser, da sie zu Werbezwecken missbraucht wurde) und dann gibt es gib verschiedene Browser, somit viel zu viele Probleme.
Ein Editor im Navi klingt natürlich schön, aber wenn ich Auto fahre, kann ich nicht nebenbei noch Mappen.
Die frage ist, ob ein guter und einfacher Android-Editor Sinn machen würde. Ich glaube ja, da hier gute Displays verbaut sind, GPS vorhanden ist und man gleich Online ist. Er muss natürlich mit dem Tuch auskommen, was zum Editieren genau das falsche ist.
Mein Fazit: JOSM als Profi-Editor ist absolut TOP. Aber es fehlt ein “EINFACHER” Editor. Einer mit Setup für Windows (alle anderen OSses können JOSM nutzen, da Linux z.B. eh nur on Profis nutzbar ist, stellt das meiner Meinung nach kein Problem dar) und einer, der so einfach zu benutzten ist daß er Intuitiv bedienbar ist.
Das klingt genau nachdem was Skobbler seit seiner Umstellung auf OSM integriert hat. Ein bug-button auf dem Hauptdisplay mit dem man einfach Verbesserungen und Fehler melden kann.
Das Ergebniss kann man auf mapdust.com sehen. Es sind einige sehr hilfreiche Meldungen dabei, die man ohne Skobbler wohl so nie bekommen haette, andererseits sind die Mehrzahl der Bugs leider nicht sehr hilfreich. Insofern funktioniert das ganze nicht so gut wie ich erhofft haette. Es ist einfach zu schwer waerend der Fahrt Bugs zu melden, insbesondere wenn einem das Navi gerade falsch geleitet hat (sie dazu auch den Thread mit dem Totalschaden), und zum anderen haben zu viele Leute das System nicht wirklich kappiert und wie die Fehlermeldungen verarbeitet werden. Dabei hat Sokbbler das eigentlich sehr gut durchdacht und geloest und im Prinzip ein deutlich (fuer Navis) geeigneteres System erschaffen als OpenStreetBugs. Insofern bin ich skeptisch ob das besser machbar ist.
NavMii Free hat wohl ebenfalls ein Bugreporting System in ihrer Navi-App integriert, aber trotz ihrer Beteuerung das sie “eng mit OpenStreetMap zusammen arbeiten um die gemeldeten Fehler in deren Daten zu verbessern” habe ich noch nie, trotz Nachfrage, etwas von deren Fehler Datenbank gesehen. Deren PR-Leuten ist leider wohl nicht bekannt das man nicht im Verborgenen mit “OpenStreetMap eng zusammen arbeiten” kann, da OSM keine Firma ist.
Dennoch halte ich die Integration von Editoren / Bugreports in die altaechliche Verwendung von “OSM Produkten” als essentiell um die hohe Datenquallitaet zu guarantieren. Nur hat bislang noch keiner ein “funktionsfaehiges” System fuer die Allgemeinheit erschaffen.
Ich kenne Skobbler nicht, aber allein die Ergebnisse auf mapdust.com zeigen, das das System vom ersten Bugmeldesystem zwar stark verbessert wurde, aber noch lange nicht optimal ist.
Während der Fahrt sollte man nur per Button fehlerhafte Stellen markieren können. Die Abarbeitung dieser Bugs wird dann zurückgestellt werden, bis die Navigation gestoppt oder beendet wurde. Dann werden alle markierten Stellen der Reihe nach aufgelistet und man kann sie dann, wenn man möchte der Reihe nach auswählen um weitere Infos hinzuzufügen.
Hat man dann einen solchen Bug gewählt sollte man möglichst viele Infos durch einfaches klicken von fertigen Buttons abfragen z.B. nach der wahl der Fehlerklasse “maxspeed fehlt” bekommt man eine Auswahl von Schildern in dem Geschwindigkeitsbereich vorgesetzt, in dem man dort gefahren ist (und wählt noch das “bis” aus). Da will ich keine längeren Prosatexte auf dem Smartphone schreiben und mir dabei fast die Finger brechen müssen. Bei “oneway” wird dann z.B. die Richtung und von … bis abgefragt, bei Abbiegebeschränkungen kann man wieder ein paar Schilder anzeigen, etc.
Wie man sieht ist das Fehlermeldesystem alles andere als optimal, weil das durchklicken solcher Abfragen bringt beiden Seiten was, wobei natürlich nur ein Bug erstellt wird, wenn der Benutzer da vollständig alle Abfragen durchgeklickt hat.
Ich denke, mit Editoren ist die OSM-Welt gut ausgestattet. Was meines Erachtens fehlt, ist ein einfach zu bedienendes Rendering-System (mit GUI).
Nachdem die Datendichte bei OSM mittlerweile so hoch ist, dass man sich vielerorts durchaus auf die Karten verlassen kann, wird neben Online- und Navi-Karten der Wunsch nach gedruckten Karten laut. Ich habe selbst schon einige für unsere Verbandsgemeinde erstellt und bekomme jetzt häufiger Anfragen, wie ich das denn gemacht habe. Spätenstens, wenn ich davon rede, dass die exportierten OSM-Daten in Maperitive mit Hilfe einer externen Rules-Datei (die man im Idealfall noch selbst umschreibt) gerendert werden, schlagen die Menschen die Hände vorm Kopf zusammen und sind überfordert. Dass die daraus resultierende svg-Datei abschließend noch in Inkscape verfeinert werden muss, was bei größeren Karten sehr schnell die Rechenkapazität üblicher Desktop-Computer sprengt, brauch ich dann gar nicht mehr zu erwähnen.
Ach ja, und dieser beschriebene Weg ist ja schon die einfache Version eines Renderings. Über Mapnik will ich gar nicht reden.
Leider bin ich selbst kein Programmierer. Und so bleibt mir nur der Traum von einem Rendering-Tool, in dem ähnlich wie in JOSM die OSM-Rohdaten geladen werden, man dann in einem Einstellungen-Fenster (vielleicht ebenfalls ähnlich wie in JOSM) den Zeichenstil der einzelnen Elemente anpasst, man die Labels und Straßennamen noch verschieben kann und es möglich ist, durch das Ein- und Ausblenden von Ebenen über die grundsätzliche Darstellung einzelner Elemente zu entscheiden. Und wenn dann noch eine Ausgabe als svg-, pdf und png-Datei in beliebiger Auflösung möglich wäre …
Ich stimme dem Tenor aus den Artikeln eigentlich zu. Potlatch2 ist eigentlich eine schöne Sache, krankt aber an Details (zu viele Objekte werden nicht erkannt, Advanced View ist etwas umständlich, zu viele Bugs was u.A. zu zweifelhaften Ruhm in der Community führt, wenn Daten dabei ausversehend kaputt gemacht werden. Für Einsteiger ist er ideal, mitlerweile empfehle ich aber ausnahmslos JOSM, da es meiner Erfahrung nach ein konsistenteres Konzept verfolgt, was man in 5min erklären kann. Ich würde es aber toll finden, wenn Potlatch da weiterentwickelt werden würde, da er die Mitarbeit natürlich gnadenlos einfach machen kann (Edit what you see). Aber wir haben nicht viele ActionScript Entwickler hier, oder?
Viele, die hier zu Lande noch zu OSM stoßen, fangen damit an, Rad- oder Fußwege zu mappen oder entsprechende Routen. Für die straßenbegleitenden Wege war P1 definitiv ungeeignet, weil man nicht hoch genug zoomen konnte um die Verbindungen zu den anderen Straße richtig hinzubekommen. Ist das in P2 inzwischen besser? Ich denke, daß ein editor, der auch Straßen können soll, das volle Programm können muß. Deswegen empfehle ich auch JOSM schon für Einsteiger. Das aktuelle MS Word finde ich schwieriger.
Spezialisierte Editoren für POIs können natürlich einfacher sein, aber auch die POIs hängen ja häufig an Häuser-Flächen oder sogar -MPs. Es wäre also schön, wenn man diese Komplexität verbergen könnte ohne dabei komplexe Daten zu zerstören oder ständig Dubletten zu generieren.
unabhängig von den Editoren, wäre ein anderes Datenmodell hilfreich. Ich denke manchmal, dass eine strikte Trennung von Flächen, Linien und Punkten gut wäre…so wie halt im GIS Umfeld üblich. Das würden die Übersicht beim Editieren vereinfachen, wenn man bspw nur im Linien-Layer arbeitet und auch manche Streitpunkte (Flächen an Linien kleben) wären damit erledigt. Man kann zwar mit JOSM schön filtern, das kann aber auch gefährlich sein wenn man etwas weggefiltert hat, das an dem gleichen Node/Weg klebt, den man gerade bearbeitet.
Es gibt aber auch Nachteile. Zum Beispiel würde man es nicht merken, wenn man eine Straße über ein falsch eingezeichnetes Haus zieht.
Jedenfalls stört mich eher die Unübersichtlichkeit als die Bedienbarkeit der Editoren. Und ich bin nicht vom Fach, kann nicht programmieren und verwechsele dauernd lat und lon
Ein guter Editor würde daher erstmal fragen, was man editieren möchte und dann nur die relevanten Daten darstellen. Einen Power User Modus kann es ja immernoch geben
@amm: Um einen freien Bug-Report ging es mir nur sehr begrenzt. Eher darum, dass der Nutzer gezielt einen Auftrag/Frage erhält. Neben simplen Fragen wie “Existiert der Aldi noch?” könnte ich mir auch vorstellen: “Mach ein Foto von den Öffnungszeiten des Aldi.”
