Update OSM Carto

Nein, absolut nicht. Dass ist ein sehr großes - und ziemlich weit verbreitet - Missverständnis.

EDIT: File Geodatabase basiert sich offensichtlich auf Enterprise Geodabases, und ist ein Art “File Varianz” für ESRI basierte Oracle / SQL Server / DB2 / PostGIS Geodaten Speicherung (und nein, auch die speichern kein Shapefile in RDBMS System, ein anderes hartnäckig Missverständnis).

Sehe auch (Deutschsprachige ESRI Help):
Was ist eine Geodatabase?
Die Architektur einer Geodatabase
Kurzer Überblick über die Geodatabase

Das Problem, dass die Geofabrik in ihren Shapefiles keine Multipolygone darstellt, existierte schon lange vor dem letzten Mapnik-Update (1, 2).

Die Lösung exstierte auch: Datenbank aufsetzen und dort auswerten, oder von dort Shapefiles erzeugen. Gerade wenn ich nur eine kleine Fläche brauche, ist das auch kein kostspieliges Vorgehen. Wenn ich den Planeten brauche, ist es auch nicht teuer, nur zeitraubend. Shapefiles können auch schon lange (schon immer?) Flächen mit Löchern darstellen, so wie andere Formate für geometrische Daten auch (svg z.B. oder kml oder geojson).

Unser Forscher musste auch schon immer seit der Erfindung des Konzeptes “Flächen können Löcher haben” entweder mit Daten arbeiten, die diese Löcher berücksichtigen oder geometrische Abfragen machen, um die Löcher aus übereinander liegenden Flächen rauszurechnen. Bei OSM musste er schon immer beides machen, er weiss ja nicht, was sich der Mapper dabei dachte.
Falls er den Standpunkt “Ein Tümpel/Spielplatz/Friedhof… im Wald ist Teil dieses Waldes” teilt, muss er nur MPs berücksichtigen, übereinander gemappte Flächen nicht. In diesem Fall wird er sich sogar über den neuen Mapnik-Stil freuen. Das ist einer der wenigen Stile, die diese Zugehörigkeit auch grafisch ausdrücken können.

Grüße, Max

Ich kann nicht ganz nachvollziehen warum die Änderung bezüglich Wald/Wasser auf Zustimmung stößt. Landuse ist großflächig. Kleine Parkplätze, Springbrunnen, Weiher werden ja auch nicht aus landuse=residential ausgeschnitten, oder?

Moin,

hier finden sich sehr viele Kommentare von Leuten, die das Update begrüßen. Sie betonen, dass die bisherige Datenstruktur falsch sei und von GIS-Leuten belächelt würde. Was darüber aber total vergessen wird - und das finde ich in keinem Posting gewürdigt - , dass wir keine Behörde oder Industrieunternehmen mit geschulten Angestellten sind, sondern unsere Karten durch Freiwillige erstellen. Und davon haben wir immer noch viel zu wenig. Selbst im hochgelobten Deutschland ist die Grunderfassung, sprich Straßenerfassung nach über zehn Jahren Bestehen des Projektes miserabel und da ist jede andere Karte deutlich besser. Es gibt hier jemand, der sich einmal spaßeshalber als der Mapper aus Mecklenburg-Vorpommern bezeichnet hat, was bezeichnend für diesen Zustand ist.

IMHO scheinen die Befürworter der Multipolygone beim landuse einer deutlichen Fehleinschätzung darüber zu unterliegen, was unsere derzeitigen bzw. potentiellen Mapper zu leisten imstande sind. Seid ihr schon einmal zu Treffen von örtlichen Wander-, Fahrrad-, Bootfahr- Angler- oder Geocacher Vereinigungen etc. gegangen und habt versucht, Mapper einzuwerben? Ihr werdet feststellen, dass nur wenige mit Mühe und Not imstande sind, einfache Wege einzuzeichnen und zu taggen und sich in dem Infowust rund um OSM zurechtzufinden. Spätestens bei den Relationen ist dann Schluss. Da wird die Suche nach Beherrschenden schon zur Nadel im Heuhaufen. Man bedenke, dass diese Leute tagsüber z.B. Brot backen oder verkaufen und sich nicht mit Datenstrukturen beschäftigen.

Bisher konnte man bei einer Mapperwerbung argumentieren, dass nahezu alle Basisfunktionen, die man zur Erfassung der Homearea benötigt, ohne die Relationen, die sie nicht verstehen. erschlagen werden können. Jetzt ist mit dem landuse erstmals auch eine der Basic-Eigenschaften dem Zugriff von Otto Normalmapper entzogen, wenn er von eifrigen Usern ohne Vor-Ort-Kenntnissen umgewandelt wird. Die Aufgabe, aus den vorhandenen einfachen Daten komplexere Strukturen zu generieren, sollte also beim sie beherrschenden Anwender liegen und nicht beim Mapper… Dass dies möglch ist, beweist der alte Renderer, der einfach strukturierte Daten offenbar richtig interpretieren konnte.

Man kann also nicht die Vorteile eines Community-Projektes loben, ohne auch den Nachteilen entsprechende Würdigung zukommen zu lassen. Dem Wunsch nach einer sauberen Datenstruktur steht also die Durchführung im Wege, die mit der alten, “falschen” Datenstruktur offensichtlich funktionierte. Der Ruf nach der sauberen Datenstruktur bedeutet also gleichzeitig ein Herausdrängen bzw. eine schlechtere Rekrutierung von Mappern. Und ob wir uns das leisten können, wage ich mal zu bezweifeln.

Es ist eigentlich nicht das erste Mal. Bewohner von Städten wurden vom Mapnik-Stil schon letztes Jahr zu Relationen in ihrem Homearea gezwungen, als Verkehrsflächen über Häuser gemalt wurden.

Ich kenne das so, dass landuse und natural, egal in welcher Reihenfolge, ausgestanzt werden, amenity und leisure dagegen nicht.
Genauso sind Gebäude auf einer Fläche highway=* + area=yes auszustanzen. Das dies auch für landuse und natural gilt ist selbstredend.

Danke für den für Hinweis auf ArcGIS Editor for OpenStreetMap und die ausführlichen Erklärungen!

Wenn du möchtest, kann du das ja als Highlight von OSM begreifen. Dieses Alleinstellungsmerkmal der Geometriebehandlung gibt es wohl nur bei uns.
Versuche das mal jemanden begreiflich zu machen, der sich täglich mit GIS-Systemen beschäftigt. Dem schlackern dann nur die Ohren und er muss sich die Augen reiben.

Das einzige Argument, was ich hier von den “Verteidigern” höre, ist “das war schon immer so”. Toll, damit gewinnt man selbstverständlich jede Diskussion.

Gruss
walter

Ich verteidige hier gar nichts. Was ist denn die Alternative? Die Flächen wieder per layer zu stapeln, was man immer noch findet.

BTW, warst Du nicht mal der große Zampano in Sache touching_inner?

Ich find das Problem liegt einfach an den Grunddatenstrukturen. Multipolygone sind halbherzig über Relationen gelöst und noch viel halbherziger in den Editoren unterstützt. Ein Flächentyp als eine der Grunddatenstrukturen neben Nodes und Linien wäre da meiner Meinung nach sinnvoller. Auch versteh ich nicht so ganz warum die Punkte von einer Linie selbst wieder Nodes sein müssen, aber das ist eine andere Diskussion.

Darüber ist keine (lange) Diskussion notwendig. Ist ganz einfach: Nur die Nodes besitzen Koordinaten und stellen so den Verlauf der Linie dar.

Man könnte auch statt einer Liste von Verweisen auf Nodes mittels Node ID eine Liste von Koordinaten machen (Eine Node ID ist genauso 64 bit groß bei OSM wie eine Koordinate wenn man effizient speichert)

Gut, benötigt weniger Speicherplatz. Durch die Referenzierung direkt auf die Nodes ist aber sichergestellt, dass verbundene Wege einen eindeutigen gemeinsamen Node haben. Getrennt gehaltene Koordinaten wären durch Rundungsfehler nicht verbindbar oder würden bei Überlappungen falsch verbunden werden können. (Oder zusätzliche Strukturen sind wieder notwendig, um Verbindungen auszudrücken.)

Für die Leute, die in diesem Thread zum ersten Mal von File Geodatabase gelesen haben:

Die API mag zwar kostenlos sein, aber sie ist nicht frei. Würden wir auf die Freiheit sch***, würden wir alle Google Maps verwenden und keiner wäre Mapper beim OpenStreetMap-Projekt.

File Geodatabase ist ein unfreies Format, das deshalb auch nur von ganz wenigen freien Programmen gelesen werden kann.

Viele Grüße

Michael

Stimmt nicht. Ich habe ausführlich begründet, warum die alte Form für OSM die bessere ist:
http://forum.openstreetmap.org/viewtopic.php?pid=532191#p532191

Ist ja für API 0.7 angedacht, weiß aber nicht wie da der Stand ist.

Ja, hast du. Meine Zusammenfassung dessen ist: “Es ist zu kompliziert für normale Mapper”.

Das ist mit Verlaub auch eine Frage der Unterstützung durch die Editoren.
In Josm (ja, schon wieder - aber einen besseren Editor kenne ich halt nicht) ist ein Multipolygon mit zwei Klicks + einer Tastatureingabe erzeugt: Outer auswählen, Inner auswählen, STRG B und das war es schon. Hat noch nicht einmal weh getan.

Sollten das iD und Potlatch nicht können, sind die ein Problem. Und wenn sie es können um so besser.

Gruss
walter

Auch das finde ich noch eine sehr rudimentäre Unterstützung. Man muß wissen daß es MPs gibt und sie aktiv erstellen.
Würde der validator landuse Überlagerungen anmosern und ich davon ausgehen können, daß ein Klick auf (alles) Reparieren zuverlässig sinnvolle MPs erzeugt, dann hören die Beschwerden über komplizierte MPs vielleicht irgendwann mal auf.

Baßtölpel

Ein klacks mit Potlatch. Neues MP mit 2 Teichen:
Waldstück anklicken > Advanced Mode: Add to: New Relation > Multipolygon auswählen > Role:outer > fertig (wer möchte, mit Namen… )
Teiche anklicken > Advanced Mode: Add to > MP auswählen > Role:inner > fertig … 30 Sek für ein MP mit 2 Inner
ID: keine Ahnung Hier sehe ich das größte Hindernis. Oder hat hier auch jemand eine schnelle Lösung?

Allein das Wort Multipolygon läßt die Leute das Konzept schwierig finden. Ich bin dafür, Up Goer Five-artige Sprache in OSM anzustreben. https://xkcd.com/1133/ Ein einfacheres Wort für MPs könnte Mehrfachflächen sein und MPs erstellen Flächen herausnehmen. Wenn wir unter uns sind, können wir ja weiter 1337 speaken.

Baßtölpel