StreetComplete wird maxspeed:type taggen

Streng genommen doch, ein Ortsschild (city_limit oO) sagt mir nicht nur, dass hier ein Ort beginnt oder endet, sondern auch, welches maxspeed ab hier gilt.

Die Höchstgeschwindigkeit der Heinrich-Heine-Straße ändert sich “on the ground” mit dem Aufstellen eines Schildes oder mit der Änderung des Gesetzes. Wenn ich in der Heinestraße nur 50 fahren darf, dann mappe ich das auch. Das einzige Problem wäre bei einer Änderung eine fehlende Quelle, aber davon reden wir ja hier nicht.

Fände ich erst einmal gar nicht so verkehrt. StreetComplete ist eben nicht zu vergleichen mit einem Editor wie JOSM, da Taggingentscheidungen hier letztlich durch den Programmautor getroffen werden, statt dass jeder Mapper diese in Eigenverantwortung selbst trifft.

Grob gesagt:

  • JOSM: Inhalte und Taggingentscheidungen in Mapperhand
  • StreetComplete: Inhalte vom Mapper, Taggingentscheidungen durch Programmautor
  • Korrekturbots: keine inhaltliche Änderung, Taggingentscheidungen durch Programmautor

Da letztere der Pflicht unterliegen, erst einen Konsens einzuholen, fände ich nicht so abwegig, selbiges auch von Tools wie StreetComplete zu fordern. Oder falls der Vergleich zu weit hergeholt erscheint: Auch die vorgeschlagenen Regeln für organisiertes Bearbeiten fordern einen vorherigen Konsens über die verwendeten Tags. Und hier wie dort übt eine zentrale Instanz Einfluss starken darüber aus, was mit welchen Tags gemappt wird.

Natürlich bin ich trotz allem kein sonderlicher Fan neuer Regelwerke. Daher wäre mir aber eigentlich eine andere Lösung viel lieber: Die Entwickler sind sich ihrer Verantwortung bewusst und lassen ein Feature vielleicht auch einfach mal weg, wenn es in der Community noch keine Einigkeit über das Tagging gibt, oder finden andere Kompromisslösungen.

PS: Ganz unabhängig davon finde ich maxspeed:type das deutlich schönere Tag. :wink:

Das britische Forum ist praktisch tot und deine Thread dort hat keinerlei bindende Wirkung. Stattdessen musst du auf der Mailingliste Talk-gb posten.

Das stimmt IMHO so nicht. Dadurch, dass der Autor auch “hier ist was falsch und muss korrigiert werden” aussagt, ist auch der Antrieb überhaupt was zu ändern zu 100% vom Entwickler gesteuert, und zum grössten Teil deswegen auch der Inhalt. Es ist ja nicht so, dass wir nicht schon jahrelange Erfahrungen mit den Vor- und Nachteilen von QA Tools haben und mit der Effekt, dass blind solchen Fehlermeldungen gefolgt wird (auch wenn sie völlig daneben liegen).

Zurück zum konkreten Anlass, westnordost hat beschlossen, dass jetzt ein maxspeed source Tag überall dran gekloppt werden muss (ja, er hat uns netterweise die Hinrichtungsmethode freigestellt).

Es gibt gute Argumente dafür, dass wir durch die Gesetzgebung vorgegebene Höchstgeschwindigkeiten anders als nur nummerisch erfassen. So scheint in Russland es populär zu sein, dass mit maxspeed=RU:zone zu machen. Was den Vorteil hat, dass es keine Synchronisierung zwischen 2 Tags braucht (wie mit einem separaten source Tag welcher Art auch immer) um die Information korrekt weiterzugeben. Zwar gibt es relativ viele source:maxspeed ~1 million Tags (was ca 1/8 der gesamten Anzahl maxspeed Tags entspricht), aber wirklich durchgesetzt hat sich das nicht, z.B. kommt das weder in den Standardpresets vor, noch gibt es Editorunterstützung dazu (mal abgesehen davon, dass die ja jetzt alle umgetaggt werden).

Langer Rede, kurzer Sinn, es hat sich bis jetzt noch nicht wirklich ein weltweiter Konsens ausgebildet wie man das am besten macht, und vielleicht wäre es eine gute Idee daran zuerst zu arbeiten, bevor man alles flachbügelt.

Bei den QA-Tools gibt es solche und solche. Die einen sprechen erfahrene Mapper an, die anderen sind eher für die unerfahrenen geeignet.

Je unerfahrener die Zielgruppe einer Applikation ist, desto vorsichtiger muss der Entwickler sein und desto Böser-Bot-ähnlicher sind die Resultate, wenn er von oben herab entscheidet. Programme und Aktionen, die sich an Neulinge und unerfahrene Mapper richten, sollten Tags, über die es noch keinen Konsens gibt, meiden.

+1

Das macht alles Sinn was ihr sagt (Nakaner, SimonPoole, Tordanik). Was keinen Sinn macht, ist, das ganze, also

  1. einen finalen globalen Konsens zum Taggen von impliziten Geschwindigkeitsbegrenzungen zu finden und
  2. die Verantwortung von und Richtlinien für Softwareautoren, hier in diesem einen Topic
    diskutieren zu wollen. (Abgesehen davon dass es nicht besonders höflich ist, meinen schon vorher geäußerten Wunsch kommentarlos zu ignorieren)

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)

Ich habe überhaupt kein Problem damit, sobald ein globaler Konsens gefunden ist, das Tagging der App entsprechend anzupassen. Nicht für source:maxspeed und nicht für einen beliebigen anderen Tag.
Bis dahin kann meine App nichts kaputt machen, wenn sie die eine oder andere Möglichkeit taggt (wie oben begründet). Um nun zum Eingangspost zurückzukehren, ist maxspeed:type nun eben von den halbwegs etablierten das Tag, dass sich am problemlosesten automatisch in die jeweils anderen Schemata übertragen lässt, da es weder mit *source *kollidiert (source:maxspeed), noch mit einer expliziten Geschwindigkeitsbegrenzung (maxspeed=XX:something), falls gesetzt.

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

Übrigens, StreetComplete taggt nichts automatisch um, nie. Anscheinend im Gegensatz zu iD, wenn die Behauptung hier stimmt
Im Falle von Geschwindigkeitsbegrenzungen, zeigt die App nur Aufgaben an für Straßen, die **keine **der genannten Alternativen zu source:maxspeed verwenden

(Pseudo-Overpass-Query):


highway ~ motorway|trunk|primary|secondary|tertiary|unclassified|residential
and !maxspeed and !maxspeed:forward and !maxspeed:backward
and !zone:maxspeed and !maxspeed:type and !source:maxspeed 
and (access !~ private|no or (foot and foot !~ private|no)) // not on private roads

Es muss also niemand Angst haben, dass sein Lieblingstag überschrieben wird, bevor kein globaler Konsens gefunden wurde. Ich habe den Eindruck, das ist nicht allen hier bewusst.

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.

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

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.

„Schuld“ daran, dass es vier unterschiedliche keys gibt, um im Prinzip dasselbe auszudrücken, sind Leute wie Du :wink:
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.

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…

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

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.

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.

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

Nebenbei bemertk:

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 ;–)

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

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

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

Ein schöner Traum, aber unrealistisch.

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

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.

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.