Sinn & Zweck von StreetComplete

Ich habe diese Erfahrung nicht machen können. Natürlich gibt es auch weniger relevante oder unnütze Hinweise (z.B. wenn auf die Existenz von bereits erfasste Objekte hingewiesen wird, die SC nicht anzeigt), aber die meisten Hinweise, die mich stören sind vor allem anonyme Hinweise, die zu wenig Informationen enthalten, die Datenquelle unklar ist oder für uns offensichtlich sind.

SC Hinweise finde ich besonders wertvoll, weil ich davon ausgehen kann, dass die Person vor Ort war und oftmals ein Foto anhängt.

3 Likes

SC Hinweise finde ich besonders wertvoll, weil ich davon ausgehen kann, dass die Person vor Ort war und oftmals ein Foto anhängt.

vor ein paar Tagen hatte ich einen SC Hinweis, dass eine Bushaltestelle nicht existiert, aber die Haltestelle gibt es, sie war nur 20-30m neben dem Standort gemappt. Gerade dieses „gibt es nicht mehr“ in notes ist meiner Erfahrung nach sehr oft falsch, entweder wegen geringer Lageungenauigkeiten in den OpenStreetMapdaten, oder weil der Hinweisgeber sich nicht richtig auf der Karte orientiert hat (und vielleicht die GPS-Lage nicht genau war).

2 Likes

Es wird halt schon irgendwie “genaues Hingucken” erwartet, bzw. das ist sehr sinnvoll. Oder “mal über den Kartenrand schauen” oder wie soll ich das mal sagen. Und das findet in der Tat nicht immer statt, wie ich auch schon oft bemerken musste :joy: Allerdings gilt das natürlich nicht nur für StreetComplete, sondern passiert auch ohne die App.

Und das liegt an SC? z.B. iD und JSOM erkennen benachbarte Wege und verhindern aktiv falsches Tagging durch den Nutzer? Meine letzten Versuche zu dem Thema zeigten ein anderes Ergebnis und in SC steht zur Auswahl, dass der Fuß-/Radweg separat auf der Karte eingetragen ist, also ist dein gewähltes Beispiel ein Anwenderfehler und kein Fehler in der App. Separat erfasste Wege, wie Radwege neben der Straße, werden auch entsprechend als Wege dargestellt :slight_smile:

Also ist es besser, wie ich selbst schon erleben und berichtigen durfte, dass per JSOM und Luftbild der Gebäudetyp geschätzt wird, anstelle es vor Ort zu erheben? Und falls mir der Typ nicht bekannt ist, es für einen “Armchair”-Mapper mit einem Hinweis zu versehen ist auch negativ? Besonders kann man auf Notes ja antworten und reagieren, um ggf. Zusammen ein optimiertes Tagging für ein Objekt zu finden.

Ich habe regelmäßig nicht erfasste Gebäude, also per Luftbild das Gebäude erfassen (lassen). Wenn ich dann im Anschluss vor Ort z.B. die Hausnummern ermitteln und erfassen möchte, ist es in erster Linie aber wichtig zu wissen, das es sich eben nicht nur um eine große Garage o.ä. handelt, daher ist die Quest grundsätzlich wichtig, besonders in Gegenden wo eben nur “building=yes” erfasst ist.
Ein Feature-Request mit einer guten Idee zur besseren Einführung der User in Gebäudetypen wäre aber bestimmt eine gute Sache.

Aber dann ist doch der Hinweis 100mal besser, als wen das Objekt einfach gelöscht wird. Umgedreht gibt es auch genug Benutzer die von veralteten Luftbilder Objekte abzeichnen oder Lagen anpassen, die man mit “on the ground” Wissen verbessert hatte.

Generell ist die Diskussion hier nach meiner Meinung einfach ein Zahlenspiel: Wie viele Nutzer mit geringem OSM-Wissen nutzen JSOM und machen entsprechend Fehler und welche Zahl an vergleichbaren Users nutzt SC? Ist es die Schuld der App, dass die Einstiegshürde “zu gering” ist?

So eine Einstellung halte ich so eine Einstellung gefährlich und klingt nach “Elite-Denken” für mich oder mit Überspitzte Fragen geantwortet:
Sollten weniger Menschen bei OSM mitwirken? Welche Qualifikation muss man vorweisen, bevor bei OSM mitgewirkt werden darf? Das Wiki und Forum 2 mal vollständig durchgelesen?

Ich möchte keines der genannten Probleme verneinen, ich glaube jedoch das SC nur ein Multiplikator ist für Probleme in OSM und vielen anderen Projekten mit offenen Strukturen zur Mitarbeit:
Beitragen (Daten, Code, Meldungen, …) geht (bewusst) leicht, das Überprüfen der Beiträge benötigt jedoch häufig mehr Wissen und spricht seltener das Belohnungssystem an, weshalb sich für diese Aufgaben weniger Personen finden. Wer will schon kleinlich 30 Minuten prüfen, was andere in wenigen Momenten produziert haben? Zusätzlich ist man eben nicht Selbst kreativ.

3 Likes

Ja, natürlich, dafür ist das auch sinnvoll. Was mich stört ist, dass diese Quest standardmäßig aktiv ist und es regional große Unterschiede im Tagging von bestimmten Gebäudearten gibt. Plus: building=yes ist nicht falsch, sondern teilweise die einzig korrekte Antwort:

Beispiel: Ich erfasse Anbauten an Wohngebäude mit building=yes, wenn sie einen separaten Eingang und keine Verbindung zum Haupthaus haben. Das kommt nicht selten vor, etwa 10 % der Häuser bei uns haben das, vor allem weil viel an Messegäste vermietet wird. Es ist kein building=house, weil es eben „nur“ ein Anbau ist, zumindest mache ich das hier so. Und dann kamen schon diverse Mapper und haben das in building=detached geändert und dann noch ein addr:housenumber:signed=no hinterher. Nett gemeint, aber hier eher unsinnig.

Bei einigen Quests wäre es besser, wenn sie nicht standardmäßig aktiv wären und dazu würde ich die Gebäudeart auch zählen, denn der Gebäudetyp ist in OSM nicht immer selbsterklärend. Garage / Carport - alles kein Problem. Aber der Wohnhaustyp, da sehen wir ja schon im Forum, dass da ein wenig Übung und auch Lokalkolorit dazugehört. Aber ich würde niemanden aufhalten, der aktiv rumläuft und Carports oder Garagen umtaggt – vor Ort ist immer besser.

2 Likes

I would like it too. However, disabling “building type” quest (which I do not care about at all) would automatically disable “housenumber address” (which I care very much about) because it is only asked on building with values different than yes (for reasons mentioned above: it does not want to create confusion by asking for housenumber of a shed or a garage).

If you are interested, see the history of the problem at Give priority to address (housenumber) quest · Issue #2464 · streetcomplete/StreetComplete · GitHub

Garage / carport - no problem. But the type of residential building, we can already see in the forum that a little practice

I agree. Do note however that people can click just on the “category” name like “residential”, and building will get tagged with more generic building=residential, without requiring the user to know exactly the type. The user would need extra clicks for that though (there is an issue for that too: House Type quest: also allow caching "residential" and other more generic types · Issue #3600 · streetcomplete/StreetComplete · GitHub).
And that feature is probably not very discoverable due to how UI looks; many users might guess they cannot just click on generic categories like “residential” or “commercial” so wouldn’t even try, even if it works just fine.

Ja, ich kann deine, ich sage mal, “Gegenargumentation” durchaus nachvollziehen und du hast Recht, SC mag durchaus eine Art Spiegel sein, der uns allen bestimmte in OSM bestehende ich sage mal “interessante Ansatzpunkte zur Diskussion” liefert, in wirklich vielen unterschiedlichen Bereichen.

Was man glaube ich definitv festhalten kann, ist, dass SC (zumindest in meiner Region) doch recht viele Leute auf jeden Fall zu Beitragenden gemacht hat und wir neue Leute gewonnen haben, was natürlich eine super Sache ist!!! Das will ich gar nicht bestreiten. Sicherlich sind dadurch viele Daten eingetragen und Sachen gemeldet worden, auf die sonst eine Ewigleit lang keiner gekommen wäre oder die lange nicht aufgefallen wären.

Im Prinzip erhöht das rein zahlenmäßige Mehrwerden aller Mappenden (was nat. ausdrücklich zu befürworten ist) natürlich ganz automatisch den Wartungsaufwand, wenn man das so nennen will, egal, wodurch / wie die neuen Mapper auf OSM gekommen sind.

Etwas schade finde ich z. B. das folgende Beispiel: Node History: 5413978820 | OpenStreetMap

Da hat SC nach den recycled materials gefragt (obwohl diese ja eig. schon eingetragen waren) und der User hat “Kleidung” geantwortet, die Schuhe aber vergessen.
Böse Zungen würden jetzt sagen, da sind Daten verloren gegangen. (Oder: im Prinzip war es hier nicht erforderlich, den Node überhaupt anzufassen). (Habe heute noch mal vor Ort geprüft, dass auch wirklich weiterhin Altkleider und Schuhe angeommen werden). Dieser Datenverlust kann immer mal passieren. Wenn man den User drauf aufmerksam macht, wird er/sie sicher nicht böse sein, ist ja bestimmt auch nicht mit Absicht passiert. So. Nur wenn dieser Fall jetzt eben verschiedenen Usern öfter passiert (bis er ggf. gelöst wird…), dann wird der dadurch entstehende Wartungsaufwand (oder halt Datenverlust) schon größer, das ist das, was ich damit meine. Das kann ja dann nicht auf die bzw. ggf. “den kleinen” SC-User ich sage mal “abgewälzt” werden, wenn so was öfter passiert (ist).

Ich hatte ja den Vorschlag gemacht, dass sich die recycled materials gar nicht mal sooo oft wirklich vor Ort ändern. Also sprich, SC seltener danach fragen zu lassen. Aber das scheint irgendwie niemand der Verantwortlichen genauso zu sehen, na ja. Manches ist einfach auch eine Frage dessen, wie oft etwas in der Praxis wirklich vorkommt.

Ich werde dazu mal ein Ticket aufmachen, dass SC vlt. besser so etwas frageb soll wie “Ist die folgende Liste der Materialien, die hier zum Recycling angenommen werden, noch vollständig?” anstatt “Welche Materialien können hier recycelt werden?”, könnte mir vorstellen, dass das hilft.

3 Likes

I didn’t know that either. Thank you for pointing it out. :+1:

2 Likes

Wo wir dabei sind, unser tagging für Wohnhäuser ist noch komplett unterentwickelt, wir haben nur Differenzierungen für Einfamilienhäuser, sei es freistehend, als Doppelhaus, Villa, oder in Reihe. Für alles andere gibt es nur einen einzigen tag, apartments.

Stimmt. Auch für ein Haus mit Geschäft im EG und einer Wohnung im OG. Davon habe ich sehr viele.

1 Like

If you really want to micromap such detail (I personally don’t find it good use of my time, but YMMV), solution is to use multiple building:part=*. See Simple Indoor Tagging - Advanced modelling of the different levels for more instructions.

As for why I don’t think it’s needed to map to, is because you’ll add shop=*+level=0 or similar objects inside that (predominantly) building=apartment which will make it amply clear what is happening there.

1 Like

Ich möchte kein Micromapping. Ich möchte nur einen Wert für building. building=apartment passt meiner Meinung nicht (nur eine Wohnung). building=house passt eher.

I apologize, I mistranslated/misunderstood exact building type you meant (over here, it is mostly building with many apartments at above-ground floors, and shops on the ground floor; thus my suggestion mentioning that case).
The main principle of the my post / advice still stands, regardless that tiny misunderstanding.

So if in your case it is single residence with single shop (and you don’t want to micromap indoors), that would be building=house for polygon and extra shop=* node inside it.

1 Like

Das nennt sich auf Englisch mixed use:

a skyscraper that has floors of office space as well as a hotel complex, or a terrace building that has a flat on the first floor and a shop on the ground floor.

building=mixed_use ist immerhin ca. 2.500 mal benutzt worden. Könnte man mal dokumentieren?

Natürlich wie immer nur für Gebäude, die für solch eine gemischte Nutzung gebaut wurden.

building=mixed_use ist immerhin ca. 2.500 mal benutzt worden. Könnte man mal dokumentieren?

Natürlich wie immer nur für Gebäude, die für solch eine gemischte Nutzung gebaut wurden.

die Nutzung erfassen wir mit building:use und/oder über das flächige Eintragen von features mit level-Angabe, oder mit building:part

Ein Gebäude mit unterschiedlichen Nutzungen kann trotzdem ein Haus sein, oder ein Hochhaus (ggf. könnte man die weiter unterteilen in Punkthochhäuser/Türme und Scheiben und …), oder ein Einkaufszentrum, etc.

2 Likes

Also irgendwie klingt das falsch. Wenn wir eine ehemalige Kirche weiterhin als building=church taggen, auch wenn es mittlerweile eine Metro-Station ist, eben weil wir nicht die Nutzung, sondern die Bauart taggen, dann finde ich mixed_use einen unpassenden Wert. Außerdem sehe ich keinen Unterschied zwischen einem Wohnhaus, welches nach 20 Jahren das Erdgeschoss so umbaut, dass dort ein Fahrradgeschäft geführt werden kann und dem direkten Bauen dieser Zuammensetzung von Anfang an.

Ein Wohnhaus mit Geschäft im Erdgeschoss erfasse ich als building=apartments oder building=residential mit einem shop=* in level=0. Braucht’s dazu ein eigenes Tag für den Gebäudetyp?

5 Likes

Wenn wir zwischen einem nicht freistehenden und einem freistehenden EFH unterscheiden, wenn wir zischen einem Wohngebäude mit einer Wohneinheit oder mit zwei (oder mehr) Wohneinheiten unterscheiden, warum dann nicht auch zwischen einem reinen Wohngebäude und einem Gebäude, dass im EG durch großflächige Verkaufsräume mit Schaufensterfront geprägt wird und im OG eine normale Wohnung beinhaltet?

1 Like

That sounds like an tagging mistake…

Note that specific building=* values are used to mark (architectural) type of a building, not its use.

Actual current use of the building is instead marked with building:use=*.

So maybe building:use=mixed_use instead might make some sense, but it does not add much more information than just omitting that tag completely.

1 Like

danke für das Beispiel, das wäre für mich ein “house” (und ggf. Untertyp mit house=*), ich hielte es für Murks wenn das ein building=apartments sein soll wenn im ersten Stock 2 Wohnungen sind, und detached wenn es eine ist (abgesehen davon dass man für “detached” erwartet, dass es reine Wohnnutzung ist, oder wie seht ihr das?)

In meiner Gegend gibt es auch viele Gebäude, die offensichtlich von Anfang an so konzipiert waren, dass das Erdgeschoss kommerziell genutzt wird (große Schaufenster etc.) Eine Nutzung als Wohnraum wäre nur nach aufwändigem Umbau möglich. Die meisten sind seit über 10 Jahren als “yes” getaggt. Die SC-Quest ist bei mir nicht aktiv, weil sich die Alternativen (apartments, retail) für mich falsch anfühlen.