StreetComplete - die nächste suboptimale App

Neuerdings mach StreetComplete Notes auf:
http://www.openstreetmap.org/note/1106472
http://www.openstreetmap.org/note/1106474

Diese surface habe ich nachgetragen. Der Note lässt sich aber nicht schließen. Ich finde die Erstellung einer Note durch StreetComplete falsch.

Habe jetzt noch einmal mit Chrome probiert und erhalte nun keinen Zugriff auf openstreetmap.org - soll mich authentifizieren, obwohl ich angemeldet bin. Auch mit FF funktioniert es nicht mehr. Wie kann ich mich auf OSM noch anmelden? (Ins OSM-Wiki komme ich und auf openstreetmap.org wird auch mein Profil angezeigt.)

wir unterbrechen die aktuelle dauermeckersendung für einen moment:

*** breaking news ***

https://twitter.com/sotm/status/898910845857447937

Glückwunsch, well done!

Ebenso - Glückwunsch!

Anmeldung und Note erledigen funktioniert (wieder) - Fehler war eine falsche (nachgehende) Computer-Uhrzeit …

Hi,

ich bin grade auf diesen Thread gestoßen und hab mir die App direkt auch runtergeladen.

Ich weiß nicht, ob westnordost hier noch mitließt, aber mein Feedback dazu würde ich trotzdem gerne los werden:

-Erstmal: Super Idee, easy Umsetzung, sowas brauchen wir hier dringend häufiger! Also: Weiter so!

-Mir fehlt zu Beginn ein kleines Intro, das erklärt, wie die App funktioniert. Sowas gibt’s ja heutzutage in vielen Apps und sollte nicht so aufwändig sein. Mir war z.B. nicht klar, dass ich bereits beantwortete Fragen gar nicht mehr aufrufen kann. Auch ist mir bisher nicht klar, ob die Änderungen auf jeden Fall hochgeladen werden, oder erst dann, wenn ich im Menü auf “Antworten hochladen” gehe. Wenn ich die App schließe, kommt auf jeden Fall keine Warnung, dass Daten verloren gehen könnten.

-Ich würde z.B. gerne vorm Hochladen die Fragen nochmal auf Richtigkeit durchgehen können.

-Auch sollte vlt in einem möglichen Intro nochmal darauf hingewiesen werden, dass hier auf eigene Verantwortung in den Datenbestand von OSM eingegriffen wird.

-Bei den Geschwindigkeiten fehlt mir die Option, dass die eingetragene Vmax nicht aufgrund eines Schildes gilt, sondern, weil man sich hier auf einer Land-, Innerstädtischen- oder sonstigen Straße befindet mit allgemeinen Höchstgeschwindigkeiten. Also eine Option für source:maxspeed=*.

Ich werde die App auf jeden Fall weiter nutzen, da man hier easy vor Ort Informationen erfassen kann, ohne sich großartige Notizen, Bilder oder was auch immer machen zu müssen. Grade in Gebieten mit einem sehr dürftigen Datenbestand ist das ein Segen (man erinnere sich nur an den Aufwand, der hier schon betrieben wurde, um große Gebiete ohne Hausnummern anzugehen).

Viele Grüße,

hsimpson

Verleitet die App dann etwas einzutragen, was eventuell schon separat gemappt ist? Oder werden die Umgebungsdaten angezeigt?
z. B. ist mir aufgefallen Bushaltestelle: shelter, bin, bench werden ergänzt, obwohl separat oder an pt=plattform vorhanden.

hmm, scheint aber wohl mal genauso funktioniert zu haben, siehe meinen Post weiter oben (#86)

Weil es bei den Diskussionen (bitte einfach mal danach suchen) bisher auch immer darum ging, source:maxspeed für “implizit” (oder rechtliche grundlage) zu verwenden. Wenn du jede Innerortsstraße mit maxspeed=50 taggst, dann musst du nach einer Gesetzesänderung alles anpassen (ich sag nur automated edit, und leider hatten wir auch schon andere Diskussionen, dass es gar nicht so einfach ist, “innerorts”-Straßen überhaupt einwandfrei rauszufiltern). Mit nur source:maxspeed=DE:urban könnte Navis und Co einfach so dann die aktuell gesetzliche Regelung anzeigen/verwenden.

Hab ich gesehen, daher wunder es mich auch, dass ich bisher nur auf die Option “Zone” gestoßen bin. Aber vieleicht hatte ich bisher auch nur Straßen, die bereits ein source:maxspeed hatten?

Oha, jetzt wirds interessant: Offensichtlich hat die App ein automatisches source:maxspeed=sign gesetzt. Das finde ich wiederum gar nicht lustig. Siehe u.a. http://www.openstreetmap.org/way/6187381

Hier sind wir wieder bei: Was tut die App eigentlich genau und warum? Das muss definitiv genauer beantwortet werden und z.B. die Fragen genauer gestellt werden. Ansonsten haben wir bald in allen Innenstädten fälschlicherweise ein source:maxspeed=sign!

Ein source:maxspeed würde genau das ermöglichen!

Grüße

Meiner Ansicht nach müsste eine korrekte Abfrage nach der Geschwindigkeit etwa so ausschauen:

1.: Gibt es auf dieser Straße ein Schild, was die Geschwindigkeit explizit regelt oder liegt die Straße in einer expliziten Geschwindigkeitszone?
Wenn ja: Geschwindigkeit und evtl Zone eigeben lassen wie bisher.
Wenn nein:
2.:Befindet sich die Straße innerorts oder Außerorts?
(3.:Wie lautet die implizite Geschwindigkeit für diese Straße?) ← Optional, würde ich persönlich auch abfragen.

Grüße

Edit: In Frage 2 können auch Fälle wie der Verkehrsberuhigte Bereich abgefragt werden.

Leider nein! Siehe Innerorts außerorts unterscheiden. Ein Beispiel von vielen: innerorts-Straße mit maxspeed=60/70 und source:maxspeed=sign

Solche Straßen wären aber auch von einer Gesetzesänderung nicht betroffen, da die Vmax nicht impliziert wird. Daher ist es für den Fall unwesentlich, ob solche Straßen als innerorts oder außerorts erkannt werden können.

Grüße

Glückwunsch auch von mir, ich finde die Idee auch gut und die Auszeichnung verdient.

Vo daher bin ich der Meinung, das auch der Titel dieser Diskussion mal geändert gehört!!!
Ein schönes Rest-Wochenende wünscht
Uwe

Habe grade zwei Tickets geöffnet:
Da und da.

Grüße

Changeset: http://www.openstreetmap.org/changeset/51278638
So gut die App sein mag zeigt der Changeset gleich mehrere Probleme:

  • Couven-Gymnasium (oben links): Die Adresse ist korrekt auf der Fläche der Schule erfasst. Die App dürfte für die einzelnen Gebäude (“school”) gar keine Hausnummer abfragen.
  • Generali (unten rechts): Die Hausnummer 16 war bereits an einem der Gebäude erfasst (http://www.openstreetmap.org/relation/1461507). Nun gibt es die Hausnummer mehrfach.
  • Allgemein (+ Lösungsvorschlag): Warum kann man Hausnummern ohne Straße angeben (das ist doch zwecklos)? Wäre die Straße ein Pflichtangabe, hätte man dem User in o.g. Fällen anzeigen können, dass die Adresse bereits existiert.

PS: Ich nutze die App nicht und kann daher nicht sagen, ob dem User in o.g. Fällen vielleicht beim Upload etwas angezeigt wurde (z.B. ein Hinweis auf fehlende Straßennamen).

Korrektes bestimmen ob eine Adresse fehlt oder nicht, ist eher schwierig. Nicht nur wegen der Dutzend oder so Varianten wo eine vorhandene Adresse stecken kann, sondern auch wegen den lokalen Regelungen (sind Grundstücke, Gebäude, Eingänge oder was anderes nummeriert).

betrifft aber auch z.B. shelter an busstop - falls sie separat eingetragen sind werden sie durch die App gedoppelt (bench, bin, … )

Also die App erkennt auf jeden Fall schonmal den Fall, dass die Hausnummer als Node an die Tür gesetzt wurde, hab ich eben mal gecheckt. Also müsste das mit der Fläche auch eigentlich machbar sein.

Grüße

Man kann aber doch bestimmt prüfen, ob eine Adresse, die eingegeben wird, bereits existiert, oder?

Ich habe gesehen, dass es zum ersten Problem (Adresse inkl. Hausnummer auf Fläche vorhanden) ein Issue auf GitHub gibt: https://github.com/westnordost/StreetComplete/issues/510

Lang nicht mehr hier reingeschaut. Hier ein paar Antworten:

Habe ich mir angeschaut, kein Bug. Hier ein Beispiel wo das passiert ist.
Hier wurde das alte higway=bus_stop Schema mit dem neuen Schema vermischt. Wenn man das neue Schema nutzt (public_transport=platform), dann sollte das auch konsistent pro-Haltestelle angewendet werden. Ein highway=bus_stop auf einem public_transport=platform ist an sich schon eine Dopplung. Für Haltestellen auf einer (langen) Plattform gibt es public_transport=pole.

Ganz unabhängig davon stellt sich natürlich die Frage, ob wenn eine Plattform lang genug ist um detailliert als way getaggt zu sein und einzelne (mehrere) Haltestellen vereinigt (poles / hier im Beispiel: highway=bus_stop), ob es dann nicht eh sinnig ist, die angesprochenen Eigenschaften (auch) dort zu taggen, da eine Oma die vorne an einem langen Busstieg auf ihren Bus wartet sicherlich nicht interessiert ob irgendwo am anderen Ende eine Bank vorhanden ist, sondern genau dort wo sie wartet. Hier nur mal so als Anregung, ich werde nichts dergleichen einbauen solange das nicht offiziell dokumentiert ist.

An diesem Beispiel sieht man gut, dass die Auffassung, sowohl im alten als auch neuen Schema zu taggen für Data-Consumers hilfreich ist, ein Mythos ist. Das Gegenteil ist der Fall.

Hier mal eine Auflistung, wie StreetComplete auf die Tags kommt:

  1. Gibt der Nutzer normal die Geschwindigkeitsbegrenzung ein und drückt [OK], wird die Eingabe grob auf Plausibilität geprüft. Erscheint die Eingabe unplausibel, muss der Nutzer seine Eingabe bestätigen, ansonsten wird sie sofort übernommen. Es wird getaggt: maxspeed=[Eingabe], source:maxspeed=sign. Befindet sich die Straße in einem Land befindet, in dem mit Meilen gerechnet wird, wird an die Eingabe entsprechend * mph* angehängt.

  2. Befindet sich die Straße in einem Land, in dem das Konzept von (30-)Zonen bekannt ist, befindet sich im Formular eine Checkbox die der Nutzer ankreuzen kann, um diese Straße als Teil einer (30-)Zone zu markieren. Wenn angeklickt, wird die Geschwindigkeitsbegrenzung im Formular mit 30 (bzw. 20 mph) vorausgefüllt sofern noch nichts eingetragen wurde, kann man aber editieren. Statt source:maxspeed=sign wird dann z.B. source:maxspeed=DE:zone30 getaggt. Ansonsten wie 1.

  3. Befindet sich die Straße in einem Land, in dem man das Konzept von Spielstraßen kennt, kann der Nutzer die Frage mit “Es ist eine Spielstraße” beantworten. Der Nutzer muss dies in einem Dialog in dem ein Bild eines Spielstraßen-Schildes gezeigt wird, bestätigen. Die Bilder variieren je nach Land in dem sich die Straße befindet. Siehe 1, 2, 3, 4. Die Straße wird dann lediglich in highway=living_street umgetaggt.

  4. Der Nutzer hat immer die Möglichkeit, die Frage mit “Es gibt hier kein Schild” zu beantworten. Grundsätzlich muss diese Antwort bestätigt werden. Befindet der Nutzer sich in einer Wohngebietsstraße (highway=residential) und einem Land, in dem man (30-)Zonen kennt, wird der Nutzer noch einmal darauf hingewiesen, dass man runter zur Hauptstraße gehen müsste um festzustellen ob es hier nur kein Schild gibt oder es doch eine Zone ist, da innerhalb einer Zone keine weiteren Geschwindigkeitsbegrenzungsschilder vorhanden sein werden. In diesem Dialog wird noch einmal ein Bild eines Zonen-Schildes gezeigt. Wird bestätigt, dass kein Schild vorhanden ist, wird der Nutzer für alle Straßen außer residential, motorway, trunk usw. noch einmal gefragt, ob die Straße inner- oder außerorts ist. Das ist (leider) notwendig, denn es gibt kein Tagging-Schema dass erlauben würde, einfach nur den Fakt dass es keine Speed-Limit-Schilder gibt, so direkt zu taggen. Der Fall wird dann also z.B. mit source:maxspeed=urban (ohne maxspeed=, denn u.a. kann man vom Nutzer nicht verlangen, das zu wissen) getaggt.

    Hier meckern übrigens die Briten, denn die Community hat sich leider noch immer nicht auf ein weltweit gültiges Schema für implizite Geschwindigkeitsbegrenzungen geeinigt. :-/

Geplante Erweiterungen:

  1. In Zukunft soll noch für Länder in denen das Konzept von “Richtgeschwindigkeit” vorhanden ist, eine zusätzliche Antwort-Option angezeigt werden. Klickt der Nutzer darauf, verwandelt sich das runde weiße Schild mit dem rotem Rand (das Eingabefeld) in ein blaues eckiges mit weißem Rand bzw. in andere Formen und Farben, je nach Land. Dort kann der Nutzer dann statt der Höchstgeschwindigkeit, die Richtgeschwindigkeit eingeben.

  2. Außerdem soll der Nutzer später noch die Möglichkeit bekommen, zeitgebundene Höchstgeschwindigkeiten anzugeben, auch wieder aktiviert über eine zusätzliche Antwort-Option. Die Eingabe erfolgt analog wie im Öffnungszeiten-Dialog. Dies hat aber weniger Priorität, da solche Straßen selten sind und dies auch erstmal über Notizen abgehandelt werden kann.

Du sprichst hier mehrere Punkte an.

  1. Du hast die App richtig bedient

  2. Dass kein Hinweis in welchem Kontext die OSM Notiz entstanden ist, angefügt wird, ist falsch. Schau nochmal

  3. Momentan werden Hausnummern an einzelnen Gebäuden von z.B. einer Schule abgefragt, selbst wenn die gesamte Schule (amenity=school) schon eine Hausnummer hat. Das ist so implementiert, weil ich dachte, es sei nicht erwünscht, Hausnummern an nicht-Häusern zu haben. Dies scheint doch nicht der Fall zu sein, daher werde ich demnächst implementieren, dass die Hausnummer von Gebäuden innerhalb von solchen Areas nicht mehr abgefragt wird, wenn die Hausnummer schon daran getaggt ist. Dazu gibt es schon ein Github issue, den du abonnieren kannst wenn du über Fortschritte informiert werden willst.

  4. Es wurde irgendwo anders in diesem Thread noch angemerkt dass noaddress=yes (noch) nicht implementiert ist. Das ist richtig, ist noch nicht implementiert. Siehe das Github issue hier.

Da kannste ja gerne mal meinen, durchaus wohl nur an der Oberfläche kratzenden Blogeintrag maxspeed … eine Perle des Wikis überfliegen :wink:

PS: Auch “DE:zone30” wurde erst vor ein paar Monaten auf talk-de “zerlegt”, da es hier gerade mal 10tsd einträge mehr gibt, als für “DE:zone:30” usw.