StreetComplete - die nächste suboptimale App

Ist mir vorhin auch aufgefallen und finde ich ebenso unübersichtlich. In Berlin ein User - dem ich natürlich persönlich auch keinen Vorwurf mache - an zwei Stellen. Bsp.: http://tyrasd.github.io/latest-changes/ … 61/13.2558

Fürchte, es wird wenig passieren, ebenso wie bei das extreme Gegenbeispiel: die flächenmäßigen Riesen-CS der wheelchair map, bei denen achavi i.d.R. scheitert, mal lokal aufzuteilen, um sinnvolle QA betreiben zu können...

Nur zur (Hintergrund-)Info für Euch zwei: Diskussion bei github bzgl. den atomic commits 😉

PS: und daraus ist dann auch meine Frage nach Gamification in OSM entstanden...

Das ist wieder so ein Beitrag, der mich ratlos macht. Ich bin ja kein Anfänger, aber ich nichts, aber auch rein gar nichts kapiert. Ich werde wohl das Forum nach dem Motto lesen, wer mir nicht erklären will um was es geht, der ist auch nicht an meinen Gedanken interessiert.

@wegavision: Es geht darum, dass die Android App StreetComplete für jede (wirklich jede) einzelne Änderung je eine Änderung (Changeset) in die Datenbank hochlädt. Das wäre ungefähr so, wenn du

highway=track
tracktype=grade1

in

highway=track
tracktype=grade2␣<-␣Änderung
surface=grass␣<-␣neu
smoothness=bad␣<-␣neu

änderst, das aber eben nicht, wie du es vielleicht von anderen Editoren gewohnt bist, in EINEN Änderungssatz, sondern in DREI getrennten Änderungssätze in die Datenbank hochlädt.

Korrektur: streng genommen ist es zwar nicht ganz so (außer surface und smoothness sind zwei getrennte Aufgaben in dieser App), weil z.b. beim Erfassen von Stockwerken eines Hauses durchaus in EINEM Änderungssatz hochgeladen wird, aber eben für jedes Haus einzeln. (Würde ich das hier für meinen Ort tun, ca. 1.000 Häuser, dann wären das eben 1.000 Änderungssätze.)

Und das o.g. Eingangsbeispiel bezog sich eben darauf, dass in einem Stadtviertel, in dem es natürlich viele Straßenabschnitte (aufgetrennte ways) gibt, die Oberfläche für jeden Straßenabschnitt hinzugefügt, aber eben pro Straßenabschnitt einzeln hochgeladen wird. Normalerweise würde man ja sich das Stadtviertel im Editor vornehmen, alle Änderungen vornehmen und einmal auf Speichern klicken und das in einem Änderungssatz hochladen.

Und ich denke immer ich mache einen Fehler, wenn ich eine Korrektur nach 2-3 Minuten in einem neuem Änderungssatz "nachlade" ...

geri-oc wrote:

Und ich denke immer ich mache einen Fehler, wenn ich eine Korrektur nach 2-3 Minuten in einem neuem Änderungssatz "nachlade" ...

Ich habe flüchtig einen Blick auf die Größe deiner Änderungssätze geworfen und wüsste nicht, was da zu kritisieren wäre.

Harald Hartmann wrote:

Nur zur (Hintergrund-)Info für Euch zwei: Diskussion bei github bzgl. den atomic commits 😉

Da gibt es ein paar interessante Kommentare, v.a. von woodpeck und Nop.

Jo, ich hab mal auf GitHub geantwortet. Keine Sorge, ich will hier niemandem vor den Karren fahren.
Mir war bis heute u.a. nicht bewusst, dass QA tools Probleme haben, viele minimale Changesets sinnvoll darzustellen. Macht ja keinen Sinn wenn sich OSM tools gegenseitig behindern.

westnordost wrote:

Jo, ich hab mal auf GitHub geantwortet. Keine Sorge, ich will hier niemandem vor den Karren fahren.
Mir war bis heute u.a. nicht bewusst, dass QA tools Probleme haben, viele minimale Changesets sinnvoll darzustellen. Macht ja keinen Sinn wenn sich OSM tools gegenseitig behindern.

Servus westnordost,
Danke, dass Du Dich gemeldet hast, an den Karren wollen wir uns (natürlich) alle nicht fahren ;-)
das mit der "Seuche" kommt vielleicht vom Mapsme-Frust und "Errungenschaften" anderer Apps,
die (meiner Meinung nach) im Moment mehr Probleme als Freude erzeugen.

Ich denke Dir ist klar geworden wo die Problematik liegt und freue mich auf kommende "Sammel-CS"
Gruss derBeKri

Hallo BeKri,

könntest Du bitte einen freundlicheren/sachlicheren Titel als StreetComplete die nächste Seuche ? 124 CS in 43 Minuten wählen? (Hintergedanke: Man findet es in Zukunft leichter mit den Suchmaschinen, wenn einschlägige Suchbegriffe im Titel auftauchen, weil man einen anderen App-Entwickler auf Fallen hinweisen möchte.)

Viele Grüße

Michael

Servus Michael,

es war klar, dass im Zeitalter des political correctness es "ganz böse" ist
das Wort Seuche zu benutzen, aber Du darfst Dich gerne mal hier umsehen
http://tyrasd.github.io/latest-changes/ … 38/11.5212
um mir erklären mit wieviel Millionen Einzel-CS es jetzt weitergeht,
bis sämtliche Strassenschnuppsel mit asphalt, Gebäude mit level etc. versehen sind.

Wie würdest Du das freundlich und sachlich nennen ?

Servus derBeKri

@bekri, kannst du bitte Nakaners Post nochmal aufmerksam lesen, vor allem das nach dem "Hintergedanke" ? Da kommt mir der Eindruck auf, du hast nur darauf gewartet, dass jemand auf deinen provokativen Titel reagiert. Kein schöner Stil. Wie Nakaner schon sagte, geht es vor allem darum, dass Thread Titel ausreichend Informativ über den Inhalt informieren.

Und ich find es zusätzlich auch nicht Hilfreich gleich einen so provokativen Stil anzuschlagen. Mit freundlich und sachlich ist man erst einmal immer besser bedient. (edit: der restliche Beitrag war ja im Gegensatz zum Titel ja auch sachlich und informativ)

Hallo zusammen,

ich benutze natürlich einen provokanten Titel, damit darauf reagiert wird.
Zitat: " Mit freundlich und sachlich ist man erst einmal immer besser bedient." ist sicher richtig,
ABER: ich betrachte mich als lang genug dabei und alt genug
das ich mir dabei auch was gedacht haben, diesen Titel zu wählen.

Ich schlage Folgendes vor:

1. Ihr schaut Euch die letzten Beträge der letzten 3 ! Tage folgender Accounts an
und erklär mir wie das weitergehen soll.

http://www.openstreetmap.org/user/rastabob/history
http://www.openstreetmap.org/user/smokephil/history
http://www.openstreetmap.org/user/DwyaneWade/history
https://www.openstreetmap.org/user/Brai … ck/history
https://www.openstreetmap.org/user/Pin14/history
https://www.openstreetmap.org/user/silviof/history
https://www.openstreetmap.org/user/yain … mi/history
https://www.openstreetmap.org/user/mobeki/history
https://www.openstreetmap.org/user/MPuls/history

So nebenbei:
Local User ToniE versucht schon, die ersten AddOpeningHours Beiträge zu fixen,
https://www.openstreetmap.org/changeset/47291950
ich hab ihm empfohlen vorsorglich in Rente zu gehen ...

Ihr dürft Euch gerne auch die anderen AddOpeningHours-Beiträge ansehen ...
Viel Spaß 😄 Chips nicht vergessen ...

2. Ich wenn ich es sehr ungern tu, komme ich Eurem Ansinnen nach und
erwarte Eure "freundlichen und sachlichen" Vorschläge für eine Umbenennung der Titelzeile 😐

Ansonsten mache ich jetzt mein (virtuelle) Karton mit den Chipstüten auf
und schaue zu, wie OSM langsam zugeschissen wird.

Wir hatten (aus meiner Sicht) in letzter Zeit "sehr viel Spaß" mit verschiedene Apps:
Wheelmap: es werden doppelt POI mit Halbangaben zu vorhanden POI erzeugt,
die vielfach daneben/ völlig falsch plaziert wurden
Mapsme (liebevoll vom mir als LECKS me am A... bezeichnet)
Da wird dann schon mal ein Brunnen zum Schinkenverkauf deklariert ...
Ich betrache persönlich gefühlte 80 % der Beiträge als einfach nur löschenswert
PoGo: brauchen wir glaube ich nicht ausdiskutieren ...

StreetComplete bezeichne ich als die nächste Seuche, ich stehe zu dieser Bezeichnung.
(so sehr ich im übrigen das Konzept/ die Idee begrüße)

Es mag "easy" sein, mal schnell mit irgendwelchen Baukästen ne App zu schaffen,
aber die "Beiträge" der letzten Zeit betrachte ich als (freundlich und sachlich formuliert) sehr zweifelhaft.
Ich muss nicht alles begrüßen, was gut gemeint, aber schlecht umgesetzt ist.
Dafür erlaube ich mir ein deutliche, sogar provokante Meinung.

Ich erwarte durchaus mehr Verantwortung der Entwickler und auch der Nutzer vom Apps
Eine beleidigte Reaktion wie zB. hier
https://www.openstreetmap.org/changeset/46724101
betrachte ich schlicht als unpassend.

Und OSM sollte sich dringend langsam etwas überlegen, wie es solchen "Beiträgen" begegnet.
Denn für diese Beiträge muss es auch immer eine "Putze" geben, die den Dreck wieder wegräumt ...

Mit freundlichen und hoffentlich sachlichen Grüßen
derBeKri

BeKri wrote:

... So nebenbei:
Local User ToniE versucht schon, die ersten AddOpeningHours Beiträge zu fixen,
https://www.openstreetmap.org/changeset/47291950
ich hab ihm empfohlen vorsorglich in Rente zu gehen ...

Es ist aber m.E. kein Fehler die Zeit in eine "richtige" Reihenfolge zu bringen:
Mo-Th 07:45-10:00,11:15-13:30; Fr 07:45-10:00,11:15-13:00
statt
Mo-Th 11:15-13:30,07:45-10:00; Fr 11:15-13:00,07:45-10:00

EDIT:
Für die Zugriffe der Apps muss es doch eine "Genehmigung" durch OSM geben?
Das war ja auch schon mit MapsMe mit den doppelten Punkten ärgerlich.

Ich stelle mir wie geri-oc in seinem Edit dieselbe Frage.

Gibt es eigentlich für Apps, speziell solche die Daten erstellen und ändern können, keine Genehmigungspflicht? Wenn man neue Tags einführen oder einen automatischen Edit durchführen will, muss das durch die Community abgesegnet werden (und wehe man tut das nicht, dann folgt ziemlich schnell die Revert-Keule 😉).

Für Apps scheint es das nicht zu geben. Hier wäre vielleicht auch eine Regelung nötig, wonach der Community die App vor Produktivsetzung (evtl. auch bei jeder größeren Änderung) vorgestellt werden muss. Dabei muss dann dargelegt werden, was sie macht und welche Mechanismen benutzt werden. In diesem Fall hätte man möglicherweise noch vor Produktivsetzung feststellen können, dass viel zu viele Changesets generiert werden und das einen negativen Einfluss auf andere Tools hat. Oder man hätte gesehen, dass Öffnungszeiten falsch herum eingetragen werden (können).

Nakaner wrote:

Hallo BeKri,

könntest Du bitte einen freundlicheren/sachlicheren Titel als StreetComplete die nächste Seuche ? 124 CS in 43 Minuten wählen? (Hintergedanke: Man findet es in Zukunft leichter mit den Suchmaschinen, wenn einschlägige Suchbegriffe im Titel auftauchen, weil man einen anderen App-Entwickler auf Fallen hinweisen möchte.)

Viele Grüße

Michael

1+

Eine App als "Seuche" zu bezeichnen betrachte ich nicht allein als provokant, sondern als schlichtweg arrogant (egal wie alt und wie lang dabei der Ersteller ist)! Auch ich bin gern mal Querulant,das geht aber nicht!

Dies dient keinesfalls einer vernünftigen Kommunikation. Dabei erachte ich die sehr besonnene und kompromissbereite Haltung von westnordost lobenswert!

Gruß Uwe

na soweit ich weiß, macht ja sizusagen nicht die App/der Editor einen edit, sondern du bzw. dein Account. Das geht über die OSM API und der Editor sagt mit created_by lediglich Bescheid wer er ist. Da könnte man auch einfach JOSM reinschreiben obwohls nicht stimmt.

Aber Nakaner hat im Github Issue Thread ja nun auch schon angedeutet, dass er die DWG/OWG um eine Sperre bitten wird, wenn das Problem nicht beseitigt wird. Weiß nicht ob es da schon einen etablierten Weg gibt, aber OWG/DWG könnten evtl. edits mit dem Tag created_by=X blockieren. Das würde eine App aber auch nicht daran hindern da dann einfach einen neuen Namen zu verwenden wenn sie es darauf anlegt.

Hallo,

aixbrick wrote:

Ich stelle mir wie geri-oc in seinem Edit dieselbe Frage.

Gibt es eigentlich für Apps, speziell solche die Daten erstellen und ändern können, keine Genehmigungspflicht? Wenn man neue Tags einführen oder einen automatischen Edit durchführen will, muss das durch die Community abgesegnet werden (und wehe man tut das nicht, dann folgt ziemlich schnell die Revert-Keule 😉).

Ich habe westnordost vorher auf Github nochmal ermahnt, sich schleunigst um die Problemlösung zu kümmern und eine vorübergehende Sperre der App (nicht ihrer Benutzer, denn diese sind nicht schuld) angedroht, wenn ich innerhalb von 48 Stunden keine Fortschritte/Bemühungen erkenne. Das heißt nicht, dass es bis dahin behoben sein muss. Wenn aber die Behebung nicht in Angriff genommen wird und stattdessen die Zeit in andere Dinge im Code gesteckt wird, die weniger wichtig sind, halte ich eine Sperre als Druckmittel für angemessen. Mir tut es selber leid, mit der bösen Keule zu drohen, aber wenn das Problem seit drei Tagen bekannt ist und in zwei Tagen wir so weit sind wie vor drei Tagen, dann …

Wir hatten letztes Jahr mal den Amenity-Editor bis zum Release der nächsten Version gesperrt, ohne seinem Entwickler vorher eine Reparaturfrist einzuräumen. Da war aber der Schaden weitaus größer und mit dem Länge-Breite-Vertausch-Bug von JOSM vor Urzeiten vergleichbar.

Hakuch wrote:

Aber Nakaner hat im Github Issue Thread ja nun auch schon angedeutet, dass er die DWG/OWG um eine Sperre bitten wird, wenn das Problem nicht beseitigt wird. Weiß nicht ob es da schon einen etablierten Weg gibt, aber OWG/DWG könnten evtl. edits mit dem Tag created_by=X blockieren. Das würde eine App aber auch nicht daran hindern da dann einfach einen neuen Namen zu verwenden wenn sie es darauf anlegt.

Wenn die App OAuth nutzt, werden deren Schlüssel deaktiviert. Das ist letzten Herbst beim Amenity Editor geschehen.

aixbrick wrote:

Für Apps scheint es das nicht zu geben. Hier wäre vielleicht auch eine Regelung nötig, wonach der Community die App vor Produktivsetzung (evtl. auch bei jeder größeren Änderung) vorgestellt werden muss. Dabei muss dann dargelegt werden, was sie macht und welche Mechanismen benutzt werden. In diesem Fall hätte man möglicherweise noch vor Produktivsetzung feststellen können, dass viel zu viele Changesets generiert werden und das einen negativen Einfluss auf andere Tools hat. Oder man hätte gesehen, dass Öffnungszeiten falsch herum eingetragen werden (können).

Überlegenswert wäre eine Richtlinie mit Empfehlungscharakter, die weniger streng als die Import-Richtlinie ist und im Kern aus einem "Zertifizierungsprozess" (pfui, ich hasse dieses Wort, aber Review ist Englisch) besteht, bei dem erfahrene Leute einer Anwendung attestieren, dass sie bestimmte Kritierien besteht (z.B. korrekte Tag-Behandlung beim Umdrehen von Ways, angemessener Umgang mit Relationen, …). Es sollten aber nur freie Anwendungen zertifiziert werden. Wer nicht zertifiziert ist, muss damit rechnen, dass seine Anwendung bei ausreichend schwerwiegenden Problemen mehr oder minder unangekündigt vorübergehend gesperrt wird. Das würde die Nutzer stören und gerade bei Anwendungen die sich an Nicht-Mapper richten und keine OSM-Erfahrung verlangen, zu schlechten Bewertungen führen ("Die scheiß App stürzt ab, wenn ich etwas speichern will").

Ich spreche mich jedoch ausdrücklich gegen eine Genehmigungspflicht aus, weil diese jegliche Innovation hindert und nicht im Interesse des OSM-Projekts ist.

Viele Grüße

Michael

Nakaner wrote:

Ich spreche mich jedoch ausdrücklich gegen eine Genehmigungspflicht aus, weil diese jegliche Innovation hindert und nicht im Interesse des OSM-Projekts ist.

Seh ich auch so, der Schaden und Aufwand wäre viel größer als bei gelegentlchen Problemen einzugreifen. Dass man ja einfach über den oauth schlüssel sperren kann hab ich garnicht bedacht 🙂

Hakuch wrote:

na soweit ich weiß, macht ja sizusagen nicht die App/der Editor einen edit, sondern du bzw. dein Account.

Auch nicht ganz richtig, denn einige Dienste nutzen einen Sammelaccount, über den alle Änderungen der Nutzer laufen, z.B. die Wheelmap. Frage mich, warum so etwas überhaupt zugelassen wird.

https://www.openstreetmap.org/user/wheelmap_visitor

Im Dezember hat sich der Autor der App schon positiv zur Idee "Kill Switch" geäußert, d.h. ein zentraler Schalter, der die App global deaktiviert. Vielleicht kann man die aktuelle Version ja auch am Upload von Änderungen hindern, so wie damals die 0.1.

https://forum.openstreetmap.org/viewtop … 51#p621351

SammysHP wrote:

Hakuch wrote:

na soweit ich weiß, macht ja sizusagen nicht die App/der Editor einen edit, sondern du bzw. dein Account.

Auch nicht ganz richtig, denn einige Dienste nutzen einen Sammelaccount, über den alle Änderungen der Nutzer laufen, z.B. die Wheelmap. Frage mich, warum so etwas überhaupt zugelassen wird.

https://www.openstreetmap.org/user/wheelmap_visitor

naja war ja nur um den technischen ablauf zu illustrieren, klar kann man das dann auch verhumbeutelt über einen account laufen lassen 🙂

SammysHP wrote:

einige Dienste nutzen einen Sammelaccount, über den alle Änderungen der Nutzer laufen, z.B. die Wheelmap. Frage mich, warum so etwas überhaupt zugelassen wird.

Es ist nicht erwünscht, weil es die folgenden Nachteile hat:

• bei Vandalismus/Copyrightproblemen kann man die problematischen nicht von den normalen Usern trennen
  
• Rückfragen sind nicht möglich
  

Im konkreten Fall der Wheelmap haben wir da bislang immer ein Auge zugedrückt, weil man dort ja nur sehr, sehr begrenzt Edits machen kann, und das Potential für Vandalismus relativ gering ist. Wenn man mit der Wheelmap umfassendere Änderungen machen will, muss man sich ja anmelden, das geht dann nicht mehr über den "visitor".

Bye
Frederik

Hui, was ist hier denn los.

Zum Thema Genehmigungspflicht ganz allgemein: Das ist in der Tat zurzeit so, dass nach meinen Information es keine gibt und dass generell nur in Notfällen (Programm macht OSM Daten kaputt) ein Programm gesperrt wird. Darüber habe ich mich auch gewundert, ich meine, dass dieser gutmütige Ansatz bisher so relativ problemlos funktioniert hat, finde ich bemerkenswert. Im positiven Sinne.

Mir tut es selber leid, mit der bösen Keule zu drohen, aber wenn das Problem seit drei Tagen bekannt ist und in zwei Tagen wir so weit sind wie vor drei Tagen, dann …

Puh, du hast vielleicht eine falsche Vorstellung davon, wie schnell Softwareentwicklung so geht. Erstensmal bin ich Vollzeit beschäftigt, SC mache ich also in meiner Freizeit. Die Version von StreetComplete, wie sie jetzt ist, hat mich anderthalb Jahre Arbeit gekostet. Und so viel drin ist da ja, wie du siehst, noch nicht.

Für die Implementierung brauche ich erstmal einen Plan, wie genau das umgesetzt werden soll, insofern sei da nochmal auf das Ticket verwiesen, ich kann da noch Input gebrauchen.

Zum Thema "böse Keule" und drohen: Ja, liest sich nicht schön. Aber ist schon okay, das kann man auch ganz sachlich und unemotional behandeln. Wenn das Feature so wichtig ist, dass die App geblockt werden soll, solange es noch nicht implementiert ist, dann stirbt ja auch niemand daran.

Unabhängig davon bin ich ehrlich gesagt grad etwas überstrapaziert von all dem Feedback (Bugs und Feature Requests) den ich seit etwa einer Woche bekomme. Vorher fast ein halbes Jahr fast nix, jetzt plötzlich pro Tag dutzende von Mails zu SC, von 5 auf 70 offene Tickets auf GitHub.

westnordost wrote:

Zum Thema "böse Keule" und drohen: Ja, liest sich nicht schön. Aber ist schon okay, das kann man auch ganz sachlich und unemotional behandeln. Wenn das Feature so wichtig ist, dass die App geblockt werden soll, solange es noch nicht implementiert ist, dann stirbt ja auch niemand daran.

Evtl hast du ja das hier überlesen:

nakaner wrote:

Wenn aber die Behebung nicht in Angriff genommen wird und stattdessen die Zeit in andere Dinge im Code gesteckt wird, die weniger wichtig sind, halte ich eine Sperre als Druckmittel für angemessen.

westnordwest wrote:

Unabhängig davon bin ich ehrlich gesagt grad etwas überstrapaziert von all dem Feedback (Bugs und Feature Requests) den ich seit etwa einer Woche bekomme. Vorher fast ein halbes Jahr fast nix, jetzt plötzlich pro Tag dutzende von Mails zu SC, von 5 auf 70 offene Tickets auf GitHub.

Ist alles eine Frage der Prioritäten. Ich würde mich in deiner Situation derzeit um nix anderes bemühen, als dieses Problem zu beseitigen.

Gruss
walter

@nakaner: +1

Eine Sperre um dieses nervende Verhalten der App zu verhindern, halte ich für durchaus angebracht. Zudem ist ja (mir) unklar, wie eine eventuell zügige Korrektur seinen Weg zu den Endusern findet. Bis die freiwillig updaten, vergeht ja auch noch einige Zeit.

Bin einer der "bösen" Münchner User - hab mich auch schon gefragt warum keine Changesets gebaut wurden, mir waren die Implikationen für Qualitätsmanagement nicht so ganz klar - hab die Nutzung jetzt erstmal auf Eis gelegt.

@westnordost: Klasse app! m.M. nach die "bequemste" Art, OSM edits on-the-go zu machen und insb. auch für Nutzer ohne großen Buy-in nutzbar.

Brainlessnick wrote:

@westnordost: Klasse app! m.M. nach die "bequemste" Art, OSM edits on-the-go zu machen und insb. auch für Nutzer ohne großen Buy-in nutzbar.

Dem kann ich nur zustimmen! Ich halte StreetComplete nicht nur für die bequemste, sondern auch für die schönste App für die mobile Datenerfassung.

Kopf hoch @westnordost: bin gespannt auf Version 0.6, die das Problem mit den CS löst!

Anstatt den Oauth key zu widerrufen könnte man ja auch schauen, ob eine Sperrung von Versionen <= x möglich ist. Dann könnten Nutzer von einer neueren Version die App normal nutzen, andere mit einer veralteten Version hingegen nicht.

Ich bin auch der Meinung, dass der Zugriff über die aktuelle Version möglichst schnell gestoppt werden sollte. In meiner Region gab es zwar noch keine Changesets darüber, aber wenn jemand durch die Stadt geht und dutzende CS mit je einer Änderung erzeugt, würde mich das schon ziemlich stören.

SammysHP wrote:

Anstatt den Oauth key zu widerrufen könnte man ja auch schauen, ob eine Sperrung von Versionen <= x möglich ist. Dann könnten Nutzer von einer neueren Version die App normal nutzen, andere mit einer veralteten Version hingegen nicht.

westnordost müsste sich halt einen neuen OAuth-Schlüssel holen, bevor er die neue Version freigibt. Das ist nichts Bürokratisches, sondern erfordert nur das Ausfüllen eines Formulars. Das ist im Wiki beschrieben. Es ist einfach. Ich habe es selbst schon gemacht, als ich mit JOSM über die Dev-API editieren wollte (Änderungssätze für ein Revertskript erzeugen).

Ich hatte mit ihm schon Mailkontakt, bevor ich hier nachgelesen hatte. Es wurde zwar schon genug drüber diskutiert, aber ich geb jetzt doch noch meinen Senf dazu:

Wie man hier sehen kann: http://tyrasd.github.io/latest-changes/ … 298/8.3376

Hat er mit der App auch bei der Reaktivierung von einem in letzter Zeit inaktiven Nutzer geholfen 😉

Finde den einfachen Ansatz wenn man unterwegs ist kurz was einzutragen echt super, mir fehlt ja oft die Kreativität zu checken, was in gut gemappten Regionen noch fehlt.

Edit: Krass, hab mal ein paar Städte angeschaut, z.B. Tübingen, da sind ja echt extrem viele im Lande mit der App unterwegs!
(Bzw. einige wenige recht fleißig)

So, ich habe mir jetzt einmal auführlich überlegt, wie ich das implementieren würde. Nachdem ich im GitHub Ticket nicht allzu viel Feedback bekommen habe, hier einmal zusammengefasst. Wer große Bedenken dagegen hat, der möge jetzt sprechen oder für immer schweigen.

Grundsätzlich sind drei Modi zu unterscheiden: Automatisch (Online), Automatisch im Wifi und Manuell (Offline).

Für jeden Aufgabentyp wird ein eigenes Changeset erzeugt. Dieser Changeset hat je nach Aufgabentyp als Kommentar eine kurze Beschreibung, zum Beispiel "Added street surfaces" (also statt pro Aufgabe).
So ist nach wie vor am Kommentar des Changesets sofort die Natur der Änderungen zu erkennen, gleichzeitig reduziert sich die Anzahl der einzelnen Changesets deutlich.

Zunächst für den automatischen Modus: Gelöste Aufgaben werden sofort innerhalb ihres jeweiligen Changesets hochgeladen. Existiert noch keiner oder ist dieser schon geschlossen worden, wird dieser on-the-fly erstellt.
Der Changeset wächst also während der "survey" des Benutzers und wird schließlich von der App geschlossen, nachdem der Benutzer 10 Minuten keine Aufgaben dieses Typs mehr eingetragen hat. Diese Dauer kann nach Bedarf angepasst werden, wird aber nie über 1 Stunde betragen, da er nach einer Stunde automatisch vom OSM Server geschlossen wird. Tatsächlich wird dieser Fall recht häufig eintreten, denn es ist wahrscheinlich, dass nach dieser Wartezeit die App selbst garnicht mehr läuft.*
(Die App muss sich also persistent pro Aufgabentyp die zugehörige changeset id und die Zeit des letzten Lösen einer Aufgabe dieses Typs merken.)

Der "Automatisch im Wifi" Modus verhält sich wie der Name schon sagt im Wifi wie der automatische Modus und außerhalb des Wifis wie der manuelle. Das heißt, kommt man (zurück) in ein Wifi, werden die gelösten Aufgaben zwar sofort hochgeladen, aber die zugehörigen Changesets erst nach der Wartezeit geschlossen.

Manueller Modus: Der manuelle Modus ist ein bischen wie man es von einem klassischem Editor kennt. Es wird nichts automatisch hochgeladen und wenn der Benutzer den "Hochladen" Knopf drückt, wird sofort für jeden Aufgabentyp ein Changeset geöffnet, die Änderungen übertragen und der Changeset geschlossen. Das bedeutet, wenn ein Benutzer ständig auf diesen Knopf drückt, dann sind die Changesets eben auch klein. Das hat er da selbst in der Hand, wie bei jedem anderen Editor auch.
Es wäre natürlich möglich, auch im manuellen Modus die Changesets nicht sofort zu schließen sondern erst nach der Wartezeit, ich denke aber das läuft zuwider der Erwartung der Benutzer, dass nach Druck auf den Hochladen-Button wirklich alles abgeschlossen ist (würde aber natürlich zu weniger Changesets führen).

• technisch wäre es möglich, dies auch nach Ableben der App zu machen (Android AlarmManager). Das ist etwas komplexer und kann später implementiert werden.
  

Hallo,

westnordost wrote:

Grundsätzlich sind drei Modi zu unterscheiden: Automatisch (Online), Automatisch im Wifi und Manuell (Offline).

Für jeden Aufgabentyp wird ein eigenes Changeset erzeugt. Dieser Changeset hat je nach Aufgabentyp als Kommentar eine kurze Beschreibung, zum Beispiel "Added street surfaces" (also statt pro Aufgabe).
So ist nach wie vor am Kommentar des Changesets sofort die Natur der Änderungen zu erkennen, gleichzeitig reduziert sich die Anzahl der einzelnen Changesets deutlich.

Zunächst für den automatischen Modus: Gelöste Aufgaben werden sofort innerhalb ihres jeweiligen Changesets hochgeladen. Existiert noch keiner oder ist dieser schon geschlossen worden, wird dieser on-the-fly erstellt.
Der Changeset wächst also während der "survey" des Benutzers und wird schließlich von der App geschlossen, nachdem der Benutzer 10 Minuten keine Aufgaben dieses Typs mehr eingetragen hat. Diese Dauer kann nach Bedarf angepasst werden, wird aber nie über 1 Stunde betragen, da er nach einer Stunde automatisch vom OSM Server geschlossen wird. Tatsächlich wird dieser Fall recht häufig eintreten, denn es ist wahrscheinlich, dass nach dieser Wartezeit die App selbst garnicht mehr läuft.*
(Die App muss sich also persistent pro Aufgabentyp die zugehörige changeset id und die Zeit des letzten Lösen einer Aufgabe dieses Typs merken.)

Der "Automatisch im Wifi" Modus verhält sich wie der Name schon sagt im Wifi wie der automatische Modus und außerhalb des Wifis wie der manuelle. Das heißt, kommt man (zurück) in ein Wifi, werden die gelösten Aufgaben zwar sofort hochgeladen, aber die zugehörigen Changesets erst nach der Wartezeit geschlossen.

Manueller Modus: Der manuelle Modus ist ein bischen wie man es von einem klassischem Editor kennt. Es wird nichts automatisch hochgeladen und wenn der Benutzer den "Hochladen" Knopf drückt, wird sofort für jeden Aufgabentyp ein Changeset geöffnet, die Änderungen übertragen und der Changeset geschlossen. Das bedeutet, wenn ein Benutzer ständig auf diesen Knopf drückt, dann sind die Changesets eben auch klein. Das hat er da selbst in der Hand, wie bei jedem anderen Editor auch.
Es wäre natürlich möglich, auch im manuellen Modus die Changesets nicht sofort zu schließen sondern erst nach der Wartezeit, ich denke aber das läuft zuwider der Erwartung der Benutzer, dass nach Druck auf den Hochladen-Button wirklich alles abgeschlossen ist (würde aber natürlich zu weniger Changesets führen).

Welche Vorteile erhoffst du dir davon, dass es mehrere Modi gibt und nicht nur den manuellen? Das erhöht doch nur deinen Implementierungsaufwand? Der Nutzer weiß wahrscheinlich am besten, wann er ein stabileres Netz erwartet, um die Daten hochladen zu können.

Dumme Frage eines Nicht-Nutzers deiner App: Kann die App Objekte in OSM anlegen? Dann solltest du ein automatisches Hochladen über wackelige Netzwerverbindungen vermeiden. OSM kennt keine Transaktionen, sprich wenn die Transaktion abbricht, erfolgt kein Rollback, sondern das, was geschrieben wurde, bleibt persistent und der Rest ist weg. Was geschrieben wurde, kannst du nur umständlich herausfinden. Wenn man dann einfach ein zweites Mal blind hochlädt, erzeugt man Objekte doppelt.

Viele Grüße

Michael

BeKri wrote:

Hallo zusammen,

ich benutze natürlich einen provokanten Titel, damit darauf reagiert wird.

Hallo BeKri,

Ich bemühe mich bisher immer, Sachliche Titel zu verwenden (gut, ab und an gehen auch bei mir die Nerven mal durch) und ich fahre damit bisher immer ziemlich gut. Es gibt genug Leute hier im Forum, die alles zumindest überfliegen und wenn nötig ihren Senf dazu geben (danke dafür). Von daher hatte ich bisher nie ein Problem, dass meine Probleme nicht gehört wirden wären.

Es ist vielmehr so, dass reißerische Titel dem Niveau des Threads schaden und damit auch der Antwortqualität. Von daher schneidest du dir damit auch ein Stück weit ins eigene Fleisch.

Grüße

Kann die App Objekte in OSM anlegen?

Nein

OSM kennt keine Transaktionen, sprich wenn die Transaktion abbricht, erfolgt kein Rollback, sondern das, was geschrieben wurde, bleibt persistent und der Rest ist weg.

Das ist nicht ganz richtig. Ein Changeset ist an sich keine atomare Transaktion, aber ein Diff upload innerhalb eines Changesets ist eine.

westnordost wrote:

So, ich habe mir jetzt einmal auführlich überlegt, wie ich das implementieren würde. Nachdem ich im GitHub Ticket nicht allzu viel Feedback bekommen habe, hier einmal zusammengefasst. Wer große Bedenken dagegen hat, der möge jetzt sprechen oder für immer schweigen.

Der erste Eindruck dieses Entwurfes ist sehr zufriedenstellen.

Grundsätzlich sind drei Modi zu unterscheiden: Automatisch (Online), Automatisch im Wifi und Manuell (Offline).

Die Feinheiten und Notwendigkeit dieser drei Modi beginne ich langsam zu erkennen (halt nur dann hochladen, wenn es nötig und auch technisch möglich ist und dabei Datenvolumen sparen) und hab da auch keine grossen Bedenken.

Alles was dabei hilft, die Anzahl der CS zu minimieren, ist äußerst hilfreich. Und wenn dann mal einer manuell ein Dutzend kleine CS hochlädt, ist das auch nicht so schlimm - das machen unsere Kollegen (und ich) auch gelegentlich so.

Auf jeden Fall ein Schritt in die richtige Richtung.

Gruss
walter

westnordost wrote:

Manueller Modus: Der manuelle Modus ist ein bischen wie man es von einem klassischem Editor kennt. Es wird nichts automatisch hochgeladen und wenn der Benutzer den "Hochladen" Knopf drückt, wird sofort für jeden Aufgabentyp ein Changeset geöffnet, die Änderungen übertragen und der Changeset geschlossen. Das bedeutet, wenn ein Benutzer ständig auf diesen Knopf drückt, dann sind die Changesets eben auch klein.

Die Darstellung ist so nicht richtig. In "jedem anderen Editor" bei OSM wird nur ein CS erzeugt, egal wie oft man auf den Speichern Knopf drückt.

So sollte sich auch Dein manueller Modus verhalten: Keine mehrfachen CS bei mehrfachem Speichern.

bye, Nop

@Nop: Stimmt, danke für die Korrektur, es ist also nur in der Hinsicht so wie jeder andere Editor, als dass die Changesets direkt hintereinander geöffnet, Änderungen übertragen und direkt geschlossen werden.

So sollte sich auch Dein manueller Modus verhalten: Keine mehrfachen CS bei mehrfachem Speichern.

Also du fändest es sinnvoller, wenn im manuellen Modus die CS nicht geschlossen werden?

Ehrlich gesagt war mir heute dazu noch was eingefallen, ich hatte es aber vergessen. Hier ist ein tolle Idee, ich denke ich werde das so machen, weil 1. weniger Changesets und 2. einheitlicheres Verhalten (und 3. dadurch weniger Code):
Im manuellen Modus gelten die gleichen Regeln wie im automatischen Modus. CS werden nur geschlossen, wenn 10 Minuten seit der letzten Änderung vergangen sind.
Kommt man also von einer Offline-Survey nach Hause, drückt man "Upload" und die CS werden alle schön im bulk übertragen, dann direkt geschlossen weil die letzte Änderung etwas länger her ist.
Ist man auf der Survey, hat nur aus welchen Gründen auch immer den automatischen Modus aus, macht es nichts wenn man ständig auf "Upload" drückt, denn die App merkt dass die letzte Änderung erst vor wenigen Minuten erfolgt ist und hängt die jeweiligen Änderungen an den offenen CS an.
Dann passt es auch besser mit dem Wifi-Modus. (Denn normalerweise wenn man zurück kommt ins Wifi, ist man eben zurück von der Survey und will alles abgeschlossen sehen)
Tadaa, alle sind bedient :-)

Die OSM-API schließt ein CS erst nach einer Stunde Inaktivität bzw. bei Dauereditieren nach 24 Stunden. Du kannst also Deine Zeiten noch erheblich ausdehnen und sicherheitshalber die Antwort der API auf eine Fehlermeldung für ein bereits geschlossene CS berücksichtigen.

Normale Straßen für den Autoverkehr sind zu 99% asphaltiert und die Oberfläche wird für das Autorouting in den Industrienationen nicht benötigt. Gleiches gilt für tracktype=grade1. Effektiver wäre eine nur eine Erfassung für fehlende Tracktype (grade1-5) bzw. die Oberflächenbeschaffenheit und evtl. Güte bei Wegen für Fußgänger und Radfahrer (footway, cycleway, foot=*, bicycle=*).

Ergänzend zu den Öffnungszeiten wären die (letzten) Leerungszeiten und Operator/Brand von Briefkästen interessant.

Die Erfassung von Dachform und Anzahl der Stockweke könnte in einen Vorgang zussammengelegt werden.

Bisher ist zwar Löschen/Neuanlegen von Objekten nicht vorgesehen. Dennoch wäre eine Möglichkeit sinnvoll, z.B eine geschlossene Gaststätte auf disused:amenity und old_name umtaggen zu können. Langfristig wäre auch eine Überprüfung von abgebauten Telefonzellen denkbar mittels last_check (oder ähnlich). Wenn die letzte Bestätigung/Edit länger als ein bis zwei Jahre zurückliegt, erscheint das Symbol wieder zur Überprüfung.

Ob eine Trennung der CS nach Edit-Art sinnvoll ist, wird sich noch zeigen. Nach einer Offline-Erfassung sollte bei einer CS-Trennung vor dem Hochladen vorsortiert werden.

Trotz der "Anlaufschwierigkeiten" sehe ich in der App ein großes Potential für OSM.

DD1GJ wrote:

Normale Straßen für den Autoverkehr sind zu 99% asphaltiert und die Oberfläche wird für das Autorouting in den Industrienationen nicht benötigt. Gleiches gilt für tracktype=grade1. Effektiver wäre eine nur eine Erfassung für fehlende Tracktype (grade1-5) bzw. die Oberflächenbeschaffenheit und evtl. Güte bei Wegen für Fußgänger und Radfahrer (footway, cycleway, foot=*, bicycle=*).

In Baden-Württemberg mag das vielleicht so sein, aber in Ostdeutschland ist innerorts der Anteil von Straßen mit schrecklichem alten Kopfsteinpflaster deutlich höher und diese Information trotzdem von Relevanz.

DD1GJ wrote:

Ergänzend zu den Öffnungszeiten wären die (letzten) Leerungszeiten und Operator/Brand von Briefkästen interessant.

solche vorschläge find ich auch gut, aber vielleicht finden sie in einem eigenen Thread oder im github issue mehr beachtung als hier wo der Thread mit der Seuche StreetComplete startet 🙂

DD1GJ wrote:

Trotz der "Anlaufschwierigkeiten" sehe ich in der App ein großes Potential für OSM.

dito, hat mich sehr gefreut endlich mal eine App mit einem so einfachen Konzept nutzen zu können, soetwas in der Art hatte ich mir eigentlich immer gewünscht. Wenn diese Changeset Problematik erledigt ist und das Ding stabil läuft wird es bestimmt noch einen guten Beitrag zum mappen leisten.

DD1GJ wrote:

Normale Straßen für den Autoverkehr sind zu 99% asphaltiert und die Oberfläche wird für das Autorouting in den Industrienationen nicht benötigt. Gleiches gilt für tracktype=grade1. Effektiver wäre eine nur eine Erfassung für fehlende Tracktype (grade1-5) bzw. die Oberflächenbeschaffenheit und evtl. Güte bei Wegen für Fußgänger und Radfahrer (footway, cycleway, foot=*, bicycle=*).

Bei unclassified- und service-highways kann es durchaus auch in BW vorkommen, daß diese nicht geteert sind. Hier erfasse ich grundsätzlich surface und - fürs Fahrradrouting - auch smoothness, ebenso bei path ...

Grüße aus Oberschwaben

DD1GJ wrote:

Normale Straßen für den Autoverkehr sind zu 99% asphaltiert und die Oberfläche wird für das Autorouting in den Industrienationen nicht benötigt. Gleiches gilt für tracktype=grade1.

Sehe ich nicht so.
Gerade in Altstadtbereichen gibt es sehr viele gepflasterte Straßen, auch viele Anwohnerstraßen sind gepflastert.
Autobahnen sind oft betoniert, deshalb gilt dort im Sommer oft Tempo 80, wegen aufplatzendem Beton.
grade1-Feldwege sind oft nicht asphaltiert, sondern betoniert.
unclassified sind gerne auch mal nicht befestigt...

(zur info: ich hab jetzt den Titel geändert, aufgrund der vorangegangenen Diskussion und da gezielte provokative Äußerungen hier nicht angebracht sind. Ich hätte mir mehr gewünscht, dass Bekri selbst handelt weil ich ungerne in andere Posts eingreife.)

Nop wrote:

Die Darstellung ist so nicht richtig. In "jedem anderen Editor" bei OSM wird nur ein CS erzeugt, egal wie oft man auf den Speichern Knopf drückt.

So sollte sich auch Dein manueller Modus verhalten: Keine mehrfachen CS bei mehrfachem Speichern.

Hmm: Bei JOSM wird standardmäßig (zumindest war es, meine ich, der Standard, als ich JOSM das erte mal eingerichtet habe), pro Upload ein Changeset erstellt und geschlossen. "Speichern" habe ich da noch nie benutzt, ehrlich gesagt. In iD wird auch jedes Mal beim Drücken von "Speichern" ein neues Changeset erzeugt und geschlossen. Habe es gerade noch mal ausprobiert.

TZorn wrote:

Hmm: Bei JOSM wird standardmäßig (zumindest war es, meine ich, der Standard, als ich JOSM das erte mal eingerichtet habe), pro Upload ein Changeset erstellt und geschlossen.

Man kann das allerdings in den Upload-Optionen einstellen. Ich hab das Schliessen nach dem Upload z.B. abgestellt und kann somit mehrere Uploads in einen Changegeset packen. Erst wenn ich "Datei/Offene Änderungssätze schliessen" macht, wird mein CS geschlossen.

Das mache ich idR., wenn ich Missing Boundaries verarbeite und jeweils ein Land in einem CS haben will - und wenn ich das mal vergesse, werd ich angesch... https://www.openstreetmap.org/changeset/47365222 😉

Gruss
walter

OSM kennt keine Transaktionen, sprich wenn die Transaktion abbricht, erfolgt kein Rollback, sondern das, was geschrieben wurde, bleibt persistent und der Rest ist weg. Was geschrieben wurde, kannst du nur umständlich herausfinden. Wenn man dann einfach ein zweites Mal blind hochlädt, erzeugt man Objekte doppelt.

Daran müsste meiner Meinung auch dringend gearbeitet werden. Weiters bestünde auch die Möglichkeit von Seiten der OSM-API ChangeSets von sich aus zu Gruppieren wenn Sie das gleiche Tag und den gleichen Benutzer innerhalb eines Zeitfensters beinhalten.
So würde von vornherein ein unerwünschtes Verhalten dieser Art von einer Applikation verhindert. Des weiteren könnte die API auch berücksichtigen das ChangeSets aufgespalten werden wenn sich die Länge und Breite des Ortes von einer anderen Änderung zu weit entfernt ist. Das würde das Wheelmap-Problem lösen.
Zusammengefasst: Wenn die Probleme von der API erst gar nicht ermöglicht werden, ist das Problem schon Zentral gelöst und muss nicht in jeder Applikation behandelt werden. Es ist deshalb aus technischer Sicht falsch Applikationen auszusperren weil die API von OSM Fehlverhalten zulässt. Es ist vielmehr ein Aufruf die API selbst zu berichtigen.

Hakuch wrote:

zur info: ich hab jetzt den Titel geändert

Was ist denn das gefährliche an den vielen CS? Wird die DB zu warm?

Ein sachlicher Titel für mich wäre: "Neue App erstellt pro Änderung ein Changeset" oder so.........

chris66 wrote:

Hakuch wrote:

zur info: ich hab jetzt den Titel geändert

Was ist denn das gefährliche an den vielen CS? Wird die DB zu warm?

wäre jetzt auch nicht meine persönliche Wortwahl gewesen, aber da es Bekri so wichtig war hab ich noch ein bisschen Brisanz ohne Provokation dringelassen 🙂

Hakuch wrote:

chris66 wrote:

Hakuch wrote:

zur info: ich hab jetzt den Titel geändert

Was ist denn das gefährliche an den vielen CS? Wird die DB zu warm?

wäre jetzt auch nicht meine persönliche Wortwahl gewesen, aber da es Bekri so wichtig war hab ich noch ein bisschen Brisanz ohne Provokation dringelassen 🙂

Servus Hakuch, Du kleiner Wtzbold,
das Du Deine Möglichkeiten als Admin ausnutzt,
eine Meinung, die Dir nicht pass in Deinem Sinne passend zu machst,
nun gut, Meinungsfreiheit ist halt nicht jedermann Sache.

Wenn Du aber schon die Provokations-Moral-Keule schwingst, dann solltest Du schon fähig sein,
eine angemessenen Titel zu wählen, also mal was RICHTIGES zu machen.
"gefährlich viele CS" hat mit "ein bischen Brisanz" recht wenig zu tun sondern ist einfach nur lächerlich.

Ich habe mich bei dem neue Titel an die Formulierung von DD1GJ angelehnt,
der die letzten Tage gut damit beschäftigt ist zu Bitten von der Nutzung der App abzusehen.
http://resultmaps.neis-one.org/osm-disc … &commented
(Hat fast was ansteckendes, epidemieartiges ... 🙁 )

Hakuch, Du schreibst das Du "ungerne in andere Posts eingreifst". Ich empfehle Dir dringend das in Zukunft auch zu lassen.
Ich bin fast geneigt Dich zur Abgabe Deiner Adminrechte zu bitten
da ich Dich für zu unreif halte mit dessen Rechten und Möglichkeiten passend umzugehen.

Mit wenig freundlichen Grüßen
derBeKri

BeKri wrote:

Hakuch, Du schreibst das Du "ungerne in andere Posts eingreifst". Ich empfehle Dir dringend das in Zukunft auch zu lassen.
Ich bin fast geneigt Dich zur Abgabe Deiner Adminrechte zu bitten
da ich Dich für zu unreif halte mit dessen Rechten und Möglichkeiten passend umzugehen.

Ich möchte mich nicht einmischen, aber vielleicht kann ich das gerade als Nur-Mitleser dieses Threads halbwegs unvoreingenommen beurteilen. Gerade beim bloßen Mitlesen sieht man, dass Hakuch den Titel keineswegs „mal eben kurz“ geändert hat, sondern erst nach mehreren Bitten, den Titel zu ändern, und erst, nachdem durch die konstruktiven Antworten des App-Erstellers deutlich geworden war, dass die aufmerksamkeitsheischende Provokation nicht (mehr) nötig ist. Auch dass er den Titel nicht ganz entschärft hat, sondern ein bisschen Schärfe dringelassen hat, zeigt eigentlich deutlich, dass Hakuch sich sehr um Ausgleich bemüht. Kurz, von außen gesehen: Hakuch ist sogar vorbildlich mit seinen Adminrechten umgegangen.

Chrysopras wrote:

BeKri wrote:

Hakuch, Du schreibst das Du "ungerne in andere Posts eingreifst". Ich empfehle Dir dringend das in Zukunft auch zu lassen.
Ich bin fast geneigt Dich zur Abgabe Deiner Adminrechte zu bitten
da ich Dich für zu unreif halte mit dessen Rechten und Möglichkeiten passend umzugehen.

Ich möchte mich nicht einmischen, aber vielleicht kann ich das gerade als Nur-Mitleser dieses Threads halbwegs unvoreingenommen beurteilen. Gerade beim bloßen Mitlesen sieht man, dass Hakuch den Titel keineswegs „mal eben kurz“ geändert hat, sondern erst nach mehreren Bitten, den Titel zu ändern, und erst, nachdem durch die konstruktiven Antworten des App-Erstellers deutlich geworden war, dass die aufmerksamkeitsheischende Provokation nicht (mehr) nötig ist. Auch dass er den Titel nicht ganz entschärft hat, sondern ein bisschen Schärfe dringelassen hat, zeigt eigentlich deutlich, dass Hakuch sich sehr um Ausgleich bemüht. Kurz, von außen gesehen: Hakuch ist sogar vorbildlich mit seinen Adminrechten umgegangen.

+1

Ok, jetzt bin ich mit dem Subjekt zufrieden. 😉
Dann schaun mer mal wie schnell der Entwickler die Äpp korrigieren kann.

Chrysopras wrote:

Hakuch ist sogar vorbildlich mit seinen Adminrechten umgegangen.

Find ich auch. Er war auch nicht nur der einzigste dem der Titel nicht so gut gefiel. Warum wurde der Titel nicht selbst geändert?

PS: Ich finde es gut, das es MOD und ADM gibt - war lange Zeit ja leider nicht so.

Chrysopras wrote:

Hakuch ist sogar vorbildlich mit seinen Adminrechten umgegangen.

+1

Leider entspricht es auch dem Standardmuster, nach dem Einschreiten eines Admins/Mods grundsätzlich als nächstes ihn anzugreifen und je nach Gusto sein Handeln, Kompetenz, Ethik und/oder Verstand in Frage zu stellen.

Von daher: Beenden wir die Metadiskussion und kommen wieder zum Thema zurück.

bye, Nop

Die OSM-QA-Abteilung (offizieller Name: Data Team) im Hause Mapbox hat es jetzt auch entdeckt. PlaneMad, der dort arbeitet, schreibt in seinem Benutzerblog darüber. https://www.openstreetmap.org/user/PlaneMad/diary/40801

wegen der ganzen ärgerlichen Metadiskussion (danke übrigens an die Vorredner) hab ich jetzt ganz den Überblick verloren. Ist das Problem jetzt praktisch schon ausgemerzt oder nur steht nur ein theoretischer Plan? Ist eine veraltetete Version immer noch in Nutzung oder wird die automatisch upgedatet/gesperrt?

Abgesehen von dem changeset Problem hat die App aber auch so scheinbar einen Nerv getroffen, dass viele Leute gerne damit rumziehen (kann ich auch selbst bestätigen). Es scheint sich zu lohnen, da gemeinsam Ideen zu investieren.

Der angesprochene Plan für die Implementation wird gerade von mir umgesetzt. Das sollte die nächsten Tage fertig sein. Dann habe ich mir überlegt dass ich einen RC hier im Forum poste, denn es gibt leider schon zu viele "Beta" User als dass ich diese kritischen Änderungen direkt auf eine solche Masse loslassen möchte.
Wenn nach ein paar Tagen keine Issues auffallen, veröffentliche ich 0.6 auf Google Play und F-Droid mit der geänderten Changeset-Mechanik.

Hallo,

Hakuch wrote:

wegen der ganzen ärgerlichen Metadiskussion (danke übrigens an die Vorredner) hab ich jetzt ganz den Überblick verloren. Ist das Problem jetzt praktisch schon ausgemerzt oder nur steht nur ein theoretischer Plan? Ist eine veraltetete Version immer noch in Nutzung oder wird die automatisch upgedatet/gesperrt?

westnordost ist dabei, einen besseren Umgang mit Änderungssätzen zu implementieren. Die Commits in seinem Github-Repository lassen das vermuten. Deshalb und aufgrund seiner Kooperationsbereitschaft hat man von einer Sperre des OAuth-Schlüssels abgesehen.

Hakuch wrote:

Abgesehen von dem changeset Problem hat die App aber auch so scheinbar einen Nerv getroffen, dass viele Leute gerne damit rumziehen (kann ich auch selbst bestätigen). Es scheint sich zu lohnen, da gemeinsam Ideen zu investieren.

Ja, die App ist wirklich sinnvoll und nützlich. Über die Aufgabenstellungen kann man sich streiten. Die App scheint bei einer Zielgruppe gut anzukommen, die uns gefallen dürfte – Leute, die inaktiv sind, aber wissen was OSM ist. Oder habe ich mich geirrt?

westnordost wrote:

Der angesprochene Plan für die Implementation wird gerade von mir umgesetzt. Das sollte die nächsten Tage fertig sein. Dann habe ich mir überlegt dass ich einen RC hier im Forum poste, denn es gibt leider schon zu viele "Beta" User als dass ich diese kritischen Änderungen direkt auf eine solche Masse loslassen möchte.
Wenn nach ein paar Tagen keine Issues auffallen, veröffentliche ich 0.6 auf Google Play und F-Droid mit der geänderten Changeset-Mechanik.

Du kannst uns ja einen Build zur Verfügung stellen, der die Dev-API nutzt. Sicherer geht es nicht. Vorher muss man aber einen Schwung Daten einer Gegend in die Dev-API kopieren (ist leichter gesagt als getan).

Viele Grüße

Michael, der gern noch motivierender schreiben würde und das alles ganz toll findet, dem aber die Worte dazu fehlen

Danke.

Ich würd mir bei der Aufgabe "Wie viele Stockwerke hat dieses Gebäude?" noch eine Kommastelle wünschen, damit der Kniestock auch berücksichtigt ist 🤔. Der fällt ganz unterschiedlich aus 🙄.

https://de.wikipedia.org/wiki/Kniestock

westnordost wrote:

Der angesprochene Plan für die Implementation wird gerade von mir umgesetzt. Das sollte die nächsten Tage fertig sein. Dann habe ich mir überlegt dass ich einen RC hier im Forum poste, denn es gibt leider schon zu viele "Beta" User als dass ich diese kritischen Änderungen direkt auf eine solche Masse loslassen möchte.
Wenn nach ein paar Tagen keine Issues auffallen, veröffentliche ich 0.6 auf Google Play und F-Droid mit der geänderten Changeset-Mechanik.

https://www.openstreetmap.org/changeset/47495777
https://www.openstreetmap.org/changeset/47495863

Build von heute morgen. Autoclose noch nicht getestet, aber sieht gut aus. Top!

miche101 wrote:

Ich würd mir bei der Aufgabe "Wie viele Stockwerke hat dieses Gebäude?" noch eine Kommastelle wünschen, damit der Kniestock auch berücksichtigt ist 🤔. Der fällt ganz unterschiedlich aus 🙄.

https://de.wikipedia.org/wiki/Kniestock

BITTE nicht:

Ist das nicht roof:levels?

https://wiki.openstreetmap.org/wiki/Key:building:levels

sieht keine Kommastelle vor!

-snip- (Gerry war schneller)

geri-oc wrote:

sieht keine Kommastelle vor!

Wo steht das?

http://wiki.openstreetmap.org/wiki/Prop … Koordinate

Zwischengeschosse lassen sich mit Komma-Werten ausdrücken. In Geschoss zwischen EG und 1. OG wäre demnach Level 0.5. Das selbe Prinzip lässt sich auch bei Treppenhäusern anwenden, vgl. Bild. Es sind bis zu zwei Nachkommastellen erlaubt.

und hier:

http://wiki.openstreetmap.org/wiki/DE:K … ommazahlen

miche101 wrote:

http://wiki.openstreetmap.org/wiki/Prop … Koordinate

Zwischengeschosse lassen sich mit Komma-Werten ausdrücken. In Geschoss zwischen EG und 1. OG wäre demnach Level 0.5. Das selbe Prinzip lässt sich auch bei Treppenhäusern anwenden, vgl. Bild. Es sind bis zu zwei Nachkommastellen erlaubt.

und hier:

http://wiki.openstreetmap.org/wiki/DE:K … ommazahlen

Du beziehst es von indoor-mapping.

Ich würde es von "außen" jedenfalls nicht einschätzen wollen, ob eine Mansardenwohnung level=0.25 und roof=level=0.75 ist. Die Kommazahlen sind in Diskussion ...

Die Levelangaben sollen der "vereinfachten Höhendarstellung im 3D" dienen. Deshalb verwende ich "ganze" Zahlen. Wer es genauer möchte sollte m.E. mit Höhenangaben in m,cm arbeiten.

geri-oc wrote:

Du beziehst es von indoor-mapping.

Das Stimmt, aber wenn das Gebäude äußerlich schon nicht in der Höhe stimmt wie soll es dann innen stimmen? Wie bokommt man dann z.B. einen Kniestock zusammen?

geri-oc wrote:

Die Levelangaben sollen der "vereinfachten Höhendarstellung im 3D" dienen. Deshalb verwende ich "ganze" Zahlen. Wer es genauer möchte sollte m.E. mit Höhenangaben in m,cm arbeiten.

Die f4map verwendet pro Level 3m. Dann gibt es es bei dir nur Gebäude mit 3, 6, 9, 12, 15m usw. Höhe? Da würde ganz schön viel über einen Kamm geschert, was sich in Wirklichkeit deutlich unterscheiden würde.

Wenn man mathematisch Runden würde ... dann schauen bei dir Gedäude von Level 1.5-2.4, alle dann Level 2, alle gleich aus? Also von 4,5m-7,2m alle gleich?

Moin,

miche101 wrote:

Wenn man mathematisch Runden würde ... dann schauen bei dir Gedäude von Level 1.5-2.4, alle dann Level 2, alle gleich aus? Also von 4,5m-7,2m alle gleich?

ja, bei f4map oder osm2world schon - wenn sie alle zwei Stockwerke haben.
Natürlich kann ein 3-Etagen-Neubau genauso hoch sein wie ein 2-Etagen-Altbau.
Genauso ist ein 2-Etagen-Haus mit Kniestock ggf. genauso hoch, wie ein 2-Etagen-Haus mit überhohem Erdgeschoss.
Beide würdest Du dann mit 2,5 einleveln? Welche Höhe würdest Du denn dann für einen level vorgeben, um die Nachkommastellen bestimmen zu können?

Grüße, Georg

GeorgFausB wrote:

Natürlich kann ein 3-Etagen-Neubau genauso hoch sein wie ein 2-Etagen-Altbau.
Genauso ist ein 2-Etagen-Haus mit Kniestock ggf. genauso hoch, wie ein 2-Etagen-Haus mit überhohem Erdgeschoss.
Beide würdest Du dann mit 2,5 einleveln?

Bei ungewöhnlichen Stockwerkhöhe die nicht dem Standard oder dem gewöhnlichen bauarbeiten entsprechen... ist es dann sowieso erforderlich das man die Höhe des Gebäudes auf eine andere Weise bestimmt. Eine Kirchturm kann man auch nicht mit Level bestimmen.

GeorgFausB wrote:

Welche Höhe würdest Du denn dann für einen level vorgeben, um die Nachkommastellen bestimmen zu können?

Die Höhe es Levels gebe ich nicht vor das macht die Karte... im Fall von F4map.com ist es z.B. 3m andere Karten verwenden vielleicht andere Werte.

Die Nachkommastelle wird geschätzt. Kniestock zur Höhe eines Stockwerkes... Also eine Relativer Wert.. z.B. halb so Hoch wie eine Stockwerk ist 0,5 🙂

Zu level mit Dezimalangaben:
Also osm2world macht das soweit ich sehe so das ohne 'height' in m die Level mit (ca) 3m multipliziert werden, die Anzahl Fensterreihen entspricht den Leveln.

Will man also Hohe Etagen darstellen (Altbau) muss man beide, building:levels und height angeben. Dann kann ein 3-Etagen Altbau auch mal 18m hoch sein, das Dach ist ja in height drinnen. Und hier kommt man schon dazu das der Editor für die komplette 3-D Bearbeitung vielleicht nicht umfangreich genug ist? Man müsste dann schon: building:levels, roof:levels und height eingeben können, evtl gleich auch roof:shape. Was ist mit colour (Dach, Wand)?

Das level Konzept ist ein einfaches, das sollte so bleiben (Ganzzahlen). Gerade da man beim eben mal vorbeigehen die Höhe in Metern nicht gut messen kann. Man kommt auf die Idee zwischen höhe-exakt und höhe-schätzung unterscheiden zu wollen. Level kann man dagegen leicht abzählen.
Ok, ein Hochparterre wo der Keller ein halbes Geschoss aus dem Boden ragt ist auch einfach und könnte 2,5 als Wert haben, aber ist das halbe dann unten (Keller) oder oben am Dach (hoher Kniestock). Hier braucht man also weitere tags.

(Aber eigentlich sollte das ein neues Thema sein)

miche101 wrote:

und hier:
http://wiki.openstreetmap.org/wiki/DE:K … ommazahlen

Bitte nicht alles durcheinanderwerfen. Da geht es um den Key "level" nicht "building:levels".
Ansonsten: separater Thread zu dieser Spezialfrage wäre besser gewesen.

@miche101: sag mal, nur weil du hier mit deinem Anliegen nicht weiter gekommen bist, versuchst du es hier, wo es um was anderes ging, gleich nochmal? ! 🙄

PS: so, und wo ist jetzt der viel gepriesene Admin?

Naja hier komm man echt nicht weiter... 🙄 Und wo das steht das man keine Nachkommastellen machen darf hat auch noch keiner mir gesagt.

Ich glaub ich geb es einfach 15 ein wenn ich 1.5 haben möchte und bearbeite es dann später mit JOSM nach.. wenn man es nicht anders haben möchte. 🙄

miche101 wrote:

Naja hier komm man echt nicht weiter... 🙄 Und wo das steht das man keine Nachkommastellen machen darf hat auch noch keiner mir gesagt.

Ich glaub ich geb es einfach 15 ein wenn ich 1.5 haben möchte und bearbeite es dann später mit JOSM nach.. wenn man es nicht anders haben möchte. 🙄

Lass das bitte, denn du trägst absichtlich falsche Daten ein, was ich als Vandalismus deute und entsprechend behandeln würde.
Und noch einmal ganz deutlich für dich:
level=* ist keine hilfsweise Höhenabgabe sondern erfasst die Geschosse als Ganzzahl ohne Nachkommastellen.

Ahemm das Tag heisst

a) building:levels

und hat

b) nichts mit dem level Tag zu tun.

Um die Verwirrung mal zurecht zu rücken:

level Tag ist dafür da z.B. POIs in Gebäuden fürs Indoor Tagging ein Stockwerk zuzuweisen, also Ganze Zahlen.

Die building:levels und roof:levels sind dazu da die Stockwerke z.B. fürs 3D Mapping als relative Höhe anzugeben. Hier sind auch Zahlen wie 1.5 un 0.5 möglich, wenn auch nur selten sinnvoll.

R0bst3r wrote:

Die building:levels und roof:levels sind dazu da die Stockwerke z.B. fürs 3D Mapping als relative Höhe anzugeben. Hier sind auch Zahlen wie 1.5 un 0.5 möglich, wenn auch nur selten sinnvoll.

Die Werte von building:levels sollten ganze Zahlen sein, da ja nicht nur die Höhe darüber abgeschätzt wird, sondern wie weiter oben erwähnt auch Dinge wie Fensterreihen u.ä. die Stockwerksangabe nutzen. Auch damit die Innen- und Außenansicht eines Gebäudes nahtlos zusammenpassen können ist das wichtig.

Ich verstehe zwar, dass man gerne komplexere Situationen abbilden möchte als das allein mit ganzzahligen Werten möglich ist. Dafür sollten aber neue Tags erfunden werden. Einfach Kommawerte zu nehmen führt zu dem Problem, dass der eine mit den Nachkommastellen einen Kniestock zum Ausdruck bringen will und der nächste z.B. ein teilweise überirdisches Kellergeschoss. Es braucht explizite Tags, bei denen solche Situationen voneinander unterscheidbar sind.

Vielleicht habe ich das überlesen, aber ist das ursprüngliche Problem (zuviele Changesets) eigentlich mittlerweile behoben? Wenn ja, wäre das gut zu wissen, damit man User, die evtl. noch die Version 0.5 verwenden, auf die neue Version hinweisen kann.

Sollte zumindest anders sein: https://forum.openstreetmap.org/viewtopic.php?id=57943

OK, sieht so aus.

(Ich gebe zu, in die anderen Foren hier schaue ich so gut wie gar nicht.)

Schön, dass man über einen Hinweis erfährt, dass man mit StreetComplete nun auch Hinweise erstellen kann...

Besteht allgemein Konsens darüber, dass Apps, die so etwas tun, dies auch im initialen Kommentar mit einem HashTag (ähnlich wie #mapsme) kenntlich machen (am besten mit Versionsnummer)?

Dann würde ich das als Issue auf github einstellen.

PS: Und vielleicht sollte man bzw. die App noch mehr kommunizieren, letztendlich bin ich auch nach der Antwort des Users immer noch ratlos ... ähnlich wie bei den ganzen offenen #mapsme "The place has gone or never existed." Hinweisen... 🤔

Ich wär dafür. Hier gibts auch Hinweise ala "kein Schild way #...."

Harald Hartmann wrote:

letztendlich bin ich auch nach der Antwort des Users immer noch ratlos

StreetComplete fragt nach der (fehlenden) Hausnummer bei bestimmten building=? Werten. Da das betreffende Gebäude eine Garage ist, ist building=house wohl falsch und würde zu building=garage geändert gehören. Dann würde StreetComplete wahrscheinlich auch nicht mehr nach der Hausnummer fragen.

Naja, das habe ich schon verstanden, aber für mich wäre es dann eher ein note/fixme direkt an dem Objekt, weil hier den anderen Mappern ja eine "direkte" Anweisung gegeben wird, bzw. könnte es der betreffende Mappe (> 100 Changesets) ja dann auch selbst ändern, und braucht im Gegensatz zu den mapsme Hinweisen eigentlich keine "zweite" Meinung...

ADD: und das direkte ändern der building Werte möchte der Autor der App aktuell nicht umsetzten.

Siehe Ticket. In der nächsten Version wird explizit die Frage die dem User gestellt wurde mit in die Note reingeschrieben, inklusive Link auf das Element um das es geht.

Schön, dass man über einen Hinweis erfährt, dass man mit StreetComplete nun auch Hinweise erstellen kann...

Das war möglich von Stunde 1 an.

Und während wir hier immer wieder kontrovers über implizite Geschwindigkeiten (source:maxspeed) taggen diskutieren, schafft StreetComplete Fakten , siehe dieses Beispiel .

geri-oc wrote:

Mir ist aufgefallen, das mit StreetComplete shelter=yes an hw= bus_stop eingetragen werden. Diese sind aber tw separat oder am pt=platform schon vorhanden. Auf Kommentar wurde geantwortet: das macht StreetComplete so: http://www.openstreetmap.org/changeset/51005954

Sollten nicht weniger neuere Editoren als die schon "bekannten, etablierten" die Änderungen der Datenbank vornehmen können?

Ich habe es fälschlicherweise bei der verkehrten App gepostet - https://forum.openstreetmap.org/viewtop … 05#p659205

Harald Hartmann wrote:

Und während wir hier immer wieder kontrovers über implizite Geschwindigkeiten (source:maxspeed) taggen diskutieren, schafft StreetComplete Fakten , siehe dieses Beispiel .

Was bringt es source:maxspeed zu taggen ohne ein maxspeed zu tagten?

Hatte den CS bereits kommentiert. Ich vermute einen Bug, denn Sinn macht das Tagging ja überhaupt nicht.

Wird wohl eher weniger helfen, und der User dir höchstenfalls antworten: StreetComplete macht das so... 😉
PS: mach doch lieber ein github Issue auf...

Moin!

ich habe diese App auch einmal ausprobiert und fand das eigentlich ganz interessant - aber eines finde ich fehl am Platz.

(Nachfolgendes auch auf die Gefahr hin, dass ich vorangegangenes überlesen habe)

Oftmals werden Hausnummern angemerkt wo keine sind. Damit diese Fragen nicht wieder auftauchen habe ich eine Note hinterlegt und ich dachte damit verschwinden diese Marker wie bei KeepRight.

Aber stattdesse wurden osm-notes angelegt. In der App bekam ich keinen Hinweis das diese daraus generiert werden finde ich den Weg unpassend. Wenn dann hätte ein Note am Objekt besser gefunden. Weiterhin steht dann nicht einmal in dem osm-note-Text das dieses von mir über die App versand wurde.

Vielleicht trifft diese Rückmeldung hier auf offene Ohren.

Vielleicht liegt es auch an meiner fehlerhaften Bedienung.

Gruß Jan

Bezüglich der Hausnummern gab es im Juni schonmal auf Github eine Diskussion. Mir waren in letzter Zeit auch ein paar mehr dieser "no housenumber"-notes aufgefallen und hatte deswegen selber mal geschaut. Zumindest bei mir im Raum sind bislang wohl aber eher weniger "noaddress=yes" entstanden, sondern eher Notes mit der non-information.

Über das Note-Erstellen kann ich nichts sagen, habe die App schon länger nicht mehr angeschaut.

Neuerdings mach StreetComplete Notes auf:
http://www.openstreetmap.org/note/1106472
http://www.openstreetmap.org/note/1106474

Diese surface habe ich nachgetragen. Der Note lässt sich aber nicht schließen. Ich finde die Erstellung einer Note durch StreetComplete falsch.

Habe jetzt noch einmal mit Chrome probiert und erhalte nun keinen Zugriff auf openstreetmap.org - soll mich authentifizieren, obwohl ich angemeldet bin. Auch mit FF funktioniert es nicht mehr. Wie kann ich mich auf OSM noch anmelden? (Ins OSM-Wiki komme ich und auf openstreetmap.org wird auch mein Profil angezeigt.)

wir unterbrechen die aktuelle dauermeckersendung für einen moment:

• • • breaking news ***
      

https://twitter.com/sotm/status/898910845857447937

Glückwunsch, well done!

Ebenso - Glückwunsch!

geri-oc wrote:

... keinen Zugriff auf openstreetmap.org - soll mich authentifizieren ...

Anmeldung und Note erledigen funktioniert (wieder) - Fehler war eine falsche (nachgehende) Computer-Uhrzeit ...

Hi,

ich bin grade auf diesen Thread gestoßen und hab mir die App direkt auch runtergeladen.

Ich weiß nicht, ob westnordost hier noch mitließt, aber mein Feedback dazu würde ich trotzdem gerne los werden:

-Erstmal: Super Idee, easy Umsetzung, sowas brauchen wir hier dringend häufiger! Also: Weiter so!

-Mir fehlt zu Beginn ein kleines Intro, das erklärt, wie die App funktioniert. Sowas gibt's ja heutzutage in vielen Apps und sollte nicht so aufwändig sein. Mir war z.B. nicht klar, dass ich bereits beantwortete Fragen gar nicht mehr aufrufen kann. Auch ist mir bisher nicht klar, ob die Änderungen auf jeden Fall hochgeladen werden, oder erst dann, wenn ich im Menü auf "Antworten hochladen" gehe. Wenn ich die App schließe, kommt auf jeden Fall keine Warnung, dass Daten verloren gehen könnten.

-Ich würde z.B. gerne vorm Hochladen die Fragen nochmal auf Richtigkeit durchgehen können.

-Auch sollte vlt in einem möglichen Intro nochmal darauf hingewiesen werden, dass hier auf eigene Verantwortung in den Datenbestand von OSM eingegriffen wird.

-Bei den Geschwindigkeiten fehlt mir die Option, dass die eingetragene Vmax nicht aufgrund eines Schildes gilt, sondern, weil man sich hier auf einer Land-, Innerstädtischen- oder sonstigen Straße befindet mit allgemeinen Höchstgeschwindigkeiten. Also eine Option für source:maxspeed=*.

Ich werde die App auf jeden Fall weiter nutzen, da man hier easy vor Ort Informationen erfassen kann, ohne sich großartige Notizen, Bilder oder was auch immer machen zu müssen. Grade in Gebieten mit einem sehr dürftigen Datenbestand ist das ein Segen (man erinnere sich nur an den Aufwand, der hier schon betrieben wurde, um große Gebiete ohne Hausnummern anzugehen).

Viele Grüße,

hsimpson

Verleitet die App dann etwas einzutragen, was eventuell schon separat gemappt ist? Oder werden die Umgebungsdaten angezeigt?
z. B. ist mir aufgefallen Bushaltestelle: shelter, bin, bench werden ergänzt, obwohl separat oder an pt=plattform vorhanden.

hsimpson wrote:

-Bei den Geschwindigkeiten fehlt mir die Option, dass die eingetragene Vmax nicht aufgrund eines Schildes gilt, sondern, weil man sich hier auf einer Land-, Innerstädtischen- oder sonstigen Straße befindet mit allgemeinen Höchstgeschwindigkeiten. Also eine Option für source:maxspeed=*.

hmm, scheint aber wohl mal genauso funktioniert zu haben, siehe meinen Post weiter oben (#86)

R0bst3r wrote:

Was bringt es source:maxspeed zu taggen ohne ein maxspeed zu tagten?

Weil es bei den Diskussionen (bitte einfach mal danach suchen) bisher auch immer darum ging, source:maxspeed für "implizit" (oder rechtliche grundlage) zu verwenden. Wenn du jede Innerortsstraße mit maxspeed=50 taggst, dann musst du nach einer Gesetzesänderung alles anpassen (ich sag nur automated edit, und leider hatten wir auch schon andere Diskussionen, dass es gar nicht so einfach ist, "innerorts"-Straßen überhaupt einwandfrei rauszufiltern). Mit nur source:maxspeed=DE:urban könnte Navis und Co einfach so dann die aktuell gesetzliche Regelung anzeigen/verwenden.

Harald Hartmann wrote:

hsimpson wrote:

-Bei den Geschwindigkeiten fehlt mir die Option, dass die eingetragene Vmax nicht aufgrund eines Schildes gilt, sondern, weil man sich hier auf einer Land-, Innerstädtischen- oder sonstigen Straße befindet mit allgemeinen Höchstgeschwindigkeiten. Also eine Option für source:maxspeed=*.

hmm, scheint aber wohl mal genauso funktioniert zu haben, siehe meinen Post weiter oben (#86)

Hab ich gesehen, daher wunder es mich auch, dass ich bisher nur auf die Option "Zone" gestoßen bin. Aber vieleicht hatte ich bisher auch nur Straßen, die bereits ein source:maxspeed hatten?

Oha, jetzt wirds interessant: Offensichtlich hat die App ein automatisches source:maxspeed=sign gesetzt. Das finde ich wiederum gar nicht lustig. Siehe u.a. http://www.openstreetmap.org/way/6187381

Hier sind wir wieder bei: Was tut die App eigentlich genau und warum? Das muss definitiv genauer beantwortet werden und z.B. die Fragen genauer gestellt werden. Ansonsten haben wir bald in allen Innenstädten fälschlicherweise ein source:maxspeed=sign!

Harald Hartmann wrote:

und leider hatten wir auch schon andere Diskussionen, dass es gar nicht so einfach ist, "innerorts"-Straßen überhaupt einwandfrei rauszufiltern

Ein source:maxspeed würde genau das ermöglichen!

Grüße

Meiner Ansicht nach müsste eine korrekte Abfrage nach der Geschwindigkeit etwa so ausschauen:

1.: Gibt es auf dieser Straße ein Schild, was die Geschwindigkeit explizit regelt oder liegt die Straße in einer expliziten Geschwindigkeitszone?
Wenn ja: Geschwindigkeit und evtl Zone eigeben lassen wie bisher.
Wenn nein:
2.:Befindet sich die Straße innerorts oder Außerorts?
(3.:Wie lautet die implizite Geschwindigkeit für diese Straße?) <- Optional, würde ich persönlich auch abfragen.

Grüße

Edit: In Frage 2 können auch Fälle wie der Verkehrsberuhigte Bereich abgefragt werden.

hsimpson wrote:

Harald Hartmann schrieb:
und leider hatten wir auch schon andere Diskussionen, dass es gar nicht so einfach ist, "innerorts"-Straßen überhaupt einwandfrei rauszufiltern
Ein source:maxspeed würde genau das ermöglichen!

Leider nein! Siehe Innerorts außerorts unterscheiden. Ein Beispiel von vielen: innerorts-Straße mit maxspeed=60/70 und source:maxspeed=sign

Solche Straßen wären aber auch von einer Gesetzesänderung nicht betroffen, da die Vmax nicht impliziert wird. Daher ist es für den Fall unwesentlich, ob solche Straßen als innerorts oder außerorts erkannt werden können.

Grüße

mmd wrote:

wir unterbrechen die aktuelle dauermeckersendung für einen moment:

• • • breaking news ***
      

https://twitter.com/sotm/status/898910845857447937

Glückwunsch, well done!

Glückwunsch auch von mir, ich finde die Idee auch gut und die Auszeichnung verdient.

Vo daher bin ich der Meinung, das auch der Titel dieser Diskussion mal geändert gehört!!!
Ein schönes Rest-Wochenende wünscht
Uwe

Habe grade zwei Tickets geöffnet:
Da und da.

Grüße

Changeset: http://www.openstreetmap.org/changeset/51278638
So gut die App sein mag zeigt der Changeset gleich mehrere Probleme:
- Couven-Gymnasium (oben links): Die Adresse ist korrekt auf der Fläche der Schule erfasst. Die App dürfte für die einzelnen Gebäude ("school") gar keine Hausnummer abfragen.
- Generali (unten rechts): Die Hausnummer 16 war bereits an einem der Gebäude erfasst (http://www.openstreetmap.org/relation/1461507). Nun gibt es die Hausnummer mehrfach.
- Allgemein (+ Lösungsvorschlag): Warum kann man Hausnummern ohne Straße angeben (das ist doch zwecklos)? Wäre die Straße ein Pflichtangabe, hätte man dem User in o.g. Fällen anzeigen können, dass die Adresse bereits existiert.

PS: Ich nutze die App nicht und kann daher nicht sagen, ob dem User in o.g. Fällen vielleicht beim Upload etwas angezeigt wurde (z.B. ein Hinweis auf fehlende Straßennamen).

aixbrick wrote:

Changeset: http://www.openstreetmap.org/changeset/51278638

Korrektes bestimmen ob eine Adresse fehlt oder nicht, ist eher schwierig. Nicht nur wegen der Dutzend oder so Varianten wo eine vorhandene Adresse stecken kann, sondern auch wegen den lokalen Regelungen (sind Grundstücke, Gebäude, Eingänge oder was anderes nummeriert).

SimonPoole wrote:

Korrektes bestimmen ob eine Adresse fehlt oder nicht, ist eher schwierig.

betrifft aber auch z.B. shelter an busstop - falls sie separat eingetragen sind werden sie durch die App gedoppelt (bench, bin, ... )

Also die App erkennt auf jeden Fall schonmal den Fall, dass die Hausnummer als Node an die Tür gesetzt wurde, hab ich eben mal gecheckt. Also müsste das mit der Fläche auch eigentlich machbar sein.

Grüße

SimonPoole wrote:

Korrektes bestimmen ob eine Adresse fehlt oder nicht, ist eher schwierig. Nicht nur wegen der Dutzend oder so Varianten wo eine vorhandene Adresse stecken kann, sondern auch wegen den lokalen Regelungen (sind Grundstücke, Gebäude, Eingänge oder was anderes nummeriert).

Man kann aber doch bestimmt prüfen, ob eine Adresse, die eingegeben wird, bereits existiert, oder?

Ich habe gesehen, dass es zum ersten Problem (Adresse inkl. Hausnummer auf Fläche vorhanden) ein Issue auf GitHub gibt: https://github.com/westnordost/StreetCo … issues/510

Lang nicht mehr hier reingeschaut. Hier ein paar Antworten:

geri-oc wrote:

Mir ist aufgefallen, das mit StreetComplete shelter=yes an hw= bus_stop eingetragen werden. Diese sind aber tw separat oder am pt=platform schon vorhanden.

Habe ich mir angeschaut, kein Bug. Hier ein Beispiel wo das passiert ist.
Hier wurde das alte higway=bus_stop Schema mit dem neuen Schema vermischt. Wenn man das neue Schema nutzt (public_transport=platform), dann sollte das auch konsistent pro-Haltestelle angewendet werden. Ein highway=bus_stop auf einem public_transport=platform ist an sich schon eine Dopplung. Für Haltestellen auf einer (langen) Plattform gibt es public_transport=pole.

Ganz unabhängig davon stellt sich natürlich die Frage, ob wenn eine Plattform lang genug ist um detailliert als way getaggt zu sein und einzelne (mehrere) Haltestellen vereinigt (poles / hier im Beispiel: highway=bus_stop), ob es dann nicht eh sinnig ist, die angesprochenen Eigenschaften (auch) dort zu taggen, da eine Oma die vorne an einem langen Busstieg auf ihren Bus wartet sicherlich nicht interessiert ob irgendwo am anderen Ende eine Bank vorhanden ist, sondern genau dort wo sie wartet. Hier nur mal so als Anregung, ich werde nichts dergleichen einbauen solange das nicht offiziell dokumentiert ist.

An diesem Beispiel sieht man gut, dass die Auffassung, sowohl im alten als auch neuen Schema zu taggen für Data-Consumers hilfreich ist, ein Mythos ist. Das Gegenteil ist der Fall.

hsimpson wrote:

Meiner Ansicht nach müsste eine korrekte Abfrage nach der Geschwindigkeit etwa so ausschauen: [...]

Hier mal eine Auflistung, wie StreetComplete auf die Tags kommt:

• Gibt der Nutzer normal die Geschwindigkeitsbegrenzung ein und drückt [OK], wird die Eingabe grob auf Plausibilität geprüft. Erscheint die Eingabe unplausibel, muss der Nutzer seine Eingabe bestätigen, ansonsten wird sie sofort übernommen. Es wird getaggt: maxspeed=[Eingabe], source:maxspeed=sign. Befindet sich die Straße in einem Land befindet, in dem mit Meilen gerechnet wird, wird an die Eingabe entsprechend mph angehängt.
• Befindet sich die Straße in einem Land, in dem das Konzept von (30-)Zonen bekannt ist, befindet sich im Formular eine Checkbox die der Nutzer ankreuzen kann, um diese Straße als Teil einer (30-)Zone zu markieren. Wenn angeklickt, wird die Geschwindigkeitsbegrenzung im Formular mit 30 (bzw. 20 mph) vorausgefüllt sofern noch nichts eingetragen wurde, kann man aber editieren. Statt source:maxspeed=sign wird dann z.B. source:maxspeed=DE:zone30 getaggt. Ansonsten wie 1.
• Befindet sich die Straße in einem Land, in dem man das Konzept von Spielstraßen kennt, kann der Nutzer die Frage mit "Es ist eine Spielstraße" beantworten. Der Nutzer muss dies in einem Dialog in dem ein Bild eines Spielstraßen-Schildes gezeigt wird, bestätigen. Die Bilder variieren je nach Land in dem sich die Straße befindet. Siehe 1, 2, 3, 4. Die Straße wird dann lediglich in highway=living_street umgetaggt.
• Der Nutzer hat immer die Möglichkeit, die Frage mit "Es gibt hier kein Schild" zu beantworten. Grundsätzlich muss diese Antwort bestätigt werden. Befindet der Nutzer sich in einer Wohngebietsstraße (highway=residential) und einem Land, in dem man (30-)Zonen kennt, wird der Nutzer noch einmal darauf hingewiesen, dass man runter zur Hauptstraße gehen müsste um festzustellen ob es hier nur kein Schild gibt oder es doch eine Zone ist, da innerhalb einer Zone keine weiteren Geschwindigkeitsbegrenzungsschilder vorhanden sein werden. In diesem Dialog wird noch einmal ein Bild eines Zonen-Schildes gezeigt. Wird bestätigt, dass kein Schild vorhanden ist, wird der Nutzer für alle Straßen außer residential, motorway, trunk usw. noch einmal gefragt, ob die Straße inner- oder außerorts ist. Das ist (leider) notwendig, denn es gibt kein Tagging-Schema dass erlauben würde, einfach nur den Fakt dass es keine Speed-Limit-Schilder gibt, so direkt zu taggen. Der Fall wird dann also z.B. mit source:maxspeed=urban (ohne maxspeed=, denn u.a. kann man vom Nutzer nicht verlangen, das zu wissen) getaggt.

Hier meckern übrigens die Briten, denn die Community hat sich leider noch immer nicht auf ein weltweit gültiges Schema für implizite Geschwindigkeitsbegrenzungen geeinigt. :-/

Geplante Erweiterungen:

• In Zukunft soll noch für Länder in denen das Konzept von "Richtgeschwindigkeit" vorhanden ist, eine zusätzliche Antwort-Option angezeigt werden. Klickt der Nutzer darauf, verwandelt sich das runde weiße Schild mit dem rotem Rand (das Eingabefeld) in ein blaues eckiges mit weißem Rand bzw. in andere Formen und Farben, je nach Land. Dort kann der Nutzer dann statt der Höchstgeschwindigkeit, die Richtgeschwindigkeit eingeben.
• Außerdem soll der Nutzer später noch die Möglichkeit bekommen, zeitgebundene Höchstgeschwindigkeiten anzugeben, auch wieder aktiviert über eine zusätzliche Antwort-Option. Die Eingabe erfolgt analog wie im Öffnungszeiten-Dialog. Dies hat aber weniger Priorität, da solche Straßen selten sind und dies auch erstmal über Notizen abgehandelt werden kann.

Lübeck wrote:

Oftmals werden Hausnummern angemerkt wo keine sind. Damit diese Fragen nicht wieder auftauchen habe ich eine Note hinterlegt und ich dachte damit verschwinden diese Marker wie bei KeepRight.

Aber stattdesse wurden osm-notes angelegt. In der App bekam ich keinen Hinweis das diese daraus generiert werden finde ich den Weg unpassend. Wenn dann hätte ein Note am Objekt besser gefunden. Weiterhin steht dann nicht einmal in dem osm-note-Text das dieses von mir über die App versand wurde.

Vielleicht trifft diese Rückmeldung hier auf offene Ohren.

Vielleicht liegt es auch an meiner fehlerhaften Bedienung.

Du sprichst hier mehrere Punkte an.

• Du hast die App richtig bedient
• Dass kein Hinweis in welchem Kontext die OSM Notiz entstanden ist, angefügt wird, ist falsch. Schau nochmal
• Momentan werden Hausnummern an einzelnen Gebäuden von z.B. einer Schule abgefragt, selbst wenn die gesamte Schule (amenity=school) schon eine Hausnummer hat. Das ist so implementiert, weil ich dachte, es sei nicht erwünscht, Hausnummern an nicht-Häusern zu haben. Dies scheint doch nicht der Fall zu sein, daher werde ich demnächst implementieren, dass die Hausnummer von Gebäuden innerhalb von solchen Areas nicht mehr abgefragt wird, wenn die Hausnummer schon daran getaggt ist. Dazu gibt es schon ein Github issue, den du abonnieren kannst wenn du über Fortschritte informiert werden willst.
• Es wurde irgendwo anders in diesem Thread noch angemerkt dass noaddress=yes (noch) nicht implementiert ist. Das ist richtig, ist noch nicht implementiert. Siehe das Github issue hier.

westnordost wrote:

Hier meckern übrigens die Briten, denn die Community hat sich leider noch immer nicht auf ein weltweit gültiges Schema für implizite Geschwindigkeitsbegrenzungen geeinigt. :-/

Da kannste ja gerne mal meinen, durchaus wohl nur an der Oberfläche kratzenden Blogeintrag maxspeed ... eine Perle des Wikis überfliegen 😉

PS: Auch "DE:zone30" wurde erst vor ein paar Monaten auf talk-de "zerlegt", da es hier gerade mal 10tsd einträge mehr gibt, als für "DE:zone:30" usw.

westnordost wrote:

Habe ich mir angeschaut, kein Bug. Hier ein Beispiel wo das passiert ist.
Hier wurde das alte higway=bus_stop Schema mit dem neuen Schema vermischt. Wenn man das neue Schema nutzt (public_transport=platform), dann sollte das auch konsistent pro-Haltestelle angewendet werden. Ein highway=bus_stop auf einem public_transport=platform ist an sich schon eine Dopplung. Für Haltestellen auf einer (langen) Plattform gibt es public_transport=pole.

Jupp, das Beispiel ist definitiv falsch, aber weil es einen unnötigen zusätzlichen Punkt gibt. highway=bus_stop an einer platform-Node ist hingegen das gängige Schema. Wenn die platform ein Way ist, gehört der bus_stop an die stop_position.
Generell sollten die PTv1-Tags komplett ignoriert werden, wenn PTv2 existiert, aber selbst das würde bei deinem Beispiel nicht weiter führen, da jemand für PTv1 komplett eigene Nodes hingesetzt hat...

westnordost wrote:

Ganz unabhängig davon stellt sich natürlich die Frage, ob wenn eine Plattform lang genug ist um detailliert als way getaggt zu sein und einzelne (mehrere) Haltestellen vereinigt

Konsens hier im Forum war, dass die platform nur noch dann ein Way sein darf, wenn sie definitiv nicht im Verlauf des Normalen Bürgersteiges liegt. Folglich muss hier der Way weg.

Aber die Gegend ist eh grauenhaft gemappt, ich sage nur Bürgersteige als eigener way, etc...

EDIT: Uiuiui das hier ist ja Toll 🙂 Sehe ich so auch zum ersten mal^^

Zu den Geschwindigkeiten:

Ich denke das größte Übel sollte mit der expliziten Frage nach dem Schild behoben sein 🙂 Ich hätte die Frage etwas anders gestaltet, um den Interpretationsspielraum noch zu verringern, aber ich denke das sollte so fürs erste reichen.

Grüße

hsimpson wrote:

das hier ist ja Toll

Na ja, Ein Kran namens Schrottplatz?

https://www.openstreetmap.org/way/98898 … 1/13.64543

rechts daneben, die Parkplatz-wege sind access-private, die Fläche(?) aber nicht....

Und die Fußwege am Rand des Bahnsteigs? Gefährlich... 🙂

Hi, mir ist eben aufgegangen, dass einige rätselhafte Fehlermeldungen aus Erlangen sehr warscheinlich au StreetComplete zurückzuführen sind.
Beispiele:
1.: http://www.openstreetmap.org/note/1060936
2.: http://www.openstreetmap.org/note/1034011

Bei anderen Programmen, die Fehlermeldungen in der Hauptmap setzen, ist es üblich, dass diese einen Zusatz setzen, in dem steht, welches Programm in welcher Version für diese Meldung verantwortlich ist. Wäre das hier auch möglich? Das würde glaube ich einige Verwirrungen beseitigen, wenn ein Zusatz wie "created via StreetComplete v1.1" oder so dabei steht.

Btw: Wieso fragt die App die Öffnungszeiten von Hotels ab (Beispiel 1)? Das ergibt für mich wenig Sinn.
Grüße

Moin,

hsimpson wrote:

Hi, mir ist eben aufgegangen, dass einige rätselhafte Fehlermeldungen aus Erlangen sehr warscheinlich au StreetComplete zurückzuführen sind.
Beispiele:
1.: http://www.openstreetmap.org/note/1060936
2.: http://www.openstreetmap.org/note/1034011

Bei anderen Programmen, die Fehlermeldungen in der Hauptmap setzen, ist es üblich, dass diese einen Zusatz setzen, in dem steht, welches Programm in welcher Version für diese Meldung verantwortlich ist. Wäre das hier auch möglich? Das würde glaube ich einige Verwirrungen beseitigen, wenn ein Zusatz wie "created via StreetComplete v1.1" oder so dabei steht.

+1

Btw: Wieso fragt die App die Öffnungszeiten von Hotels ab (Beispiel 1)? Das ergibt für mich wenig Sinn.

Gemeint sind hier wohl die Rezeptionszeiten - gerade in kleinen Hotels kann man ja nicht rund um die Uhr einchecken.
Aber das Hotel ist ja durchaus auskunftsbereit im www.

PS:
Beim Schlachter kann man ruhig noch die kleine Restauration ergänzen - Hotel mit eigener Schlachterei wäre bei mir durchaus ein Suchkriterium, hab ich eigentlich immer gute Erfahrungen gemacht. 🙂

hsimpson wrote:

Bei anderen Programmen, die Fehlermeldungen in der Hauptmap setzen, ist es üblich, dass diese einen Zusatz setzen, in dem steht, welches Programm in welcher Version für diese Meldung verantwortlich ist. Wäre das hier auch möglich?

Wäre möglich, wird aber vom Author der App "mehr oder weniger" abgelehnt ... oder anders ausgedrückt, er wartet einfach darauf, bis andere ihre Arbeit gemacht haben 🤔

Sagmal, wo nimmt die App eig ihre Daten her und wie oft werden die aktualisiert?
Ich hab hier gestern Mittag ne groß angelegte surface-Überarbeitung durchgeführt, aber StreetComplete fragt immer noch nach der Straßenoberfläche...
Grüße

Das Problem mit den Hausnummern innerhalb einer Area mit Hausnummern wurde übrigens laut Changelog eben behoben! 🙂
Grüße

Ich glaube übrigens inzwischen, dass das Problem mit den veralteten Fragen weniger ein Problem der Aktualität der Daten als ein Chache-Problem ist. Beim Abrufen von neuen Fragen werden die alten wohl erst gelöscht, wenn der Cache voll ist (oder so).
Mich würde jetzt nur interessieren, was passiert, wenn ich eine Frage beantworte, die für einen Way gilt, der überhaupt nicht mehr in den Daten existiert 🙂
Grüße

Edit: Den Chache der App zu leeren brachte nicht das gewünschte Ergebnis...

hsimpson wrote:

[...]Btw: Wieso fragt die App die Öffnungszeiten von Hotels ab (Beispiel 1)? Das ergibt für mich wenig Sinn.
1.: http://www.openstreetmap.org/note/1060936

Die app fragt keine Öffnungszeiten von Hotels ab. Zum Zeitpunkt der Erstellung der Notiz war der POI als Restaurant getaggt. Die Notiz ist also gerechtfertigt.

hsimpson wrote:

[...] einen Zusatz setzen, in dem steht, welches Programm in welcher Version für diese Meldung verantwortlich ist. Wäre das hier auch möglich? Das würde glaube ich einige Verwirrungen beseitigen, wenn ein Zusatz wie "created via StreetComplete v1.1" oder so dabei steht.

Ja, ist so seit Version 1 (20. Juli). Die Aussage von Harald Hartmann, ist falsch.

Es ist aber eine gute Idee, die Versionsnummer zusätzlich zu erwähnen, das baue ich mal ein.

hsimpson wrote:

Mich würde jetzt nur interessieren, was passiert, wenn ich eine Frage beantworte, die für einen Way gilt, der überhaupt nicht mehr in den Daten existiert

Wenn beim Beantworten ein (solcher) Konflikt passiert, wird deine Antwort ohne weitere Meldung verworfen und der Bereich in dem der Konflikt passiert ist, als neu-herunterzuladen markiert, so dass bei der nächsten Gelegenheit die Aufgaben entweder automatisch (bei auto-sync an) oder per Knopfdruck neu heruntergeladen werden. (Die app hat sozusagen gemerkt, dass hier noch andere Mapper unterwegs sind, und frischt den angesprochenen Cache auf.)
Dass das passiert ist, kannst du übrigens daran erkennen, dass der ★-Zähler nicht hochgezählt hat.

westnordost wrote:

Ja, ist so seit Version 1 (20. Juli). Die Aussage von Harald Hartmann, ist falsch.

Sorry, aber in dem von mir verlinkten Ticket steht, außer ich bin zwischenzeitlich erblindet, nichts davon (auch nicht in den Querverweisen), dass es nun eingebaut wäre (sondern es ist immer nur vom Context in welchem die Antwort erfolgt ist die Rede) .. und da ich die App nicht verwende, lese ich auch die Release Notes nicht 😉

Harald Hartmann wrote:

[...]in dem von mir verlinkten Ticket steht, außer ich bin zwischenzeitlich erblindet, nichts davon (auch nicht in den Querverweisen), dass es nun eingebaut wäre

Scrolle runter zu

westnordost referenced this issue on 10 Jun
Add StreetComplete name to notes #308

Aber schon okay, kann man leicht übersehen.

Habe mir nach längerer Zeit mal wieder erlaubt StreetComplete zu öffnen ... und gleich wieder eine Frage: ist es in Deutschland üblich, dass ein highway=unclassified zwingend ein name braucht? Oder wie kommt es dazu, dass mich StreetComplete bis zum Erbrechen danach fragt und dann die schöne Option "die Straße hat keinen Namen" anbietet, was vermutlich in einem noname=yes resultiert... 🤔

Nicht immer gibt es einen Namen aber oft schon... aber das macht Gemeinde für Gemeinde anders.

Harald Hartmann wrote:

Oder wie kommt es dazu, dass mich StreetComplete bis zum Erbrechen danach fragt und dann die schöne Option "die Straße hat keinen Namen" anbietet, was vermutlich in einem noname=yes resultiert... 🤔

JOSM bietet diese Option noname=yes inzwischen auch an. Keine Ahnung, wie lange schon.

Gruss
walter

Wurde das schon irgendwo diskutiert (und ich finde es nur nicht), dass wir jetzt alles mit "noname=yes" zupflastern wollen?

EDIT: Also nicht das wir uns falsch verstehen, bei primary, secondary, tertiary, residential und Co ja, da sehe ich das mit noname=yes ja ein, aber unclassified ist mir dabei noch nicht untergekommen. Oder wird das nach dem Prinzip "noname=yes" ist die Prüfung/der Eintrag, dass es schon jemand geprüft hat (also unabhängig von StreetComplete), gehandhabt?

Harald Hartmann wrote:

wird das nach dem Prinzip "noname=yes" ist die Prüfung/der Eintrag, dass es schon jemand geprüft hat (also unabhängig von StreetComplete), gehandhabt?

Nö, das würde ich bei unclassified auch nicht für gut halten. Und für highway=road auch nicht. Road kommt leider öfter vor als man denkt - besonders im fernen Ausland.

Gruss
walter

Unclassified kommt doch genau zwischen tertiary, residential... Von der Reihenfolge. Ich glaub ich bin schon zu lange hier 😉 und Road ist alles was man nicht weiß... Aber naja anscheinend wird das wieder von jedem anders interpretiert... Tertiary ist die offizielle Kreisstraße und unclassified die Gemeindestraße...

Ja, mehr oder weniger und bei uns haben die (ortsverbindungstechnischen) Gemeindestraße eher keinen Namen...

@miche101: Soll ich eigentlich aus deinem Beitrag das so interpretieren, dass nur weil unclassfied zwischen tertiary und residential ist, es auch einen Namen haben sollte?

Harald Hartmann wrote:

Ja, mehr oder weniger und bei uns haben die (ortsverbindungstechnischen) Gemeindestraße eher keinen Namen...

@miche101: Soll ich eigentlich aus deinem Beitrag das so interpretieren, dass nur weil unclassfied zwischen tertiary und residential ist, es auch einen Namen haben sollte?

Des ist halt bei uns falsch... "(ortsverbindungstechnischen)".. die Straße behält ihren Namen auch nach dem Ortsschild bis zur Orts- bzw. Gemeindegrenze.

Es ist eher das tertiary keinen Namen hat.. und auch hier werden Straßennamen vergeben.. zum Teil aus Verwaltungs- bzw. Sicherheitstechnischen gründen.. Auffindbarkeit usw.

http://wiki.openstreetmap.org/wiki/Key:noname

One of the main points of this noname=yes tag would be to allow such tools like StreetComplete to exclude streets from the highlighting where they genuinely have no name.

ach na dann, wieso sagt ihr das nicht gleich, dass StreetComplete anscheinend mit solchen und anderen Sachen und unter dem Deckmantel der "Vor Ort Survey" die absolute Absolution für einfach alles zu haben scheint 😠

Harald Hartmann wrote:

ach na dann, wieso sagt ihr das nicht gleich, dass StreetComplete anscheinend mit solchen und anderen Sachen und unter dem Deckmantel der "Vor Ort Survey" die absolute Absolution für einfach alles zu haben scheint

Verstehe das Problem nicht, der Tag ist nicht für StreetComplete erfunden worden. Oder was ist das Problem?

Das es StreetComplete für etwas verwendet, wofür es (zumindest in Deutschland und auch der Meinung anderer) normalerweise nicht benötigt wird.

ADD: Und wie oft haben wir zustimmend diskutiert, dass solche Apps dann halt selbst eine Datenbank vorhalten müssen, was sie schon geprüft haben und was nicht und nicht die ganzen OSM Elemente mit irgendwelchen Tags zupflastern...

miche101 wrote:

die Straße behält ihren Namen auch nach dem Ortsschild bis zur Orts- bzw. Gemeindegrenze.

Ok, d.h. ich tagge dann jetzt an die Straße folgendes

name:forward=Straßenname␣von␣Ortschaft␣A
name:backward=Straßenname␣von␣Ortschaft␣B

Naja, die Wikiseite könnte man schon so verstehen, daß es Tagging für den Editor ist.
Andersrum würde eher ein Schuh draus: die App sagt dem Nutzer, der Straßenname würde fehlen und er trägt noname=yes ein, um die Namenlosigkeit zu bestätigen.
Bleibt für mich aber eine Info, die vielleicht den Mappern hilft, aber dem Nutzer einer Karte nichts.

Achso verstehe, genauso wie an jede Straße oneway=no dranzuhängen.

Thomas8122 wrote:

Achso verstehe, genauso wie an jede Straße oneway=no dranzuhängen.

Also ich mache das definitiv nicht, warum auch? ... und sag jetzt nicht StreetComplete macht sowas

Harald Hartmann wrote:

Also ich mache das definitiv nicht, warum auch?

Ich auch nicht.

Harald Hartmann wrote:

und sag jetzt nicht StreetComplete macht sowas

Ich denke nicht.

Laut [1], dürfte das Problem, dass nach Hausnummern gefragt wird, obwohl die darunterliegende Fläche bereits eine hat, behoben sein. Das scheint aber bei amenity=kindergarten bzw. building=kindergarten nicht zu funktionieren. Mit dem Changeset [2] wurde nämlich durch StreetComplete nach der Hausnummer gefragt und konnte durch den User eingegeben werden.

Aus diesem Anlass würde ich gerne nochmal meine Frage aus Beitrag #106 stellen: Warum lässt es die App überhaupt zu, Hausnummern ohne Straße angeben zu können? Ich glaube nach wie vor, dass das zwecklos ist, weil die Hausnummer alleine gar nichts aussagt. Sie ist nur in Verbindung mit einer Straße sinnvoll.

[1] https://github.com/westnordost/StreetCo … issues/510
[2] http://www.openstreetmap.org/changeset/54009680

aixbrick wrote:

Aus diesem Anlass würde ich gerne nochmal meine Frage aus Beitrag #106 stellen: Warum lässt es die App überhaupt zu, Hausnummern ohne Straße angeben zu können? Ich glaube nach wie vor, dass das zwecklos ist, weil die Hausnummer alleine gar nichts aussagt. Sie ist nur in Verbindung mit einer Straße sinnvoll.

Gute Frage; ich möchte mich anschließen. 🙂 In Bretzfeld und in Weißbach (Hohenlohekreis) hat ein fleißiger neuer Mapper in diesem Herbst zahlreiche bisher fehlende Hausnummern per StreetComplete erfasst, nur leider oft/meist ohne Straßenangabe (addr:housenumber ohne addr:street). Ich habe das fehlende addr:street überall nachgetragen, wo ich es eindeutig bestimmen konnte. Aber wäre es nicht schöner, wenn der Mapper gleich nicht nur nach der Hausnummer, sondern auch nach dem Straßennamen gefragt würde? Oder ist das (inzwischen) so?

PS: Das soll kein Herumgemeckere an der App sein. Im Gegenteil, daran, dass ein neuer Mapper von StreetComplete so zum fleißigen Erfassen der Hausnummern animiert wurde, ist ja ein Beleg, dass die App wirklich sinnvoll ist – Kompliment! Nur, ehm, sie wäre eben vielleicht noch besser, wenn wir auch gleich die Straßennamen bekämen und nicht (wie ich es hier getan habe) danach nochmal mit JOSM hinterherputzen müssen … 😉

Das war eine längere Diskussion. Nachlesbar hier. (Weiter unten im Ticket habe ich ein langes Resumé gezogen und nochmal alle Gründe genannt, die dagegen sprechen, für jede Hausnummer gleich die Straße mit erfassen zu lassen). Natürlich ist ohne Straßenangabe die Addressinformation unvollständig, klar, und muss dann irgendwann später nachgetragen werden. Als Follow-Up der erwähnten Diskussion gibt es ein Ticket als Feature-Wunsch für die Erstellung eines weiteren Aufgabentyps "In welcher Straße befindet sich das Haus mit Hausnummer ...?"

Wegen der Schule, das liegt daran, dass die Geometrie des Gebäudes nicht vollständig innerhalb des Schulgeländes liegt. Ich könnte das ändern, so dass es schon reicht, wenn sich die Geometrie des Schulgeländes mit der des Gebäudes schneidet damit nicht nach der Hausnummer gefragt wird.
Aber das würde bedeuten, dass in allen Fällen, in denen das Schulgelände korrekt scharf mit dem Gebäude abschließt, nicht nach der Hausnummer für das benachbarte Gebäude, also http://www.openstreetmap.org/way/87081364 in dem Fall gefragt werden würde, weil dieses Gebäude dann auch das Schulgelände schneiden würde.

westnordost wrote:

Das war eine längere Diskussion. Nachlesbar hier. (Weiter unten im Ticket habe ich ein langes Resumé gezogen und nochmal alle Gründe genannt, die dagegen sprechen, für jede Hausnummer gleich die Straße mit erfassen zu lassen). Natürlich ist ohne Straßenangabe die Addressinformation unvollständig, klar, und muss dann irgendwann später nachgetragen werden.

Danke für den Hinweis! Es ist schön zu sehen, dass Ihr Euch soviel Gedanken gemacht habt. (Bei anderen Apps bin ich mir mit dem „Gedanken machen“ nicht immer so sicher 😉) … Ich halte das Vorgehen, nur nach den Hausnummer zu fragen, immer noch für suboptimal, aber es ist natürlich aus der Konzeption der App heraus sehr einleuchtend.

westnordost wrote:

Als Follow-Up der erwähnten Diskussion gibt es ein Ticket als Feature-Wunsch für die Erstellung eines weiteren Aufgabentyps "In welcher Straße befindet sich das Haus mit Hausnummer ...?"

Das wäre dann doch recht wünschenswert.

Danke für deine Erläuterung. Warum nicht nach dem Straßennamen gefragt wird, ist in der Tat nachvollziehbar.

Bei der Fläche ist eine Anpassung der App aus meiner Sicht nicht nötig. Man muss nur richtig mappen, und das bedeutet in diesem Fall, dass das Geände scharf mit dem Nachbargebäude abschließen muss, sodass das Kindergarten-Gebäude vollständig umschlossen ist (was dann auch der Realität entspricht). Im Prinzip weist die App hier also indirekt auf ein Problem hin.

Zu dem Schulgelände-Thema gäbe es eventuell noch einen dritten Weg. StreetComplete nutzt die JTS Topology Suite für geometrische Berechnungen.
Der Source Code zu der angesprochenen Logik ist hier - es wird a.coveredBy(b) genutzt, welches als "b enthält (alle Punkte von) a" dokumentiert ist. a.intersects(b) wäre dann "b hat Punkt(e) mit a gemein".

Die beste Lösung wäre "b hat eine Fläche mit a gemein", mit anderen Worten, es hat mindestens eine Intersection, die eine Fläche ist. Allerdings scheint es keinerlei Funktion zu geben, die diese Logik abbildet, es gibt a.overlaps(b), aber das tut was anderes als man erwarten würde.
Vielleicht kennt sich da jemand mit JTS besser aus als ich?

westnordost wrote:

Die beste Lösung wäre "b hat eine Fläche mit a gemein", mit anderen Worten, es hat mindestens eine Intersection, die eine Fläche ist. Allerdings scheint es keinerlei Funktion zu geben, die diese Logik abbildet, es gibt a.overlaps(b), aber das tut was anderes als man erwarten würde.

Wenn diese Suite OGC-konform ist, gibts hier eine nette Übersicht: http://docs.safe.com/fme/html/FME_Deskt … 9IM_Matrix An diese OGC-Definitionen halten sich AFAIK alle mir bekannten Bibliotheken.

Habe mir mal gedacht, ach komm, testest die App nochmal und trägst einfach ein paar Hausnummern ein.

Nach dem fünften Haus (plus 5 Sterne) stelle ich fest, daß es falsch war, was ich gemacht habe, weil zwei der Buildings Zweifachreihenhäuser waren und somit statt einer eben zwei Hausnummer haben.

Also habe ich fünfmal auf dem Undo Button geklickt, fünfmal wurde (-1) bei den Sternen angezeigt, aber die eigentlichen Sterne weiter aufaddiert, macht jetzt also +10 Sterne, obwohl nichts geändert/beigetragen wurde.

Nichts geändert ... ähm wie jetzt, was soll dieses Changeset** ... WTF ... es ist echt unglaublich was eine Awardwinning App so alles darf ... bin einfach nur noch fassungslos...

PS: @westnordost
Nein, ich werde keine github Issues erstellen, das kannste schön selber machen.

• • für diejenigen, die nicht reingucken wollen: zu nächst wurde für die 5 Gebäude die v3 mit Hausnummer angelegt, und dann nach dem Undo jeweils die v4 wieder ohne Hausnummer erzeugt, der changeset Kommentar ist aber ironischer weiße "add housenumber", d.h. wenn man sich nur die letzte Version anschaut kann man sich schon fragen, was der Schei.. soll
    

Harald Hartmann wrote:

für diejenigen, die nicht reingucken wollen

Was soll die App auch sonst großartig machen. Sachen die schon auf dem Server sind, können nur durch neue Versionen geändert werden. Rückgängig machen ohne neue Version zu erzeugen geht halt nur solange die Änderungen lokal sind. Ich sehe hier kein Problem, es geht technisch einfach nicht anders.

Immerhin sieht man hier, dass sich nichts geändert hat: https://overpass-api.de/achavi/?changeset=54172357
OSMCha dagegen ist komplett verwirrt: https://osmcha.mapbox.com/changesets/54172357

Gar nicht erst hochladen, sondern endlich mal, wie vor Monaten gefordert, lokale Changesets vorhalten...

Das geht auch netter, Harald. Noch so eine Entgleisung und du musst dich nicht wundern wenn ich dir überhaupt nicht mehr antworte. Ich habe keine Lust mehr, deine auf falschen Fakten basierenden Denunziationen zu widerlegen.

Erstmal, siehe mmd. Genauer: Rückgängig gemachte schon hochgeladene Änderungen werden in den gleichen Änderungssatz getan aus dem sie kommen, weil sie idR thematisch und zeitlich (wie auch in deinem Fall) zusammenhängen, da sie aus der gleichen Begehung stammen. Das gilt auch für die Korrekturen, die man üblicherweise nach Nutzen der Rückgängig-Funktion macht.

Gar nicht erst hochladen, sondern endlich mal, wie vor Monaten gefordert, lokale Changesets vorhalten...

Änderungen werden schon seit es die App gibt lokal vorgehalten! 😠

Einstellungen -> Auto-Synchronisierung -> Aus

Damit werden Aufgaben nur runter- und Antworten nur hochgeladen wenn du das explizit über das Menü triggerst ("Hier nach Aufgaben suchen" / "Antworten hochladen"). Die Rückgängig-Funktion funktioniert auch lokal.

Also habe ich fünfmal auf dem Undo Button geklickt, fünfmal wurde (-1) bei den Sternen angezeigt, aber die eigentlichen Sterne weiter aufaddiert, macht jetzt also +10 Sterne, obwohl nichts geändert/beigetragen wurde.

Die Sterne zählen nur die Anzahl der Änderungen, die du hochgeladen hast.

Und genau das ist das Problem an der ganzen APP: MAN WEISS NICHTS WAS SIE TUT .. muss ich wirklich erst eine Standardeinstellung (Auto-Sync = AN) ausschalten, damit solcher BULLSHIT gar nicht erst passiert?! Gibt es nicht genug andere Trigger Events, welche die APP nutzen könnte (z.B. beenden der App, wechseln des Quests, usw.)

Und nochwas: STERNE zählen obwohl der Datenbank schlussendlich REIN GAR NICHTS an Information hinzugefügt wurde, AUßER die Historie aufzublähen ist dann wohl *sarkasmusAN* Gamification in PERFEKTION *sarkasmusAUS* ?! 😠

PS: ich geh dann morgen mal spielen ... laufe durch die Straßen, setze hunderte von Hausnummern, Oberflächen von Straßen, Stockwerke von Gebäuden und mache dann beim zurücklaufen einfach solange UNDO bis ich wieder am Anfang bin ... Ähm wo gab's die Highscore Liste nochmal gleich?

Harald Hartmann wrote:

... damit solcher BULLSHIT gar nicht erst passiert?!...
... *sarkasmusAN* Gamification in PERFEKTION *sarkasmusAUS* ?! 😠...
...sondern endlich mal, wie vor Monaten gefordert..

Ich kann leider keinen Grund erkennen, warum bei diesem Thema in Ton und Umgang eskaliert werden muss.

Mir ist keine Instanz in osm bekannt, die festlegen darf, wie ein Programm funktionieren darf, noch viel weniger erkenne ich ein Recht Einzelner, Forderungen an andere erfüllt zu bekommen.

Mit Sicherheit hat die App von westnordost erheblichen Verbesserungsbedarf in bestimmten Bereichen, Fehlerhinweise durch die Community sind dabei bestimmt wertvoll. Dabei hat jeder das Recht auf seine Meinung niemand muss um den heißen Brei reden.

Ich bin jedoch der Überzeugung, dass Meinungen sachlich formuliert - ansonsten besser seien gelassen werden.

Markus

Markus366 wrote:

Mir ist keine Instanz in osm bekannt, die festlegen darf, wie ein Programm funktionieren darf,

Schade eigentlich ... aber braucht es auch nicht, da es in OSM ja "Good Practices" (wenn teilweise auch unausgesprochen/undokumentiert) gibt.

Jeden Mapper würden wir durchaus freundlich darauf hinweisen, wenn er in einem Changeset Objekte mit vX ändern und im selbigen mit vY wieder zurücksetzt.

Naja und mmd gab mit seinem Beitrag westnordost wieder die Möglichkeit sich herauszureden und den schwarzen Peter erst einmal auf andere (Drittsysteme) zu schieben - wäre nicht das erste mal - um es dann nach langer Diskussion doch irgendwie - nach meinem Eindruck widerwillig - umzusetzen.

Und zum Schluß habe ich dennoch immer noch kein Verständnis dafür, warum man mit dieser App von der Couch aus agieren kann ... sollte doch sehr einfach möglich sein nur Aufgaben im, sagen wir mal max. 250m Radius um die aktuelle GPS Position abzuarbeiten ... nur dann wäre es eine (berechtigte) "VorOrt Survey".

PS: Und nur zur Info, der Threadtitel kommt nicht von mir!

Markus366 wrote:

Ich bin jedoch der Überzeugung, dass Meinungen sachlich formuliert - ansonsten besser seien gelassen werden.

Soll ich jetzt deswegen "lindnern"? (lieber besser nichts sagen, als etwas falsch zu sagen)

Also ich finde die App auch nicht perfekt, das Thema was Harald anspricht, wäre aber auch aus meiner Sicht auch ein Optimierungsgrund.
Autosync, von der der Benutzer nichts weiß ist nicht optimal.

Verschiedene Aufgaben finde ich ebenfalls unnötig und manche eher gefährlich als gewinnbringend ...

... ABER ...
die App ist eine der ersten, die wirklich versucht "schlechte" Eintragungen durch mangelhaftes Wissen zu verhindern.
In der Regel sind die Changeset in meiner Gegend so gut, dass ich die ungesehen durchwinken kann.

Ob die nun ein paar mehr Changesets erzeugen oder weniger ... mir egal, Hauptsache der Mehrwert stimmt.

Inzwischen kann man auch Aufgaben deaktivieren, hab ich sofort gemacht. Auch hier wäre es vielleicht sinnvoll am Anfang nur Standardaufgaben zu aktivieren und den ganzen Kinderkram (Aufgaben, die sinnvoll werden, wenn erst mal Straßen und Häußer da sind) manuell aktivieren zu müssen.
Etwas defensivere App-Einstellungen, ähnlich wie bei den Aufgaben ...., wären zu begrüßen.

R0bst3r wrote:

Inzwischen kann man auch Aufgaben deaktivieren, hab ich sofort gemacht.

Schön - aber wie? Bei der Version 2.3, die sowohl im PlayStore als auch bei FDroid angeboten wird, finde ich jedenfalls keine Info, wie man das macht.

Gruss
walter

wambacher wrote:

R0bst3r wrote:

Inzwischen kann man auch Aufgaben deaktivieren, hab ich sofort gemacht.

Schön - aber wie? Bei der Version 2.3, die sowohl im PlayStore als auch bei FDroid angeboten wird, finde ich jedenfalls keine Info, wie man das macht.

Gruss
walter

Einstellungen --> Aufgabenauswahl ...

Gruß
Stephan

@wambacher: wieso hast du das nicht gefunden? Die App ist doch voll intuitiv... oder liegt es am nicht vorhandenem sonst üblichen Changelog Fenster?

Ach ja, sorry, habe wohl gerade mein Sarkasmus Flag vergessen...

tux67 wrote:

Einstellungen --> Aufgabenauswahl ...

Lieb gemeint, aber ...

Gruss
walter

@Harald: irgendwie hab ich - wie einige Kollegen - den Eindruck, dass du derzeit nicht gerade gut drauf bist 🙁
Lindnern wäre hier besser gewesen.

wambacher wrote:

tux67 wrote:

Einstellungen --> Aufgabenauswahl ...

Lieb gemeint, aber ...

Ok, also die Version, die der BlähStore bei mir anbietet (und auch F-Droid) ist 3.2 .. die ist bei mir auch seit dem 25.11. installiert.
Wenn also die Versionsnummer, die du oben genannt hast kein Zahlendreher ist, dann erklärt das vielleicht die unterschiedlichen Features.

Davon ab sehe ich hier immer mehr StreetComplete user, wo ich den Mehrwert der Beiträge aber selten sehe, weil es sich meist um recht isolierte Updates einzelner Objekte handelt. Zur Zeit kommt mir das noch ähnlich suspekt vor, wie viele Wheelmap oder maps.me Einträge.

Gruß
Stephan

tux67 wrote:

Ok, also die Version, die der BlähStore bei mir anbietet (und auch F-Droid) ist 3.2 .. die ist bei mir auch seit dem 25.11. installiert.
Wenn also die Versionsnummer, die du oben genannt hast kein Zahlendreher ist, dann erklärt das vielleicht die unterschiedlichen Features.

Oops, bin bei PlayStore darauf reingefallen, dass er mir "installiert" meldet - und das hat eben nicht zu bedeuten, dass ich auch die neueste Version installiert habe, sondern nur das Produkt als solches 🙁

Und bei FDroid war es tatsächlich der von dir erwartete Zahlendreher.

Danke und Gruss
walter, der sich jetzt für 5 Minuten in seine Schämecke stellt.

na dann versuche ich es halt mal furztrocken, ganz ohne Emotion (und das sollte eigentlich jemandem Sorgen machen**)

R0bst3r wrote:

...die App ist eine der ersten, die wirklich versucht "schlechte" Eintragungen durch mangelhaftes Wissen zu verhindern.

+1, ja, ihr mögt es vielleicht nicht glauben, aber das sehe ich in der Tat genauso ... dann hört es aber leider auch schon wieder auf

• keine (wirkliche) Dokumentation (der App, bzw. der Quests, welche viel transparenter sein müssten) .. die wurde übrigens nicht nur von mir "gewünscht"
  
• keine direkte Anzeige des Changelogs .. muss man manuell bei StreetComplete - Releases nachgucken
  
• teilweise "Alleingänge" über die Community hinweg ..
  
• keine (gesicherte) VorOrt Survey App, da man GPS nicht aktivieren muss
  
• nicht nachvollziehbare Gamification Ansätze (2x Bonus für's Nichtstun, siehe oben)
  
• "start starting - stop finishing" anstatt "start finishing - stop starting" .. mein persönlicher Eindruck
  

tux67 wrote:

Zur Zeit kommt mir das noch ähnlich suspekt vor, wie viele Wheelmap oder maps.me Einträge.

+1

**PS: Und jetzt habt ihr, zumindest was StreetComplete angeht, wieder Ruhe vor mir, ich bin dann mal raus hier und deinstalliere StreetComplete, dann muss ich mich darüber schon mal nicht mehr Aufregen.

tux67 wrote:

Davon ab sehe ich hier immer mehr StreetComplete user, wo ich den Mehrwert der Beiträge aber selten sehe, weil es sich meist um recht isolierte Updates einzelner Objekte handelt. Zur Zeit kommt mir das noch ähnlich suspekt vor, wie viele Wheelmap oder maps.me Einträge.

Um auch mal was Positives zu sagen: Ich „stolpere“ in BW auch über immer mehr StreetComplete-Beiträge. Ich bin zwar nicht 100% glücklich damit, dass da tlw. Hausnummern eingetragen werden, ohne anschließend auch gleich die Straßennamen zu ergänzen (das ist dann wohl mein Job 😉), aber bisher wirkten alle Einträge, die ich mir angesehen habe, vernünftig, manche sind sogar ausgezeichnet.

Insofern unterscheidet sich StreetComplete, auch wenn es nicht perfekt ist (gibt es das denn überhaupt bei Apps?), für mich schon wohltuend von Wheelmap etc. Wheelmap wäre an sich eine super Idee, aber wegen hier im Forum oft diskutierter Probleme sind viele viele Bearbeitungen suboptimal bis abwegig. StreetComplete dagegen trägt schon richtig gute Dinge zu unserer Datenbank bei.

Also lasst uns doch versuchen, durch konstruktive Kritik diese App noch besser zu machen, statt durch Gemotze die Fronten nur zu verhärten. 🙂

Chrysopras wrote:

Also lasst uns doch versuchen, durch konstruktive Kritik diese App noch besser zu machen, statt durch Gemotze die Fronten nur zu verhärten. 🙂

Guter Vorschlag .. das würde vielleicht einen neuen Thread unter einem weniger provokanten Titel vorrausstetzen, der vielleicht sogar vom Autoren von StreetComplete gestartet / maintained wird .. a La "StreetComplete - Verbesserungsvorschäge" oder so?!?

Ich denke bestehende Datenbestände von Usern ohne besonderes Hintergrundwissen erweitern/aktualisieren zu lassen - das stellt den Entwickler vor besondere Herausforderungen bzgl. der Quests und deren Implementierung.

Wenn man da helfen kann und die Hilfe akzeptiert wird .. warum nicht.

Gruß
Stephan

tux67 wrote:

Guter Vorschlag .. das würde vielleicht einen neuen Thread unter einem weniger provokanten Titel vorrausstetzen, der vielleicht sogar vom Autoren von StreetComplete gestartet / maintained wird .. a La "StreetComplete - Verbesserungsvorschäge" oder so?!?

Hat der Autor nicht eigentlich Github dafür vorgesehen? https://github.com/westnordost/StreetComplete/issues

dort kann man ohne Github-Kentnisse - allerdings mit einem Account - zentral alle Wünsche kundtun. Ich halte das für sinnvoller als wenn man sich an verschiedenen Stellen verzettelt. ich werde jedenfalls diesen Weg gehen.

Gruss
walter

wambacher wrote:

dort kann man ohne Github-Kentnisse - allerdings mit einem Account - zentral alle Wünsche kundtun. Ich halte das für sinnvoller als wenn man sich an verschiedenen Stellen verzettelt. ich werde jedenfalls diesen Weg gehen.

Klar - wenn man einen einen konkreten Änderungsvorschlag oder Fehler hat, macht das Sinn .. aber um Dinge zu erörtern, bevor daraus was konkretes wird, ist so ein bug/issue tracker doch nicht gedacht, oder?
Ausserdem ist die Reichweite an kundigen Kommentatoren hier vielleicht größer .. dachte ich ..

Gruß und schönes WE
Stephan

Harald Hartmann wrote:

ich bin dann mal raus hier und deinstalliere StreetComplete, dann muss ich mich darüber schon mal nicht mehr Aufregen.

Spätestens wenn man QA macht, nutzt das Deinstallieren gar nix, weil Du Streetcomplete hinterherwischen musst. Speziell bei opening_hours (siehe #13 von vor nem halben Jahr...) sind die Eintragungen teilweise so falsch, dass man überhaupt nicht erahnen kann, was eigentlich gemeint sein könnte.
Willkürliche aktuelle Beispiele:

Tu-Fr␣17:00-22:00+,␣Sa,Su␣22:00-18:00+

5.11. SC 2.4

Tu-Su␣19:00-18:00+

6.11. SC 2.3

MKnight wrote:

Speziell bei opening_hours (siehe #13 von vor nem halben Jahr...) sind die Eintragungen teilweise so falsch, dass man überhaupt nicht erahnen kann, was eigentlich gemeint sein könnte.
Willkürliche aktuelle Beispiele:

Tu-Fr␣17:00-22:00+,␣Sa,Su␣22:00-18:00+

5.11. SC 2.4

Tu-Su␣19:00-18:00+

6.11. SC 2.3

Das ist natürlich gar nicht schön. Wäre es möglich, StreetComplete mit einer etwas intelligenteren Eingabemaske für Öffnungszeiten zu versehen, die solche Dinge verhindert? Oder aber, falls das nicht möglich ist, mit einem nachgelagerten Öffnungszeiten-Parser, der zumindest einen Teil solcher offensichtlich unsinniger Eingaben erkennt und, statt sie zu speichern, dem Benutzer eine Fehlermeldung anzeigt? (Dass es ein Fehler sein muss, wenn in HH1:MM1-HH2:MM2 der Wert von HH2 < HH1 ist oder, wenn HH2 = HH1, MM2 <= MM1, sollte sich ja relativ leicht erkennen lassen. 🙂)

Chrysopras wrote:

Oder aber, falls das nicht möglich ist, mit einem nachgelagerten Öffnungszeiten-Parser, der zumindest einen Teil solcher offensichtlich unsinniger Eingaben erkennt und, statt sie zu speichern, dem Benutzer eine Fehlermeldung anzeigt?

Sorry, das könnte allenfalls eine Warnung sein. Oder müssen wir die Nachtbar, die jeden Tag von 22:00-03:00 offen hat, dann in in Mo-Su 00:00-03:00, 22:00-24:00 umschreiben?

user_5359 wrote:

Sorry, das könnte allenfalls eine Warnung sein. Oder müssen wir die Nachtbar, die jeden Tag von 22:00-03:00 offen hat, dann in in Mo-Su 00:00-03:00, 22:00-24:00 umschreiben?

Stimmt auch wieder. Gut, dann eben eine Warnung. 😉

Ich hab mir SC heute mal wieder kurz angeschaut und glaube, dass es eher an den Eingabemöglichkeiten UND Einstellmöglichkeiten liegt und weniger an der fehlenden Fehlerprüfung. (Welche bei den Beispielen in JOSM und anderen Tools mindestens eine Warnung wenn nicht gar einen Error wirft).

Bei der Eingabe in SC habe ich nirgends eine Möglichkeit gefunden zu sehen, was ich da überhaupt eingegeben habe. Jemand, der sich etwas unsicher ist, ob das korrekt ist, verwirft das evtl. deswegen, aber als Laie bekommt man das nicht mit und kippt es in die DB. In der Quintessenz heisst das für mich, dass speziell bei OH wahrscheinlich niemand, der seinen Job ernst nimmt und/oder hinterfragt, sinnvolle OH abkippen KANN.

Ich hab vor längerer Zeit mal ein paar Dinge auf SC abgekippt und heute gesehen, dass ich die nich hochgeladen hab. Ja nun, es gibt da so einen Button, wo man die letzte Eingabe rückgängig machen kann, aber weder, was die Eingabe war, noch, was die vorher waren.
Hab das mal abgekippt und schau mir morgen an, was ich kaputtgemacht hab.

Hm, es scheint tatsächlich praktisch wirkungslose Änderungssätze von StreetComplete zu geben – jedenfalls erkenne ich nicht, was hier:

https://www.openstreetmap.org/changeset/54290790

letztlich geändert worden wäre (die Straße wurde benannt und dann der Name wieder entfernt). Kommt so etwas öfter vor? Könnte man solche wirkungslosen Änderungssätze nicht irgendwie vermeiden?

Chrysopras wrote:

Könnte man solche wirkungslosen Änderungssätze nicht irgendwie vermeiden?

Ich glaube, dazu müssten sich die Entwickler mal auf das Mapper- und/oder OSM-Niveau herablassen*. Es gab zwar hier und anderswo diverse als konstruktiv zu verstehende Angebote in die Richtung, wirklich passiert ist imho nicht sehr viel.

• ODER Kritik nicht als Anpiss wahrnehmen, sondern als Hinweis, dass etwas kaputt oder Scheisse ist oder nicht funktioniert. Peinliches Beispiel: https://github.com/westnordost/StreetCo … issues/305 DAS hat mich angepisst. Dass man (als Mapper) versucht etwas zu verbessern und nur als Störfaktor oder Anpisser wahrgenommen wird weil es nicht in die Developer-agenda passt.
  

Edit:
Grad noch mal den ganzen issue gelesen:

Hmm, I don't understand the big interest on which rule separator to use.

Nach einer elend langen Diskussion ist das ein guter Indikator, sich von OH zu entfernen und sich auf andere Dinge zu konzentrieren. Bei den "anderen Dingen" sollte mal als Entwickler auch so fair ggü. der Community sein, Dinge, die man nicht überschaut einfach rauszuwerfen und nicht wochenlang Ahnungslosigkeit raushängen zu lassen.

P.s.Klingt wirklich pissig, ich weiss, ich will niemanden persönlich angreifen, ich meine es neutral und ernst.

--snip--

Hi,
in meiner Gegend finde ich in letzter Zeit oft das Tag "cycleway:both=(meistens no)" scheint zur Standardauswahl bei Straßen in StreetComplete 3.2 gehören.
Wird fast an jede Straße gekleistert. Ist das notwendig?

Gruß
svr54

surveyor54 wrote:

Wird fast an jede Straße gekleistert. Ist das notwendig?

Habe ich auch schon bemängelt; zumal surface, smoothness, lit, ... sinnvoller wären, wenn man schon einmal vor Ort ist.

geri-oc wrote:

Habe ich auch schon bemängelt; zumal surface, smoothness, lit, ... sinnvoller wären, wenn man schon einmal vor Ort ist.

Du kannst selber auswählen was Dir angezeigt werden soll. Ich habe zur Zeit nur die englischsprachige Version drauf. Da kann ich das wie folgt einstellen.

1.Oben rechts auf die 3 Punkte gehen.
2. Settings auswählen.
3. Runter scrollen bis Advanced.
4.Quest selection auswählen
5.Dann auswählen was man angezeigt bekommen möchte.

Unter anderem kannst da auch surface und lit auswählen.

5R-MFT wrote:

Du kannst selber auswählen ...

Ich bin aber der Meinung, wenn ich eine Straße / POI auswähle sollte schon angezeigt werden welche (Haupt-) Schlüssel vorhanden sind. Falls dann ein Schlüssel nicht vorhanden ist, kann ich erweitern oder extra eingeben. Ob ich die dann nutze ist eine andere Sache. Ob aber gerade cycleway:both=no wichtiger ist?

Und es sollte auch nur etwas eingetragen werden, wenn man vor Ort ist.

geri-oc wrote:

Ich bin aber der Meinung, wenn ich eine Straße / POI auswähle sollte schon angezeigt werden welche (Haupt-) Schlüssel vorhanden sind. Falls dann ein Schlüssel nicht vorhanden ist, kann ich erweitern oder extra eingeben.

Ich finde es praktisch das angezeigt wird was fehlt, denn ich kenne nicht alle Unterschlüssel und kann dann vor Ort den passenden aus de App auswählen. Zum Beispiel Dachformen. Zur besseren Übersicht habe ich mittlerweile nur einen Teil aktiviert .

Was mich stört ist das GPS. Während auf der OsmAnd die Position immer sehr genau ist, finde ich die Position bei StreetComplete immer verzögert dargestellt wird.

5R-MFT wrote:

Ich finde es praktisch das angezeigt wird was fehlt, denn ich kenne nicht alle Unterschlüssel und kann dann vor Ort den passenden aus de App auswählen.

Warum wird dann nur z.B. cycleway:both=no ergänzt und surface, smoothness, lit nicht?

Na gut - ich nutze SC nicht. Bin nur immer erstaunt, wenn solche einzelne Schlüssel auftauchen - obwohl wichtigeres fehlt. Auch z.B. bei wheelchair:toilets=no an einer Bushaltestelle.

Man kann die Häkchen in der Auswahl so setzten das z.B. nur surface und lit auftaucht wo es noch fehlt. In meiner Gegend habe ich zuerst surface und lit ergänzt. Bei anderer Gelegenheit die fehlenden Öffnungszeiten und die Haltestellenhäuschen. Irgendwann mache ich dann auch mal die cycleway so fern das mit no zu beantworten ist. Die Radwege überlasse ich den Radspezialisten.

Ich setzte immer nur 1 oder 2 Häkchen max. 3, um die Übersicht zu behalten, denn es gibt schon 28 Topics zum auswählen.

Ein User, der allein heut Nachmittag 22x folgende Frage verneinend als note in die Datenbank gepfeffert hat:

Unable to answer "Is there a cycleway in this street?" for https://www.openstreetmap.org/way/23917807 via StreetComplete 3.2:

Am Sonnenhang hat keinen Radweg

Dabei wäre grad hier ein Radweg unbedingt zu erwarten; wo, wenn nicht hier, Am Sonnenhang in Prittlbach, an einer sicherlich verkehrlich hochbelasteten Straße

Dem User gebe ich keine Schuld - der App hingegen schon. Wir brauchen einfach keine solche Schwemme an notes. Es gibt sowieso schon genug offene notes, die auf eine Bearbeitung warten. OSM sollte auch nicht kartieren, was alles nicht ist, sondern was vorhanden ist. Ansonsten überlege ich eine note-Schwemme auf jeden Feld-, Wald und Wiesenweg, der mir unterkommt, loszuschießen, um zu vermerken, dass dort weder Fahrradwege, Beleuchtung, Bürgersteige, Busspuren etc. vorhanden sind. Und zwar alles einzeln.

Da hat der betreffende User die App aber definitiv falsch bedient. Ansonsten hätte diese keine notes, sondern ein cycleway:both=no ausgeworfen.

Und ich finde das mappen von cycleway:both=no definitiv nicht verwerflich, da das definitiv klarstellt, dass es hier keinen Radweg gibt. Damit wird ausgeschlossen, dass die Straße nicht einfach nur noch nicht gemappt wurde (was auch noch sehr oft vorkommt). Die Frage ist, wie sich die App verhält, wenn es einen benutzungspflichtigen straßenbegleitenden Radweg gibt. Dann wäre nämlich bicycle=use_sidepath angebracht. Wenn das dann da dran geklatscht wird, ohne dass der Radweg schon gemalt wurde, könnte das zu Falsch-Negativ-Fehlern kommen.

Für residental und alles da drunter ist die Info sicherlich nicht notwendig, da kann ich allerdings nicht sagen, wie sich die App hier verhält. Aber auch hier bin ich eig der Meinung, dass es besser ist, die Info zu haben, als dass es mögliche Lücken in der Abdeckung gibt.

Viele Grüße

hsimpson wrote:

da kann ich allerdings nicht sagen, wie sich die App hier verhält.

Wenn du nicht weisst, wie sich die App verhält, wie kommst Du dann drauf, dass es ein Fehler beim User wäre?

MKnight wrote:

hsimpson wrote:

da kann ich allerdings nicht sagen, wie sich die App hier verhält.

Wenn du nicht weisst, wie sich die App verhält, wie kommst Du dann drauf, dass es ein Fehler beim User wäre?

Bitte nochmal genau lesen 😉

Ich habe mich nur darauf bezogen, dass ich nicht weiß, ob die App bicycle=use_sidepath mappt.

Da die App offensichtlich bereits für einige oneway:bicycle=no verantwortlich ist, habe ich daraus geschlossen, dass es einen Button "Kein Radweg" gibt und der User daher keine Notes erstellen musste um das eintragen zu lassen.

Viele Grüße

Kann die Äpp eigentlich erkennen, ob eine Straße einen separat gemappten begleitenden Radweg hat?
In dem Fall soll ja nicht zusätzlich cycleway=* getaggt werden.

hsimpson wrote:

Und ich finde das mappen von cycleway:both=no definitiv nicht verwerflich, da das definitiv klarstellt, dass es hier keinen Radweg gibt. Damit wird ausgeschlossen, dass die Straße nicht einfach nur noch nicht gemappt wurde (was auch noch sehr oft vorkommt).

Und ich bin der Meinung, dass wir keine Negativ-Datenbank mit Einträgen brauchen, die vor allem der Befriedigung irgendwelcher Apps dienen. Tagging for the app sozusagen.
Ansonsten gibt es - auch nur ein Beispiel von vielen - so etwas schönes wie hier aus dem recycling-Bereich: http://www.openstreetmap.org/node/2277053564
20x "no", 1x "yes"
Sollen so Straßen getaggt werden, dann vielleicht auch für jede residential noch inklusive foot=yes und bicycle=yes? Denn weiß ich in letzter Konsequenz, ob Fußgänger oder Radfahrer nicht doch die Passage hier verwehrt ist? Das muss doch immer erstmal festgestellt sein!

Leicht ironische Grüße 🙂

Vielleicht könnte man ja als Lösung für manches "Tagging for the app" Standardwerte einführen, aber ich weiß, daß ist ein alter Hut...
Z B. finde ich, dass man für highway=residential sidewalk=both, surface=asphalt und cycleway=no erwarten kann. Überall da, wo das nicht zutrifft, wird dann sidewalk und cycleway getaggt. Überall wo's zutrifft, nicht. Aber klar, jetzt kommt wieder jemand und sagt, dass das von Land zu Land unterschiedlich ist und so weiter... Die Frage ist aber, wohin das führen soll.

EDIT: Falsche Aussage von mir korrigiert.

chris66 wrote:

Kann die Äpp eigentlich erkennen, ob eine Straße einen separat gemappten begleitenden Radweg hat?
In dem Fall soll ja nicht zusätzlich cycleway=* getaggt werden.

Ja, die App schließt Straßen, die einen Abstand von 15 Metern oder weniger zu einem seperaten Radweg haben, aus und zeigt für diese folglich keine Quests an (https://github.com/westnordost/StreetCo … y.java#L24)

Cool, hätte ich jetzt nicht vermutet.

Moin
Mir sind gestern paar "Feldwege" mitten in der Stadt aufgefallen, die sich als bisher namenlose Ex-Pedestrians entpuppten aus diesem und vor allem diesem Changesets, beide von StreetComplete 3.6.
Beim Korrigieren festgestellt, dass sowas in der Ecke schon mal passiert ist *), was diesem CS zu entnehmen ist mit SC 2.3.
Gibt es diesen offensichtlichen bug immer noch?

• ) den Weg hat's schon 2x erwischt ...
  

MitteloberrheinischerWaldameisenschreck wrote:

Gibt es diesen offensichtlichen bug immer noch?

Jetzt hatte ich ganz kurz eine ganz gemeine Antwort im Sinn .. aber die kneif ich mir .. keine Fiesitäten vor dem Wochenende 😉

Gruß
Stephan

Ich denke mal das hier dürfte die entsprechende Stelle im Questcode sein, d.h. nach meiner sehr subjektiven bisherigen Wahrnehmung wird dir westnordost daraufhin antworten, dass es sich hierbei leider um einen Bedienerfehler handelt und er sich nicht zuständig fühlt ... oder er könnte dir entgegen, dass es sich hierbei um einen footway anstatt um einen pedestrian handelt

MitteloberrheinischerWaldameisenschreck wrote:

Gibt es diesen offensichtlichen bug immer noch?

Hab es gerade eben mal überprüft:
Das sollte kein Bug sein, sondern viel mehr ein Fehlverhalten des Nutzers:
Stellt die App dem Nutzer die Frage wie eine Straße heißt, kann der Nutzer natürlich den Straßennamen eintragen, aber auch als weitere Antwortmöglichkeit auswählen, dass diese Straße gar keinen Namen hat. Mit dieser Antwort öffnet sich dann ein weiterer Dialog, in dem der Nutzer angeben kann, wieso die Straße keinen Namen hat. Unter anderem sind dies:
- Ist bloß so etwas wie eine Zufahrt -> ändert den Weg zu "highway=service"
- Ist nur ein Feld- oder Waldweg -> ändert den Weg zu "highway=track"!
- Etwas anderes -> lässt den Nutzer eine Notiz hinterlassen
- Sie hat einfach keinen Namen -> fügt "noname=yes" hinzu

Der Nutzer hat hier wahrscheinlich fälschlicherweise die zweite Antwort gewählt, obwohl es eher die letzte sein sollte...

Harald Hartmann wrote:

nach meiner sehr subjektiven bisherigen Wahrnehmung wird dir westnordost daraufhin antworten, dass es sich hierbei leider um einen Bedienerfehler handelt und er sich nicht zuständig fühlt

Oder ich mach das einfach... 🙂

ENT8R wrote:

MitteloberrheinischerWaldameisenschreck wrote:

Gibt es diesen offensichtlichen bug immer noch?

Hab es gerade eben mal überprüft:
Das sollte kein Bug sein, sondern viel mehr ein Fehlverhalten des Nutzers:
Stellt die App dem Nutzer die Frage wie eine Straße heißt, kann der Nutzer natürlich den Straßennamen eintragen, aber auch als weitere Antwortmöglichkeit auswählen, dass diese Straße gar keinen Namen hat. Mit dieser Antwort öffnet sich dann ein weiterer Dialog, in dem der Nutzer angeben kann, wieso die Straße keinen Namen hat. Unter anderem sind dies:
- Ist bloß so etwas wie eine Zufahrt -> ändert den Weg zu "highway=service"
- Ist nur ein Feld- oder Waldweg -> ändert den Weg zu "highway=track"!
- Etwas anderes -> lässt den Nutzer eine Notiz hinterlassen
- Sie hat einfach keinen Namen -> fügt "noname=yes" hinzu

Der Nutzer hat hier wahrscheinlich fälschlicherweise die zweite Antwort gewählt, obwohl es eher die letzte sein sollte...

Harald Hartmann wrote:

nach meiner sehr subjektiven bisherigen Wahrnehmung wird dir westnordost daraufhin antworten, dass es sich hierbei leider um einen Bedienerfehler handelt und er sich nicht zuständig fühlt

Oder ich mach das einfach... 🙂

Sry, aber wer man eine Fußgängerzone nicht von einem Feldweg unterscheiden kann, dem ist auch nicht merh zu helfen...

Da kann man dem Entwickler wirklich keinen Vorwurf machen.

Bitte solche Changesets auch kommentieren! Auch wenn der User nur mit StreetComplete arbeitet, hat er trotzdem ein gültiges OSM-Konto und kann daher auch auf seine Fehler aufmerksam gemacht werden!

Grüße

Okay hsimpson, ich mache dir folgendes Angebot: du bekommst von mir ein Bier ausgegeben, wenn du erfolgreich einen der User erreichst und eine entsprechende Antwort erhälst... also dahingehend, dass man ihnen auf Grund mangelnder Unterscheidungskompetenz nicht mehr helfen könne.

hmm,
- Miggel seit 7.11.2007 angemeldet und alle paar Jahre mal ganze 6 Edits
- und olvagor macht nicht den Eindruck, als ob er den Fehler bewusst gemacht hat

hsimpson wrote:

Sry, aber wer man eine Fußgängerzone nicht von einem Feldweg unterscheiden kann, dem ist auch nicht merh zu helfen...

Da kann man dem Entwickler wirklich keinen Vorwurf machen.

Doch, ich denke schon. Nämlich den, dass er dem Nutzer die Konsequenz seiner Angabe nicht klar macht.

Ich habe das Interface jetzt nicht gesehen, aber wenn es wie oben beschrieben ist, kann ich gut verstehen, wenn jemand denkt, dass er hier wirklich nur die Begründung für die App angibt (für die "Naja, so ne Fußgängerzone ist wie so ein Feldweg, das ist zwar Weg, aber nicht benannt") und nicht die Klassifizierung ändert. Dazu kommt die kleine Menge an Auswahlmöglichkeiten (service, track), wo viele andere denkbar wären (vor allem footway, path, etc.).

Hier wäre es durchaus Sache des Entwicklers, das Interface deutlicher zu gestalten. Als Vorschlag könnte der Dialog vielleicht eher so aussehen:

• Es handelt sich hierbei nicht um [aktueller highway-key], sondern um... (würde eine längere Liste üblicher highway-keys öffnen, aus denen einer ausgewählt werden kann, wobei entweder vor oder nach der Auswahl eines neuen Schlüssels ein Hinweis angezeigte werden könnte im Sinne von "Wegtyp ändern" bzw."Soll der Typ des Wegs wirklich auf [neuer highway-key] geändert werden?")
  
• Hat einfach keinen Namen
  
• Etwas anderes
  

errt wrote:

Dazu kommt die kleine Menge an Auswahlmöglichkeiten (service, track), wo viele andere denkbar wären (vor allem footway, path, etc.).

Die aber auch Sinn macht, denn ich glaube nicht, dass jemand eine einen (in der Realität) Fußweg als Straße in OSM einträgt. (Die App sucht nur nach Straßen ohne Namen und nicht Fußwege...)

errt wrote:

• Es handelt sich hierbei nicht um [aktueller highway-key], sondern um... (würde eine längere Liste üblicher highway-keys öffnen, aus denen einer ausgewählt werden kann, wobei entweder vor oder nach der Auswahl eines neuen Schlüssels ein Hinweis angezeigte werden könnte im Sinne von "Wegtyp ändern" bzw."Soll der Typ des Wegs wirklich auf [neuer highway-key] geändert werden?")
  

In der ganzen App ist nie die Rede von OSM-Tags und -Values, weil die App vor allem für neuere Nutzer gedacht ist, die evtl. gar keine Ahnung von OSM haben... Insofern kann man hier dem Nutzer keine Liste an irgendwelchen highway-Tags vorsetzen sondern muss die Werte geschickt in Worte verpacken. Und so wird es ja im Moment quasi auch schon gemacht...

Aber genau dann sind wir bei dem Punkt angekommen, wo wir gar nicht mehr anders können, also solche changesets zwangsweise zu reviewen und gesondert freizugeben ...

@ENT8R: Ja, ich ging von einer entsprechenden Übersetzung, nicht von den konkreten Werten aus. Mir geht es aber gar nicht primär darum, sondern darum a) klar zu machen, dass die Auswahl den Wegtyp ändern wird, b) dass es mehr als nur zwei oder drei Typen in Frage kommen, auch wenn die vielleicht die häufigsten sein mögen (aber wie man sieht taucht zumindest pedestrian halt auch auf) sowie c) die Möglichkeiten, die den Wegtyp nicht ändern, prominenter darzustellen, in dem nicht mehrere verschieden Wegtypen auf der gleichen Auswahlebene wie diese Möglichkeiten angezeigt werden. Zusammen sollten diese drei Punkte dem Nutzer klarer zeigen könne, welche Antwort hier die Situation am Besten beschreibt. Denn wie gerade da, wo eben nicht konkrete Tags angezeigt, sondern nur verklausuliert werden, scheint mir das eben nicht klar zu sein, was welche Antwort bewirkt und ob man sie auswählen sollte. Denn wer sagt "Ich kann dem Benutzer nicht zumuten, den Unterschied zwischen highway=track und highway=path zu kennen", der sollte auch sagen "Ich kann dem Benutzer nicht zumuten, zu erkennen, ob seine Antwort nur eine (vielleicht applikationsinterne) Notiz ist oder ob das eine konkrete Änderung der Datenbank bewirkt."

Hier wird durch StreetComplete an jeden Fußweg (ohne ein Namensschild) der Name der Straße gemappt:
www.openstreetmap.org/#map=19/51.05944/13.74285

Der Name ist in m.E richtig in der Relation enthalten. Habe zwei Cs kommentiert:
http://www.openstreetmap.org/changeset/55473269
http://www.openstreetmap.org/changeset/52728173

geri-oc wrote:

Und ich denke immer ich mache einen Fehler, wenn ich eine Korrektur nach 2-3 Minuten in einem neuem Änderungssatz "nachlade" ...

Hihi, geht mir immer genau so... habe teilweise ein total schlechtes gewissen, dass mir "dass" nicht schon im ersten Änderungssatz aufgefallen ist ;-)

access=yes an Parkplatz ergänzen - ist das sinnvoll / nötig ?
https://www.openstreetmap.org/way/161124792/history

Was kommt sonst noch alles ?

PT-53 wrote:

access=yes an Parkplatz ergänzen - ist das sinnvoll / nötig ?
https://www.openstreetmap.org/way/161124792/history
Was kommt sonst noch alles ?

Falsch ist es nicht, aber überflüssig. boat=no wäre eine Steigerung 😄.
Löschen lohnt aber mMn nicht, gibt nur einen weiteren Eintrag in der DB.

Sinnvoll wäre u.U. ein (freundlicher) CS-Kommentar als Hinweis für den Ersteller.
Wenn der es löscht - auch recht.

Wichtiger wäre eine Anbindung ans Straßennetz (Zufahrt). Wird von QA-Tools angemeckert und war möglicherweise Auslöser des Zusatzes (der nebenbei die Fehlermeldung nicht beseitigt).

seichter wrote:

Sinnvoll wäre u.U. ein (freundlicher) CS-Kommentar als Hinweis für den Ersteller.
Wenn der es löscht - auch recht.

Ein CS-Kommentar wird da nichts bringen. Das war ein Anfänger mit 6 CS, alle mit StreetComplete. Der macht das, was ihm die App vorgibt.

Grüße

PT-53 wrote:

Ein CS-Kommentar wird da nichts bringen. Das war ein Anfänger mit 6 CS, alle mit StreetComplete. Der macht das, was ihm die App vorgibt.

Die Verwendung von access=yes ist nicht falsch.
Selbst der Profi-Editor JOSM bietet das bei Parkplätzen unter "Genereller Zugang" ganz oben in der Liste als "ja" an.
Ich finde so eine Information schon oft sehr hilfreich, da viele private Parkplätze einfach ohne access eingetragen werden, daraus dann zu schließen, diese seien öffentlich, geht da oft schief.
Auch im Wiki wird access=yes empfohlen:

access | yes/customers/permissive/private | Zur Unterscheidung zwischen öffentlichen Parkplätzen, Kundenparkplätzen (wie beispielsweise an Kinos) und privaten Parkplätzen (wie beispielsweise Mitarbeiter einer Firma). Ein öffentlicher Parkplatz wird in diesem Fall mit yes gekennzeichnet.

https://wiki.openstreetmap.org/wiki/DE: … ty=parking

Also bitte nicht eine App dafür verantwortlich machen, dass diese das anbietet, was empfohlen wird.

whb wrote:

Also bitte nicht eine App dafür verantwortlich machen, dass diese das anbietet, was empfohlen wird.

Ok, das wird ja auch bei anderen Tags gemacht, dass ein Eintrag gesetzt wird als Zeichen dafür, dass der Wert überprüft wurde.
Damit kann man default von "ich weiß nicht" unterscheiden und man ist weniger von den (eigentlich zwingenden) access=private etc abhängig (s.o.).

Ob das "access=yes" wirklich richtig gesetzt wurde, steht dann auf einem anderen Blatt, das ist aber das Schicksal von OSM 🤔.

Streng genommen wäre access=yes an Parkplätzen nur richtig, wenn man dort auch Pferde, Snowmobile, LKW etc. parken darf.

Aber bekanntlich ist ja bei OSM alles eher fuzzy-logic. 😉

chris66 wrote:

Streng genommen wäre access=yes an Parkplätzen nur richtig, wenn man dort auch Pferde, Snowmobile, LKW etc. parken darf.
Aber bekanntlich ist ja bei OSM alles eher fuzzy-logic. 😉

Ganz so fuzzy ist das nicht: In den Parkplatz darf zunächst alles rein, was auch auf die Straße darf.
Wenn nicht für Wohnmobile o.ä., steht ein Zusatzschild, das man im Prinzip ins Tagging aufnehmen sollte.

seichter wrote:

Ganz so fuzzy ist das nicht: In den Parkplatz darf zunächst alles rein, was auch auf die Straße darf.

Alles klaro: https://youtu.be/PTKmB5HjbPs

Gruss
walter

seichter wrote:

Ok, das wird ja auch bei anderen Tags gemacht, dass ein Eintrag gesetzt wird als Zeichen dafür, dass der Wert überprüft wurde.

Ich finde es seit längerem frustrierend, dass StreetComplete das Setzen überflüssiger Defaultwerte in offenem Widerspruch zu vorherigen Konventionen etabliert. Es war nämlich eigentlich lange Zeit Konsens, dass Dinge wie access=yes, surface=asphalt, oneway=no (kommt bestimmt noch) eben nicht gesetzt werden, weil sie die Liste der Tags unnötig unübersichtlich machen und echte Informationen (und Änderungen an solchen echten Informationen) im Rauschen des eigentlich Selbstverständlichen untergehen.

Es ist auch keineswegs eine nachhaltige Lösung, um zu dokumentieren, dass jemand diese Info nachgeprüft hat, Denn man muss so was ja nicht nur einmal überprüfen, sondern regelmäßig. Das kann aber ein access=yes nicht leisten – das wird auch in zehn Jahen noch in der DB stehen und eine Überprüftheit suggerieren.

Tordanik wrote:

...surface=asphalt,..

Wieso denn das?

Thomas8122 wrote:

Tordanik wrote:

...surface=asphalt,..

Wieso denn das?

Weil in unseren Breiten Straßen bestimmter Typen üblicherweise asphaltiert sind und es daher nicht wirklich nützlich ist, diese Information explizit mit anzugeben. Stattdessen macht es aus meiner Sicht mehr Sinn, die vergleichsweise wenigen Ausnahmen entsprechend zu taggen.

Tordanik wrote:

Weil in unseren Breiten Straßen bestimmter Typen üblicherweise asphaltiert sind und es daher nicht wirklich nützlich ist, diese Information explizit mit anzugeben. Stattdessen macht es aus meiner Sicht mehr Sinn, die vergleichsweise wenigen Ausnahmen entsprechend zu taggen.

Von Autobahnen bis runter zur Kreisstraße und residential dürfte das bei uns i.d.R. zutreffen und stimme Dir voll zu. Bei unclassified, service, track, und path etc. sehe ich das anderst und ergänze surface und smoothness nach Ortsbesichtigung.

Grüße

Tordanik wrote:

...

Es ist auch keineswegs eine nachhaltige Lösung, um zu dokumentieren, dass jemand diese Info nachgeprüft hat, Denn man muss so was ja nicht nur einmal überprüfen, sondern regelmäßig. Das kann aber ein access=yes nicht leisten – das wird auch in zehn Jahen noch in der DB stehen und eine Überprüftheit suggerieren.

Was wir denn da suggeriert? Der Tag wurde zum Zeitpunkt der Setzung faktisch gesichtet (soweit der Ersteller nicht schummelt). In 10 Jahren wird man in der DB halt sehen, dass der Tag ein Jahrzehnt alt ist und ihn entsprechend bewerten.

Dass es bei OSM keinen ordentlichen geregelten Umgang mit Default Werten oder Aktualisierungen der Werte gibt kann man der App nicht vorwerfen. Sie bewegt sich meiner Meinung nach wegen ihrer schlichten und effizienten Bedienung in einem Feld, dass man bei OSM noch nicht ausreichend beackert hat, da es durch den hohen Aufwand bisher zu wenig angewandt wurde. Und ja, dabei kommen mit Sicherheit auch sehr irritierende Sachen bei raus.

Also wenn die App eine Frage enthält ähnlich wie: "Ist dieser Parkplatz frei zugänglich?" und mit ja, nein, privat, nur für Kunden etc. beantwortet wird, dann kann das Ergebnis durchaus mehrwert haben. Heute weis ich nämlich in der Regel nicht, ob ich auf den vielen Parkplätzen in OSM parken darf oder nicht.

seichter wrote:

chris66 wrote:

Streng genommen wäre access=yes an Parkplätzen nur richtig, wenn man dort auch Pferde, Snowmobile, LKW etc. parken darf.
Aber bekanntlich ist ja bei OSM alles eher fuzzy-logic. 😉

Ganz so fuzzy ist das nicht: In den Parkplatz darf zunächst alles rein, was auch auf die Straße darf.
Wenn nicht für Wohnmobile o.ä., steht ein Zusatzschild, das man im Prinzip ins Tagging aufnehmen sollte.

Die Frage ist nur was bedeutet ein "access=yes" überhaupt (an einer Strasse, oder von mir aus an einem Parkplatz)?

Heisst das alle Beschränkungen sowohl für Nutzungsart wie auch Farhrzeugsart/Bewegungsart aufgehoben?

Muss ich also tatsächlich ein boat=no und ein motor_boat=no an so einer Strasse pappen (hab ich schon gesehen)?

Kriegt jeder das dann auch hin die korrekten Breiten-, Höhen- und Längenbeschränkungen wieder hin (pro Fahrzeugart)?

Pappt da auch jeder ein carriage=no an die Autobahn?

Und so weiter.

Es stimmt access=yes ist ein guter Marker,

DAFÜR DAS FASLCH GETAGGT WURDE

SimonPoole wrote:

Es stimmt access=yes ist ein guter Marker,

DAFÜR DAS FASLCH GETAGGT WURDE

Naja, solange auf dem Parkplatz kein verbotsschild für Bote steht, dürfen die da aber rauf. (ob sie es können ist ein völlig anderes Thema)

In diesem CS https://www.openstreetmap.org/changeset … 20/9.77551 wurden 3 Hausnummern ergänzt. An diesen Gebäuden fehlt auch noch die Straße.
Fragt StreetComplete nicht beides gleichzeitig ab ?
Das wäre suboptimal.

PT-53 wrote:

Fragt StreetComplete nicht beides gleichzeitig ab ?

StreetComplete fragt nicht beides gleichzeitig ab. Jedenfalls wurde das in einer früheren Diskussion so festgestellt … Auch ich war und bin (siehe meine damaligen Posts) der Meinung, dass Hausnummer und Straßenname/Place-Name immer zusammen erfasst werden sollten.

PT-53 wrote:

Fragt StreetComplete nicht beides gleichzeitig ab ?
Das wäre suboptimal.

Nein, immer nur eine einzelne Aufgabe.
Der Benutzer kann aber Adresse und Hausnummer nacheinander abarbeiten und dann, je nach Einstellung, zusammen hochladen.

R0bst3r wrote:

PT-53 wrote:

Fragt StreetComplete nicht beides gleichzeitig ab ?
Das wäre suboptimal.

Nein, immer nur eine einzelne Aufgabe.
Der Benutzer kann aber Adresse und Hausnummer nacheinander abarbeiten und dann, je nach Einstellung, zusammen hochladen.

Ein ausdrücklicher Hinweis, daß an diesem Objekt noch mehr Daten fehlen, fehlt dann wohl. Und deshalb bleibt das Objekt halt weiterhin unvollständig erfaßt = suboptimal

Ich sehe da kein großes Problem drin. Denn SC liefert hier etwas wertvolles aus der Surveyperspektive, das vom Remote Tagging nicht erfasst werden kann. Natürlich ist ein Haus, das von der Adressangabe nur die Nummer hat unvollständig erfasst. Aber gerade die Nummer ist ein Problem das SC perfekt lösen kann, aber allen Häusern an einer Strasse die Adressangaben zu verpassen geht viel leichter in JOSM.
Vielmehr noch geht es noch leichter wenn die Nummer schon da ist um anhand der fortlaufenden Reihe zu erkennen, welche Adressen welchen Strassen zugeordnet sind (an Kreuzungen beispielsweise).

PT-53 wrote:

Und deshalb bleibt das Objekt halt weiterhin unvollständig erfaßt

Na und? Das kann man ja mit Qualitätssicherungstools auffinden und vervollständigen.

Hakuch wrote:

Na und? Das kann man ja mit Qualitätssicherungstools auffinden und vervollständigen.

Und warum soll das nicht gleich mit StreetComplete erledigt werden?
Arbeitsteilung ?

PT-53 wrote:

Arbeitsteilung ?

Arbeitsteilung zwischen Tools, ja. Wie gesagt, ich glaube dass das mit JOSM sehr viel einfacher geht und dass das nicht wirklich Aufgabe einer Survey App ist/sein muss.

Aber es könnte alternativ auch jemand eine entsprechende Aufgabe für SC entwerfen, dann würde (je nachdem wie man die Aufgaben priorisiert) erst die Strasse und dann die Hausnummer abgefragt. Ich würde mir aber ehrlich gesagt auch ein bisschen blöd vorkommen, wenn ich an einer Strasse entlang gehe und an jedem Haus bestätigen muss, dass es zu dieser Strasse gehört. Wie gesagt, sowas geht meiner Meinung nach super mit JOSM.

Hakuch wrote:

Ich würde mir aber ehrlich gesagt auch ein bisschen blöd vorkommen, wenn ich an einer Strasse entlang gehe und an jedem Haus bestätigen muss, dass es zu dieser Strasse gehört.

Ich würde mir blöd vorkommen, wenn ich heute an jedem Haus nach der Haus-Nr. gefragt werde und morgen an jedem Haus in der gleichen Straße nach dem Straßennamen.

Tordanik wrote:

Thomas8122 wrote:

Tordanik wrote:

...surface=asphalt,..

Wieso denn das?

Weil in unseren Breiten Straßen bestimmter Typen üblicherweise asphaltiert sind und es daher nicht wirklich nützlich ist, diese Information explizit mit anzugeben. Stattdessen macht es aus meiner Sicht mehr Sinn, die vergleichsweise wenigen Ausnahmen entsprechend zu taggen.

Die Einschränkung gibst du selbst: "in unseren Breiten", StreetComplete hat wie OSM nicht das Ziel nur "in unseren Breiten" genutzt zu werden, sondern weltweit. Und da können je nach Region diese Tags sehr viel Sinn machen.

Hakuch wrote:

Arbeitsteilung zwischen Tools, ja. Wie gesagt, ich glaube dass das mit JOSM sehr viel einfacher geht und dass das nicht wirklich Aufgabe einer Survey App ist/sein muss. [...]

Ich würde mir aber ehrlich gesagt auch ein bisschen blöd vorkommen, wenn ich an einer Strasse entlang gehe und an jedem Haus bestätigen muss, dass es zu dieser Strasse gehört.

Sehe ich genauso.

PT-53 wrote:

Ich würde mir blöd vorkommen, wenn ich heute an jedem Haus nach der Haus-Nr. gefragt werde und morgen an jedem Haus in der gleichen Straße nach dem Straßennamen.

Stimmt. Allerdings muss es nicht zwangsläufig so sein. Ich habe jüngst dann und wann SC genutzt und wenn ich maxspeed=* eintrage, folgt sofort die Frage nach surface=*, danach nach der Beleuchtung.

Hakuch wrote:

Ich würde mir aber ehrlich gesagt auch ein bisschen blöd vorkommen, wenn ich an einer Strasse entlang gehe und an jedem Haus bestätigen muss, dass es zu dieser Strasse gehört.

Das kommt auf die Straße an. Wenn zwei Straßen im spitzen Winkel zueinander stehen und dazwischen Häuser eingekeilt sind, lässt sich oft nur vor Ort klären, zu welcher Straße ein Haus gehört.

Hier https://www.openstreetmap.org/way/8610105/history wurde an einer Straße maxspeed=100 mit maxspeed_type=sign per StreetComplete eingetragen. Die Straße liegt teilweise innerhalb der Ortschaft wo sicher keine 100 kmh erlaubt sind. Und außerorts gibt es keine 100 kmh-Beschränkung durch ein Verkehrsschild.

Werden durch StreetComplete keine ausreichenden Hinweise / Informationen für das korrekte ergänzen von maxspeed gegeben ?

Ich kann es nicht selbst testen, da StreetComplete auf meinem Handy (Android 4.1.2) nicht läuft.

Grüße

Kann ich nicht sagen, ich habe diese Aufgabe ausgeblendet, da man häufiger gezwungen ist die Strassenabschnitte zu zerschneiden, wenn man die v-max exakt an die Abschnitte taggen möchte wo die Schilder stehen. Das Zerschneiden von ways kann die App (soweit ich weiss) leider noch nicht leisten...

Könnte ein "vergessenes Zerschneiden" ein Grund für diesen Fall sein?

AB-inf-x-chg-AB wrote:

Das Zerschneiden von ways kann die App (soweit ich weiss) leider noch nicht leisten...

Könnte ein "vergessenes Zerschneiden" ein Grund für diesen Fall sein?

Wenn man mit der App Straßen nicht entspr. auftrennen kann, dann kann das ja auch (vom App-Anwender) nicht vergessen worden sein.

Grüße

AB-inf-x-chg-AB wrote:

da man häufiger gezwungen ist die Strassenabschnitte zu zerschneiden, wenn man die v-max exakt an die Abschnitte taggen möchte wo die Schilder stehen

Das könnte auf jeden Fall ein berechtigter Kritikpunkt an der App sein, ich war auch schon öfter in der Situation wo Wege aufgetrennt werden müssten um Strasseneigenschaften richtig zu taggen, die Versuchung das nicht so eng zu nehmen ist schon sehr groß. Und ich kann mir gut vorstellen, dass Leute die nicht so in OSM drin sind (und ja auch gerade von der App angesprochen werden sollen) dass dann öfter falsch machen, also die Aufgabe nicht verwerfen und/oder eine entsprechende note setzen.

Da sollte es von der App auf irgendeine Weise nochmal einen strengen Hinweis draufgeben, wie genau man das lösen könnte, dafür hab ich allerdings auch noch keine Idee.

Ansonsten bin ich aber immer noch erstaunt wie hier versucht wird die App von allen Seiten schlecht zu machen, auch wenn Leute irgendwas falsch taggen wie 100kmh innerhalb einer Ortschaft, muss ja auf jeden Fall die App schuld sein 🙂 Ich sag ja nicht, dass das auch sein kann, aber ich sehe bei vielen das strengen Bedürfnis hier etwas schlechtes an SC zu finden weil sie halt nicht son vollwertiger Profi Editor wie josm etc ist oder warum auch immer. Schner wär es aus einer konstruktiven Perspektive zu argumentieren und beim verbessern von Problemen zu helfen.

Hakuch wrote:

Schöner wär es aus einer konstruktiven Perspektive zu argumentieren und beim verbessern von Problemen zu helfen.

Es wäre auch schön, wenn westnordwest hier Stellung nehmen würde! Dann könnte man die "Probleme" mit ihm diskutieren.

https://github.com/westnordost/StreetComplete/issues

Vorschläge und Bugs können auch auf GitHub gepostet werden.
https://github.com/westnordost/StreetComplete

Ich sehe das ja so: Solange durch die App mehr richtige als falsche Informationen in die DB kommen ist es ein Gewinn.
Korrekturen wird und muss es immer geben, daher lassen sich auch die mit der App produzierten Fehler ausmerzen und so wie ich bis jetzt mitbekommen habe gibt es einige Stellen im Tagging Schema das von einigen Gruppen ganz unterschiedlich aufgefasst und umgesetzt oder verstanden wird.

Wenn ich mir einige Beiträge auf Githup ansehe bemerke ich schon wieviel Mühe sich westnordost gibt korrektes tagging zu nutzen und gleichzeitig die Einstiegshürden niedrig zu halten um damit mehr potentielle User anzusprechen und somit auch den Datenbestand zu verbessern. Streetcomplete dürfte sich auf einem Smartphone auch bedeutend einfacher nutzen lassen als JOSM

Bitboy wrote:

Ich sehe das ja so: Solange durch die App mehr richtige als falsche Informationen in die DB kommen ist es ein Gewinn.

Warum beschränkt sich die App - vorest - nicht auf die Dinge, die mit ihr gut umzusetzen sind bis es eine gute Lösung für die Problemfälle - wie z.B. maxspeed - gibt ?

@Hakuch:

PT-53 wrote:

In diesem CS https://www.openstreetmap.org/changeset … 20/9.77551 wurden 3 Hausnummern ergänzt. An diesen Gebäuden fehlt auch noch die Straße.
Fragt StreetComplete nicht beides gleichzeitig ab ?
Das wäre suboptimal.

Hakuch wrote:

Ich würde mir aber ehrlich gesagt auch ein bisschen blöd vorkommen, wenn ich an einer Strasse entlang gehe und an jedem Haus bestätigen muss, dass es zu dieser Strasse gehört.

PT-53 wrote:

Ich würde mir blöd vorkommen, wenn ich heute an jedem Haus nach der Haus-Nr. gefragt werde und morgen an jedem Haus in der gleichen Straße nach dem Straßennamen.

Kommunikation mit einem StreetComplet-Nutzer:
Hallo MartinBC,
Du hast an 3 Gebäuden die Haus-Nr. ergänzt. Vielen Dank dafür.
Jetzt fehlt für eine vollständige Adresse aber noch die Straße. Kannst du diese auch noch ergänzen?
Grüße und Willkommen bei OSM

Hi PT-53,
Hab die Daten eben ergänzt. Die App "StreetComplete" scheint doch noch einige Fehler zu haben. Ich wurde nur nach den Nummern gefragt.
Danke für den Hinweis.

@PT-53, du bringst hier nur Teilzitate ohne den Kontext und marginalisierst damit die Aussagen, du bringst keine wirklichen Argumente und gehst auf Gegenargumente nicht ein indem du sie ausblendest. Daher hab ich auch schon auf deine Aussage

PT-53 wrote:

Ich würde mir blöd vorkommen, wenn ich heute an jedem Haus nach der Haus-Nr. gefragt werde und morgen an jedem Haus in der gleichen Straße nach dem Straßennamen.

schon nicht geantwortet, weil das nur eine trollhafte Reaktion war und von den eigentlichen Argumenten abgelenkt hat. Für so eine Diskussion ist mir die Zeit zu schade, alle Antworten dazu stehen schon oben und ich werde sie nicht wiederholen. Wenn du darauf konkret eingehst werde ich mich auch wieder dazu äußern ansonsten nicht.

Bitboy wrote:

Solange durch die App mehr richtige als falsche Informationen in die DB kommen ist es ein Gewinn.

Und ich habe aber in den letzten Wochen in diversen Themen hier eher das Mehrheitsempfinden mitgenommen: lieber keine Daten als falsche Daten.

@Hakuch: und gerade weil die App ja eher unbedarfte Nutzer mit sehr niedriger Einstiegshürde anspricht, wäre das für mich ein Hauptgrund, warum diese App niemals direkt in die Datenbank schreiben dürfte, sondern die Änderungen mindestens einer weiteren Person bedürfte (wie z.B. bei kort.ch), und damit würde sich auch das Gamification der App verbessern, wenn z.B. der erste User seine Punkte erst gut geschrieben bekommen würde, wenn sie ein zweiter User "absegnet".
Und dann ergibt sich, meiner Meinung nach, eben auch, dass es (alles) eher ein Problem der App an sich ist anstatt des unbedarften Users.

Harald Hartmann wrote:

Bitboy wrote:

Solange durch die App mehr richtige als falsche Informationen in die DB kommen ist es ein Gewinn.

Und ich habe aber in den letzten Wochen in diversen Themen hier eher das Mehrheitsempfinden mitgenommen: lieber keine Daten als falsche Daten.

Ja das würde ich auch so sehen, falsche Daten bemerkt man viel schlechter als fehlende, das ist so ein Grundsatz der in SC besser kommuniziert werden müsste.

Harald Hartmann wrote:

... und damit würde sich auch das Gamification der App verbessern, wenn z.B. der erste User seine Punkte erst gut geschrieben bekommen würde, wenn sie ein zweiter User "absegnet".

Also bisher bekommt man keine "Punkte" (naja, also es wird nur oben angezeigt wieviele Änderungen man bisher durchgeführt hat). Ich find das mit der Kontrolle recht unrealistisch, weil die Stärke von SC ist ja, dass es eine survey App ist, wie willst du das von remote kontrollieren ob das stimmt? Das hieße, es müssten immer zwei Leute vor Ort surveyen, ist ebenso unrealitisch und würde den Wert der App drastisch verringern. Vielleicht könnte man sagen, man braucht so 20 geproofte Änderungen und dann ist man selbständig, mh vielleicht.

Die Gefahr sehe ich tatsächlich vor allem in Fehlern die man nicht böswillig macht, aber die sich einschleichen. Bisher sehe ich die z.B. bei dem nicht-wege teilen, da sehe ich wie gesagt auch Verbesserungsbedarf weil man das im survey zu verführend ist und von remote nicht mehr/selten kontrollieren kann. Ansonsten greift aber doch das gleiche Fehlerkorrektur und user anschreiben Prozedere wie ansonsten auch bei OSM.

Das mit den Hausnummern sehe ich wie beschrieben nicht als Problem sondern als sinnvoll an.

glglgl wrote:

Das kommt auf die Straße an. Wenn zwei Straßen im spitzen Winkel zueinander stehen und dazwischen Häuser eingekeilt sind, lässt sich oft nur vor Ort klären, zu welcher Straße ein Haus gehört.

Gerade bei diesem Beispiel finde ich das solo-Hausnummertagging nämlich sinnvoll, wenn du schon die Hausnummern ohne Adresse hast, kannst du von Remote feststellen in welcher Richtung (Strasse) die Hausnummern weitergehen und es dann passend Taggen. Und falls nicht, pack ein note hin und auch das kann man bei SC beantworten. Und wer ganz gewitzt ist kann ja einen Quest schreiben für besonders unklare Hausadressenzuweisung.

Da man in SC ja eine Anmeldung mit OSM Account braucht, wie wäre es damit: je nach Quest wird, am besten durch die Community, festgelegt, wie anfällig dieser für "falsche" Angaben ist und man zur Erledigung dieses Quests eine gewisse Erfahrung braucht, was man ja durchaus ein bisschen anhand Registrierdatum und Changeset Count (das stünde SC durch die OSM OAuth zur Verfügung) bestimmen und somit die Bearbeitung/Auswahl des Quests zulassen oder ablehnen könnte.

Nachtrag: Zur Not auch noch die "internen" Sternchen von SC

Ach Hakuch,

wenn ich auf Deine Aussage

Hakuch wrote:

Ich würde mir aber ehrlich gesagt auch ein bisschen blöd vorkommen, wenn ich an einer Strasse entlang gehe und an jedem Haus bestätigen muss, dass es zu dieser Strasse gehört.

mit

PT-53 wrote:

Ich würde mir blöd vorkommen, wenn ich heute an jedem Haus nach der Haus-Nr. gefragt werde und morgen an jedem Haus in der gleichen Straße nach dem Straßennamen.

antworte ist das Trollhaft ?
Wer hat den diese Wortwahl getroffen ?

@Harald, ja das fänd ich prinzipiell auch gut. Denn bei einigen Quests oder auch noch nicht existierenden möglichen Quests denke ich, die würde ich gerne nur versierten Leuten anvertrauen. Ich glaube in der Richtung könnte man was sinnvolles machen.

@PT-53, wenn du aus einem Post zitierst, lies bitte auch den Rest des Posts und gehe auf die Argumente dort ein. Und weiteren Offtopic bitte per PM und nicht hier den Thread verstopfen.

Harald Hartmann wrote:

Bitboy wrote:

Solange durch die App mehr richtige als falsche Informationen in die DB kommen ist es ein Gewinn.

Und ich habe aber in den letzten Wochen in diversen Themen hier eher das Mehrheitsempfinden mitgenommen: lieber keine Daten als falsche Daten.

@Hakuch: und gerade weil die App ja eher unbedarfte Nutzer mit sehr niedriger Einstiegshürde anspricht, wäre das für mich ein Hauptgrund, warum diese App niemals direkt in die Datenbank schreiben dürfte, sondern die Änderungen mindestens einer weiteren Person bedürfte (wie z.B. bei kort.ch), und damit würde sich auch das Gamification der App verbessern, wenn z.B. der erste User seine Punkte erst gut geschrieben bekommen würde, wenn sie ein zweiter User "absegnet".
Und dann ergibt sich, meiner Meinung nach, eben auch, dass es (alles) eher ein Problem der App an sich ist anstatt des unbedarften Users.

Persönlich sehe ich das eben anders. Allein schon durch den Fakt, dass sich Daten sowieso ändern können und nachkorrigiert werden müssen, früher oder später, Schilder werden neu beschriftet (Destination), Geschwindigkeitsbegrenzungen werden hinzugefügt oder abgebaut, Straßennamen geändert, zusätzliche Spuren hinzugefügt... Selbst wenn wir Stand jetzt eine absolut perfekte Karte hätten müssten wir in 6 Monaten mit Korrekturen anfangen und dann muss man auch die falschen Daten finden. Das ist so oder so eine Aufgabe die sich nicht vermeiden lässt, ganz egal wie gut und perfekt das JETZT gemappt wird.

Wenn man von Anfang an nur auf 100% korrekte Informationen setzt verschreckt man einfach die Leute. Siehe Wikipedia. Nachdem die "Löschnazis" die Oberhand hatten ging die Zahl der freiwilligen Autoren massiv zurück. Ich finde man muss diese Fehler nicht wiederholen.
Eine Geschwindigkeitsangabe die vllt 100 oder 200m zu weit reicht ist jedenfalls immer noch besser als gar keine denn bei gar keiner weiß man nicht ob eine fehlt oder dort keine ist.
Grade im Bezug auf Hausnummern oder Öffnungszeiten (oder grade on der Mache: Gebäudeart) kann eine App wie Streetcomplete die Daten massiv verbessern gerade weil die Nutzung einfach ist und man das im vorbeilaufen erledigen kann.
Davon wiederum profitieren massiv die Navis wodurch sich der Interessentenkreis generell vergrößern kann.

Andere Editoren ermöglichen es genauso Fehler zu machen und weit mehr kaputt zu bekommen.

Wie bei jeder jungen Software hat die nunmal ihre Bugs und ich denke schon, wenn diese Vernünftig auf Github angesprochen werden, dann gibt es auch irgendwann einen Fix.

Eine Kontrolle durch eine 2. Person erscheint sinnvoll wenn die Mapperdichte hoch genug ist, ansonsten muss man, wie bei den anderen Editoren, eben darauf vertrauen, dass derjenige die Info wirklich vor Ort gesammelt hat oder aus einer zulässigen Quelle bezogen hat.
Aber selbst dann besteht das Problem der technischen Umsetzung. Irgendwer müsste die ganzen schwebenden Changesets speichern und anderen Benutzern zur Prüfung vorlegen und erst dann in die Datenbank schreiben.

Bitboy wrote:

... weil die Nutzung einfach ist und man das im vorbeilaufen erledigen kann. ...

Nach den Einträgen, die ich hier im Umfeld gesehen habe, wird die App so scheinbar nicht genutzt.
Mehrheitlich machen die Einträge den Eindruck, als hätte jemand die App mal runtergeladen, ein paar Änderungen aus dem Kopf gemacht ... und es wieder sein gelassen.
Resultat sind dann fragmentierte Inseln mit teilweise redundanter oder unvollständiger Information.

Bitboy wrote:

... Wie bei jeder jungen Software hat die nunmal ihre Bugs und ich denke schon, wenn diese Vernünftig auf Github angesprochen werden, dann gibt es auch irgendwann einen Fix.

Ich denke der "Bug" liegt im Konzept, welches sich m.E (sicher by intention) an User ohne großes Interesse wendet sich allzu tief in OSM einzuarbeiten. Das führt dann zu den oben beschiebenen (mehr oder minder sinnvollen) Detail-Inseln.
Wenn ich das für mich mit den - hier auch sehr kontovers diskutierten - maps.me oder Wheelchair App Resultaten vergleiche, benötigen alle 3 meistens noch Nacharbeit .. für mich hatten die letzten beiden jedoch noch den brauchbareren Input geliefert.

Aber solange sich das alles mengenmäßig in Grenzen hält ist es zu handeln und wenn die Infos stimmen gibt's so zumindest Hinweise auf neue Bereiche zur Bearbeitung.

Meine 2 cents
Gruß
Stephan (tux67)

tux67 wrote:

Resultat sind dann fragmentierte Inseln mit teilweise redundanter oder unvollständiger Information.

Kannst du da mal Beispiele für nennen? Ich kann nicht ganz nachvollziehen was du damit meinst.

Wenn's passt sende ich die mal welche per PM .. schon um hier niemandes gutgemeinten Input an den Pranger zu stellen.
Letztendlich hast du z.B. als Resultat nur ein Stück Parkstraße, welches als "mit Beleuchtung" und "ohne Fahrrad-Schutzstreifen auf beiden Seiten" markiert ist, obwohl du weißt, daß mit Ausnahmen die gesamte Stadt beleuchtet ist, und das nicht-Vorhandensein der Schutzstreifen eine immanente Information des highway tags ist - auch ohne zu erwähnen das keiner da ist.
Keiner der bisher von mir gesichteten Nutzer hat mal einen ganzen Bereich konsistent gemappt.

Gruß
Stephan

tux67 wrote:

Wenn's passt sende ich die mal welche per PM .. schon um hier niemandes gutgemeinten Input an den Pranger zu stellen.

Pranger ist es nur, wenn Leute so darauf reagieren und es so zu verwenden. Im Sinne der Diskussion find ich es schon sinnvoll auch mit Beispielen zu arbeiten.

tux67 wrote:

obwohl du weißt, daß mit Ausnahmen die gesamte Stadt beleuchtet ist

Das ist doch wiederum die Diskussion über Default Werte die tatsächlich eine komplizierte ist und meiner Meinung nach auch sehr unzureichend in OSM geführt wird, so wie viele grundlegende Fragen. "Obwohl du weißt" ist eine recht untechnisch Definition, wie willst du das klar festlegen? In einem Stadt Boundary sind per Default alle Straßen beleuchtet, wenn nicht soll nur das gemappt werden. Aber wie ist es in Ländern in deren Städten das nicht so einfach Standard ist?

Es gibt hier keine Richtlinien im OSM Datenmodell, wie bei so vielem wird danach gemappt und definiert wie der Mapperin gerade die Nase gewachsen ist.

Hakuch wrote:

Es gibt hier keine Richtlinien im OSM Datenmodell, wie bei so vielem wird danach gemappt und definiert wie der Mapperin gerade die Nase gewachsen ist.

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

Hakuch wrote:

... ist eine recht untechnisch Definition, ...

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 😉

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.

PT-53 wrote:

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

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?
- https://www.openstreetmap.org/note/1407434
- https://www.openstreetmap.org/note/1407438
- https://www.openstreetmap.org/note/1407465

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 😛 🤣

Harald Hartmann wrote:

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 😛 🤣

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.

kartonage wrote:

Die drei verlinkten Notes weisen alle auf Gebäude mit house-Attributen.

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.

kartonage wrote:

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

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.

Harald Hartmann wrote:

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

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=<schild> + 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=<zeitungsmeldung>

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

--ks

Robert46798 wrote:

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

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.

kreuzschnabel wrote:

Auch maxspeed:source ist dann =survey, denn ich war dort und habe gesehen, dass da ein Ortseingang ist.

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.

geri-oc wrote:

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

kreuzschnabel wrote:

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

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

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.

kreuzschnabel wrote:

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?“).

Im Wiki steht allerdings etwas anderes. Das ist schon seit 2009 so. Die zitierte Aussage widerspricht der Dokumentation im Wiki wie auch der jahrelangenhundert-tausendfachen Nutzung in der Praxis. Die Nutzung des Tag-Namens mag unglücklich sein, aber wenn man jetzt anfängt und einen so etablierten und gut dokumentierten Tag umdeutet weil die Namenswahl nicht perfekt ist, macht es das auch nicht besser.

Oh, einige Briten haben den gleichen Gedanken wie Du 🙂

Wiki wrote:

Some mappers use source:maxspeed=* to tag the source of the information as for other tags of the form source:*. In Great Britain, prolonged discussion of this point on talk-gb resulted in agreement to use source:maxspeed for the data source (survey, Open Data, etc) and maxspeed:type=* for the information described on this page. This usage is more consistent with the general pattern of tagging. It also resolved a conflict about how unsigned national speed limits should be tagged.

Fängt StreetComplete jetzt auch noch an Notes zu generieren?
https://www.openstreetmap.org/note/1450433

Gruß
Stephan

tux67 wrote:

Fängt StreetComplete jetzt auch noch an Notes zu generieren?

Nein, fängt es nicht. Ist schon länger dabei 🙁

--ks

[polemik]oh gott, mit der App kann man sogar notes machen, Skandal!![/polemik]

Hakuch wrote:

[polemik]oh gott, mit der App kann man sogar notes machen, Skandal!![/polemik]

Skandal nicht, aber wenn unter all den Wichtigkeiten à la „Unable to specify the exact colour of this pebblestone“ die wirklich dringenden Notes ertrinken, ist es schade.

--ks

kreuzschnabel wrote:

tux67 wrote:

Fängt StreetComplete jetzt auch noch an Notes zu generieren?
https://www.openstreetmap.org/note/1450433

Nein, fängt es nicht. Ist schon länger dabei 🙁

--ks

Es ist wohl besser eine note zu setzen, als etwas falsch über die beschränkte App zu taggen. Das Beispiel von tux67 ist hierfür sehr gut geeignet:

https://www.openstreetmap.org/note/1450433 wrote:

Unable to answer "What surface does the road Am Brauhaus have here?" for https://www.openstreetmap.org/way/24576275 via StreetComplete 6.0:

die Straße hat mehrere unterschiedliche Beläge - erst Asphalt, dann Steinpflaster

Die Alternative wäre gewesen, entweder keine Info zu geben oder die ganze Straße mit surface=asphalt oder surface=sett/cobblestone falsch zu taggen. Beides hätte nicht geholfen. Schön wäre natürlich noch gewesen zu erfahren, bis/ab wo welcher Straßenbelag ist.

Mehr ärgert mich bei Apps wie SC, aber auch maps.me, dass User nicht einfach ankreuzen können, dass es den POI nicht mehr gibt und daraufhin weitere Fragen gestellt werden: Weißt Du, ob der Laden woanders hingezogen ist und wenn ja, wohin? Was befindet sich hier jetzt? Neues Geschäft oder steht das Ladengeschäft jetzt leer?
Statt dessen kommt häufig nur auf die Frage
"What are the opening hours of Fitness Body?" -> "Closed permanently"
Schade. Da ist jemand vor Ort, könnte mehr Infos geben, aber das bleibt aus.

kreuzschnabel wrote:

Skandal nicht, aber wenn unter all den Wichtigkeiten à la „Unable to specify the exact colour of this pebblestone“ die wirklich dringenden Notes ertrinken, ist es schade.

Durchsuch mal über JOSM weltweit in allen offenen/in jüngster Zeit geschlossenen notes mit "StreetComplete". Es hält sich arg in Grenzen. Auch ich bin kein großer Freund der Apps, sehe einiges an Problemen, aber vom Ertrinken sind wir hier weit entfernt.
Im übrigen: Was ist wichtig? ;-)

Mal eine Kopie aus dem anderen Thema https://forum.openstreetmap.org/viewtop … 39#p707139 :

westnordost schrieb:
Natürlich nicht, wir können nicht einfach Tags "für Deutschland" umdefinieren, ein Tag muss weltweit die gleiche Definition haben, sonst macht er keinen Sinn.

zum Kommentar:
Warum verwendet dann streetcomplete maxspeed:type statt source:maxspeed?
(Ich vermute einmal dass es durch die APP einfach zur Überlegenheit des englischen Schlüssels getrimmt wird.)

Hakuch wrote:

[polemik]oh gott, mit der App kann man sogar notes machen, Skandal!![/polemik]

Und das als Moderator !?

PT-53 wrote:

Und das als Moderator !?

Meinst du als Admin oder Moderator kann ich keine eigene Meinung haben? Ich nutze aus guten Gründen einen extra Admin Account damit meinem Wort nicht mehr Gewicht gegeben wird als dem von Anderen und ich sehe kein Problem darin einen überspitzten Kommentar abzugeben der sogar noch extra als solche gekennzeichnet ist.

geri-oc wrote:

Warum verwendet dann streetcomplete maxspeed:type statt source:maxspeed?

Warum bringst du zum wiederholten Male dieses Thema hier ein, lediglich ein paar Posts vorher hab ich auch dich darauf hingewiesen bitte den schon vorhandenen Thread dafür zu nutzen.

OK - dann immer vereinzelte Probleme vereinzelt beschreiben und vereinzelt klären - oder auch nicht?

Es ging hier um die Aussage

westnordost schrieb:
Natürlich nicht, wir können nicht einfach Tags "für Deutschland" umdefinieren, ein Tag muss weltweit die gleiche Definition haben, sonst macht er keinen Sinn.

von dem User - der selbst diese Aussage in (seiner) APP umgeht.

Hakuch wrote:

PT-53 wrote:

Und das als Moderator !?

Meinst du als Admin oder Moderator kann ich keine eigene Meinung haben? Ich nutze aus guten Gründen einen extra Admin Account damit meinem Wort nicht mehr Gewicht gegeben wird als dem von Anderen und ich sehe kein Problem darin einen überspitzten Kommentar abzugeben der sogar noch extra als solche gekennzeichnet ist.

So oder so und ob mit oder ohne Polemik-Tag bringt einen die Antwort nicht richtig weiter.

Meine Frage zielte dahin, ob man sich jetzt darauf einstellen muß, nicht nur hier und da Changesets zu sehen, wo ein wenig Asphalt auf die Staße gebröselt wird, oder 50 Meter Staße die Information bekommen, daß links und rechts kein Radweg ist, während 10 km davor und dahinter der default "Weiss ich nicht" verbleibt, oder die App nun mehr oder weniger automatisiert diese punktuelle Wissen- oder Unwissenheit auch noch in Notes umsetzt.

Letztere lönnte man schlicht nicht weiter beachten .. machen aber das Auffinden relevanter Notes nicht leichter.

Letztendlich würde ich mit RoterEmil anschließen .. dann ist viellecht die Note das kleinere Übel.

Und jetzt sag' bitte keiner man könne das aber nicht so überspitzt darstellen .. 😉

Gruß
Stephan

Also sagen wirs mal so: Diejenigen, die StreetComplete wirklich nutzen, sind in aller Regel solche Nutzer, die niemals einen normalen Editor anfassen würden. Diese App aktiviert uns also ne Menge Wissen, das anders nicht erreicht werden kann.

Das geht eben deshalb so gut, weil die App sehr spartanisch ist und den User nicht mit Unmengen an Infos zuballert. Damit einher gehen dann aber auch Nachteile wie eben ein begrenzter Funktionsumfang.

Dass die App dann am Ende ihres Funktionsumfangs Notes setzt halte ich da dann für total unproblematisch. Zumal sich diese Notes bisher dadurch auszeichnen, dass sie deutlich informativer sind als vergleichbare Notes, wie etwa die von Maps.Me. Das führt dazu, dass sie auch schneller bearbeitet werden können und somit auch schneller erledigt sind.

Insgesamt habe ich tatsächlich in letzter zeit kaum noch StreetComplete-Notes gesehen, was ich von den Maps.Me-Notes definitiv nicht sagen kann.

Auch sind mir bisher keine CS von StreetComplete aufgefallen, die in irgendeiner Art problematisch wären. Spätestens, seit die App die Daten gebündelt hochlädt kann man hier eig keinen Anhaltspunkt für Kritik finden.

tux67 wrote:

Meine Frage zielte dahin, ob man sich jetzt darauf einstellen muß, nicht nur hier und da Changesets zu sehen, wo ein wenig Asphalt auf die Staße gebröselt wird, oder 50 Meter Staße die Information bekommen, daß links und rechts kein Radweg ist, während 10 km davor und dahinter der default "Weiss ich nicht" verbleibt, oder die App nun mehr oder weniger automatisiert diese punktuelle Wissen- oder Unwissenheit auch noch in Notes umsetzt.

Warum sollte das so passieren?

Die App spaltet keine Ways auf und erstellt auch keine neuen Ways oder Nodes. Wenn also ein 50m Stück entstehen sollte, dann nur deshalb, weil es vorher schon existierte. Und hinter der App sitzen ja auch Menschen mit der Befähigung zum Denken. Wenn sie eine Frage zum Radweg beantworten werden sie sicher erkennen, dass das angrenzende Straßenstück dieselbe Frage hat.

Entweder wird diese Frage dann auch beantwortet, oder eben nicht. Letzteres dann meist mangels Wissen.

In dem Fall ist mir trotzdem lieber, dass die User der App die 50m, bei denen sie über Wissen verfügen, dann so korrigieren, als gar nichts zu machen. So kommen dann vieleicht andere Mapper auf die Idee, dass man sich diese Stelle nochmal genauer anschauen sollte!

Viele Grüße

hsimpson wrote:

Warum sollte das so passieren?

Die App spaltet keine Ways auf und erstellt ...

So "schwierige Sachen" hatte ich gar nicht im Sinn .. mir geht's eher um den Mehrwert bereits ohnehin vorhandene Objekte "insulär" mit einem Detaillierungsgrad zu versehen, der durch die App und deren Entwickler bestimmt wird (wie du eingangs richtig bemerktest - mit einem Editor mit mehr Freiheitsgraden oder Diskussionen über was wie zu taggen wäre wird sich die Zielgruppe der App eher nicht auseinandersetzen).

Aber das kann man natürlich jeder für sich bewerten. Ich find's nur anders nervig als maps.me.

Gruß
Stephan

Ich verstehe gar nicht warum aus den "Detailinseln" so ein Problem gemacht wird.
Die gibt es auch völlig ohne solche Apps da der Detailgrad von OSM in erster Linie davon abhängt wie viele aktive Mapper aus dem Gebiet stammen und wie sehr deren Hang nach Perfektionismus ausgeprägt ist.
Da gibt es Gegenden wo jeder Baum einzeln gemappt und vollständig getaggt ist und andere wo sämtliche Gebäude fehlen und nur die rudimentär die Straßen vorhanden sind. Apps die es für den User sehr einfach machen Informationen hinzuzufügen können der Anfang sein in solchen Gegenden überhaupt mal etwas zu mappen.

Persönlich viel kritischer sehe ich unterschiedliche Wikidefinitionen die ein uneinheitliches und damit schwer auswertbares Tagging produzieren. Das sind Probleme die man wirklich angehen müsste, aber wahrscheinlich nie gelöst werden weil jede Community für sich beansprucht den Stein der Weisen gefunden zu haben.

Bitboy wrote:

Ich verstehe gar nicht warum aus den "Detailinseln" so ein Problem gemacht wird.
Die gibt es auch völlig ohne solche Apps da der Detailgrad von OSM in erster Linie davon abhängt wie viele aktive Mapper aus dem Gebiet stammen und wie sehr deren Hang nach Perfektionismus ausgeprägt ist.
Da gibt es Gegenden wo jeder Baum einzeln gemappt und vollständig getaggt ist und andere wo sämtliche Gebäude fehlen und nur die rudimentär die Straßen vorhanden sind. Apps die es für den User sehr einfach machen Informationen hinzuzufügen können der Anfang sein in solchen Gegenden überhaupt mal etwas zu mappen.

Dem kann ich nur zustimmen.

Bitboy wrote:

Ich verstehe gar nicht warum aus den "Detailinseln" so ein Problem gemacht wird.

Sie richten vielleicht keinen Schaden an, aber man kann sich fragen, was damit erreicht wird, wenn dort, wo zufällig ein SC-Nutzer vorbei kommt, das surface-Tag auf den Wert gesetzt wird, der dort bisher nach allgemeinem Verständnis als Default-Wert galt. Das wäre dann sinnvoll, wenn man langfristig auf Defaults verzichtet. Solange es darüber keinen Konsens gibt, verschwendet dieses punktuelle Taggen von Default-Werten Ressourcen, die man besser für was anderes einsetzen könnte.

rainerU wrote:

verschwendet dieses punktuelle Taggen von Default-Werten Ressourcen, die man besser für was anderes einsetzen könnte.

Ein Dauerbrenner, der hier im Thread, wenn ich mich recht entsinne schon mehrmals besprochen wurde. Aber gern nochmal:
1. Jeder verschwendet die Resourcen auf die er gerade Lust hat.
2. Wenn ich Lust habe defaultwerte zu taggen, dann habe ich einen guten Grund. Fehlendes surface=asphalt (bspw.) kann 2erlei bedeuten: ein Vormapper hat zwecks default seine Ressourcen anders verschwendet oder er hat sich keine Gedanken über den Strassenbelag gemacht.
surface=asphalt heisst, jmd. hat sich den Strassenbelag angeschaut und es heisst, dass da kein Kopfsteinpflaster ist oder sonstwas.
Kein surface=asphalt heisst garnix.

Bitboy wrote:

Ich verstehe gar nicht warum aus den "Detailinseln" so ein Problem gemacht wird.

Also das Verstehen einer anderen Position würde m. E. aus dem Diskurs entstehen. Natürlich kann auch jeder seine Meinung behalten und die Welt ist auch schön.

Letztendlich ist es weniger das Ergebnis, als vielmehr die Tatsache das dieses Verhalten und das erzeugte Muster durch eine einzelne App erzeugt und gefördert werden.
Natürlich haben auch alle Recht, die sagen, daß das nun im größeren, indivduellen OSM Wildwuchs nun auch nichts mehr ausmacht.

Mir scheint z.B. eine Straße einheitlich ohne surface attribute sauberer, als ein Flickenteppich. Das ist nicht "so ein Problem" sondern erstmal eine Meinung. Die kann man teilen oder nicht - so ganz einsam schein' ich damit nicht zu sein.

Aber wir werden das hier nicht lösen .. und es ist nichts, das OSM an den Abgrund bringen wird.

Gruß
Stephan

tux67 wrote:

Mir scheint z.B. eine Straße einheitlich ohne surface attribute sauberer, als ein Flickenteppich.

Ich als Radfahrer sehe das genau anders herum. Kein surface kann wirklich alles bedeuten - vom nagelneuen glatten asphalt bis zur letzten Buckelpiste.

Klar, auf ner Autobahn mag das vieleicht ein wenig übertrieben sein, überall surface=asphalt oder concrete zu taggen, aber alle anderen Straßen sind da keineswegs so eindeutig. Und das gilt eigentlich für alle erfassten Werte.

Ich würde z.B. gerne mal wissen, wie die Verbreitung des Schlüssels opening_hours=* durch StreetComplete zugenommen hat. Als ich das erste mal hier rein geschaut habe, waren in meiner Umgebung nahezu alle Geschäfte mit dieser Frage versehen (ich wohne im Innenstadtbereich). Inzwischen sehe ich keine einzige Frage mehr zu dem Thema!

Und ich muss auch aus Erfahrung sagen, dass es einige StreetComplete-Nutzer gibt, die sehr systematisch alle Fragen in ihrer Gegend abarbeiten und dadurch tatsächlich viel zum aktuellen Datenbestand beigetragen haben.

Ich verstehe echt nicht, wie man sich so an einer einzigen App aufhängen kann. Ich hab langsam das Gefühl, dass einige hier einfach nicht ertragen können, dass es andere Leute gibt, die gerne für OSM zuarbeiten wollen, aber keine Lust und Nerven oder sonstwas haben, sich in die Komplexe Welt des OSM-Kosmos einzudenken und stattdessen gerne auf Angebote wie StreetComplete zurückgreifen.

Es ist aber grade für das langfristige Fortbestehen von OSM essentiell, dass jeder, der möchte, ohne große Hürden mitarbeiten kann! Das Beispiel Wikipedia zeigt gut, was passieren kann, wenn man die Einstiegshürden zu hoch legt und das System so komplex macht, dass man erstmal ne zweistellige Zahl an Stunden investieren muss, um überhaupt einigermaßen fehlerfrei arbeiten zu können!

Nur zur Erinnerung: Die App hat bisher über 10.000 Downloads und ist im Play Store mit 4,6 von 5 Sternen bewertet. Diese App kommt an, und zwar ordentlich!

Grüße

hsimpson wrote:

Nur zur Erinnerung: Die App hat bisher über 10.000 Downloads und ist im Play Store mit 4,6 von 5 Sternen bewertet. Diese App kommt an, und zwar ordentlich!

Genau deshalb war die Frage von mir:
maxspeed:type gegen source:maxspeed

und die Aussage:

westnordost wrote:

Natürlich nicht, wir können nicht einfach Tags "für Deutschland" umdefinieren, ein Tag muss weltweit die gleiche Definition haben, sonst macht er keinen Sinn.

Umsomehr die APP ihre Daten einbringt, wird auch maxspeed:type steigen. Obwohl es im WIKI nicht dokumentiert ist (nur für GB als eigenes Ding), sollte doch in DE source:maxspeed genutzt werden.
oder:
Wir schmeißen in DE und anderen Länder das source:maxspeed über den Haufen und taggen alles "Weltweit" um nach maxspeed:type.

hsimpson wrote:

Klar, auf ner Autobahn mag das vielleicht ein wenig übertrieben sein, überall surface=asphalt oder concrete zu taggen, ...

Keineswegs, dafür gäbe es sogar einen konkreten Anwendungsfall: Router könnten Beton-Autobahnen in Sommer an sehr heißen Tagen wegen "Blow Ups" meiden, oder zumindest die Fahrzeit verlängern, da mittlerweile bei solchen Strecken sehr häufig dann im Hochsommer auf einmal komplett max. 80km/h ausgeschildert ist.

Harald Hartmann wrote:

hsimpson wrote:

Klar, auf ner Autobahn mag das vielleicht ein wenig übertrieben sein, überall surface=asphalt oder concrete zu taggen, ...

Keineswegs, dafür gäbe es sogar einen konkreten Anwendungsfall: Router könnten Beton-Autobahnen in Sommer an sehr heißen Tagen wegen "Blow Ups" meiden, oder zumindest die Fahrzeit verlängern, da mittlerweile bei solchen Strecken sehr häufig dann im Hochsommer auf einmal komplett max. 80km/h ausgeschildert ist.

Aber nur, wenn man weiß, wann die Betonfahrbahnen das letzte mal gewartet wurden 😉 Das Problem tritt nämlich erst auf, wenn man Elemente wie Fugen etc. über einen längeren zeitraum vernachlässigt.

Dazu kommen dann Autobahnen mit viel LKW-Verkehr, bei denen nur die rechte Spur betoniert ist... Da sind wir dann bei surface:lanes=* 😄

Aber prinzipiell liegen wir beide glaube ich auf einer Wellenlänge: Es ist besser, solche Infos pöapö zu erfassen, als sie gar nicht zu erfassen. Denn erst, wenn man eine gewisse Abdeckung erreicht, können die Auswerter sinnvoll damit umgehen.

Grüße

geri-oc wrote:

hsimpson wrote:

Nur zur Erinnerung: Die App hat bisher über 10.000 Downloads und ist im Play Store mit 4,6 von 5 Sternen bewertet. Diese App kommt an, und zwar ordentlich!

Genau deshalb war die Frage von mir:
maxspeed:type gegen source:maxspeed

und die Aussage:

westnordost wrote:

Natürlich nicht, wir können nicht einfach Tags "für Deutschland" umdefinieren, ein Tag muss weltweit die gleiche Definition haben, sonst macht er keinen Sinn.

Umsomehr die APP ihre Daten einbringt, wird auch maxspeed:type steigen. Obwohl es im WIKI nicht dokumentiert ist (nur für GB als eigenes Ding), sollte doch in DE source:maxspeed genutzt werden.
oder:
Wir schmeißen in DE und anderen Länder das source:maxspeed über den Haufen und taggen alles "Weltweit" um nach maxspeed:type.

Ich hab dazu shcon oft meine Meinung gesagt, daher mache ich das hier knapp:

Das was StreetComplete hier ausdrücken will, hat mit source:maxspeed recht wenig zu tun. Im Falle maxspeed:type=DE:urban z.B. gab es vorher schlicht keine Möglichkeit, das so darzustellen.

Ja, es ist nicht die beste Option, dass das so eingeführt wurde, aber wir hatten hier im Forum schon Romane zu dem Thema zusammendiskutiert und es gab nicht einmal ansatzweise eine Lösung, die von allen getragen wurde. Dass die Entwickler irgendwann nicht mehr da drauf warten wollten, kann ich schon irgendwo verstehen.

Grüße

rainerU wrote:

Bitboy wrote:

Ich verstehe gar nicht warum aus den "Detailinseln" so ein Problem gemacht wird.

Sie richten vielleicht keinen Schaden an, aber man kann sich fragen, was damit erreicht wird, wenn dort, wo zufällig ein SC-Nutzer vorbei kommt, das surface-Tag auf den Wert gesetzt wird, der dort bisher nach allgemeinem Verständnis als Default-Wert galt. Das wäre dann sinnvoll, wenn man langfristig auf Defaults verzichtet. Solange es darüber keinen Konsens gibt, verschwendet dieses punktuelle Taggen von Default-Werten Ressourcen, die man besser für was anderes einsetzen könnte.

Das Problem mit Defaults habe ich in einem anderen Beitrag schon beschrieben. Zum einen bräuchte man erstmal weltweite Defaults. Länderspezifische Defaults, wie öfters zu sehen, würden im Extremfall zu einem 193 (Zahl der Länder auf der Erde) fachen Implementierungsaufwand für Software Entwickler führen die OSM nutzen wollen. Das wird keiner tun. Man wird sich auch nicht auf weltweite Defaults einigen können weil Gesetzgebung und finanzielle Mittel zum Bau einfach zu stark unterschiedlich sind. Es bleibt unterm Strich also nur noch das definitive angeben von Eigenschaften.
Das nächste Problem ist, das keine Software unterscheiden kann ob nun ein Default Wert gilt, oder ob die Information schlicht unbekannt ist. Anstatt das Feld einfach leer zu lassen müsste dann auch ein explizites "Default" gesetzt werden damit es für Software (und Menschen) eindeutig ist.

Der Gedanke der verschwendeten Ressourcen basiert auf der Idee, dass die Nutzer von Streetcomplete in der Zeit einfach etwas anderes mappen könnten. Aber wenn die Quest oder gar die ganze App nicht angeboten werden würde, würden Sie wahrscheinlich überhaupt nichts eintragen.

tux67 wrote:

Letztendlich ist es weniger das Ergebnis, als vielmehr die Tatsache das dieses Verhalten und das erzeugte Muster durch eine einzelne App erzeugt und gefördert werden.
Natürlich haben auch alle Recht, die sagen, daß das nun im größeren, indivduellen OSM Wildwuchs nun auch nichts mehr ausmacht.

Sehe ich deswegen anders weil je mehr Leute eine solche App Nutzen, umso vollständiger wird der Datensatz. Bevor eine komplette Stadt gemappt ist, ist da zunächst einmal ein einzelnes Gebäude...
Auch ohne diese Apps würde es sowas geben. Ich selbst neige zum Beispiel dazu einzelne Häuser und Hausnummern zu mappen einfach weil ich sie beim nächsten Kartenupdate im Navi haben will. Ich möchte nicht das daraus eine "Verpflichtung" entsteht auch noch den Rest des Viertels zu mappen nur damit keine Detailinsel entsteht.
OSM ist eben ein wachsendes Projekt und es wächst schneller wenn mehr Menschen mitmachen und dafür sind Apps die das editieren vereinfachen eine hervoragende Möglichkeit.

hsimpson wrote:

Ich verstehe echt nicht, wie man sich so an einer einzigen App aufhängen kann. Ich hab langsam das Gefühl, dass einige hier einfach nicht ertragen können ...
Grüße

Ich dachte ich hätte sachlich erläutert um was es mir geht und das es damit auch gut sein soll ... über die resultierende unterstellende Interpretation möcht ich mich erst gar nicht weiter ärgern.

Über User mit systematischem Output via SC kann ich hier nicht berichten (sont würde meine Meinung vielleicht eine andere sein). Vielleicht gibt's für sowas ja mal eine exemplarische Statistik über alle Editoren, um verschiedene Wahrnehmungen mit Zahlen zu untermauern.

Über die Notwenigkeit zu einem einfach zu handhabenden Zugang zur OSM Pflege für die Zukunft besteht sicher auch kein Dissenz - ob allerdings die Download Zahlen und Bewertungen der App allein sie qualifizieren?!?

Und wie gesagt - ich wills nicht weiter auswalzen, da ich für mich den Eindruck gewinne die Diskussion dreht sich im Kreis und sollte keinen Grabenkieg wert sein.

Gruß
Stephan

Bitboy wrote:

Länderspezifische Defaults, wie öfters zu sehen, würden im Extremfall zu einem 193 (Zahl der Länder auf der Erde) fachen Implementierungsaufwand für Software Entwickler führen die OSM nutzen wollen.

Man könnte die landesspezifischen Default-Werte in der Grenzrelation oder sonst an einem landesspezifischen Objekt ablegen. Dann könnte das jeder mittelmäßig begabte SW-Entwickler mit demselben Code für alle 193 Länder erledigen. Aber gut, das wäre zu elegant und wird deshalb bei OSM nie gemacht werden.

Ein Defaultwert ist solange Default, wie nix da steht. Steht ein Wert in der DB, ist es kein Default mehr, sondern ein bestätigter Wert.

Moin!

ich habe die Frage gestellt bekommen nach einer Öffnungszeit für eine Turnhalle. Ich habe die Info gegeben, dass es eine Turnhalle zur Schule ist und daher keine Öffnungszeiten gibt.

Daraufhin wurde ein OSM-Notes ertstellt.

Unable to answer "What are the opening hours of Turnhalle?" for https://www.openstreetmap.org/node/2731423990 via StreetComplete 6.1:

Turnhalle der Schule

Ich findes unpassend automatisch bei solchen Informationen automatisch einen Note zu generieren. Damit wird die Welt unter umständen vollgemüllt mit notes.

Wenn notes - dann mit explizietem Erstellungshaken durch den Anwender. Selbst das finde ich suboptimal.

Jan

Lübeck wrote:

Ich findes unpassend automatisch bei solchen Informationen automatisch einen Note zu generieren.

Die Notiz wurde nicht automatisch erstellt, du hast ja selber einen Text eingegeben und auf OK gedrückt... Auch der Titel der Eingabe (Stattdessen eine Notiz hinterlassen) und dann noch die Erklärung (dass du eine öffentliche Notiz hinterlässt) weisen doch eigentlich unmissverständlich daraufhin, dass mit der Eingabe eine Notiz erstellt wird, die dann auf der Website sichtbar ist.

Außerdem denke ich nicht, dass die Welt mit solchen Notizen "vollgemüllt" wird, da diese Notizen im Vergleich zu anderen oftmals leichter zu lösen sind und man sich relativ sicher sein kann, dass der Nutzer auch vor Ort war und diese Information, die angegeben wird auch überprüft wurde und damit stimmt. Am sinnvollsten ist es natürlich wenn der Nutzer noch ein oder zwei Fotos an die Notiz anhängt, dann sind diese Notizen eigentlich die mit dem höchsten Informationsgehalt. Von Müll würde ich also nicht sprechen...

Lübeck wrote:

ich habe die Frage gestellt bekommen nach einer Öffnungszeit für eine Turnhalle.

Die Turnhalle liegt innerhalb eines Gebiets, das mit amenity=school getaggt ist. Es ist daher keine frei zugängliche Sportstätte und StreetComplete sollte erst gar nicht nach den Öffnungszeiten fragen.

Also ich kenne mehrere Turnhallen die sich auf einem Gelände mit amenity=school befinden, aber trotzdem nicht nur für den Schulsport vorgesehen sind. Wenn es tatsächlich eine nicht öffentlich zugängliche Turnhalle sein sollte, dann sollte wohl eher der Tag access=private an die Turnhalle gesetzt werden. Dann fragt StreetComplete auch nicht nach dem Öffnungszeiten...
Aber ob die Turnhalle mit access=private ergänzt werden soll, sollte wohl eher in den Kommentaren unter der Notiz geklärt werde.

ENT8R wrote:

Also ich kenne mehrere Turnhallen die sich auf einem Gelände mit amenity=school befinden, aber trotzdem nicht nur für den Schulsport vorgesehen sind.

Solche kenne ich auch. Allerdings haben die keine Öffnungszeiten im klassischen Sinn, sondern dort finden zu festgelegten Zeiten von einem Verein durchgeführte Sportkurse statt. Das ist für mich dann ein Fall von access=private.

ENT8R wrote:

Wenn es tatsächlich eine nicht öffentlich zugängliche Turnhalle sein sollte, dann sollte wohl eher der Tag access=private an die Turnhalle gesetzt werden. Dann fragt StreetComplete auch nicht nach dem Öffnungszeiten...

Was ist, wenn am Schulgelände oder einem anderen umgebenden Gebiet access=private gesetzt wird?

rainerU wrote:

Was ist, wenn am Schulgelände oder einem anderen umgebenden Gebiet access=private gesetzt wird?

Dazu müsste ein Zaun mit Tor o.ä. vorhanden sein oder zumindest ein Schild der Art "Zutritt für Unbefugte verboten".
An einem Schulgelände wäre das ungewöhnlich.

seichter wrote:

rainerU wrote:

Was ist, wenn am Schulgelände oder einem anderen umgebenden Gebiet access=private gesetzt wird?

Dazu müsste ein Zaun mit Tor o.ä. vorhanden sein oder zumindest ein Schild der Art "Zutritt für Unbefugte verboten".
An einem Schulgelände wäre das ungewöhnlich.

Du wohnst auf dem Land, oder 🙂

In Innenstädten überhaupt nichts ungewöhnliches - leider.

Schulhöfe sind nachts sehr beliebte Drogenkonsumräume, was leider leider zu sehr Unerwünschten Erscheinungen von zuurinierten Ecken bis zu benutzten Spritzen im Sandkasten führt. Daher sind inzwischen viele Schulgelände komplett umzäunt und werden nach Schulschluss verschlossen.

Grüße

rainerU wrote:

Lübeck wrote:

ich habe die Frage gestellt bekommen nach einer Öffnungszeit für eine Turnhalle.

Die Turnhalle liegt innerhalb eines Gebiets, das mit amenity=school getaggt ist. Es ist daher keine frei zugängliche Sportstätte und StreetComplete sollte erst gar nicht nach den Öffnungszeiten fragen.

Vieleicht ein Ticket setzen?

Nebenbei finde ich, sollte man überlegen, ob man die Turnhalle einer Schule überhaupt als leisure=sports_centre bezeichnen sollte. Auch, wenn dort mitunter Vereinssport betrieben wird, ist das immer noch ein himmelschreiender Unterschied zu einer öffentlichen Anlage, die dem Freizeitsprot und der Erholung dient, wie leisure=sports_centre eigentlich definiert ist.

Ich hab dafür mal ein eigenes Thema aufgemacht.

seichter wrote:

rainerU wrote:

Was ist, wenn am Schulgelände oder einem anderen umgebenden Gebiet access=private gesetzt wird?

Dazu müsste ein Zaun mit Tor o.ä. vorhanden sein oder zumindest ein Schild der Art "Zutritt für Unbefugte verboten".
An einem Schulgelände wäre das ungewöhnlich.

Meine Frage war, ob StreetComplete auch dann die Öffnungszeiten einer Sporthalle abfragt, wenn diese auf einem Gelände liegt, das in OSM mit access=private gemappt ist, Warum das access=private gesetzt ist, spielt dabei keine Rolle. Anders ausgedrückt: berücksichtigt SC bei der Auswahl von Objekten vererbte Eigenschaften?

Ja selbst dann werden die Öffnungszeiten abgefragt... Allerdings sollte doch auch die Turnhalle access=private haben, wenn es sich auf einem nicht öffentlich zugänglichen Gelände befinden sollte, oder?
Noch eine extra Überprüfung für so einen Fall, der eigentlich ziemlich selten sein sollte hinzuzufügen ist meiner Meinung nach nicht notwendig. In solchen Fällen kann der Nutzer ja immer eine Notiz erstellen...

ENT8R wrote:

Ja selbst dann werden die Öffnungszeiten abgefragt... Allerdings sollte doch auch die Turnhalle access=private haben, wenn es sich auf einem nicht öffentlich zugänglichen Gelände befinden sollte, oder?

Kann man so sehen. Im Prinzip ist das wie bei der Frage, ob man an einem POI-Punkt, der in einem Gebäude liegt, die Adresse erfassen soll, wenn diese schon beim Gebäude abgelegt ist.

rainerU wrote:

ENT8R wrote:

Ja selbst dann werden die Öffnungszeiten abgefragt... Allerdings sollte doch auch die Turnhalle access=private haben, wenn es sich auf einem nicht öffentlich zugänglichen Gelände befinden sollte, oder?

Kann man so sehen. Im Prinzip ist das wie bei der Frage, ob man an einem POI-Punkt, der in einem Gebäude liegt, die Adresse erfassen soll, wenn diese schon beim Gebäude abgelegt ist.

Ich bin klar dafür, dass jedes Objekt vollständig getaggt wird, auch wenn dadurch möglicherweise bzw. ganz sicher redundante Informationen in der DB stehen. Der Grund ist, das Auswertetools es sehr schwer haben ohne dieses tagging sinnvolle Ergebnisse zu liefern.
Nehmen wir die POI Suche. Soll das Programm die Adresse des POIs anzeigen so ist es sehr hilfreich wenn diese am POI gemappt ist. Umgebende Gebäude, Gebiete oder Admin Bounderies auszuwerten und das für eventuell hunderte von POIs in der Suchabfrage ist technisch und zeitmäßig einfach zu aufwendig als das es praktikabel wäre.

Hi,
hier in diesem Changeset: https://www.openstreetmap.org/changeset/63068614
wurden mit StreetComplete meiner Ansicht nach wieder ein paar zu diskutierende Änderungen gemacht. Ich möchte jetzt nicht wieder SC komplett die Schuld in die Schuhe schieben, aber halt wissen, was da los ist/war. Hatte den User dazu berets kurz angeschrieben.

Aus meiner Sicht zu Bemängelndes:
- setzen von maxspeed:type=NL:urban → was hat das in Deutschland zu suchen? Vermutlich eine falsche Einstellung des Users? Oder wie?

- setzen von maxspeed:type=default:urban → hab' ich da wieder etwas verpasst? War es nicht wenn schon dann maxspeed:type=DE:urban gewesen? "default" heißt Standard, bringt aber keine Information dazu, woher dieses "Standard" denn jetzt kommt... Warum werden einfach so jetzt schon wieder neue Werte eingeführt? Wo ist das dokumentiert weiß das vielleicht jemand?

- setzen von maxspeed:type ohne maxspeed=*-Werte. Schon wieder diese Sache, dass maxspeed:type maxspeed ohne Diskussion quasi ersetzen soll. Ja und was ist dann, wenn maxspeed:type = sign ist? Dann wird maxspeed=* sowieso gebraucht. Warum wird maxspeed:type ohne maxpseed gesetzt.

Vielleicht kann mir jemand auf die Sprünge helfen oder meine Kritik entkräften. Ich verstehe diesen Changeset ehrlich gesagt nicht so ganz...
Danke

Lukas458 wrote:

setzen von maxspeed:type=NL:urban → was hat das in Deutschland zu suchen? Vermutlich eine falsche Einstellung des Users? Oder wie?

Der Benutzer von StreetComplete muss keine Vorkenntnisse wie OSM funktioniert haben. Deshalb gibt es auch keine Einstellung dafür... Ich denke dieses Problem liegt bei https://github.com/westnordost/StreetCo … ssues/1215 wurde mit der vor kurzem erschienenen Version 8.1 behoben. Ich werde im Issue mal vorschlagen die Version 8.0 vom Upload zu sperren.

Lukas458 wrote:

setzen von maxspeed:type=default:urban

Das müsste auch mit dem vorherigen Fehler zu tun haben. Ein neues Tagging ist das nicht (macht auch überhaupt keinen Sinn, wenn kein Land genannt ist...)

Lukas458 wrote:

setzen von maxspeed:type ohne maxspeed=*-Werte

So ganz ohne Diskussion ist das ja nicht abgelaufen... Irgendwo hier im Thread gab es dazu auch mal ne Diskussion... Wenn maxspeed:type=sign vorhanden ist, wird natürlich der explizite Geschwindigkeitswert gesetzt. Bei maxspeed:type=<country>:[urban/rural] hingegen ist es so schwierig zu sagen, welche explizite Geschwindigkeitsbegrenzung es gibt, sodass dass Setzen dieser Werte keinen Sinn macht (zumal der Wert ja durch maxspeed:type impliziert werden kann). Dabei muss man auch bedenken, dass SC nicht nur in Deutschland verwendet wird und dadurch die Geschwindigkeitsbegrenzungen per Gesetz nicht wirklich explizit erfasst werden können... westnordost hat mal angefangen eine Liste dazu erstellen (wer mehr Informationen hat kann ja gerne helfen die Liste zu erweitern): https://wiki.openstreetmap.org/wiki/Def … eed_limits

Ich hoffe deine Fragen sind damit geklärt 🙂
P.S.: Generell ist es oft besser Fehler direkt auf Github (https://github.com/westnordost/StreetComplete/issues) zu melden, weil dort i.d.R. schneller reagiert und geantwortet wird...

Wo ich mich noch schwer due.. Häuser mit hohem Kniestock... ist des dann building:levels= 1 oder 2; roof:levels=1.. oder auch 2 wenn vielleicht noch eine Zwischendecke drin ist mit kleinem halbhohen Speicher.. sieht man aber oft nicht.. nur wenn man durch das Fenster schauen kann um die Raumhöhe zu erkennen 🤔

z.B.
https://www.hausbau-portal.net/typo3tem … 074c17.jpg

Also bei deinem Beispiel würde ich building:levels=1 und roof:levels=1 eintragen. Das obere Stockwerk befindet sich ja streng genommen unter dem Dach... Im Wiki ist dieses Bild als Erklärung zu sehen, vlt. hilft dir das ja weiter: https://wiki.openstreetmap.org/wiki/Fil … levels.png

ENT8R wrote:

Also bei deinem Beispiel würde ich building:levels=1 und roof:levels=1 eintragen.

Ich finde das so ungenau.. weil building:levels=1 und roof:levels=1 können auch so richtig kleine Gebäude sein.. meist sehr alte.. oder Bungalows 🤔 dann müsste der Kniestock wenn es ein Tagging gibt da dran getaggt werden.. oder wie soll man später einer Anwendung erklären das dass Dach erst mit Kniestock beginnt und dann das Dach kommt.. 🤔

ENT8R wrote:

Das obere Stockwerk befindet sich ja streng genommen unter dem Dach...

Ganz Streng genommen befinden sich alle Stockwerke unter einem Dach 😉

ENT8R wrote:

Im Wiki ist dieses Bild als Erklärung zu sehen, vlt. hilft dir das ja weiter: https://wiki.openstreetmap.org/wiki/Fil … levels.png

Das Bild hilft leider nicht.. weil das ist der "saubere" Fall.. ohne Kniestock.., alle Stockwerke die gleiche Höhe

Wenn du das Tagging von Stockwerken weiter diskutieren willst schlage ich vor, dass du lieber einen neuen Thread eröffnest, anstatt hier in diesem Thread komplett vom eigentlichen Thema (der App StreetComplete) abzuweichen...

ENT8R wrote:

..hier in diesem Thread komplett vom eigentlichen Thema (der App StreetComplete) abzuweichen...

nicht ganz... weil StreetComplete einen hier maßregelt was man hier eingeben kann.. nur Ganzzahlen.. also 1.5 oder sowas geht nicht 🤔 fand ich recht elegant hier diese größe des Gebäudes zu beschreiben... anders könnte man das bisher nur über height & roof:height was ich aber dann nur schätzen würde.. z.b. height=10 & roof:height=4, aber das müsste man wieder im Nachgang nachbearbeiten.

Ich seh gerade es auch nicht unüblich: >30000+
https://taginfo.openstreetmap.org/keys/ … els#values

10000+

https://taginfo.openstreetmap.org/keys/ … els#values

Walk a Round wäre statt 1.5 kurzerhand 15 oder 105 einzugeben und dann mit overpass im Nachgang nachzuarbeiten.. ist aber auch nicht Sinn der Sache, drum hier 🤔

miche101 wrote:

nicht ganz... weil StreetComplete einen hier maßregelt was man hier eingeben kann

Wenn du glaubst, dass es sich dabei um einen Fehler bei StreetComplete handelt, ist es meistens der bessere Weg den Fehler direkt auf Github (https://github.com/westnordost/StreetComplete/issues) zu melden... Hier im Forum wird diesbezüglich eher nichts passieren.

miche101 wrote:

also 1.5 oder sowas geht nicht hmm fand ich recht elegant hier diese größe des Gebäudes zu beschreiben...

Gibt es überhaupt so etwas wie ein halbes Stockwerk? Was genau soll das denn ausdrücken? Entweder man baut ein Stockwerk oder nicht... Meiner Meinung nach hat die Anzahl der Stockwerke nichts mit der expliziten Höhe der Gebäude zu tun. Aus der Anzahl der Stockwerke kann man die ungefähre Höhe des Gebäudes erraten, aber um die genaue Höhe zu bekommen müssen Werte wie building:height oder roof:height natürlich auch vorhanden sein. Ich würde die ganzen Werte mit ,5 eher als ein Taggingfehler klassifizieren.

@miche101 (leicht OT)
Dein Photo zeigt keinen besonders hohen Kniestock,
sondern ein stinknormales Pfettendach im (heutigen) Wohnungsbau in DE,
die Fußpfette liegt geschätzt ca. 1,0 m ü OKF.

https://wiki.openstreetmap.org/wiki/Fil … levels.png
ist die laienhafte Darstellung einer Situation ohne Drempel im DG,
wie sie in DE eigentlich nur bei einem (eher historischen) Sparrendach vorzufinden ist.
Dieses Bildchen bitte nicht zu genau nehmen ...

miche101 wrote:

nicht ganz... weil StreetComplete einen hier maßregelt was man hier eingeben kann.. nur Ganzzahlen.. also 1.5 oder sowas geht nicht f

das maßregelt nicht StreetComlete, sondern das Wiki sieht schlicht halbe Geschosse nicht vor, sondern ausschließlich eine ganze Zählung.

miche101 wrote:

fand ich recht elegant hier diese größe des Gebäudes zu beschreiben... anders könnte man das bisher nur über height & roof:height was ich aber dann nur schätzen würde..

die Größe eines Gebäudes mit der Anzahl der Geschosse zu beschreiben ist genauso eine Schätzung, i.d.R. viel ungenauer. Ein Wohngebäude mit 5 Geschossen ist bei einer durchaus üblichen Raumhöhe von 2,40 m etwa genauso groß wie ein Bürogebäude mit 4 Geschossen und einer Raumhöhe von 3m oder eine eingeschossige Lagerhalle von 12m Höhe.
Ich persönlich zähle auch nur Vollgeschosse, Spitzböden, die auch von außen augenscheinlich keine Vollgeschosse sein können (Höhenabschätzung im Vergleich zu den übrigen Etagen, deutlich kleinere Fenster) zähle ich nicht mit, auch nicht als halbes Geschoss.

Der Mammi

Natürlich verwenden 3D Renderer levels zur Abschätzung der Gebäudehöhe. Das ist auch in den meisten Anwendungsfällen hinreichend genau. Wenn ich das genauer brauche, komme ich nicht umhin, die Höhe zu taggen.

hier in diesem Changeset: https://www.openstreetmap.org/changeset/63068614
wurden mit StreetComplete meiner Ansicht nach wieder ein paar zu diskutierende Änderungen gemacht. Ich möchte jetzt nicht wieder SC komplett die Schuld in die Schuhe schieben, aber halt wissen, was da los ist/war. Hatte den User dazu berets kurz angeschrieben.

Aus meiner Sicht zu Bemängelndes:
- setzen von maxspeed:type=NL:urban → was hat das in Deutschland zu suchen? Vermutlich eine falsche Einstellung des Users? Oder wie?

Das war kein Fehler des Nutzers sondern ein Fehler in StreetComplete v8.0-beta1 und v8.0 (16. September). Danke für die Meldung und Danke an ENT8R, der das noch auf GitHub gemeldet hat, wäre fast wieder in diesem Topic untergegangen.
Das Land in dem ein Element sich befand, wurde nicht korrekt erkannt. Das ist behoben mit StreetComplete v8.1 (29. September) und die alten Versionen habe ich jetzt geblockt (können keine Änderungen mehr hochladen). Ich werde die Changesets die in dieser Zeit entstanden sind nach solchen Fehlern durchforsten und korrigieren.

Siehe auch https://github.com/westnordost/StreetCo … ssues/1222 für eine genaure Problembeschreibung.

Danke euch!

ENT8R wrote:

Gibt es überhaupt so etwas wie ein halbes Stockwerk? Was genau soll das denn ausdrücken? Entweder man baut ein Stockwerk oder nicht... Meiner Meinung nach hat die Anzahl der Stockwerke nichts mit der expliziten Höhe der Gebäude zu tun. Aus der Anzahl der Stockwerke kann man die ungefähre Höhe des Gebäudes erraten, aber um die genaue Höhe zu bekommen müssen Werte wie building:height oder roof:height natürlich auch vorhanden sein. Ich würde die ganzen Werte mit ,5 eher als ein Taggingfehler klassifizieren.

Taggingfehler? dann könnte man auch sagen.. Ein Gebäude hat eine gewisse Zahl an Stockwerke dabei wird aber normalerweise auch nicht zwischen "Dach" & "Gebäude" Stockwerken unterschieden oder getrennt. Es gibt nur eine Gesamtzahl..

Dächer mit geringer/höhe Dachneigung wären dann immer roof:levels=0?

"Dach" & "Gebäude" Stockwerken werden nur dafür gebraucht um da was daraus zu rendern.. und um eine einfache Möglichkeitet dem Mapper an die Hand zu geben was sinnvolles einzugeben woraus man eine Höhe ableiten kann... wenn keine Höhe eingegeben ist. Oder schon mal die Höhe eines Gebäudes gemessen? Bzw. das für eine ganzen Ort gemacht?

miche101 wrote:

Dächer mit geringer/höhe Dachneigung wären dann immer roof:levels=0?

M.E. ist das durchaus korrekt. Es gibt Dachformen, Pultdächer und Spitzböden, da kann man kaum reinkriechen. Das ist für mich kein Stockwerk mehr.

miche101 wrote:

"Dach" & "Gebäude" Stockwerken werden nur dafür gebraucht um da was daraus zu rendern.. und um eine einfache Möglichkeitet dem Mapper an die Hand zu geben was sinnvolles einzugeben woraus man eine Höhe ableiten kann... wenn keine Höhe eingegeben ist.

Vollkommen richtig erkannt. Dabei sollte die Betonung auf "einfache Möglichkeit" und "ableiten" liegen. Halbe und andere Bruchteile eines Geschosses sind schon nicht mehr einfach und machen die abgeleitete Höhe auch nicht genauer (schrieb ich weiter oben schon). Letztlich ist dieser Tag nichts anderes als die Fensterreihen zählen, was m.E. in SC auch gut dargestellt ist. Halbe Fensterreihen hab ich noch nicht gesehen.

der Mammi

Mammi71 wrote:

M.E. ist das durchaus korrekt. Es gibt Dachformen, Pultdächer und Spitzböden, da kann man kaum reinkriechen. Das ist für mich kein Stockwerk mehr.

Aber da ist dann das nächste Problem.. wenn man 0 eingibt gekommt man kein Dachform Quest:

siehe:
https://wiki.openstreetmap.org/wiki/Str … ete/Quests

What basic shape does this building's roof have?
https://overpass-turbo.eu/s/s1n

...["roof:levels"!="0"]...

Weil angenommen wird dann das es ein Flachdach ist... also muss man 1 eingeben 🤔

Schließe ich dann richtig das wenn eine Garage zum Dach keine Zwischendecke hat dann building:levels=0 roof:levels=1 ist, weil dann ist es ja wie ein Dachgeschoss 🤣

Nur weil es in StreetComplete kein Quest dafür gibt, heißt das noch lange nicht, dass man die Dachform grundsätzlich nicht eintragen sollte wenn roof:levels=0 ist.

StreetComplete bietet das nicht an, weil es dann in Gegenden in denen (schräge) Dächer nicht üblich sind einerseits die User massiv mit diesen Quests zugespammt werden bei denen sie bei 99,9% immer das gleiche antworten müssen (Flachdach) und andererseits natürlich auch die Leute die QA machen mit allerlei Changesets mit 0 Informationsgehalt zugeballert werden.

Gegenden wie etwa regenarme Gebiete:
https://www.google.de/maps/@34.0207156, … a=!3m1!1e3
oder auch praktisch jedes größere Gewerbegebiet.

Siehe auch die Guidelines für neue Aufgabenvorschläge in StreetComplete

• No spam: It must be possible to determine whether the quest should reasonably be asked. A quest which is to be answered in 99% of the time with the same answer is not a good quest, don't bore the users. I.e. asking for any road if it is a one-way road, is silly, because the vast majority of all roads will not be one-ways.
  
• Valuable Surveyors: Surveyor time is valuable, they shouldn't be asked to complete data that does not require a survey and can more efficiently be done remotely.
  

Plus, bezüglich dem zweiten Punkt im Zitat: Die Form von relativ Flachen Dächern ist von unten oft garnicht sichtbar. Da ist es oft einfacher, die Dachform om Satellitenbild aus zu bestimmen, und wohl auch effizienter.

miche101 wrote:

Aber da ist dann das nächste Problem.. wenn man 0 eingibt gekommt man kein Dachform Quest

Da trage ich nicht "0" ein sondern lasse es einfach leer.

Naja... für mich macht das mappen von levels nur Sinn für die Ermittelung der ungefähren Höhe.. Die Stockwerke als solches interessieren mich anderweitig nicht... (mehr würde mich interessieren ob es einen Aufzug gibt 😉 ) sehe auch keinen nutzen für mich darin warum ich das mappen sollte das ist mir meine Zeit zu schade 🤔

Vor allem wenn man den Kniestock nicht eingeben kann.. ist die Höhe die man aus dem Level berechnenen kann sichtbar ungenau.. (ohne Kommastelle..) Die Höhen(in Meter) der Gebäude und Dächer fange ich bei normaler Wohnbebauung nicht an zu messen.. kann gern wer anders machen 😛

Außerdem sollte man mal vielleicht doch mal darauf kommen den Kniestock oder Komma beim Level einzuführen.. muss man wieder alles neu abfahren 🙁

Glaub dann mach ich das Quest nur bei Gebäude mit building:levels=3 und mehr...

mfg Miche

Ein x:levels wird glaub oft mit 3m übersetzt.
roof:levels macht also nur bei einem Flachdach Sinn.

Ansonsten sollte roof:height zusammen mit roof:shape und ggf. roof:orientation verwendet werden.
Wie macht sowas StreetComplete?

roof:orientation nein, ist aber auch dann immer abhängig von der geometrie des Gebäudes wie des dann ausgerichtet wird 🤔 und das wird auch nicht immer gleich gemacht...

wobei roof:shapes farbe, ausrichtung usw. mit dem Luftbild auch schön machen kann... >>meist<<

R0bst3r wrote:

Ein x:levels wird glaub oft mit 3m übersetzt.
roof:levels macht also nur bei einem Flachdach Sinn.

Nein, wieso?
wiki sagt:

Number of floors within the roof, which are not already counted in building:levels=*.

Wo kommt da jetzt das Flachdach her?

Sollte roof:levels=0 heißen. Damit lassen sich nur Flachdächer modellieren.

Hi

weil ich gerade darüber gestolpert bin: amenity=telephone wäre ein Quest schön.. covered=, indoor=, payment:...= oder so..? Alleine da viele noch in OSM sind die eventuell schon abgebaut wurden.. so als Nebeneffekt um die Existenz feststellt.

https://wiki.openstreetmap.org/wiki/DE: … uselang=de

Gruß Miche

PS: Bei Git-Hub ich nix gefunden... hab aber keinen Account bei Git-Hub.. und mag jetzt nicht extra einen anlegen 😉

miche101 wrote:

Naja... für mich macht das mappen von levels nur Sinn für die Ermittelung der ungefähren Höhe.. ...
Vor allem wenn man den Kniestock nicht eingeben kann.. ist die Höhe die man aus dem Level berechnenen kann sichtbar ungenau.. (ohne Kommastelle..)

Sehr verworren, was Du da schreibst. Solange man die Höhe der Levels nicht genau kennt, kann man aus der Anzahl Levels keine genaue Höhe des Gebäudes berechnen. Das geht einfach nicht!
Da nützt Dir auch nicht, wenn Du 0,5 levels für einen Kniestock ansetzen könntest - konsequenterweise musst Du dann sowieso von den roof:levels wieder 0,5 abziehen. Einfacherweise - wenn man die Geschosse/Stockwerke/Etagen betrachtet - gehört der Kniestock zum Dachgeschoss. Für mich daher roof:levels=1 (und weitere wenn vorhanden)
Zur Ungenauigkeit der Levels: ich habe gestern die x:levels zweier benachbarter Gebäude gemappt: eines building:levels=2 + roof:levels=1; das andere building:levels=3 + roof:levels=1. Das eine verklinkerter Altbau, das andere moderner Neubau. Welche Höhen willst Du abschätzen? In der Realität sind beide Gebäude gleich hoch.

@Mammi71

Auch wenn man dem Multiplikator nicht kenne bleibt das Verhältnis das gleiche, von daher kann man in der 3d Karte sehr wohl sehr genau unterscheiden... Vielleicht kann man 1,1 von 1,2 nicht unterscheiden aber den Rest sehr wohl..

Mfg Miche

Jetzt habe ich hier einen SC User, der (mehr oder minder) mitten in Deutschland maxspeed Einträge mit maxspeed:type=NL:urban produziert ..
Wie würfelt SC das denn aus? Basierend auf GPS Daten (die da gerade vielleicht springen?). Oder muß man da was konfigurieren?

https://www.openstreetmap.org/changeset/63158023

Guck nur mal eine Seite vorher nach was da steht! Das Problem ist mittlerweile gelöst. Liest denn keiner die Beiträge der anderen?

ENT8R wrote:

Liest den keiner die Beiträge der anderen?

Mea Culpa. Aber als gelöst würde ich das nicht betrachten. Wie du richtig schreibst: "Der Benutzer von StreetComplete muss keine Vorkenntnisse wie OSM funktioniert haben. "
Wer kümmert sich denn jetzt um die zurückgelassenen Fehler? Der SC Entwickler? Die Benutzer wissen ja nix von Ihrem Glück.

Viele sind's scheinbar in D nicht: https://overpass-turbo.eu/s/CHi

Gruß
Stephan
Bearbeitet: Abfrage aktualisiert (Jetzt alle betroffenen Werte ungleich maxspeed_type=DE* in Deutschland)

Das Problem in der App ist gelöst und westnordost hat die fehlerhaften Einträge korrigiert. Hier dazu der Beitrag von westnordost im Forum: https://forum.openstreetmap.org/viewtop … 53#p718853 und exemplarisch eines der Changesets: https://www.openstreetmap.org/changeset/63240044. Aus deinem Beitrag sehe ich, dass er wohl nicht alle Fehler "erwischt" hat.

aixbrick wrote:

Aus deinem Beitrag sehe ich, dass er wohl nicht alle Fehler "erwischt" hat.

So sieht's aus ..

aixbrick wrote:

Das Problem in der App ist gelöst und ...

Allerdings ist das zumindest hier: https://www.openstreetmap.org/changeset/63348583 auch mit SC 8.1 noch in die Hose gegangen ..

Gruß
Stephan

westnordost wrote:

Das war kein Fehler des Nutzers sondern ein Fehler in StreetComplete v8.0-beta1 und v8.0 (16. September). Danke für die Meldung und Danke an ENT8R, der das noch auf GitHub gemeldet hat, wäre fast wieder in diesem Topic untergegangen.
Das Land in dem ein Element sich befand, wurde nicht korrekt erkannt. Das ist behoben mit StreetComplete v8.1 (29. September) und die alten Versionen habe ich jetzt geblockt (können keine Änderungen mehr hochladen). Ich werde die Changesets die in dieser Zeit entstanden sind nach solchen Fehlern durchforsten und korrigieren.

@westnordost,

da sind immer noch einige übrig geblieben (und die nur für Deutschland):
https://overpass-turbo.eu/s/D2B
Gruß
tux67

Das Problem betraf Antworten die mit StreetComplete v8.0-beta1 und v8.0 gegeben wurden.

Es kann sein dass einige Leute die Antworten nicht sofort/zeitnah hochgeladen haben sondern erst später mit der neuen Version - insbesondere Nutzer die StreetComplete über F-Droid beziehen, weil F-Droid das v8.2 Update mit 5 Tagen Verspätung ausgeliefert hat (das ist nicht normal, die hatten da wohl Probleme mit dem Buildprozess, siehe #1223 Can't submit quests done with v8.0 and v8.1 is not on F-Droid)

Ich kümmer mich drum, die restlichen Eintrage auch noch zu korrigieren, danke für die praktische Overpass-Query.

Hallo,

So etwas sollte mit StreetComplete nicht möglich sein. Das "Mo-Fr 18:30" ganz am Ende überschreibt das "Mo-Fr 16:30" am Anfang.

Das muss unbedingt korrigiert werden.

Prince Kassad wrote:

So etwas sollte mit StreetComplete nicht möglich sein. Das "Mo-Fr 18:30" ganz am Ende überschreibt das "Mo-Fr 16:30" am Anfang.

Nein, dazu müsste vor dem "Mo-Fr 18:30" ein Semikolon und kein Komma stehen.

schicker wäre natürlich Mo-Fr 16:30,18:30, Sa 12:45 ... nicht wahr?

Wie sieht es mit den access=yes aus die StreetComplete auf Spielplätze mappt?

In der Wiki Steht dass access=yes nicht ausdrücklich erfasst werden muss.
Dann sollte man nicht unnötig OSM mit Daten vollpacken.
Man mappt doch auch keine Straße/Lift/Strand/Park/Post/Restaurant usw. mit access=yes

Aus meiner Sicht sollte StreetComplete nur fragen ob ein Spielplatz privat oder für Kunden ist.
Logisch wird dann ein Parkplatz usw. immer wieder angezeigt wenn Kunden oder Privat nicht ausgeschlossen wird.
Das müsste in der App anders gelöst werden. Dass man z.B. eine Frage nicht beantworten möchte, sollte man die Möglichkeit haben diesen Punkte dann lokal auf dem Handy in einer Blacklist zu speichert, sonst wird irgendwann ein genervter User sie doch als Privat etc. mappen damit sie nicht mehr angezeigt werden.

Alle Spielplätze mit access=yes zu mappen nur damit StreetComplete sie nicht mehr anzeigt sehe ich als "mappen für den Renderer/Tool", da anscheinend nur StreetComplete ein Problem hat wenn access fehlt.

luschi wrote:

In der Wiki Steht dass access=yes nicht ausdrücklich erfasst werden muss.

In der deutschen Version mag das vielleicht so stehen (ich hab es mir jetzt nicht genau angesehen), aber maßgeblich ist eigentlich immer die englische Version:

It is not necessary to use explicit access=yes for public ones but it is OK to do that

Es ist also nicht unbedingt notwendig diese Information hinzuzufügen, aber es ist trotzdem erlaubt.
Die Frage ist dann natürlich immer, ab wann ein Wert als default angesehen werden kann... Aber eigentlich gibt es in OSM so gut wie keine Defaultwerte (alles was nicht als Information vorhanden ist, ist grundsätzlich erst einmal unbekannt), wodurch StreetComplete keinesfalls nur diese Information mappt um diese Frage nicht erneut anzuzeigen, sondern um OpenStreetMap um eben diese Information zu ergänzen...

ENT8R wrote:

wodurch StreetComplete keinesfalls nur diese Information mappt um diese Frage nicht erneut anzuzeigen, sondern um OpenStreetMap um eben diese Information zu ergänzen...

und dabei seine Schlüssel versucht durchzusetzen -> siehe maxspeed:source und maxspeed:type (oder wie auch immer)

ENT8R wrote:

Aber eigentlich gibt es in OSM so gut wie keine Defaultwerte (alles was nicht als Information vorhanden ist, ist grundsätzlich erst einmal unbekannt),

Es ist aber falsch an Spielplätzen ALLES (access=yes) zu erlauben. Wenn schon, dann bitte richtig: parents, childrens, age, ...

geri-oc wrote:

und dabei seine Schlüssel versucht durchzusetzen -> siehe maxspeed:source und maxspeed:type (oder wie auch immer)

Ich dachte das Thema wäre jetzt so langsam mal abgeschlossen 🙁 ... Ganz ehrlich: was hat das jetzt mit dem Thema davor zu tun? Musst du das bei jeder Gelegenheit wieder hervorholen? Es gibt nunmal leider keine vernünftige/gut dokumentierte/ausführliche Lösung um implizite Geschwindigkeiten zu taggen, und für irgendein Taggingschema muss sich StreetComplete nun mal entscheiden. Und das Schema für das sich entschieden wurde ist dann immer für jemand anderes falsch, weil er selber es ja am liebsten mit einem anderen Schema taggt... 🙁

geri-oc wrote:

Es ist aber falsch an Spielplätzen ALLES (access=yes) zu erlauben. Wenn schon, dann bitte richtig: parents, childrens, age, ...

Das sind alles Informationen, die dann gerne in nächsten Schritten noch hinzugefügt werden können. Und falsch ist es ganz sicher nicht, access=yes ist dann auch nur wieder ein weiterer grober Wert, der immer noch weiter verfeinert werden kann, Wie weit der Wert genau verfeinert wird, liegt letztendlich aber bei jedem Mapper selber...

ENT8R wrote:

geri-oc wrote:

Es ist aber falsch an Spielplätzen ALLES (access=yes) zu erlauben. Wenn schon, dann bitte richtig: parents, childrens, age, ...

Das sind alles Informationen, die dann gerne in nächsten Schritten noch hinzugefügt werden können. Und falsch ist es ganz sicher nicht, access=yes ist dann auch nur wieder ein weiterer grober Wert, der immer noch weiter verfeinert werden kann, Wie weit der Wert genau verfeinert wird, liegt letztendlich aber bei jedem Mapper selber...

Spielplätze, die auch von LKW befahren werden können, sind mir bisher noch nicht begegnet. Insofern halte ich es schon für grob falsch, einem Spielplatz, der potentiell auch an eine Straße angrenzen kann, mit access=yes, was von einem Schneemobil über Pferd bis hin zum Bus und LKW alles erlaubt, zu taggen

ENT8R wrote:

...und für irgendein Taggingschema muss sich StreetComplete nun mal entscheiden...

Ach so wird das jetzt also verargumentiert, dass ich eine App mittlerweile entscheiden muss ... wie wäre es einfach mal mit weglassen, oder eben vorher soweit durch alle Kanäle/Instanzen durchdiskutieren bis ein/das Taggingschema von der Mehrheit akzeptiert wurde?
Und deshalb gebe ich geri-oc Recht, wenn er sagt, dass StreetComplete hier etwas durchsetzt ... und nein, dass ich kein reines Bashing gegen StreetComplete, diesem Vorwurf müssen sich auch andere Apps (wie z.B. iD) gefallen lassen ... aber StreetComplete hätte es halt besser machen können 😉

SunCobalt wrote:

Spielplätze, die auch von LKW befahren werden können, sind mir bisher noch nicht begegnet. Insofern halte ich es schon für grob falsch, einem Spielplatz, der potentiell auch an eine Straße angrenzen kann, mit access=yes, was von einem Schneemobil über Pferd bis hin zum Bus und LKW alles erlaubt, zu taggen

Wenn dir solche Spielplätze bisher noch nicht begegnet sind, dann kannst du bestimmt davon ausgehen, dass auch Nutzer der Daten diese Erfahrungen in ihre Produkte einfliessen lassen werden 🙂

Außerdem dient der Wert von access=* in diesem konkreten Fall doch nicht als Zufahrtsbeschränkung für Fahrzeuge (Flächen mit Attributen wie leisure=playground werden soweit ich weiß nicht als Straße behandelt, dafür müsste dann noch ein highway=* an die Fläche dran...) sondern vielmehr als eine Art Zugangsbeschränkung für Personen, die diesen Spielplatz benutzen möchten. Insofern kann bei Spielplätzen eigentlich nur der Wert access=yes/private/customers verwendet werden...

Also bei uns sind viele Spielplätze altersbeschränkt. access=yes (JEDER darf drauf) wäre da schlichtweg falsch.

ENT8R wrote:

SunCobalt wrote:

Spielplätze, die auch von LKW befahren werden können, sind mir bisher noch nicht begegnet. Insofern halte ich es schon für grob falsch, einem Spielplatz, der potentiell auch an eine Straße angrenzen kann, mit access=yes, was von einem Schneemobil über Pferd bis hin zum Bus und LKW alles erlaubt, zu taggen

Wenn dir solche Spielplätze bisher noch nicht begegnet sind, dann kannst du bestimmt davon ausgehen, dass auch Nutzer der Daten diese Erfahrungen in ihre Produkte einfliessen lassen werden 🙂

Außerdem dient der Wert von access=* in diesem konkreten Fall doch nicht als Zufahrtsbeschränkung für Fahrzeuge (Flächen mit Attributen wie leisure=playground werden soweit ich weiß nicht als Straße behandelt, dafür müsste dann noch ein highway=* an die Fläche dran...) sondern vielmehr als eine Art Zugangsbeschränkung für Personen, die diesen Spielplatz benutzen möchten. Insofern kann bei Spielplätzen eigentlich nur der Wert access=yes/private/customers verwendet werden...

Damit überlädst Du den Tag und machst ihn kontextabhängig..... Ist das irgendwo besprochen worden oder entscheidest du das?

Harald Hartmann wrote:

Ach so wird das jetzt also verargumentiert, dass sich eine App mittlerweile entscheiden muss ... wie wäre es einfach mal mit weglassen, oder eben vorher soweit durch alle Kanäle/Instanzen durchdiskutieren bis ein/das Taggingschema von der Mehrheit akzeptiert wurde?

Seit einigen Versionen ist genau diese Frage auch schon standardmäßig deaktiviert dennoch aus einem anderen Grund...

Das mit dem Diskutieren wurde doch auch schon mal versucht: https://forum.openstreetmap.org/viewtopic.php?id=60027
Das Problem ist nur, dass es immer irgendjemanden geben wird, der mit der Lösung nicht 100%-ig zufrieden ist.

Momentan sind es vor allem die Mapper aus Deutschland, weil maxspeed:type=* verwendet wird, was in DE so gut wie kaum verwendet wird. Wenn dann aber auf source:maxspeed=* gewechselt wird, beschweren sich die Briten, dass dieses Schema falsch verwendet wird...

Und die Nutzer der Daten müssen sich sowieso auf alle möglichen Lösungen einstellen, solange es kein global gültiges Schema dafür gibt.
Falls sich irgendwann mal auf ein gültiges Schema geeinigt wird, dann können notfalls immer noch alle anderen durch (automatisierte) Edits zu einem zusammengefasst werden.

Wer sich weiterhin an einer Diskussion bezüglich des von StreetComplete verwendeten Maxspeed-Schemas beteiligen will, den lade ich gerne ein den extra dafür erstellten Thread zu nutzen: https://forum.openstreetmap.org/viewtopic.php?id=60027

chris66 wrote:

Also bei uns sind viele Spielplätze altersbeschränkt. access=yes (JEDER darf drauf) wäre da schlichtweg falsch.

Naja... Das Gelände darf jeder betreten. Solange er/sie die nicht Geräte benutzt ist ja alles in Ordnung. Da leisure=playground aber nur das Gelände und nicht die einzelnen Gerätschaften angibt, ist access=yes für öffentlich Spielplätze meiner Meinung nach schon legitim...

ENT8R wrote:

It is not necessary to use explicit access=yes for public ones but it is OK to do that

Das steht im Wiki erst seit November, und es ist nicht erkennbar, dass dieser Änderung eine Diskussion vorausgegangen wäre.

Dies nur zur Klarstellung, ist nicht mein Thema und ich hab nicht vor mich einzumischen. Aber wenn hier jemandem das Weglassen des Defaultwerts access=yes am Herzen liegt, empfehle ich einen Revert der entsprechenden Änderung. Sonst gilt das, was dort steht, schnell als "Community-Konsens" – in die Versionsgeschichte schaut kaum wer.

Dann mal eine weitere access Frage.

Seit dem Update von gestern gibt es die Frage: Sind auf dieser Straße Fußgänger erlaubt, da sidewalk=no erfasst ist?

Wenn ich hier jetzt auswähle, dass Fußgänger erlaubt sind, taggt StreetComplete die Straße mit foot=yes

Jetzt meine Fragen:

Frage 1:
Wozu foot=yes? ist die Straße das noch nicht?
Und was wenn dan jemand auf Nein tippt? foot=no macht dann doch sidewalk=no überflüssig
https://wiki.openstreetmap.org/wiki/OSM … strictions

Frage 2:
Wozu sidewalk=no? Werden nicht alle Straßen bereits als sidewalk=no ausgewertet, bis yes/left usw. erfasst wird?

Frage 3:
Sarkasmus an:
Wo ist dann die Aufgabe wo man gefragt wird ob die Straße von Fahrzeugen befahren werden darf und dann vehicle=yes erfassen wird wenn access=yes bei Straßen nicht der Standard ist?

Es muss doch jemanden geben, der den Zugriff von APPs auf die Datenbank ermöglicht. Warum gibt es dort keine Vorschriften, was gemacht werden darf und was nicht.

Wir hatten Problem mit Wheelmap und jahrelang versucht sie zu klären. Wenn jemand Interesse an OpenStreetMap hat, dann arbeitet er sich auch in einen Editor ein.

Warum überhaupt so viele APPs mit Rechten die gar nicht diskutiert oder festgelegt sind? Ich zähle auch iD dazu mit z.B. name_1, name_2 und anderes.

luschi wrote:

...
Frage 2:
Wozu sidewalk=no? Werden nicht alle Straßen bereits als sidewalk=no ausgewertet, bis yes/left usw. erfasst wird?
...

Nein, das wäre nur der Fall, wenn sidewalk=no als implizierter Defaultwert bei Straßen in OSM definiert wäre. Von daher bedeutet sidewalk=no, dass kein Gehsteig dran ist. Bei einem Weg ohne sidewalk-Tag kann ein Gehsteig dran sein oder auch nicht. Ist auch laut TagInfo in der Praxis so im Einsatz https://taginfo.openstreetmap.org/keys/sidewalk#values

sidewalk hat aber mit einem access-Tag, wie foot=yes/no nichts direkt zu tun und somit finde ich die beschrieben StreetComplete-Frage nicht sinnvoll.

geri-oc wrote:

Es muss doch jemanden geben, der den Zugriff von APPs auf die Datenbank ermöglicht. Warum gibt es dort keine Vorschriften, was gemacht werden darf und was nicht.

Weil OSM ein freies Projekt ist, was sicherlich in einigen Punkten etwas zu viel Freiheit erlaubt, aber andererseits ohne diese Freiheiten nie zu dieser Größe gelangt wäre, an der es momentan ist.
Ohne diese Freiheiten würden auch nicht drei oder vier verschiedene Tagging-Schemas für ein und dieselbe Sache existieren...

geri-oc wrote:

Wir hatten Problem mit Wheelmap und jahrelang versucht sie zu klären. Wenn jemand Interesse an OpenStreetMap hat, dann arbeitet er sich auch in einen Editor ein.

Das bezweifle ich... Mit StreetComplete gibt es viele Nutzer, die schon einmal etwas von OSM gehört haben und eine grobe Vorstellung des Projektes haben, aber vlt. nicht genug Zeit um sich in einen (für Anfänger durchaus komplizierten) Editor einzuarbeiten. Die bequemere Alternative ist dann ein Editor/eine App wie StreetComplete.

geri-oc wrote:

Warum überhaupt so viele APPs mit Rechten die gar nicht diskutiert oder festgelegt sind?

Wie gesagt... OSM ist ein freies Projekt, jeder darf im Grunde genommen das tun was er will. Ob das nun gut oder schlecht ist hängt wohl von jedem Fall selber ab.

geri-oc wrote:

Warum überhaupt so viele APPs mit Rechten die gar nicht diskutiert oder festgelegt sind? Ich zähle auch iD dazu mit z.B. name_1, name_2 und anderes.

Letzteres (*_1) wurde sehr kürzlich abgeändert, siehe:

https://github.com/openstreetmap/iD/com … 5897619433

und sollte dann mit der kommenden Version 2.14 aktiv werden...

geri-oc wrote:

Es muss doch jemanden geben, der den Zugriff von APPs auf die Datenbank ermöglicht.

Nein, so jemanden gibt es nicht. Die Schnittstellen liegen offen, falls ich die nächsten paar Wochenenden nichts besseres zu tun hätte, könnte ich einen Editor schreiben. Der hätte furchbare Fehler und wäre für alles was ich damit anfasse vernichtend, aber die API würde ihn akzeptieren.

Wenn schon OSM die Edits externer Tools nicht einschränken kann, sollten sie neue User auf ein Tutorial hingweisen, oder einen Link zur betreffenden Wikiseite anzeigen.

In StreetComplete habe ich kein Tutorial oder Hinweis zu OSM bei der ersten Installation angezeigt bekommen.
Wer sieht sich schon die Datenschutzerklärung einer App an, wo dann in 2 Sätzen was über OSM steht?
In gewisser weiße muss man als Ersteller einer solchen App, gegenüber neuen Mappern doch eine gewisse Aufklärung betreiben, da ich finde, dass so der eine oder andere wertvolle Mapper für die Comunity gewonnen werden könnte, was wichtiger ist als massig neue Mapper die nach einem halben Jahr keine Lust mehr haben.

Eine Mögichkeit wäre es z.B. neue Registrierungen standardmäßig zu sperren solange sie nicht eine Infoseite auf OSM durchgelesen haben und erst dann dürften sie editieren. Eine Account-bestätigen-Email erfüllt wohl nicht den Effekt. Egal ob sie sich über Handy oder PC registrieren und worüber sie editieren wollen.
Das würde die neuen Mapper etwas sensibilisieren.

Es ist ein Unterschied ob ich Nonsens auf Facebook hochlade oder ob ich Nonsens auf OSM hochlade...

PS:
Ergänzu zu meinem vorherigen Post:
StreetComplete erfasst bei "Nein" den Weg mit foot=no und sidewalk=no
das ist dann eine doppelte Verneinung

luschi wrote:

Alle Spielplätze mit access=yes zu mappen nur damit StreetComplete sie nicht mehr anzeigt sehe ich als "mappen für den Renderer/Tool", da anscheinend nur StreetComplete ein Problem hat wenn access fehlt.

Da gibt es noch einige mehr, die die Daten nicht so wirklich bereichern, sondern eher dazu dienen, daß Editoren wie Streetcomplete dem nächsten Benutzer diese Abfrage nicht mehr anbieten. Noname=yes an Wegen ist auch sowas oder lit=no an Waldwegen (war iD, wenn ich mich recht entsinne).
Ich würde mir halt wünschen, daß solche Äpps mehr auf das Ergänzen dessen, was ist, fokussieren als auf Eigenschaften, die nicht da sind und das ganz offenkundig. Sprich: die Mitarbeit der Äppnutzer auf Dinge mit Nutzwert lenken, statt auf Fehlen von Eigenschaften, die sowieso fast immer an solchen Objekten nicht vorhanden sind. Surface=* an highways z.B. ist eine gute Sache, da kann im Vorbeigehen eine Menge sinnvoll ergänzt werden.

Aber auch Fehlermeldungen à la "als Antwort auf: was sind die Öffnungszeiten von ...? - Stehen nicht dran" bräuchte man doch gar nicht abladen.

luschi wrote:

Wozu sidewalk=no?

Sidewalk=no finde ich eine hilfreiche Information, da man ohne dieser keine sinnvolle Aussage darüber machen kann und es mehr oder weniger gleich wahrscheinlich ist, dass es einen geben kann oder nicht. Bei foot=yes auf Straßen sehe ich das nicht so, da das implizit fast immer so ist. Die paar Ausnahmen, wo das nicht so ist, wie Privatstraßen, rechtfertigen mMn. nicht es überall anders explizit zu setzen - nur wo genau die Grenze ist, bei welchen Werten es noch sinnvoll ist, sieht wohl auch jeder subjektiv ein wenig anders.

ENT8R wrote:

Wer sich weiterhin an einer Diskussion bezüglich des von StreetComplete verwendeten Maxspeed-Schemas beteiligen will, den lade ich gerne ein den extra dafür erstellten Thread zu nutzen: https://forum.openstreetmap.org/viewtopic.php?id=60027

Danke für den Verweis.
Gibt es so eine Diskussion/Besprechung auch für die neue v10 "foot=yes"-Streetcomplete-Aufgabe?

Habe mich diesbzlg. noch nicht vollständig informiert und habe somit noch keine Meinung. Bis jetzt kenne die wiki foot=*:
https://wiki.openstreetmap.org/wiki/DE:Key:foot
Dort passt ggf. das Bild
https://wiki.openstreetmap.org/wiki/Fil … 59.svg.png
noch nicht ideal zum Thema... Wenn man auf dieses Verkehrszeichen stösst, dann bedeutet es doch ein "foot=no" Merkmal an den betreffenden highway=* zu hängen, oder?

Und ich kenne die Seite, bei der es folgende Tabelle gibt:
https://wiki.openstreetmap.org/wiki/OSM … ns#Germany

Oder bedeutet "foot=yes", dass es für die Fälle an den highway=* drangehört, wenn das seit 2017 neue Zusatzzeichen:
https://commons.wikimedia.org/wiki/File … O_2017.svg
aufgestellt ist?

AB-inf-x-chg-AB wrote:

Oder bedeutet "foot=yes", dass es für die Fälle an den highway=* drangehört, wenn das seit 2017 neue Zusatzzeichen:
https://commons.wikimedia.org/wiki/File … O_2017.svg
aufgestellt ist?

Nein. Das ist ein Zusatzzeichen und hat für sich allein keine Aussage, sondern bedeutet nur, dass das dazugehörige Hauptzeichen sich auf Fußgänger bezieht.

--ks

Wer erstellt eigentlich diese Fragen / Aufgaben für StreetComplete? Ist das (nur) der App-Betreiber oder kann "jeder" dort Aufgaben einstellen?

Fragende Grüße

AB-inf-x-chg-AB wrote:

Danke für den Verweis.
Gibt es so eine Diskussion/Besprechung auch für die neue v10 "foot=yes"-Streetcomplete-Aufgabe?

Meines Wissens nach noch nicht. Version 10 gibt es ja erst seit zwei bis drei Tagen. Du kannst ja gerne ein neuen Thread erstellen...

PT-53 wrote:

Wer erstellt eigentlich diese Fragen / Aufgaben für StreetComplete? Ist das (nur) der App-Betreiber oder kann "jeder" dort Aufgaben einstellen?

Wie es sich für ein OpenSource-Projekt gehört, kann jeder Änderungen am Quellcode vorschlagen und somit auch neue Aufgaben hinzufügen. Das geschieht natürlich nicht komplett ohne Prüfung. Es gibt eine Checkliste, anhand derer neue Aufgaben geprüft werden: https://github.com/westnordost/StreetCo … etComplete

ENT8R wrote:

Das geschieht natürlich nicht komplett ohne Prüfung. Es gibt eine Checkliste, anhand derer neue Aufgaben geprüft werden: https://github.com/westnordost/StreetCo … etComplete

Geprüft - von wem?

Auszug aus den "Adding new Quests to StreetComplete"

Kein Spam: Es muss möglich sein, zu bestimmen, ob die Aufgabe vernünftigerweise gestellt werden soll. Eine Aufgabe, die in 99% der Fälle mit der gleichen Antwort beantwortet werden soll, ist keine gute Aufgabe, langweilen Sie die Benutzer nicht. D.h., dass man nach einer Straße fragt, ob es sich um eine Einbahnstraße handelt, ist albern, denn die überwiegende Mehrheit aller Straßen wird keine Einbahnstraße sein.

Übersetzt mit www.DeepL.com/Translator

Beachtet StreetComplete seine eigenen Regeln nicht?

PT-53 wrote:

Geprüft - von wem?

Vermutlich von den Contributors, die drei Top-Contributors sind ja bekannt 😉

Harald Hartmann wrote:

PT-53 wrote:

Geprüft - von wem?

Vermutlich von den Contributors, die drei Top-Contributors sind ja bekannt 😉

Gibt es auf Github auch eine konkrete Dokumentation über welche Aufgaben wie viele Contributors abgestimmt haben?