StreetComplete - die nächste suboptimale App

Nur daß Apps wie StreetComplete da schon eine Richtung für deren Anwender vorgeben.

Ich denk’ “technischer” wird’s nicht mehr. Hier wollte ich nur den “Footprint” beschreiben, den der Output der App an meinem Ende zu hinterlassen scheint. Vielleicht sieht es jemand ähnlich und möchte Konsequenzen für die Entwicklung der App oder den Umgang mit den Resultaten daraus ziehen (wenn nicht, auch o.k. - das von mir betrachtete Gebiet ist ohnehin zu klein um statistisch relevant zu sein).

Für mich ist die eigene Nutzung der App ohnehin keine Option und die produzierten SC-Detailinseln anderer hier im Umfeld gehen (noch) im QS-Grundrauschen unter.
Bis sich das ändert, werd’ ich die Zeit für eigenen OSM-Input verwenden oder Neumapper ermutigen bei der Stange zu bleiben :wink:

Gruß
Stephan

Was genau ist denn nun mit einer Detail-Insel gemeint? Dass in einer eher wenig detailliert gemappten Gegend einige wenige Ecken sehr detailliert gemappt sind? Falls ja, hat das ja nur am Rande mit StreetComplete zu tun. Ich bearbeite im Moment z.B. auch vor allem die Gegenden um meine Wohnung und meinen Arbeitsplatz, weil ich die besonders gut kenne und jeden Tag sehe, wodurch diese deutlich detaillierte werden als die Straßen drumherum.

Und glaubst du, andere Editoren machen das nicht? Interessant dazu ist der alte Vortrag “Wer ist der Boss bei OSM” in dem Frederik Ramm auch selbst deutlich sagt, dass er als Entwickler vom JOSM Editor am meißten Einfluss hat ausüben können.

https://www.youtube.com/watch?v=QDt_EB-pQKA&t=15m43s

Das ist halt eben drum der Fall, weil die sonstige OSM Struktur so unreguliert ist.

Sind das Fehlbedienungen in StreetComplete?

Eher nicht. Die Objekte sind als building=house getaggt. Das SC da nach der Adresse fragt ist so in Ordnung. Und wenn es wirklich Garagen sind ist der Hinweis doch auch korrekt.

Nein. Das ist dem geschuldet, dass so ziemlich alles mit building=yes gemappt ist, und in dem Adressen/Hausnummer Quest das halt abgefragt wird. Und der Ausweg ist wohl nur eben eine Notiz zu hinterlassen, um so z.B. daraus ein building=shed oder was auch immer zu machen, was ja eher keine Adresse hat.
PS: mich wundert es ja fast schon, das noch keiner auf die Idee mir addr=none gekommen ist :stuck_out_tongue: :laughing:

Kann man in solchen Fällen nicht einfach auswählen “das Objekt hat keine Hausnummer” ohne eine Notiz erstellen zu müssen ?
Ich kann das leider nicht selbst testen, da StreetComplete auf meine Handy (Android 4…) nicht läuft.

Die drei verlinkten Notes weisen alle auf Gebäude mit house-Attributen. Meines Wissens fragt StreetComplete nicht nach Hausnummern wenn building=yes drin ist. Ganz unbegründet ist sowas dann also nicht.

Nichtsdestotrotz kann der User auch in der App angeben, dass es keine Hausnummer hat. Allerdings dürften dann die anderen Informationen unangetastet bleiben.

Da waren auch noch unvollständige Adressen an allen 3 Neben-Gebäuden, die aber keine eigenen Adressen haben. Das hatte ich nicht nachgeschaut, jetzt aber abgeändert.

Hätte man die falschen, unvollständigen Adressen in Streetcomplete auch löschen können ?

Löschen kann man da nichts. Man kann die Daten auch garnicht sehen. In SC sieht man nur einen ‘Quest’ den man beantwortet, gemäß den Vorgaben, oder man hinterlässt eine Notiz. Und so weit ich weiß, wird bei building=yes nicht nach Hausnummern gefragt.

Ja sorry, das mit building=yes war mein Fehler, das War in der Urversion mal, wurde aber weiter eingeschränkt.

StreetComplete 5.2

Warum wir maxspeed:type statt source:maxspeed verwendet? (203106 zu 1 221 412)?

Ich finde es nicht richtig mit einer APP einfach Schlüssel durchzusetzen. Dann sollte es auf GB beschränkt genutzt werden.

Oder sie soll es prinzipiell auslassen - wie auch an jeden highway cycleway:both=no, Hauptsache man trägt was ein, obwohl surface; lit; smoothness; … fehlt - ist man vor Ort gewesen?

Ähm wegen StreetComplete wird maxspeed:type taggen … du erinnerst dich?

Das Thema ist genau so vertrocknet wie Sachsen - obwohl in DE alle (fast alle) für Original source:maxspeed sind.

Ich finde, manche APP’s könnte man sich sparen. Wir haben genug Editoren, für die die sich wirklich interessieren.

Also einfach so weiter machen?

Wie meinst du das konkret mit “einfach so weiter machen”? (Also worauf bezieht sich das? Source:maxspeed oder die Apps?)

Ich für meinen Teil nutze zu 98 % JOSM. Manchmal finde ich SC durchaus sehr nützlich. Wenn ich irgendwo unterwegs bin habe ich nicht immer Lust alles akribisch zu dokumentieren. Beispielsweise sämtliche Straßenbeläge, um zu Hause zu schauen wo etwas fehlt. Mit der App sehe ich direkt wo etwas offen ist und kann es eintragen. Vielleicht auch Themen die sonst nicht in meinem Aufmerksamkeitsbereich sind.

Die hier (weiter oben) aufgeführten Argumente sind vielfach schlüssig und werden mich auf jeden Fall in meiner zukünftigen SC-Nutzung beeinflussen. Die App deswegen grundsätzlich zu verteufeln halte ich für falsch.

Wobei ich persönlich auch der Meinung bin, dass source:maxspeed und maxspeed:type zwei verschiedene Paar Schuhe sind. Das zweite sagt, auf welcher Grundlage das Tempolimit besteht, das erste dagegen sagt, woher ich als Mapper weiß, dass diese Grundlage dort anzuwenden ist.

Anders ausgedrückt: maxspeed:source=DE:urban bedeutet „Ich habe diesen Way maxspeed=50 getaggt, weil das in Deutschland die innerörtliche Höchstgeschwindigkeit ist“. Das ist keine logisch zulässige Begründung. Es fehlt die Information, woher ich überhaupt weiß, dass dieser Way innerorts liegt UND dort keine abweichende Regelung vorliegt.

Meine Denkweise:

Wenn ich als Mapper OTG ein Ortseingangsschild sehe, dann ist für mich alle Information, die ich aus diesem Schild ziehe, source=survey. survey heißt: ich war vor Ort und habe die Verhältnisse selbst gesehen.

Auch maxspeed:source ist dann =survey, denn ich war dort und habe gesehen, dass da ein Ortseingang ist. Habe ich das Ortsschild nicht selbst, sondern nur mittelbar gesehen, etwa bei Mapillary, dann ist maxspeed:source=mapillary. Oder auf einem Foto auf Wikimedia Commons: entsprechend.

maxspeed:type dagegen enthält die Grundlage, auf der dieses Tempolimit Gültigkeit erhält – unabhängig von dem Weg, auf dem ich die Information erlangt habe, dass genau diese Grundlage hier anzuwenden ist.

Beispiele:

Habe ich auf Mapillary ein 70-Schild gesehen:
maxspeed=70 + maxspeed:type= + source:maxspeed=mapillary.

Habe ich OTG ein Ortsausgangsschild ohne neue Beschränkung gesehen:
maxspeed=100 + maxspeed:type=DE:rural + source:maxspeed=survey.

Habe ich einem Zeitungsartikel entnommen, dass der Steinweg ab 30.2.2018 Tempo-30-Zone ist:
maxspeed=30 + maxspeed:type=DE:zone30 + source:maxspeed=

Dann sind a) die Quelle der Information und b) die Grundlage des Tempolimits separat voneinander erfasst.

–ks

Da durch die APP maxspeed:type=* verwendet wird (m.E. unberechtigt) und ich mich (jahrelang) an source:maxspeed=* halte, werde ich maxspeed=* in “meiner Gegend” auch mit source:maxspeed=* verwenden.

Sollte eine Schlüsseländerung “beschlossen” werden. kann ganz leicht aus dem source:maxspeed=* ein maxspeed:type=* werden oder aus dem maxspeed:type=* ein source:maxspeed.

Das ist der ursprüngliche Gedanke für die Datenerstellung.

Alles andere sind zwar Hilfsmittel, wie schnell sind die überholt. Ich sehe in Mapillary ein Schild 30, was aber in den letzten Jahren schon lange abgebaut wurde, weil Straßenschilder viel Geld kosten - ist zumindest bei uns so. Und es gibt auch “Zeitungsenten” …- ich gehe dann dorthin und sehe nach.

Wasser auf meine Mühle. Wir brauchen im Tagging die Information, wo der Mapper seine Daten herbekommen hat, unabhängig davon, wie das Tempolimit rechtlich zustandekommt. Das lässt sich mit source:maxspeed und maxspeed:type abbilden. Es geht aber verloren, wenn man die rechtliche Grundlage ins source:maxspeed schreibt (wo es vom Sinn dieses Tags her überhaupt nicht reingehört – source=* ist immer die Antwort auf die Frage „woher wusste der Mapper das?“).

–ks

Ist korrekt und wird auch im Wiki so gesagt, nur hat es sich bisher halt nur in UK durchgesetzt.