StreetComplete wird maxspeed:type taggen

westnordost · 2017-10-10T16:46:23.000Z

Daher, um es mal pikiert auszudrücken:

Wer hier dafür argumentiert, das Tagging von Geschwindigkeitsbegrenzungen durch SC generell zurückzustellen, bis sich ein Key durchgesetzt hat, dem ist wichtiger, den Status Quo der absoluten Nutzungszahlen der miteinander konkurrierenden Keys zu erhalten, als der zehn-, hundert-tausender Informationsgewinn durch Taggen von Geschwindigkeitsbegrenzungen durch Nutzer der App in der Zwischenzeit.

Wozu? Um es als Argument in einer Konsensfindung zu nutzen? “X wird aber am meisten genutzt!”? Wie oben argumentiert, brauchen (sollten!) solche Argumente in dieser Diskussion keine Rolle spielen.

Claudius_Henrichs · 2017-10-13T11:11:33.000Z

+1 für deinen Pragmatismus, westnordost.
Ich sehe das große Problem in der Entscheidung in SC für eine der vier Varianten auch ncht.

Zum OT-Thema des Einflusses von Editor-Autoren:
Auch die default-Presets oder das Verhalten von Editoren (Stichwort automatisiertes wikidata=* durch iD) treffen Entscheidungen ohne explizite Bestätigung des Nutzers. Bei den historischen Entwicklungen einiger Tags lässt sich das gut an Editor-Releases festmachen. Sehe keinen Grund, warum unsere Richtlinien für Massenedits jetzt auf Editoren angewendet werden sollen.

(Und im übrigen würde meine Stimme auf Grund der schlüssigeren Semantik auch an maxspeed:type gehen.)

SimonPoole · 2017-10-13T13:24:21.000Z

Zur Klärung: die created_by Tags wurden historisch (bevor es changesets gab) von den Editoren automatisch an Objekte getaggt.

Es ist schon sehr lange Usus von allen Editoren mit grösserem Verbreitungsgrad, diesen und ein handvoll andere (von grösseren Importen stammenden) Tags automatisch zu entfernen wenn das Objekt so oder so bearbeitet wird.

dieterdreist · 2017-10-20T21:36:30.000Z

westnordost:

Was keinen Sinn macht, ist, das ganze, also

einen finalen globalen Konsens zum Taggen von impliziten Geschwindigkeitsbegrenzungen zu finden
…

Was 1. angeht, hat sich in den letzten 7 Jahren schon kein Konsens gefunden (aus fehlendem Interesse(?), aber wohl jedenfalls genug Interesse, um eine starke Meinung dazu zu haben!) wohl aber haben sich 3-4 Tagging-Schemata etabliert die allesamt in der Wiki dokumentiert sind und von dem keines deprecated ist. (Die App erfindet also keineswegs neue Tags.)

Jedem, der in den vergangenen Jahren implizite Geschwindigkeitsbegrenzungen getaggt hat, dem wird bewusst gewesen sein, dass es zu dem zu verwendenden Key anscheinend global noch keinen Konsens gibt. Das Fehlen eines Konsenses hat sie aber nicht davon abgehalten. Und das, so finde ich,** ist absolut nicht schlimm**. Denn:
Was all diese Tagging-Schemata gemein haben, ist, dass sie alle im Wesentlichen kompatibel zueinander sind - in dem Sinne, als dass sie sich untereinander jeweils sehr einfach in die eine oder andere Form per automatischem Edit bringen lassen können, sobald der Community die Situation mal doll genug ein Dorn im Auge ist, dass sie sich final auf ein einheitliches Schema einigt.
(Für diejenigen die sich damit nicht beschäftigt haben: die Schemata gleichen sich im wesentlichen in ihren Werten, nur benutzen sie unterschiedliche Keys - maxspeed=XX:something, source:maxspeed=XX:something, maxspeed:type=XX:something, zone:maxspeed=XX:something)
…

Daher sehe ich keinen Grund, generell das Taggen von Geschwindigkeitsbegrenzungen zurückzuhalten, bis sich ein Key global etabliert hat, wann immer das mal geschehen

„Schuld“ daran, dass es vier unterschiedliche keys gibt, um im Prinzip dasselbe auszudrücken, sind Leute wie Du
Als wir den tag damals erfunden haben ging es vor allem darum, bei innerörtlichen Straßen festzuhalten ob da ein Schild steht oder ob der Wert impliziert ist (dass es zusätzlich zum default ein Schild gibt mit diesem Wert ist hier sehr üblich). Den key fand ich nicht so super, habe mich aber damit abgefunden, wichtiger war, erstmal zu machen anstatt weitere Jahre darüber zu diskutieren, wie man „innerorts“ einträgt (was nebenbei bemerkt immer noch nicht geklärt ist). Es musste schnell ein key her, weil ein sehr aktiver Mapper angefangen hatte, implizite limits ohne weitere tags als explizite limits einzutragen.
Was ich nach Deinen langen Ausführungen nicht verstehe ist, wie Du von global durchsetzen und so was reden kannst und dich dann ausgerechnet dafür entscheidest, die Variante zu pushen die gerade mal 6,9% derjenigen hat, die am weitesten verbreitet ist (global), während maxspeed:type fast nur von den Linksfahrern, Unzenzählern, Stromsteckerextrawürsten, Trunk-erfindern, Euroverweigerern, Ex-Imperialisten von der Insel genutzt wird, also sowohl zahlenmäßig als auch verbreitungstechnisch zumindest bisher eine Randrolle spielt und sich nicht durchsetzen konnte.

dieterdreist · 2017-10-20T21:49:12.000Z

die Linksfahrer haben sich noch nicht mal einigen können, ob es GB:nsl-single oder UK:nsl-single heissen soll, oder vielleicht braucht man ja auch beides…

PT-53 · 2017-10-28T15:32:32.000Z

Hier https://www.openstreetmap.org/way/334034162/history#map=16/48.1316/9.7689 wurde maxspeed:type=DE:urban eingetragen.
Wers glaubt wird seelig, wer stirbt …
Am Rest der Straße gibt es keine entspr. Angabe.

So viel zum Nutzen solcher QS-Tools.

Grüße aus Oberschwaben

westnordost · 2017-10-31T22:15:41.000Z

Bei möglichen Fehlern bitte mich immer direkt kontaktieren oder im Bugtracker posten, ich versuche dann so schnell wie möglich zu reagieren. Im Forum bekomme ich das erst später oder garnicht mit.

Der Straßentyp ist als highway=residential eingetragen, daher wird bei der Antwort “Hier ist kein Straßenschild” immer DE:urban getaggt statt den User vorher zu fragen “Ist diese Straße inner- oder außerorts?”- analog zu DE:motorway bei Straßen, die als Autobahn getaggt sind.

Die App geht natürlich erstmal davon aus, dass die Daten so wie sie in OSM sind, korrekt sind. Die Annahme die die App trifft, ist, dass wenn etwas als residential (=Wohngebietsstraße) getaggt ist, dass ist schon per Definition urban ist.

Ist diese Annahme falsch? Gibt es auch Wohngebietsstraßen die außerorts sind? Oder ist es falsch, diese Straße als Wohngebietsstraße zu taggen?

Ich würde die Beispielstraße da oben nicht als Wohngebietsstraße taggen, denn sie führt weder durch noch zu einem Wohngebiet (=Straße mit Häusern), sondern scheint eine rein landwirtschaftlich genutzte Straße zu sein. Demnach würde ich sie als track taggen oder ggf als unclassified, falls der Bauernhof mehr als nur ein Bauernhof (Veranstaltungsort etc, irgendwas dass Menschen dazu veranlasst, aus nicht-landswirtschaftlichen Gründen dorthinzufahren) ist.

Nachtrag:
Doch die Frage ist natürlich trotzdem, selbst wenn das residential-tagging in diesem Falle falsch ist, ob StreetComplete nicht trotzdem immer danach fragen soll, ob eine Straße inner- oder außerorts ist um nicht basierend auf falschen Infos weitere falsche Informationen zu schließen.

MKnight · 2017-10-31T22:33:19.000Z

westnordost:

Die App geht natürlich erstmal davon aus, dass die Daten so wie sie in OSM sind, korrekt sind. Die Annahme die die App trifft, ist, dass wenn etwas als residential (=Wohngebietsstraße) getaggt ist, dass ist schon per Definition urban ist.

Ist diese Annahme falsch? Gibt es auch Wohngebietsstraßen die außerorts sind? Oder ist es falsch, diese Straße als Wohngebietsstraße zu taggen?

Wie meinst Du das? Ich hab grad kein Beispiel, aber ich vermute, dass, es real reichlich residential gibt mit maxspeed 40 oder 60 oder sonstwas.

westnordost · 2017-10-31T22:35:05.000Z

Es geht um den Fall, dass kein Schild vorhanden ist.

Chrysopras · 2017-11-01T07:29:54.000Z

Nebenbei bemertk:

westnordost:

Ich würde die Beispielstraße da oben nicht als Wohngebietsstraße taggen, denn sie führt weder durch noch zu einem Wohngebiet (=Straße mit Häusern), sondern scheint eine rein landwirtschaftlich genutzte Straße zu sein. Demnach würde ich sie als track taggen oder ggf als unclassified, falls der Bauernhof mehr als nur ein Bauernhof (Veranstaltungsort etc, irgendwas dass Menschen dazu veranlasst, aus nicht-landswirtschaftlichen Gründen dorthinzufahren) ist.

Bitte nicht als highway=track (außer falls der Bauernhof unbewohnt ist und nur aus Scheunen besteht). Wenn diese Straße die offizielle Zufahrt zum Bauernhof ist, sollte sie mindestens als hw=service getaggt werden. Wir hatten das Thema gerade erst ;–)

Omegatherion · 2017-11-01T07:31:20.000Z

Mit einer Höchstgeschwindigkeit von 100 km/h (außerorts ohne Schild) sollte die Straße nicht als residential getaggt werden.

chris66 · 2017-11-01T08:53:15.000Z

westnordost:

Die App geht natürlich erstmal davon aus, dass die Daten so wie sie in OSM sind, korrekt sind. Die Annahme die die App trifft, ist, dass wenn etwas als residential (=Wohngebietsstraße) getaggt ist, dass ist schon per Definition urban ist.

Ist diese Annahme falsch? Gibt es auch Wohngebietsstraßen die außerorts sind?

Ja klar, zB. Straßen innerhalb von Weilern/Hamlets.

PT-53 · 2017-11-01T09:22:08.000Z

westnordost:

Bei möglichen Fehlern bitte mich immer direkt kontaktieren oder im Bugtracker posten, ich versuche dann so schnell wie möglich zu reagieren. Im Forum bekomme ich das erst später oder garnicht mit.

Ich bin kein StreetComplete-Nutzer.
Hast Du Deinen eigenen Thread nicht abboniert?

westnordost:

Die App geht natürlich erstmal davon aus, dass die Daten so wie sie in OSM sind, korrekt sind.

Ein schöner Traum, aber unrealistisch.

westnordost:

Der Straßentyp ist als highway=residential eingetragen, …

Ich finde, die Nutzer sollten auf mögliche vorhandene falsche Eingaben hingewiesen und immer zur kompletten Überprüfung gebeten werden.

Ein weiteres Manko ist, daß hier nur ein Teil der Straße bearbeitet wurde. Was ist mit dem Rest ? Wird der nicht abgefragt ?
So bekommen wir nur weitere Fleckenteppiche.

Vielleicht wäre es sinnvoll. den Einsatzbereich solcher Apps auf einfachere Merkmale zu beschränken.

Grüße aus Oberschwaben
PT-53

westnordost · 2017-11-01T11:32:33.000Z

OK, dann änder ich das, so dass die App den Nutzer auch bei highway=residential fragt, ob diese Straße inner- oder außerorts ist. Update ist vorraussichtlich heute abend auf Google Play.

Ein weiteres Manko ist, daß hier nur ein Teil der Straße bearbeitet wurde. Was ist mit dem Rest ? Wird der nicht abgefragt ?

Doch, der Rest wird auch abgefragt. Es ist ja dem App-Nutzer vorbehalten, was er beantwortet und was nicht. In dem o.g. Fall ist es tatsächlich fragwürdig, ob der Nutzer auf die Frage der App eingegangen ist. Hier ist nämlich folgender Dialog abgelaufen:

App: “Welche Höchstgeschwindigkeit ist hier per Schild vorgeschrieben?”
Nutzer: “Es gibt kein Schild”
App: “Bist du sicher, dass keine Höchstgeschwindigkeit angegeben ist? Hast Du am anderen Ende der Straße nachgeschaut?
Wenn dort kein Schild steht, gelten die gesetzlichen Geschwindigkeitsbegrenzungen.”
Nutzer: “Ja, kein Schild”

Wenn die anderen Straßenabschnitte bis zur nächsten Kreuzung nicht von dem Nutzer mit DE:urban getaggt wurden, dann liegt der Verdacht nahe, dass er eben nicht am anderen Ende der Straße nachgeschaut hat um zu sehen ob da wirklich kein Schild steht.

geri-oc · 2017-11-01T13:01:46.000Z

westnordost:

Wenn die anderen Straßenabschnitte bis zur nächsten Kreuzung nicht von dem Nutzer mit DE:urban getaggt wurden, dann liegt der Verdacht nahe, dass er eben nicht am anderen Ende der Straße nachgeschaut hat um zu sehen ob da wirklich kein Schild steht.

Das ist aber “falsch” - Geschwindigkeitsbegrenzungen gelten:

https://www.stvo.de/strassenverkehrsordnung/91-3-geschwindigkeit

http://koermer-fahrschule.de/faq/strecke.php

EDIT: und m.M. nach ging es um die Verwendung maxspeed:type=* zu source:maxspeed=: in DE

westnordost · 2017-11-01T14:58:15.000Z

geri-oc:

westnordost:

Wenn die anderen Straßenabschnitte bis zur nächsten Kreuzung nicht von dem Nutzer mit DE:urban getaggt wurden, dann liegt der Verdacht nahe, dass er eben nicht am anderen Ende der Straße nachgeschaut hat um zu sehen ob da wirklich kein Schild steht.

Das ist aber “falsch” - Geschwindigkeitsbegrenzungen gelten:

https://www.stvo.de/strassenverkehrsordnung/91-3-geschwindigkeit

http://koermer-fahrschule.de/faq/strecke.php

Verstehe jetzt nicht was da falsch sein soll. Nach Informationen der FAQ der Fahrschule muss der Surveyor also *maximal *bis zum “anderen Ende der Straße gehen”. Das vom User zu verlangen, sollte also alles abdecken.
Kann man gerne umformulieren wenn das nicht alle Fälle abdeckt. Ich bin offen für Vorschläge. Aktuelle Texte auf deutsch sind:

“Hast Du am anderen Ende der Straße nachgeschaut? Wenn dort kein Schild steht, gelten die gesetzlichen Geschwindigkeitsbegrenzungen.”

und für als highway=residential und highway=unclassified getaggte Straßen, wird zusätzlich ein Bild eines (30)-Zonen-Schildes gezeigt und dieser Absatz hinzugefügt:

“Wenn es ein Schild wie dieses an der Kreuzung zur Hauptstraße gibt, wirst Du keine weiteren Zeichen innerhalb der Zone finden, da die dort angegebene Höchstgeschwindigkeit für die gesamte Zone gilt.”

geri-oc:

EDIT: und m.M. nach ging es um die Verwendung maxspeed:type=* zu source:maxspeed=: in DE

Es geht um https://forum.openstreetmap.org/viewtopic.php?pid=670189#p670189

Protoxenus · 2017-11-01T19:03:07.000Z

westnordost:

Verstehe jetzt nicht was da falsch sein soll. Nach Informationen der FAQ der Fahrschule muss der Surveyor also *maximal *bis zum “anderen Ende der Straße gehen”. Das vom User zu verlangen, sollte also alles abdecken.
Kann man gerne umformulieren wenn das nicht alle Fälle abdeckt. Ich bin offen für Vorschläge.

Ich zitiere mal aus den FAQ Verkehrsrecht des ADAC:

Als Streckenverbot werden Geschwindigkeitsbeschränkungen (Zeichen 274) und Überholverbote (Zeichen 276/277) bezeichnet. Anders als Haltverbote enden diese Streckenverbote nicht ohne weiteres an der nächsten Kreuzung oder Einmündung, sondern erst mit einem Aufhebungszeichen (Zeichen 278 bis 282).

Bei einer Kombination des Streckenverbotes mit einem Gefahrenzeichen endet die Anordnung nur dann ohne weiteres nach Ende der angezeigten Gefahrenstelle, wenn sich dies zweifelsfrei aus den Örtlichkeiten ergibt und in erkennbarer Nähe kein Aufhebungszeichen folgt. Ein Aufhebungszeichen ist auch dann entbehrlich, wenn sich die Länge des Streckenverbotes unmittelbar aus einem Zusatzschild ergibt. Geschwindigkeitsbeschränkungen enden durch neue Zeichen 278 oder innerorts am Ortsausgangsschild.

Da Streckenverbote nicht nach jeder Einmündung wiederholt werden, kann dem ortsunkundigen Kraftfahrer kein Tempo- oder Überholverbotsverstoß vorgeworfen werden, wenn er nach dem Einbiegen kein Verkehrszeichen passiert. Aus Gründen der Verkehrssicherheit fordert der ADAC deshalb die Wiederholung von Verkehrszeichen nach solchen Einmündungen und Kreuzungen, wo erfahrungsgemäß viele Ortsfremde unterwegs sind.

Die Frage ist doch: Was interpretiert der Nutzer deiner App als das andere Ende der Straße? Ist das da, wo die Straße den Namen wechselt? Erkennt man das auf andere Weise?
Ich weiß aus meinem Bekanntenkreis, das nicht mal alle, die einen Führerschein haben und regelmäßig fahren, damit sicher umgehen können.

westnordost · 2017-11-01T22:32:29.000Z

Was soll die App eurer Meinung nach fragen?

Während die Diskussion läuft, mach ich jetzt erstmal keine neue Version.

Protoxenus · 2017-11-02T19:31:42.000Z

Ich finde die Idee deiner App gut
und habe sie auch schon genutzt bzw. damit herum experimentiert. Was mir sehr gut gefällt, ist, dass man quasi mit der Nase darauf gestoßen wird, das hier und da noch unkartierte Attribute von bestimmten, in der DB vorhandenen Elementen fehlen. Ich habe vorher am PC gesessen, mir fehlende Dinge in eine Liste geschrieben und versucht, diese abzuarbeiten. Das wird jetzt viel einfacher.

Es gibt da für mich ein paar Dinge, die nicht optimal gelöst sind bzw. die man besser nicht jemanden fragen sollte, der sich nicht so gut mit den Regeln auskennt und eventuell sofort im Wiki nachschlagen könnte:
Es wird für jedes kleine Teil Straße gefragt, welchen Namen dieser Teil hat. Aus den unterschiedlichsten Gründen ist es manchmal nicht sinnvoll, an alle Teile einer Straße einen Namen zu tragen (Diskussion darüber).
Es wird gefragt, ob die Straße beleuchtet ist. In HRO sind z.B. nach Bereitstellung der Daten durch die Stadtverwaltung alle Straßenlampen eingetragen. Ist es wirklich sinnvoll, da noch nach einer Beleuchtung zu fragen?
Es gibt in D oft Geschwindigkeitsbeschränkungen, die je nach Fahrtrichtung(auch innerorts) unterschiedlich sein können. Das sollte meiner Meinung nach berücksichtigt werden.
Auch das Abfragen von Öffnungszeiten von Hotels ist grenzwertig.

westnordost:

Was soll die App eurer Meinung nach fragen?

Am sinnvollsten ist es aus meiner Sicht, wenn die App nur die Verkehrszeichen abfragt. Alles Andere sollt doch besser erfahrenere Mapper in die Datenbank eintragen. Vor allem, wenn die Geschwindigkeitsbegrenzung im Verlauf einer Straße wechselt und diese da nicht zufällig geteilt ist oder in der einen Richtung von der in der anderen Richtung abweicht, ist das tool überfordert.
Ein Eintragen von POIs über einen Dialog wäre für mich noch sinnvoll.

Edit: Mir ist gerade noch aufgefallen, dass du Rasengittersteine aus Beton unter “unbefestigt” kategorisiert hast. Ich hätte das eher unter befestigt vermutet.

westnordost · 2017-11-03T12:21:16.000Z

Protexenus, danke für das Feedback und die Verbesserungsvorschläge. Der Übersicht halber bitte ich dich, dafür dann jeweils ein eigenes Topic aufzumachen wenn das einer Diskussion bedarf. Wenn du der englischen Sprache mächtig bist, vorzugsweise direkt im Issue Tracker auf github: https://github.com/westnordost/StreetComplete/issues

Ganz kurz:

App fragt keine Öffnungszeiten von Hotels. Vermutlich ist das als Restaurant getaggt
Geschwindigkeitsbegrenzungen je nach Fahrtrichtung: https://github.com/westnordost/StreetComplete/issues/353
Ist es wirklich sinnvoll, da noch nach einer Beleuchtung zu fragen? → Ich denke ja

Ich fragte eigentlich spezifisch danach, was die App den Nutzer fragen soll, wenn er antwortet, dass er hier kein Schild für Höchstgeschwindigkeit sieht. Nicht ganz allgemein.
Ich verstehe die von dir angesprochene grundlegende Problematik des Abfragens von Eigenschaften von (längeren) Wegen. Das Problem haben ja alle Aufgabentypen, die mit Straßen etc. arbeiten, also auch Straßenoberfläche, Anzahl Fahrspuren, Beleuchtung, Fahrradwege, Bürgersteig usw… Ich denke ich werde nicht darum herumkommen, die App früher oder später so zu erweitern, dass Nutzer Strecken auch als Teil ihrer Antwort aufteilen können (hier ist 50km/h, ab da sind keine Schilder / von da bis da ist Asphalt, dann hier ist Kopfsteinpflaster usw), da das Fehlen dieser Möglichkeit die Nützlichkeit dieser Aufgaben doch sehr negativ beeinflusst wenn man viele dieser Aufgaben nicht bzw. nur unkomfortabel beantworten kann. Ich glaube dafür gibt es auch schon ein Ticket auf GitHub.