Wann Sie da eine Wochenaufgabe aus macht, bitte auch place=insel/islet in waterway=riverbank oder waterway=lake beobachten. Mancher Insel sind verschwunden in die Sintflut in nicht-carto renderers…
Danke für deinen Hinweis. Selbstverständlich sind alle Flächen gemeint, die innerhalb einer “Waldfläche” liegen. Das wurde hier schon mehrmals angesprochen.
Ich sehe aber hier bei den meißten deutschen Usern, die das mitlesen, absolut keine “Begeisterung” heraus, dies “in Ordnung” zu bringen. Na ja, Frustale Opposition ist angesagt.
Einspruch. OSM ist ein weltweites Projekt, und Mapnik ist für den 08/15-Besucher die Visitenkarte des Projekts. Wenn da JETZT, nach 10-11 Jahren Projektlaufzeit, die Rendering-Regeln von Mapnik so geändert werden, dass die bisher nach weitverbreitetem Usus nicht ausgestanzten Seen mit Bäumchen bestückt werden, vergeigt Mapnik seinen Anspruch, auf der Visitenkarte präsent zu sein.
In Deutschland mit seiner hohen Zahl von “Berufsmappern” mag das nachträgliche Multipolygonisieren und Ausstanzen noch funktionieren, andere Weltregionen kriegen da richtige Probleme. Skandinavien und Polen wurden erwähnt, an Afrika mag ich gar nicht denken. Außerdem ist das Multipolygonisieren für Laienmapper in Entwicklungsländern eine zusätzliche Hürde.
Kinners, lasst den Quatsch! Entweder das Forest-Grün mit den Bäumchen verknüpfen, so dass die Seen wieder frei werden, oder die Bäumchen weglassen.
Ende 2008 wurden Multipolygone noch einmal genauer definiert (tagging an die Relation statt an den outer). Spätestens seit dieser Zeit ist es ein Fehler, Flächen mit Aussparungen nicht als MP zu erfassen. Das ist mehr als die halbe Lebensdauer von OSM her. Es wird höchste Zeit, daß die Renderer pingeliger werden.
Baßtölpel
Das Problem ist nur, dass unsere “Visitenkarte” kunstvoll Mappingfehler verschleiert(e), anstatt prägnant darauf hinzuweisen. Solange hier nur das “gilt”, was auf Mapnik korrekt aussieht, wird unsere Datenstruktur von den - nennen wir sie mal “GIS-Leuten” - belächelt bzw. mit Kopfschütteln zur Kenntniss genommen.
gruss
walter
+1
Diese Änderung im Mapnik-Style ist wohlüberlegt und eine wesentliche Verbesserung für Auswertungen.
Sehe ich genauso. Das Definieren von outer und inner ist wohl die leichteste Übung beim Multipoligonisieren und kein wirkliches Argument, als Hürde gegen saubere Erfassung in Nähe der außerhalb von OSM geltenden Standards zu dienen.
Na dann hoffe ich, dass die Advokaten der Änderung jetzt auch das weltweite Nachbessern auf sich nehmen. 
Nö.
ok, wenn ich drüber stolpere, mag sein, dass ich das verbessere aber nach suchen werde ich nicht.
Denn nur, wenn es jemanden stört und er selber aktiv was dagegen tun, lernt er wie es richtig erfasst werden sollte.
Gruss
walter
Es ist nicht Aufgabe eines Kartenstils, die Qualität des Datenbank bzw. deren Auswertbarkeit zu lenken.
Leider ist der Kartenstil für einen Großteil der Mapper das einzige Qualitätssicherungstool, deswegen muß er das leider mit erledigen.
Baßtölpel
Kann es sein, dass die Namen von Schulen und Universitäten nicht mehr gerendert werden? Das wäre ein massiver Rückschritt, wenn das so wäre.
Sieht so aus, als würde zur Zeit die Hausnummer gewinnen, wenn die Schule als Node erfasst ist… aber ich glaube, das kommt bald wieder in Ordnung: https://github.com/gravitystorm/openstreetmap-carto/issues/1800
Multipolygonisieren und Ausstanzen ist doch nicht so schwer. Der weit verbreitete Usus, den Du ansprichst, ist nunmal nicht richtig und liegt auch daran, dass Mapnik solche Flächen richtig angezeigt hat.
Von Multiploygonen, die einfache Polygone ersetzen, halte ich nichts. Dies ist neuerdings eine Seuche in manchen Gegenden in DE, angeblich um den Datenbestand kleiner zu halten und weil es in Zukunft nur noch MP-Relationen anstatt Polygone geben soll. Aus diesem Grund wurden z.T. MPs mit 1 Element erzeugt.
Bisher hat man halt für den Renderer gemappt, der jetzt endlich gefixt wurde. Sei froh!
Multipolygone mit nur einem Element sind vermutlich mal wieder ein iD-Bug oder dessen Überreste?
Wohlüberlegt mag sie ja vielleicht sein, wohl diskutiert eher nicht.
Eine Verbesserung der Auswertungen gibt’s nur dann, wenn auch tatsächlich jemand die Multipolygone einträgt!
Wie schon einer der Vorredner erwähnte, in Deutschland mag das ja vielleicht aufgrund der vielen Mapper noch funktionieren, aber was ist mit dem Rest der Welt?
Wer sich den TIGER-Mist in den USA oder den in Teilen Asiens immer noch massenhaft vorhandenen Landsat-Schrott anschaut, weiss, dass das in absehbarer Zeit so niemals passieren wird…
Oh ja. Auf einer Insel, die seit einem Vulkanausbruch in den 1980er-Jahren unbewohnt ist, gab es immer noch ein komplettes Straßennetz aus einem TIGER-Import, bis ich es vor kurzem entfernte. Das scheint echt niemanden zu interessieren.
Eine Sache lässt mich dabei nicht los:
Arbeitshypothese Nr. 1: Jemand, der Auswertungen durchführen will, verwendet dazu vermutlich Shapefiles
Arbeitshypothese Nr. 2: Dieser jemand interessiert sich nur für ein spezielles Gebiet (bspw. Deutschland) und verwendet daher aus pragmatischen Gründen nicht den Planet-Dump, sondern länder-/regionenspezifische Geofabrik-Extrakte
ABER…
Auf den ersten Blick sieht das für mich so aus, als ob unser Forscher für seine Auswertungen demnächst
a) entweder einen eigenen Server anschaffen muss, um sich die Multipolygone selbst aus dem Planet-Dump zu lutschen, oder
b) 500 € für einen kostenpflichtigen Geofabrik-Dump inkl. Multipolygonen investieren muss
In anderen Worten, wir haben dem Forscher seine Arbeit erschwert oder verteuert…
Korrigiert mich bitte gerne, ich hab wirklich keine Ahnung, wo die Umstellung auf Multipolygone praktische Verbesserungen bringen soll…
Absichtlich, wie hieraus ersichtlich:
seh keinen Grund die zurück umzuwandeln, da der Datenbestand eher wächst als schrumpft werden langfristig sowieso Multi-Polygone notwendig. Denke der Diff der Änderungen ohne sichtbare Änderung belastet die Systeme mehr als ein Rendern von Multipllygonen mit einem Element.
Einen Teil davon hatteich geändert.
Gerne, weil ich sicher sei, hier sind einige Missverständnisse…
ESRI inc., der Entwickler des Format “Shapefile”, hat sich schon zehn(!) Jahre her verabschiedet von dieses Data Format, weil es nicht länger ausreichte (nur 2GB max, die Name der Felder nur 10 Karakter, keine RDBMS “relations” möglich). Stattdessen, gibt es File Geodatabase, mit 1TB/Feature Class Limit und altere “Goodies” für GIS.
Ich weiß wirklich nicht, warum Shapefile in Open Source Community, bisher so viel genutzt wird. ESRI hat ein kostenlose API (für Software Entwickler, sehe auch diesen ESRI Blog Beitrag) zur Verfügung, zum arbeiten mit File Geodatabase… QGIS unterstützt File Geodatabase heute, aber viele andere Projekte nicht. Keine Ahnung warum, obwohl File Geodatabase offensichtlich ein Bißchen mehr Kompliziert ist (dafür ist aber auch der API).
Möglicherweise…, aber ESRI hat der kostenlose ArcGIS Editor for OpenStreetMap, und kann damit auch selbst einfach Extrakte einer Region machen. Auch unterstützt es dem Einfügen von ein *.osm XML file in ein File Geodatabase, und produziert dabei auch Multipolygonen.
Nachdem ich ESRI auf einige “issues” mit das Bearbeiten Multipolygonen aufmerksam hatte gemacht (hier und hier auf Github), hat ESRI sogar dieses Jahr ein neuer Version gemacht, die Multipolygonen fast so gut wie osm2pgsql verarbeitet… (aber nicht so schnell).
Offensichtlich, hat Geofabrik mehr getan mit diesen Shapefiles, dann nur OSM “nodes” und “ways” verarbeiten. Sie sind optimiert mit Attributen für jedes Thema.
Aber für die ArcGIS Editor for OpenStreetMap zahlen Sie nicht, und ESRI hat für nicht Kommerzielle Zwecke, das ArcGIS for Home Use Program, 100 euro/Jahr für ArcGIS for Desktop Advanced… damit macht man auch vieles.