StreetComplete - die nächste suboptimale App

westnordost · 2018-10-05 11:46:25

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.

Mammi71 · 2018-10-05 12:40:07

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.

miche101 · 2018-10-05 14:27:00

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

R0bst3r · 2018-10-05 16:01:40

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?

miche101 · 2018-10-05 17:14:15

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

miche101 · 2018-10-05 17:16:05

wobei roof:shapes farbe, ausrichtung usw. mit dem Luftbild auch schön machen kann... >>meist<<

MKnight · 2018-10-05 17:17:41

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?

R0bst3r · 2018-10-06 02:23:30

Sollte roof:levels=0 heißen. Damit lassen sich nur Flachdächer modellieren.

miche101 · 2018-10-06 09:21:34

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

Mammi71 · 2018-10-07 16:23:22

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.

miche101 · 2018-10-07 20:51:20

@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

Last edited by miche101 (2018-10-07 20:52:12)

tux67 · 2018-10-12 08:35:10

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

ENT8R · 2018-10-12 08:37:50

Guck nur mal eine Seite vorher nach was da steht! Das Problem ist mittlerweile gelöst. Liest denn keiner die Beiträge der anderen?

Last edited by ENT8R (2018-10-12 09:01:58)

tux67 · 2018-10-12 09:03:20

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)

Last edited by tux67 (2018-10-12 10:23:54)

aixbrick · 2018-10-12 11:45:30

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.

Last edited by aixbrick (2018-10-12 11:46:36)

tux67 · 2018-10-12 12:04:34

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

tux67 · 2018-10-23 14:24:30

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

westnordost · 2018-10-23 15:35:51

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.

Last edited by westnordost (2018-10-23 15:36:41)

Prince Kassad · 2019-02-03 20:54:45

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.

mmd · 2019-02-03 21:13:41

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.

Lukas458 · 2019-02-03 22:21:29

schicker wäre natürlich Mo-Fr 16:30,18:30, Sa 12:45 ... nicht wahr?

luschi · 2019-02-10 15:21:36

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.

ENT8R · 2019-02-11 16:47:48

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

geri-oc · 2019-02-11 17:01:41

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)

geri-oc · 2019-02-11 17:10:59

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, ...

Announcement

#326 2018-10-05 11:46:25

Re: StreetComplete - die nächste suboptimale App

#327 2018-10-05 12:40:07

Re: StreetComplete - die nächste suboptimale App

#328 2018-10-05 14:27:00

Re: StreetComplete - die nächste suboptimale App

#329 2018-10-05 16:01:40

Re: StreetComplete - die nächste suboptimale App

#330 2018-10-05 17:14:15

Re: StreetComplete - die nächste suboptimale App

#331 2018-10-05 17:16:05

Re: StreetComplete - die nächste suboptimale App

#332 2018-10-05 17:17:41

Re: StreetComplete - die nächste suboptimale App

#333 2018-10-06 02:23:30

Re: StreetComplete - die nächste suboptimale App

#334 2018-10-06 09:21:34

Re: StreetComplete - die nächste suboptimale App

#335 2018-10-07 16:23:22

Re: StreetComplete - die nächste suboptimale App

#336 2018-10-07 20:51:20

Re: StreetComplete - die nächste suboptimale App

#337 2018-10-12 08:35:10

Re: StreetComplete - die nächste suboptimale App

#338 2018-10-12 08:37:50

Re: StreetComplete - die nächste suboptimale App

#339 2018-10-12 09:03:20

Re: StreetComplete - die nächste suboptimale App

#340 2018-10-12 11:45:30

Re: StreetComplete - die nächste suboptimale App

#341 2018-10-12 12:04:34

Re: StreetComplete - die nächste suboptimale App

#342 2018-10-23 14:24:30

Re: StreetComplete - die nächste suboptimale App

#343 2018-10-23 15:35:51

Re: StreetComplete - die nächste suboptimale App

#344 2019-02-03 20:54:45

Re: StreetComplete - die nächste suboptimale App

#345 2019-02-03 21:13:41

Re: StreetComplete - die nächste suboptimale App

#346 2019-02-03 22:21:29

Re: StreetComplete - die nächste suboptimale App

#347 2019-02-10 15:21:36

Re: StreetComplete - die nächste suboptimale App

#348 2019-02-11 16:47:48

Re: StreetComplete - die nächste suboptimale App

#349 2019-02-11 17:01:41

Re: StreetComplete - die nächste suboptimale App

#350 2019-02-11 17:10:59

Re: StreetComplete - die nächste suboptimale App

Board footer