Hallo zusammen.
Hier nochmals eine formelle Vorstellung meinerseits, nachdem ich schon mit vielen von euch Kontakt über diverse Kommentare hatte.
Ich bin MobileGEO; ich mappe vor allem Mikro-Infrastruktur, wie etwa Beleuchtung, Mistkübel und diverse andere Dinge die so anfallen.
In letzter Zeit versuche ich mich auch an der Umsetzung der area:highway=* Initiative, wenn man das denn so sagen will. Dass die OSM so generell betrachtet, ein Sauhaufen an verschiedenen Schemata ist, muss ich denke ich niemandem erzählen.
Selbst bin ich ein recht junger Mapper, der sich gerne an verschiedenen Szenarien probiert, einige API Abfragen ausprobiert und JOSM Validator-Fehler und Warnungen (nach bestem Wissen und Gewissen) bearbeitet.
Meine Lieblingsgebiete zur OSM Arbeit sind dabei als gebürtiger Tiroler das Inntal (Telfs bis Innsbruck) und Wien, mein jetziger Aufenthaltsort. Hierbei setze ich auf eine Kombination aus SCEE (StreetComplete+) und JOSM, wobei es mir bei letzterem salopp gesprochen noch an technischer Reife fehlt, die kontinuierlich erarbeitet wird.
In diesem Sinne bin ich gerne an regem Austausch interessiert, wie wir die OSM besonders in Österreich aktuell halten können, was so eure Interessensgebiete sind, wo man sich eventuell ergänzen kann; woran ihr gerade so sitzt und in welcher Weise man sich zusammenschalten kann/möchte.
Hallo grüß dich. Ich bin auch echt neu (seit ca. einem Jahr aktiv), und ich hab es irgendwie mit glatten Straßenverläufen.
Ich bin nicht wirklich der befürworter von der area=highway initiative, vorallem da in meinen bisher bearbeiteten Gebieten generell zuerst einmal die “normale” Map beinahe perfekt darstehen sollte - ist sie bei weitem noch nicht - bevor ich mit den area=highways überhaupt anfange.
Ich habe von Flächigen Straßen auch einiges ausprobiert, aber bald wieder gelöscht - da es mir zu unübersichtlich wurde. Ich will außerdem anderen Mappern nicht noch eine Ebene antun müssen, wo alles mit allem irgendwie verklebt ist - ich finde das Zeug grausam zum bearbeiten.
Es reicht finde ich schon, dass Residential-Areas damals manchmal oft als Garten getaggt wurden, und manchmal nicht. Habe ich inzwischen einiges Vereinheitlicht - nach dem Wunderbaren Beispiel: Relation: 6051780 | OpenStreetMap
Ich bin momentan vorallem am bereinigen und vereinheitlichen von Daten beschäftigt, allen vorran landuses (zb hier: Way: 1393202724 | OpenStreetMap)
Aber ich finde es sehr gut, wenn jemand an die Zukunft denkt und auch solche neueren Tags ausrollen will. Eventuell schaffen wir gar irgendwann in Wien einen Abschnitt, ähnlich Innsbruck und Neukölln ^^
Ich trage hauptsächlich von den Straßenbezogenen Freiräumen nur streetside-parking ein, da einige Applikationen dies berreits gut verwenden können (uA. Tesla Autopilot hängt von unseren Parkplatzdaten ab)
Ich habe mir das jetzt einmal angeschaut - und finde das flächige “bemalen” mit Gärten (auch unter den Häusern oder unter dem Schulsportplatz) für nicht wirklich gutes “Mikromapping”. Sorry.
Ich habe auch nie behauptet, dass ich Mikromapping betreiben würde
Ich habe jediglich die Landuses vereinheitlicht, damit man in Zukunft besser damit arbeiten kann. Die Häuserblockgroßen Gärten sind deshalb entstanden, weil man vorhandene Daten nicht Löschen sollte. Es ist keinesfalls komplett richtig wie es so getaggt ist (Häuser sollten kein Teil des Gartens sein), aber auch nicht komplett falsch (wie vorher).
Ich bin aber auch kein Fan von Häuserblockgroßen Unterteilungen in Gärten/Residential Areas - würde am Liebsten nur eine große Residential-Area haben und keine Unterteilungen
nur Häuserblockgroße Residential Areas mit random tags wie zb: leisure=garden, manchmal landcover=grass, manchmal nicht ist finde ich noch falscher - und so war alles um den Wolfersberg wirrwar getaggt ohne Einheitlichkeit, ohne Sinn.
also war die Arbeit zumindest nicht ganz Umsonst. Denn wenn irgendwer mit dem Mikromapping beginnen will, habe ich ihm da einiges an arbeit abgenommen - selbst wenn er alle Häuserblockgroßen unterteilungen löscht (die schon lange vor meinen Bearbeitungen da waren - Ich halte solche Unterteilungen für falsch! - Habe sie aber gelassen, weil es noch kein Schema gibt.)
Mikromapping (alle Garageneinfahrten und sowas einzeichnen) habe ich zwischenzeitlich auch probiert aber wieder aufgegeben weil:
Der Wartungsaufwand immens ist
Es ewig zum Kartieren benötigt
Das noch keinen Sinn macht, solange die generellen Landuses nicht einheitlich sind - (letzteres ist jetzt rund um den Wolfersberg komplett vereinheitlicht und Grenzen berreinigt worden)
Dann sind wir uns im Großen und Ganzen eigentlich einig
Unter (größere) Parks würde ich aber kein landuse=residential legen - insbesondere, wenn dort sogar “landuse=forest” vorhanden ist…
Da gibt es in den Daten viele aufgegebene Projekte. Das noch größere Problem ist, dass dort dann “nie wieder” jemand weitermacht, weil das für Anfänger der Horror ist. Bei dem entsprechenden Gebiet in meiner Umgebung kam noch hinzu, dass die hochaufgelösten Bilder irgendwann nicht mehr zur Verfügung standen Eigentlich war das vielleicht sogar gut so
Meine sind vielleicht noch in der History vorhanden, sollten aber ziemlich alle wieder rückgängig gemacht worden sein.
Halte ich für Vollkommen richtig, dehalb ist unteranderem die Lagerwiese am Wolfersberg von einem Residential-Area Multipolygon umgeben.
Die ganzen Häuserblockgroßen Gärten würde ich eh gerne einmal Löschen, dafür braucht es aber klare Regeln seitens der Community, wann so gemappt werden darf und wann nicht. Ich finde die Residential-Area völlig ausreichend. Taggen für den Render sollte man heute nicht mehr machen, deshalb wäre der Wolfersberg dann grau - so wie er eigentlich sein sollte!
Das ganze Betrifft natürlich etliche Teile von Wien und Österreich.
Am Aller liebsten wäre es mir natürlich, wenn man für ganz Wien ein einziges Multipolygon (als Residential Area) hat, in das dann innere Grenzen (zb. Parkanlagen, Industriegebiete…) hineinkommen.
– Das kann man aber sicherlich nicht ohne Absprache in der Community umsetzen…
Ich würde gerne dieses Chaos mit den verschieden gemappten Residential-Areas* beseitigen, damit man sich anderen Dingen widmen kann.
Nur einmal einige Formen:
Residential Area großer Berreich (Stadtteil), innen Gärten oder gar nix (letzeres ist zu bevorzugen) - aktuell zb beim Wolfersberg und in weiten Teilen vom 13. Bezirk (meine Lieblingsvariante)
Residential Area Häuserblockgroß mit/ohne leisure=garden (halte ich völlig falsch)
und wo halt die Grenzen aufeinandertreffen entstehen komische Grenzen - Deshalb will ichs ja bereinigen:
beispiel: Way: 205659244 | OpenStreetMap hier ist im Norden über die Straße gemappt, im Süden hört die Area aber mit dem Grundstück auf… Wirkt sehr komisch…
Langfristig ist dieses Landuse-Chaos definitiv zu beseitigen - eventuell indem man für jeden Bezirk nur eine Residential Area hat. Dadurch würden unsere Karten sicherlich um einiges weniger an Speicherplatz brauchen
Das mit Sauhaufen hätte ich nie so gesagt. Es kommt schon auch drauf an, wie viel Mühe man sich gibt, zB dass man bevor man irgendwo loslegt sich anschaut wie Dinge dort so erfasst werden. Oder ist das nur auf area:highway bezogen? Da kenn ich mich zu wenig aus.
Was mir in Innsbruck aufgefallen ist, und was auch in Beiträgen hier in den Vordergrund drängt: Die Nähe von area:highway zu landuse. Ich hab noch nicht Dokumentation gewälzt, aber ein imaginäres landuse=highway schwebt da immer mit, wenn zB landuse=dies direkt an area:highway=jenes an landuse=das grenzt.
Es macht sogar Sinn, zumindest wenn man landuse=residential so versteht dass das an der Grundstücksgrenze endet und dann die Verkehrsfläche (der imaginäre landuse=highway) beginnt und dann eine weitere Irgendwasfläche beginnt.
Ich halt es bei landuse=*, ob residential oder commercial da anders. Die bilden nicht den Kataster ab. Im persönlichen Gespräch hat mir ein lokaler Mapper gesagt, die sind für die großräumige Kartendarstellung, wenn ichs recht in Erinnerung hab.
Ich meine, dieser Aspekt - das Verhältnis von area:highway zu landuse gehört gründlich beleuchtet bevor man da hunderte Stunden investiert.
Innsbruck ist da ein wenig fehl zitiert: In Neukölln arbeitet eine Gruppe dran, die sich regelmäßig trifft und die Daten ausgiebig auswertet und weiterverwendet. In Innsbruck wurde das von einem einzigen unter dem Radar begonnen auszurollen - wohl weit über hundert Stunden - ohne irgendwelche Bestrebungen die Daten fruchtbar zu machen. Die Freude der lokalen community hält sich in Grenzen. Ich bin nicht auf dem neuesten Stand wie weit das ist.
empfände ich so auch als sinnvoll. Führe gerne näher aus, was du als ‘fruchtbar machen’ der Daten verstehst. Eine Voronoi-Zellen-Karte könnte wohl funktionieren; ist natürlich ein erheblicher Aufwand. Auf welchen Kataster beziehst du dich vorläufig? Liegenschaft?
area:highway=* ist relativ klar definiert. Was nicht so eindeutig ausdefiniert ist, ist wo landuse=residential endet und wie kleinteilig das aufgeteilt werden soll, aber das (nicht-)Vorhandensein von area:highway=* Flächen ändert daran ja nichts.
Mapper die der Meinung sind dass landuse=residential an jeder Straße enden sollte und das davor auch schon so gemacht haben werden das weiterhin tun, und Mapper die der Meinung sind, dass landuse=residential über kleinere Wohnstraßen hinweg geht und ganze Wohngebiete umschließen soll werden das auch weiterhin so tun. [1] Nur weil da jetzt zusätzlich zum highway=* Weg etwas mehr dazwischen gemappt ist ändert das ja nichts am Grundsatz.
Mich störts vorallem, dass wir da nichts einheitliches bis jetzt ausgemacht haben.
Im Prinzip ists mir egal, ob der Landuse Häuserblockgroß oder so groß wie ein politischer Bezirk ist. Einheitlich muss es aber werden!
Ich werde dazu demnächst eine Diskussion hier im Forum eröffnen und mir erhoffen, dass man sich da trotz Jahrelanger uneinigkeit endlich auf ein System einigt und das dann auch umsetzt.
Ich halte nichts davon die Grenzen beim Häuserblock zu ziehen. Von Leuten die das mal so - mal so nach Lust und Laune machen (mal über die Primary road, dann hörts mal davor auf), halte ich noch weniger.
Wie gesagt: jeder ist herzlich dazu eingeladen dabei zu unterstützen ein einheitliches System zu finden.
Für mich beginnt ein Landuse dort wo ein anderer Aufhört (zb auf Wald oder Feld folgt mit der Straße als Grenze eine Residential Area, die Wiederrum bis zum Nächsten Wald/Feld geht)
Die Area=highway würde bei diesem System !ohne verklebung mit der Residential Area! einfach nachträglich darrübergelegt werden. (eine Straße ist schließlich Teil eines Siedlungsgebietes und nicht Niemandsland bis die Straße als Area gemappt ist) - außerdem umgeht man damit eine sonst erzwingende Verklebung (bei Häuserblockgroßen Residential Areas) - die das nachträgliche Bearbeiten massiv stört
Die Diskussion ist so alt wie der landuse. Es wird immer Gegenden geben, in denen das unterschiedlich gemacht wird, weil es eben auch unterschiedlich viel Arbeit und Ausdruck einer Weiterentwicklung (des Mappers und der Daten) ist.
verbautes Gebiet
Wohngebiet inkl. alle Straßen
Wohngebiet inkl. niederrangige Straßen
Wohngebiet exkl. Straßen
Hab schon alles irgendwann gemacht.
Mapping endet bei mir am Gartenzaun, Hausgärten, Eingänge, Garageneinfahrten etc. mache ich nicht.
area:highway sollte zuletzt gemacht werden. Es ist die Fläche, die jedenfalls übrig bleibt, wenn alles andere gemappt ist. Ich habe auch mein Versuchsfeld angelegt, ist viel Detailarbeit, weshalb es auch dabei bleibt. Und ich habe selbst in einem einzigen Dorf keinen ganz einheitlichen Stil, ist eben work in progress. Soll ja auch Spaß machen.
Verkleben ist kein Problem (sofern man keine Multipolygone konstruiert), wenn alles andere gemappt ist, ändert sich ja nicht mehr viel. Da sind landuses, die beiderseits mit der Straße verklebt sind, eine ganz andere Nummer.
Das ist mE schon ein Problem und zwar immer dann wenn verschiedene Abstraktionen “verklebt” werden: zB landuse mit landuse sindkein Problem. Landuse mit Strassen(-fläche) oder Gebäuden schon: Man zwingt damit dann immer (!) dem zukünftigen Bearbeiter seine spezielle Form der Einteilung und ein spezifisches System der Abstraktion auf (zB zementiere ich dann, dass sich Verkehrsfläche und Wohngebiet ausschließen, was für die meisten denkbaren Anwendungen ein Nonsens ) auf. Natürlich wird das mit großen Multipolygonen noch schlimmer, aber im Kern gilt auch hier das gleiche. Ein riesiger Multipolygon, der nur aus Oberflächen besteht ist nicht schwer zu warten, wenn mich das Thema grad nicht interessiert, lass ich den einfach in Ruhe. Wenn ich das Ding etwa mit Straßen und Flussläufen als Begrenzung gebaut hab, schauts gleich ganz anders aus.
Ich würde auch wenn möglich nur Landuse mit Landuse verkleben (oder Gebäude mit Gebäude). Das wichtigste finde ich, dass man zumindest die Grenzen berreinigt, denn wenn sowas: Way: Heinrich-Collin-Straße (4424320) | OpenStreetMap im Navi auftaucht hat keiner eine Freude damit…
Ich bin momentan damit beschäftigt zumindest in diesen Residential-Areas ein einheitliches System auszuprobieren, um das Möglicherweise auf größere Areale anzuwenden:
Möglicherweise werde ich alle zu einem einzigen Multipolygon zusammenfassen (im Idealfall mit nur einer Außenlinie)
Der zukünftige Bearbeiter muss immer mit dem leben, was er vorfindet (und in Teilen Österreichs ist das grausig). Je mehr Information in der Karte ist, desto höher die Chance, dass man sich auch mit Dingen befassen muss, die man gar nicht ändern wollte (Stichwort highway-Zerstückelung).
Wenn sich Verkehrsfläche und Gebiet nicht ausschließen, zwingt man dem Bearbeiter die Entscheidung auf, die Fläche einem Gebiet zuzuordnen, was in jedem Fall gegen die ground truth geht.
Jede Variante macht in einem bestimmten Zusammenhang Sinn. Ohne einen Konsens mit (möglichst verschiedenen) Datennutzern über die flexibelste Repräsentation ist das schwer zu entscheiden.
Und wenn es wirklich grausig ist mit den Daten zu arbeiten, passiert auch schnell sowas hier:
Ich habe soeben den ganzen Wienerwald gekillt, weil irgendwer damals beschlossen hat, dass der Wald in den Gärten mit allem umbedingt verklebt sein muss…
Dass ein Wald in ein Wohngebiet geht ist ohne Frage definitiv falsch…
Eigentlich war das vielleicht sogar gut so 