StreetComplete - die nächste suboptimale App

ENT8R · 2019-02-11 17:14:15

geri-oc wrote:

und dabei seine Schlüssel versucht durchzusetzen -> siehe maxspeed:source und maxspeed:type (oder wie auch immer)

Ich dachte das Thema wäre jetzt so langsam mal abgeschlossen ... Ganz ehrlich: was hat das jetzt mit dem Thema davor zu tun? Musst du das bei jeder Gelegenheit wieder hervorholen? Es gibt nunmal leider keine vernünftige/gut dokumentierte/ausführliche Lösung um implizite Geschwindigkeiten zu taggen, und für irgendein Taggingschema muss sich StreetComplete nun mal entscheiden. Und das Schema für das sich entschieden wurde ist dann immer für jemand anderes falsch, weil er selber es ja am liebsten mit einem anderen Schema taggt...

ENT8R · 2019-02-11 17:20:16

geri-oc wrote:

Es ist aber falsch an Spielplätzen ALLES (access=yes) zu erlauben. Wenn schon, dann bitte richtig: parents, childrens, age, ...

Das sind alles Informationen, die dann gerne in nächsten Schritten noch hinzugefügt werden können. Und falsch ist es ganz sicher nicht, access=yes ist dann auch nur wieder ein weiterer grober Wert, der immer noch weiter verfeinert werden kann, Wie weit der Wert genau verfeinert wird, liegt letztendlich aber bei jedem Mapper selber...

SunCobalt · 2019-02-11 17:24:23

ENT8R wrote:

geri-oc wrote:
Es ist aber falsch an Spielplätzen ALLES (access=yes) zu erlauben. Wenn schon, dann bitte richtig: parents, childrens, age, ...
Das sind alles Informationen, die dann gerne in nächsten Schritten noch hinzugefügt werden können. Und falsch ist es ganz sicher nicht, access=yes ist dann auch nur wieder ein weiterer grober Wert, der immer noch weiter verfeinert werden kann, Wie weit der Wert genau verfeinert wird, liegt letztendlich aber bei jedem Mapper selber...

Spielplätze, die auch von LKW befahren werden können, sind mir bisher noch nicht begegnet. Insofern halte ich es schon für grob falsch, einem Spielplatz, der potentiell auch an eine Straße angrenzen kann, mit access=yes, was von einem Schneemobil über Pferd bis hin zum Bus und LKW alles erlaubt, zu taggen

Last edited by SunCobalt (2019-02-11 17:25:37)

Harald Hartmann · 2019-02-11 17:30:07

ENT8R wrote:

...und für irgendein Taggingschema muss sich StreetComplete nun mal entscheiden...

Ach so wird das jetzt also verargumentiert, dass ich eine App mittlerweile entscheiden muss ... wie wäre es einfach mal mit weglassen, oder eben vorher soweit durch alle Kanäle/Instanzen durchdiskutieren bis ein/das Taggingschema von der Mehrheit akzeptiert wurde?
Und deshalb gebe ich geri-oc Recht, wenn er sagt, dass StreetComplete hier etwas durchsetzt ... und nein, dass ich kein reines Bashing gegen StreetComplete, diesem Vorwurf müssen sich auch andere Apps (wie z.B. iD) gefallen lassen ... aber StreetComplete hätte es halt besser machen können

ENT8R · 2019-02-11 17:33:38

SunCobalt wrote:

Spielplätze, die auch von LKW befahren werden können, sind mir bisher noch nicht begegnet. Insofern halte ich es schon für grob falsch, einem Spielplatz, der potentiell auch an eine Straße angrenzen kann, mit access=yes, was von einem Schneemobil über Pferd bis hin zum Bus und LKW alles erlaubt, zu taggen

Wenn dir solche Spielplätze bisher noch nicht begegnet sind, dann kannst du bestimmt davon ausgehen, dass auch Nutzer der Daten diese Erfahrungen in ihre Produkte einfliessen lassen werden

Außerdem dient der Wert von access=* in diesem konkreten Fall doch nicht als Zufahrtsbeschränkung für Fahrzeuge (Flächen mit Attributen wie leisure=playground werden soweit ich weiß nicht als Straße behandelt, dafür müsste dann noch ein highway=* an die Fläche dran...) sondern vielmehr als eine Art Zugangsbeschränkung für Personen, die diesen Spielplatz benutzen möchten. Insofern kann bei Spielplätzen eigentlich nur der Wert access=yes/private/customers verwendet werden...

chris66 · 2019-02-11 17:39:08

Also bei uns sind viele Spielplätze altersbeschränkt. access=yes (JEDER darf drauf) wäre da schlichtweg falsch.

SunCobalt · 2019-02-11 17:43:20

ENT8R wrote:

SunCobalt wrote:
Spielplätze, die auch von LKW befahren werden können, sind mir bisher noch nicht begegnet. Insofern halte ich es schon für grob falsch, einem Spielplatz, der potentiell auch an eine Straße angrenzen kann, mit access=yes, was von einem Schneemobil über Pferd bis hin zum Bus und LKW alles erlaubt, zu taggen
Wenn dir solche Spielplätze bisher noch nicht begegnet sind, dann kannst du bestimmt davon ausgehen, dass auch Nutzer der Daten diese Erfahrungen in ihre Produkte einfliessen lassen werden
Außerdem dient der Wert von access=* in diesem konkreten Fall doch nicht als Zufahrtsbeschränkung für Fahrzeuge (Flächen mit Attributen wie leisure=playground werden soweit ich weiß nicht als Straße behandelt, dafür müsste dann noch ein highway=* an die Fläche dran...) sondern vielmehr als eine Art Zugangsbeschränkung für Personen, die diesen Spielplatz benutzen möchten. Insofern kann bei Spielplätzen eigentlich nur der Wert access=yes/private/customers verwendet werden...

Damit überlädst Du den Tag und machst ihn kontextabhängig..... Ist das irgendwo besprochen worden oder entscheidest du das?

ENT8R · 2019-02-11 17:52:11

Harald Hartmann wrote:

Ach so wird das jetzt also verargumentiert, dass sich eine App mittlerweile entscheiden muss ... wie wäre es einfach mal mit weglassen, oder eben vorher soweit durch alle Kanäle/Instanzen durchdiskutieren bis ein/das Taggingschema von der Mehrheit akzeptiert wurde?

Seit einigen Versionen ist genau diese Frage auch schon standardmäßig deaktiviert dennoch aus einem anderen Grund...

Das mit dem Diskutieren wurde doch auch schon mal versucht: https://forum.openstreetmap.org/viewtopic.php?id=60027
Das Problem ist nur, dass es immer irgendjemanden geben wird, der mit der Lösung nicht 100%-ig zufrieden ist.

Momentan sind es vor allem die Mapper aus Deutschland, weil maxspeed:type=* verwendet wird, was in DE so gut wie kaum verwendet wird. Wenn dann aber auf source:maxspeed=* gewechselt wird, beschweren sich die Briten, dass dieses Schema falsch verwendet wird...

Und die Nutzer der Daten müssen sich sowieso auf alle möglichen Lösungen einstellen, solange es kein global gültiges Schema dafür gibt.
Falls sich irgendwann mal auf ein gültiges Schema geeinigt wird, dann können notfalls immer noch alle anderen durch (automatisierte) Edits zu einem zusammengefasst werden.

Wer sich weiterhin an einer Diskussion bezüglich des von StreetComplete verwendeten Maxspeed-Schemas beteiligen will, den lade ich gerne ein den extra dafür erstellten Thread zu nutzen: https://forum.openstreetmap.org/viewtopic.php?id=60027

ENT8R · 2019-02-11 17:58:10

chris66 wrote:

Also bei uns sind viele Spielplätze altersbeschränkt. access=yes (JEDER darf drauf) wäre da schlichtweg falsch.

Naja... Das Gelände darf jeder betreten. Solange er/sie die nicht Geräte benutzt ist ja alles in Ordnung. Da leisure=playground aber nur das Gelände und nicht die einzelnen Gerätschaften angibt, ist access=yes für öffentlich Spielplätze meiner Meinung nach schon legitim...

Tordanik · 2019-02-11 18:26:33

ENT8R wrote:

It is not necessary to use explicit access=yes for public ones but it is OK to do that

Das steht im Wiki erst seit November, und es ist nicht erkennbar, dass dieser Änderung eine Diskussion vorausgegangen wäre.

Dies nur zur Klarstellung, ist nicht mein Thema und ich hab nicht vor mich einzumischen. Aber wenn hier jemandem das Weglassen des Defaultwerts access=yes am Herzen liegt, empfehle ich einen Revert der entsprechenden Änderung. Sonst gilt das, was dort steht, schnell als "Community-Konsens" – in die Versionsgeschichte schaut kaum wer.

luschi · 2019-02-11 19:32:37

Dann mal eine weitere access Frage.

Seit dem Update von gestern gibt es die Frage: Sind auf dieser Straße Fußgänger erlaubt, da sidewalk=no erfasst ist?

Wenn ich hier jetzt auswähle, dass Fußgänger erlaubt sind, taggt StreetComplete die Straße mit foot=yes

Jetzt meine Fragen:

Frage 1:
Wozu foot=yes? ist die Straße das noch nicht?
Und was wenn dan jemand auf Nein tippt? foot=no macht dann doch sidewalk=no überflüssig
https://wiki.openstreetmap.org/wiki/OSM … strictions

Frage 2:
Wozu sidewalk=no? Werden nicht alle Straßen bereits als sidewalk=no ausgewertet, bis yes/left usw. erfasst wird?

Frage 3:
Sarkasmus an:
Wo ist dann die Aufgabe wo man gefragt wird ob die Straße von Fahrzeugen befahren werden darf und dann vehicle=yes erfassen wird wenn access=yes bei Straßen nicht der Standard ist?

Last edited by luschi (2019-02-11 19:38:14)

geri-oc · 2019-02-11 20:11:20

Es muss doch jemanden geben, der den Zugriff von APPs auf die Datenbank ermöglicht. Warum gibt es dort keine Vorschriften, was gemacht werden darf und was nicht.

Wir hatten Problem mit Wheelmap und jahrelang versucht sie zu klären. Wenn jemand Interesse an OpenStreetMap hat, dann arbeitet er sich auch in einen Editor ein.

Warum überhaupt so viele APPs mit Rechten die gar nicht diskutiert oder festgelegt sind? Ich zähle auch iD dazu mit z.B. name_1, name_2 und anderes.

Andreas Binder · 2019-02-11 20:23:46

luschi wrote:

...
Frage 2:
Wozu sidewalk=no? Werden nicht alle Straßen bereits als sidewalk=no ausgewertet, bis yes/left usw. erfasst wird?
...

Nein, das wäre nur der Fall, wenn sidewalk=no als implizierter Defaultwert bei Straßen in OSM definiert wäre. Von daher bedeutet sidewalk=no, dass kein Gehsteig dran ist. Bei einem Weg ohne sidewalk-Tag kann ein Gehsteig dran sein oder auch nicht. Ist auch laut TagInfo in der Praxis so im Einsatz https://taginfo.openstreetmap.org/keys/sidewalk#values

sidewalk hat aber mit einem access-Tag, wie foot=yes/no nichts direkt zu tun und somit finde ich die beschrieben StreetComplete-Frage nicht sinnvoll.

Last edited by Andreas Binder (2019-02-11 20:31:54)

ENT8R · 2019-02-11 20:47:06

geri-oc wrote:

Es muss doch jemanden geben, der den Zugriff von APPs auf die Datenbank ermöglicht. Warum gibt es dort keine Vorschriften, was gemacht werden darf und was nicht.

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...

geri-oc wrote:

Wir hatten Problem mit Wheelmap und jahrelang versucht sie zu klären. Wenn jemand Interesse an OpenStreetMap hat, dann arbeitet er sich auch in einen Editor ein.

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.

geri-oc wrote:

Warum überhaupt so viele APPs mit Rechten die gar nicht diskutiert oder festgelegt sind?

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.

AB-inf-x-chg-AB · 2019-02-11 20:49:41

geri-oc wrote:

Warum überhaupt so viele APPs mit Rechten die gar nicht diskutiert oder festgelegt sind? Ich zähle auch iD dazu mit z.B. name_1, name_2 und anderes.

Letzteres (*_1) wurde sehr kürzlich abgeändert, siehe:

https://github.com/openstreetmap/iD/com … 5897619433

und sollte dann mit der kommenden Version 2.14 aktiv werden...

maxbe · 2019-02-11 21:30:31

geri-oc wrote:

Es muss doch jemanden geben, der den Zugriff von APPs auf die Datenbank ermöglicht.

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.

luschi · 2019-02-11 21:49:03

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

Rainero · 2019-02-11 23:21:42

luschi wrote:

Alle Spielplätze mit access=yes zu mappen nur damit StreetComplete sie nicht mehr anzeigt sehe ich als "mappen für den Renderer/Tool", da anscheinend nur StreetComplete ein Problem hat wenn access fehlt.

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.

Luzandro · 2019-02-12 07:16:58

luschi wrote:

Wozu sidewalk=no?

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.

AB-inf-x-chg-AB · 2019-02-12 13:43:36

ENT8R wrote:

Wer sich weiterhin an einer Diskussion bezüglich des von StreetComplete verwendeten Maxspeed-Schemas beteiligen will, den lade ich gerne ein den extra dafür erstellten Thread zu nutzen: https://forum.openstreetmap.org/viewtopic.php?id=60027

Danke für den Verweis.
Gibt es so eine Diskussion/Besprechung auch für die neue v10 "foot=yes"-Streetcomplete-Aufgabe?

Habe mich diesbzlg. noch nicht vollständig informiert und habe somit noch keine Meinung. Bis jetzt kenne die wiki foot=*:
https://wiki.openstreetmap.org/wiki/DE:Key:foot
Dort passt ggf. das Bild
https://wiki.openstreetmap.org/wiki/Fil … 59.svg.png
noch nicht ideal zum Thema... Wenn man auf dieses Verkehrszeichen stösst, dann bedeutet es doch ein "foot=no" Merkmal an den betreffenden highway=* zu hängen, oder?

Und ich kenne die Seite, bei der es folgende Tabelle gibt:
https://wiki.openstreetmap.org/wiki/OSM … ns#Germany

Oder bedeutet "foot=yes", dass es für die Fälle an den highway=* drangehört, wenn das seit 2017 neue Zusatzzeichen:
https://commons.wikimedia.org/wiki/File … O_2017.svg
aufgestellt ist?

kreuzschnabel · 2019-02-12 14:04:25

AB-inf-x-chg-AB wrote:

Oder bedeutet "foot=yes", dass es für die Fälle an den highway=* drangehört, wenn das seit 2017 neue Zusatzzeichen:
https://commons.wikimedia.org/wiki/File … O_2017.svg
aufgestellt ist?

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.

--ks

Last edited by kreuzschnabel (2019-02-12 14:46:03)

PT-53 · 2019-02-12 14:12:04

Wer erstellt eigentlich diese Fragen / Aufgaben für StreetComplete? Ist das (nur) der App-Betreiber oder kann "jeder" dort Aufgaben einstellen?

Fragende Grüße

ENT8R · 2019-02-12 15:51:12

AB-inf-x-chg-AB wrote:

Danke für den Verweis.
Gibt es so eine Diskussion/Besprechung auch für die neue v10 "foot=yes"-Streetcomplete-Aufgabe?

Meines Wissens nach noch nicht. Version 10 gibt es ja erst seit zwei bis drei Tagen. Du kannst ja gerne ein neuen Thread erstellen...

PT-53 wrote:

Wer erstellt eigentlich diese Fragen / Aufgaben für StreetComplete? Ist das (nur) der App-Betreiber oder kann "jeder" dort Aufgaben einstellen?

Wie es sich für ein OpenSource-Projekt gehört, kann jeder Änderungen am Quellcode vorschlagen und somit auch neue Aufgaben hinzufügen. Das geschieht natürlich nicht komplett ohne Prüfung. Es gibt eine Checkliste, anhand derer neue Aufgaben geprüft werden: https://github.com/westnordost/StreetCo … etComplete

PT-53 · 2019-02-12 16:00:50

ENT8R wrote:

Das geschieht natürlich nicht komplett ohne Prüfung. Es gibt eine Checkliste, anhand derer neue Aufgaben geprüft werden: https://github.com/westnordost/StreetCo … etComplete

Geprüft - von wem?

PT-53 · 2019-02-12 16:08:40

Auszug aus den "Adding new Quests to StreetComplete"

? Kein Spam: Es muss möglich sein, zu bestimmen, ob die Aufgabe vernünftigerweise gestellt werden soll. Eine Aufgabe, die in 99% der Fälle mit der gleichen Antwort beantwortet werden soll, ist keine gute Aufgabe, langweilen Sie die Benutzer nicht. D.h., dass man nach einer Straße fragt, ob es sich um eine Einbahnstraße handelt, ist albern, denn die überwiegende Mehrheit aller Straßen wird keine Einbahnstraße sein.
Übersetzt mit www.DeepL.com/Translator

Beachtet StreetComplete seine eigenen Regeln nicht?

#351 2019-02-11 17:14:15

Re: StreetComplete - die nächste suboptimale App

#352 2019-02-11 17:20:16

Re: StreetComplete - die nächste suboptimale App

#353 2019-02-11 17:24:23

Re: StreetComplete - die nächste suboptimale App

#354 2019-02-11 17:30:07

Re: StreetComplete - die nächste suboptimale App

#355 2019-02-11 17:33:38

Re: StreetComplete - die nächste suboptimale App

#356 2019-02-11 17:39:08

Re: StreetComplete - die nächste suboptimale App

#357 2019-02-11 17:43:20

Re: StreetComplete - die nächste suboptimale App

#358 2019-02-11 17:52:11

Re: StreetComplete - die nächste suboptimale App

#359 2019-02-11 17:58:10

Re: StreetComplete - die nächste suboptimale App

#360 2019-02-11 18:26:33

Re: StreetComplete - die nächste suboptimale App

#361 2019-02-11 19:32:37

Re: StreetComplete - die nächste suboptimale App

#362 2019-02-11 20:11:20

Re: StreetComplete - die nächste suboptimale App

#363 2019-02-11 20:23:46

Re: StreetComplete - die nächste suboptimale App

#364 2019-02-11 20:47:06

Re: StreetComplete - die nächste suboptimale App

#365 2019-02-11 20:49:41

Re: StreetComplete - die nächste suboptimale App

#366 2019-02-11 21:30:31

Re: StreetComplete - die nächste suboptimale App

#367 2019-02-11 21:49:03

Re: StreetComplete - die nächste suboptimale App

#368 2019-02-11 23:21:42

Re: StreetComplete - die nächste suboptimale App

#369 2019-02-12 07:16:58

Re: StreetComplete - die nächste suboptimale App

#370 2019-02-12 13:43:36

Re: StreetComplete - die nächste suboptimale App

#371 2019-02-12 14:04:25

Re: StreetComplete - die nächste suboptimale App

#372 2019-02-12 14:12:04

Re: StreetComplete - die nächste suboptimale App

#373 2019-02-12 15:51:12

Re: StreetComplete - die nächste suboptimale App

#374 2019-02-12 16:00:50

Re: StreetComplete - die nächste suboptimale App

#375 2019-02-12 16:08:40

Re: StreetComplete - die nächste suboptimale App

Board footer