Weil OSM ein freies Projekt ist, was sicherlich in einigen Punkten etwas zu viel Freiheit erlaubt, aber andererseits ohne diese Freiheiten nie zu dieser Größe gelangt wäre, an der es momentan ist.
Ohne diese Freiheiten würden auch nicht drei oder vier verschiedene Tagging-Schemas für ein und dieselbe Sache existieren…
Das bezweifle ich… Mit StreetComplete gibt es viele Nutzer, die schon einmal etwas von OSM gehört haben und eine grobe Vorstellung des Projektes haben, aber vlt. nicht genug Zeit um sich in einen (für Anfänger durchaus komplizierten) Editor einzuarbeiten. Die bequemere Alternative ist dann ein Editor/eine App wie StreetComplete.
Wie gesagt… OSM ist ein freies Projekt, jeder darf im Grunde genommen das tun was er will. Ob das nun gut oder schlecht ist hängt wohl von jedem Fall selber ab.
Nein, so jemanden gibt es nicht. Die Schnittstellen liegen offen, falls ich die nächsten paar Wochenenden nichts besseres zu tun hätte, könnte ich einen Editor schreiben. Der hätte furchbare Fehler und wäre für alles was ich damit anfasse vernichtend, aber die API würde ihn akzeptieren.
Wenn schon OSM die Edits externer Tools nicht einschränken kann, sollten sie neue User auf ein Tutorial hingweisen, oder einen Link zur betreffenden Wikiseite anzeigen.
In StreetComplete habe ich kein Tutorial oder Hinweis zu OSM bei der ersten Installation angezeigt bekommen.
Wer sieht sich schon die Datenschutzerklärung einer App an, wo dann in 2 Sätzen was über OSM steht?
In gewisser weiße muss man als Ersteller einer solchen App, gegenüber neuen Mappern doch eine gewisse Aufklärung betreiben, da ich finde, dass so der eine oder andere wertvolle Mapper für die Comunity gewonnen werden könnte, was wichtiger ist als massig neue Mapper die nach einem halben Jahr keine Lust mehr haben.
Eine Mögichkeit wäre es z.B. neue Registrierungen standardmäßig zu sperren solange sie nicht eine Infoseite auf OSM durchgelesen haben und erst dann dürften sie editieren. Eine Account-bestätigen-Email erfüllt wohl nicht den Effekt. Egal ob sie sich über Handy oder PC registrieren und worüber sie editieren wollen.
Das würde die neuen Mapper etwas sensibilisieren.
Es ist ein Unterschied ob ich Nonsens auf Facebook hochlade oder ob ich Nonsens auf OSM hochlade…
PS:
Ergänzu zu meinem vorherigen Post:
StreetComplete erfasst bei “Nein” den Weg mit foot=no und sidewalk=no
das ist dann eine doppelte Verneinung
Da gibt es noch einige mehr, die die Daten nicht so wirklich bereichern, sondern eher dazu dienen, daß Editoren wie Streetcomplete dem nächsten Benutzer diese Abfrage nicht mehr anbieten. Noname=yes an Wegen ist auch sowas oder lit=no an Waldwegen (war iD, wenn ich mich recht entsinne).
Ich würde mir halt wünschen, daß solche Äpps mehr auf das Ergänzen dessen, was ist, fokussieren als auf Eigenschaften, die nicht da sind und das ganz offenkundig. Sprich: die Mitarbeit der Äppnutzer auf Dinge mit Nutzwert lenken, statt auf Fehlen von Eigenschaften, die sowieso fast immer an solchen Objekten nicht vorhanden sind. Surface=* an highways z.B. ist eine gute Sache, da kann im Vorbeigehen eine Menge sinnvoll ergänzt werden.
Aber auch Fehlermeldungen à la “als Antwort auf: was sind die Öffnungszeiten von …? - Stehen nicht dran” bräuchte man doch gar nicht abladen.
Sidewalk=no finde ich eine hilfreiche Information, da man ohne dieser keine sinnvolle Aussage darüber machen kann und es mehr oder weniger gleich wahrscheinlich ist, dass es einen geben kann oder nicht. Bei foot=yes auf Straßen sehe ich das nicht so, da das implizit fast immer so ist. Die paar Ausnahmen, wo das nicht so ist, wie Privatstraßen, rechtfertigen mMn. nicht es überall anders explizit zu setzen - nur wo genau die Grenze ist, bei welchen Werten es noch sinnvoll ist, sieht wohl auch jeder subjektiv ein wenig anders.
Nein. Das ist ein Zusatzzeichen und hat für sich allein keine Aussage, sondern bedeutet nur, dass das dazugehörige Hauptzeichen sich auf Fußgänger bezieht.
Von allen, die an dem Projekt teilnehmen und sich die Idee hinter der Änderung und die Änderung selbst anschauen.
Wieso bist du der Meinung, dass StreetComplete das tun sollte? Diese Guidelines sind nicht nur zum Spaß da…
Mir ist keine Aufgabe bekannt, die wirklich massiver Spam ist, wie in dem genannten Beispiel.
naja, also wenn die überwiegende Mehrheit aller Spielplätze öffentlich zugänglich sind, braucht man doch bei Spielplätzen nicht zu fragen, ob sie öffentlich zugänglich sind?!
Und ich glaube schon, dass man das aus den letzten Beiträgen dazu rauslesen konnte: erstens, dass access=yes nicht wirklich richtig ist, und zweitens, dass man darauf verzichten könnte.
Würde ich auch so sehen … Einige der SC Ergänzungen die an mir vorbeikommen empfinde ich aus der Kategorie “kann man machen … Muss man aber nicht … “
Spam hatte ich bisher eher mit SC generierten OSM Notes (z. B. in Viersen).
Ohne jetzt für oder gegen access=yes zu sprechen, wollte ich nur anmerken, dass es doch eine ganze Reihe an Spielplätzen gibt die oft ohne access erstellt werden, aber definitiv ein access tag bräuchten. Oft in “gated” Innenhöfen, Schulen oder Kindergärten. Generell eher Spielplätze die sich innerhalb einer amenity/Anlage befinden.
Nach einem kurzen Check in Berlin in meiner unmittelbaren Nähe nach Spielplätzen ohne access konnte ich feststellen, dass die Mehrzahl sicherlich öffentlich zugängliche Anlagen darstellt, aber ich konnte auch ziemlich fix einige Beispiele für fehlendes Tagging finden.
Finde die Quest in der Hinsicht also gar nicht so verkehrt.
Dazu kann man doch einen etwas detailierteren Overpass Code schreiben, der nur Spielplatze in einer Umgebung von 10-20 Meter auswirft oder sich direkt in der Fläche von Kindergarte/Schulen usw. befinden.
Dann würden schon mal die Spielplätze wegfallen die am Dorfrand oder in einem öffentlichen Park liegen.
Natürlich können dann einige durchrutschen die in einer Siedlung in einem privaten Bereich sind.
StreetComplete will wohl alles mit access zupflastern.
,_StVO_2017.svg){kind=link}