StreetComplete wird maxspeed:type taggen

ja, leider nur das grundprinzip an das man sich aber nicht halten muss … also ich habe gps ausgemacht und wie wild in der gegend rum geändert und das von der couch aus…

sorry, aber auch das wird es leider nicht leisten können … wenn z.B. eine Hauptstraße in einem Dorf am Kindergarten/Schule auf 30 begrenzt wird (also mit traffic_sign aber maxspeed:type=DE:urban auch wieder falsch ist) und es aber die 30 auch außerhalb gibt, genauso wie es die 50 außerhalb oder die 100 innerhalb gibt, usw. siehe auch Innerorts außerorts unterscheiden

Hier wird leider ein wenig vom Thema abgewichen, dennoch möchte ich Stellung nehmen zu einigen Aussagen:

Wieso leider? In JOSM “musst” du dich auch nicht an irgendwas halten und kannst alle Warnungen ignorieren.
StreetComplete warnt dich für jede einzelne Frage die du außerhalb eines bestimmten Radiusses um deine GPS Position beantwortest, dass generell nur Fragen beantwortet werden sollen, die vor Ort überprüft wurden. Das kannst du natürlich ignorieren, aber dann ist das genauso fahrlässig bzw. Vandalismus wie als wenn du mit anderen Editoren Warnungen ignorierst bzw. mutwillig falsche Informationen einträgst.

StreetComplete taggt nichts um. Wenn du das Thema wirklich grundsätzlich diskutieren möchtest, mache doch bitte der Übersichtlichkeit halber ein eigenes Topic auf. Das bezieht sich sicherlich nicht nur speziell auf source:maxspeed und auch nicht nur speziell auf StreetComplete.


Zu kreuzschnabel und woodpeck***: Das weicht jetzt auch ein bischen vom Thema ab. woodpeck hat erklärt, warum es Sinn macht, source:maxspeed (bzw. eine Alternative) zu taggen. Ob man nun nur maxspeed taggt, oder nur source:maxspeed, oder beides oder noch was anderes, ist mMn letztlich jedem selbst überlassen. Ich hörte, das Thema wird immer wieder kontrovers diskutiert und ich will hier garnicht anfangen zu versuchen, das hier auszudiskutieren. Das ist ein Thema für sich und sollte vielleicht bei Interesse eher in einem eigenen Topic diskutiert werden.
(Nachtrag: Und ein wünschenswertes Ergebnis derjenigen Diskussion wäre dann der Entschluss, sich auf ein Tagging-Schema zu einigen, die anderen zu deprecated und per automatischem Edit alle taggings in das aktzeptierte umzuändern.)

Nochmal: Es geht mir hier nicht darum, irgendein Tag zu deprecaten oder auszurotten. **Es geht mir hier nur darum, festzustellen, welchen Tag StreetComplete unter mehreren verschiedenen möglichen Tags, von denen keines weder *deprecated *noch (übrigens) approved ist, nutzen mag, um anzuzeigen, dass an einer Straße kein Schild für eine Geschwindigkeitsbegrenzung steht - mit anderen Worten, eine implizite Geschwindigkeitsbegrenzung gilt.
Meine gesamte Argumentation (jetzt doch lieber maxspeed:type nutzen zu wollen), bezieht sich allein darauf.

Was dieses source:maxspeed vs Alternativen Thema angeht, möchte einen Tag finden, mit dem niemand ein großes Problem hat, dass es so getaggt wird, nicht den Tag finden, den von nun an jeder zu nutzen hat.

Wenn SC nur source:maxspeed taggt, dann beschweren sich die einen, wenn SC nur maxspeed:type taggt, dann beschweren sich die anderen.
Die dritte Alternative, mal hier das eine und mal dort das andere zu taggen, nur um keinen Shitstorm auszulösen, kommt für mich nicht in Frage: Es ist ja nicht so, dass es implizite Geschwindigkeitsbegrenzungen in GB, CZ, RO, RU,… nicht, es stattdessen dort “was anderes” gibt, sondern es ist genau das gleiche! OpenStreetMap ist ein globales Projekt, da kann man nicht sagen, dass man hier diesen und dort jenen Tag für die gleiche Sache verwenden soll und das dann “local community consensus” nennen. Wir lassen ja auch nicht zu, dass - was war das noch? - irgendwo in Lateinamerika oder so? - highway=calle getaggt wird.
Naja, ich denke ich weiche jetzt auch vom Thema ab. Ist natürlich eine grundsätzliche Sache, aber das wär jetzt erstmal mein Grund, warum es für mich nicht in Frage kommt, je nach Präferenz der lokalen Community unterschiedliche Tags für die gleiche Sache zu nutzen. So funktioniert OSM einfach nicht.
Entweder gibt es einen globalen Konsens, oder es gibt keinen Konsens.

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.