StreetComplete wird maxspeed:type taggen

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.

geri-oc · 2018-01-20T10:30:05.000Z

In letzter Zeit taucht maxspeed:type=* durch StreetComplete 3.4 auf.
Ist das nun beschlossen oder bleibt es bei source:maxspeed=*?

Genauso kann ich nicht verstehen, dass cycleway=no getaggt werden sollte. Dann muss ich auch alles andere footway, bridleway, … auf no setzen. Ich bin der Meinung wir taggen das was wir vor Ort sehen.

Vor allem, wenn nur solche einzelnen “Ergänzungen” vorgenommen werden, statt surface=, smoothness=, lit=*, … zu ergänzen, wenn man vor Ort ist.

wegavision · 2018-01-20T11:11:14.000Z

geri-oc:

Genauso kann ich nicht verstehen, dass cycleway=no getaggt werden sollte. Dann muss ich auch alles andere footway, bridleway, … auf no setzen. Ich bin der Meinung wir taggen das was wir vor Ort sehen.

Vor allem, wenn nur solche einzelnen “Ergänzungen” vorgenommen werden, statt surface=, smoothness=, lit=*, … zu ergänzen, wenn man vor Ort ist.

Wobei zumindest bei uns die Fahrradwege wohl die am Besten kartierten Wege sind (nach den Bahnstrecken, da sind ja sogar die ehemaligen drin), ich habe da selbst wohl kaum einen hinzugefügt, höchstens mal korrigiert, wenn er auch ein Fußweg war etc.
Das bedeutet, wir verschlechtern teilweise sogar die Datenbank, wenn wir alle Straßen mit =no mappen, weil es teilweise dann doch Interpretation ist, ob der Fahrradweg zur Straße gehört oder es kommt dazu, dass mancher =no mappt, weil der Radweg schon als eigener way drin ist. Fazit viel Redundanz und noch mehr Diskussionen aber so gut wie keine Verbesserung.

Elefant_aus_Wuppertal · 2018-06-22T20:12:21.000Z

Hier: https://www.openstreetmap.org/changeset/59080536 hat ein User - zwar mit JOSM, aber angelehnt an das StreetComplete-Tagging (schaut in seine History dann seht ihr, dass er viel mit SC arbeitet) jetzt ca. über 1000 maxspeed=*'s gelöscht und dafür maxspeed:type getaggt.

Es geht um diese quasi impliziten maxspeeds (Innerstädtische Höchstgeschwindigkeit in D und 30er-Zonen). Also die, wo eben nicht oder nicht überall ein Schild steht. Quellen für das korrekte setzen von maxspeed:type gibt es schon, wie er sagt hat er alles geprüft. Manchmal war auch source:maxspeed schon da, das hat er dann in maxspeed:type umgewandelt und auf dessen Grundlage maxspeed=* gelöscht, da es ja durch die maxspeed:type-Angabe redundant sei. So habe ich das zumindest verstanden. Aber wie gesagt er will jeden Fall geprüft haben.

Ist das abgesprochen bzw. was meint ihr dazu? Kleine CS-Diskussion gab es schon wie man sehen kann.

Ersetzt maxspeed:type jetzt maxspeed= dort, wo kein Schild steht?* Sind explizite maxspeed-Werte auf Straßen ohne Schild jetzt quasi überflüssig bzw. entsprechen nicht (mehr) dem aktuell üblichen Tagging-Schema? Bzw. soll es dahin gehen, dass auf Straßen ohne Schild kein expliziter maxspeed-Wert mehr gesetzt wird?

chris66 · 2018-06-22T20:22:01.000Z

WIKI:

This tag is sometimes used to hold information about the type of speed limit specified in maxspeed=*

maxspeed:type und source:maxspeed ist derzeit nur als Ergänzung zu maxspeed gedacht.

Die Änderung führt also dazu, dass fast alle OSM basierten Router weit schlechter funktionieren.

Ich bin für Revert oder Wiederhinzufügung der entfernten maxspeed-Werte.

Thomas8122 · 2018-06-22T20:52:14.000Z

chris66:

Ich bin für sofortigen Revert.

Ja bitte.

westnordost · 2018-06-22T22:11:40.000Z

Ich verstehe nicht wieso das in diesem Thread diskutiert wird.

Wie dem auch sei: Davon ausgehend dass es stimmt was er sagt, nämlich dass er jede der in dem Changeset vorkommenen Straßen abgefahren und jeweils festgestellt hat, dass die Geschwindigkeitsbegrenzung nicht durch ein Schild (sondern implizit) zustandekommt, handelt es sich also nicht um einen mechanischen Edit, sondern ist Ergebnis einer survey, also die wertvollste Art eines Edits.

Hier nun nach einem sofortigen Revert zu rufen finde ich mit Respekt gegenüber dem Mapper, der der Größe des Edits nach zu urteilen hier wohlmöglich einen ganzen Tag Zeit investiert hat um diese Informationen zu sammeln, vollkommen unangemessen.
Zumal dieser Ruf nicht auf der Behauptung beruht, dies sei ein automatischer Edit, sondern auf Basis von Taggingstreitigkeiten.

Fakt ist, dass durch den Edit Informationen *hinzugefügt *wurden, nämlich die Information darüber wie die Geschwindigkeitsbegrenzung zustandekommt. Richtig ist aber auch was chris66 sagt, dass maxspeed:type etc. als Ergänzung zu maxspeed gedacht ist und durch Entfernung vom maxspeed-Tag die Nutzbarkeit der Daten in OSM für Router verringert wurde.

Die Lösung wäre also, dass RubenKelevra die entfernten maxspeed-Tags wieder hinzufügt und alle werden glücklich.

westnordost · 2018-06-22T22:28:46.000Z

Übrigens gehöre ich selbst ja zu der Fraktion, die eher dafür argumentiert, auf explizites maxspeed verzichten zu können wenn klar ist dass die Geschwindigkeitsbegrenzung implizt ist.
Allerdings sehe ich ein dass man das frühestens dann so praktizieren kann, wenn man an einem Punkt angelangt ist, bei denen man OSM Routern zutrauen kann, mit nicht-expliziten Geschwindigkeitsbegrenzungen (also maxspeed:type, source:maxspeed, …) überhaupt etwas anfangen zu können. Das ist momentan überhaupt nicht der Fall. Soweit ich weiß, gibt es keine Datennutzer, die irgendwas mit diesen impliziten Limits anfangen können. Insofern ist das momentan eine reine Metainformation für Mapper.

Es gibt nichtmal QA Tools, die etwa Diskrepanzen zwischen den eingetragenen ex- und impliziten Geschwindigkeitsbegrenzungen erkennen.

Dabei wäre hier der erste Schritt.

Beziehungsweise, der eigentliche erste Schritt wäre überhaupt in machinenlesbarer und für alle zugänglicher Form zu dokumentieren, welche impliziten Geschwindigkeitsbegrenzungen es überhaupt gibt, wie diese zu taggen und wie zu interpretieren sind. Eine gemeinsame Datenbasis zu haben.
Aus diesem Grund habe ich neulich mal diese Seite hier angefangen https://wiki.openstreetmap.org/wiki/Default_speed_limits - zwischenzeitlich aber die Motivation verloren. Mache ich eventuell bald mal wieder weiter.

westnordost · 2018-06-22T22:52:27.000Z

Ich habe mir den betreffenden Changeset in achavi angeguckt. Ich ändere meine Meinung. Das sieht nicht nach einem Resultat einer Begehung aus, egal was RubenKelevra behauptet, sondern ein großes Umtaggen von source:maxspeed auf maxspeed:type sowie angesprochenes Löschen von maxspeed. Das ist nicht in Ordnung.

Harald_Hartmann · 2018-06-23T05:07:26.000Z

westnordost:

Es gibt nichtmal QA Tools, die etwa Diskrepanzen zwischen den eingetragenen ex- und impliziten Geschwindigkeitsbegrenzungen erkennen.

Doch gibt es, habe ich zumindest auf Grund meines Blogposts maxspeed … eine Perle des Wikis bei osmose als Issue eingereicht und wurde auch umgesetzt.
Ich habe auch hier und da mal im Forum erwähnt, dass man es für sein Lieblingstool auch noch einreichen sollte, und habe auch darauf hingewiesen, daß maxspeed und source:maxspeed sicherlich nicht das einzige “verbundene” Wertepaar ist.

Harald_Hartmann · 2018-06-23T09:42:28.000Z

westnordost:

Beziehungsweise, der eigentliche erste Schritt wäre überhaupt in machinenlesbarer und für alle zugänglicher Form zu dokumentieren, welche impliziten Geschwindigkeitsbegrenzungen es überhaupt gibt, wie diese zu taggen und wie zu interpretieren sind. Eine gemeinsame Datenbasis zu haben.
Aus diesem Grund habe ich neulich mal diese Seite hier angefangen https://wiki.openstreetmap.org/wiki/Def … eed_limits - zwischenzeitlich aber die Motivation verloren. Mache ich eventuell bald mal wieder weiter.

Danke schon mal dafür, dass du da bald wieder weiter machst. Wenn du damit fertig bist, können wir ja die jetzigen Tabellen in Speed limits (die eben u.a. osmose nutzt) aktualisieren oder gleich ad acta legen.

geri-oc · 2018-06-25T15:14:55.000Z

Da im anderen Thema abgehackt, hier noch einmal:

Hakuch_adm:

Bitte her keine Diskussion über source:maxspeed und maxspeed:type, die könnt ihr, wenn schon, in dem anderen schon verlinkten Thread führen

https://forum.openstreetmap.org/viewtopic.php?id=60027

Dort könnt ihr dann auch die schon genannten Argumente prüfen und berücksichtigen damit sich die ganze Diskussion nicht nochmal wiederholt, so wie es hier in diesem Thread die ganze Zeit passiert.

Noch einmal die Frage:

Tragen wir jetzt source:maxspeed oder maxspeed:type oder beides ein?

Jahrelang war source:maxspeed - steht auch so im WIKI. Nun kommt die “Insel” und macht weltweit maxspeed:type.

Dann einfach einmal entscheiden → WIKI ändern → Schlüssel automatisch korrigieren (falls das überhaupt noch geht) → neuen Schlüssel anwenden → bei Fehlmapping dieses korrigieren und Mapper auf neues WIKI verweisen.

westnordost · 2018-06-25T16:11:14.000Z

Tragen wir jetzt source:maxspeed oder maxspeed:type oder beides ein?

Solange es noch keinen globalen Konsens gibt (also sich jemand mal zur Aufgabe setzt, einen zu finden), bleibt das persönliche bzw. “local community” Präferenz. Beides gleichzeitig zu setzen macht allerdings keinen Sinn.

Die von mir erwähnte Wiki page (Default speed limits) dient u.a. ehrlich gesagt der Vorbereitung dessen, ein globales Taggingschema zu finden indem wir zunächst erstmal finden, welche Parameter zu impliziten Geschwindigkeitsbegrenzungen führen. Am Ende könnte es darauf hinaus laufen, dass keine der momentan genutzen Keys (source:maxspeed, maxspeed:type, …) ideal sind, denn siehe auch Forum topic Implizite Höchstgeschwindigkeit außerhalb geschlossener Ortschaften. Aber meiner Meinung sollte wie gesagt dieser Entscheidungsfindung eine ausführliche Recherche voraus gehen.

Ich will die Gelegenheit hier nochmal nutzen, dafür zu werben, dass sich auch andere an der Recherche (am via besten Primärquellen, also Gesetzestexte) für die verlinkte Wikiseite beteiligen.

PT-53 · 2018-06-25T16:18:15.000Z

westnordost:

Tragen wir jetzt source:maxspeed oder maxspeed:type oder beides ein?

Solange es noch keinen globalen Konsens gibt (also sich jemand mal zur Aufgabe setzt, einen zu finden), bleibt das persönliche bzw. “local community” Präferenz.

Setzt StreetComplete jetzt - je nach Region und “local community” Präferenz - verschiedene Attribute ?

westnordost · 2018-06-25T17:27:16.000Z

Nein