Update OSM Carto

Ich finde die geplante, neue Straßen-Darstellung sehr gelungen.
Die Hierarchie der Straßen ist intuitiv verstĂ€ndlich, wĂ€hrend bislang “primary” markanter als “motorway” und “trunk” zwischen WĂ€ldern und Wiesen fast unsichtbar war.
Die gleiche Farbe von “tertiary” und “residential” stört mich nicht, da ich sie durch die Breite deutlich unterscheiden kann.
Das Kartenbild wirkt fĂŒr mich angenehmer. Einzig in z=18 und z=19 wirken die Straßen jetzt deutlich zu schmal.

Bei den Baumsymbolen im Wasser wĂŒrde ich den Kartenerstellern erst einmal Gelegenheit geben, das Problem zu lösen.
Die Darstellung, bei der das Wasser die FlĂ€chenfarbe aber nicht das Symbol ĂŒberdeckt, ist sinnlos und war vermutlich nicht so geplant.
Einen See habe ich schon bisher aus dem Wald ausgeschnitten, einen TĂŒmpel oder Teich nicht.
Das werde ich auch zukĂŒnftig so halten, unabhĂ€ngig davon wie Mapnik es darstellt.

Eben. Wir spielen “Finde die Straße SS38 von Bozen nach Meran” auf dieser Karte: http://www.openstreetmap.org/#map=12/46.5774/11.2610 .

Dieses Beispiel ist mit Abstand das schlimmste, was ein Kartograph produzieren kann. DafĂŒr schĂ€me ich mich (ich bin kein Kartograph). Die Straße (ich kenne sie selbst gut genug) fĂŒhrt aussließlich durch Obstanlagen (und einen Tunnel).

Das toppt die Beispiele, die ich bisher gesehen habe und meist die als trunk gemappten Bundesstraßen in diversen deutschen Ballungsgebieten zeigten. Das war die MĂŒhe wert. Ich kann daher nicht verstehen, wie die Briten (siehe Diskussion auf talk-gb) solch ein schrecklich-hĂ€ssliches Rendering toll finden können. Oder mappen die einfach keine Landnutzung? :confused:

Ich habe den Thread jetzt nach meinem Urlaub mal durchgelesen. Ich finde es gut, dass endlich Wert auf eine gescheite Erfassung von FlĂ€chen gelegt wird. Das erleichert Auswertern die Nutzung unserer Daten. (Ich denke, dass lieber einmal ein Mapper einen Moment mehr Zeit investiert, um eine Mulitpolygon anzulegen, als dass Tausende Nutzer, die die Daten in ihre PostGIS-Datenbanken importieren, aufwendig Polygone mit Löchern erzeugen mĂŒssen.) HĂ€tte der alte Mapnik-Stil (vor der Umstellung auf CartoCSS) vor drei bis fĂŒnf Jahren schon Wert auf Multipolygone gelegt, wĂŒrdet ihr das heute als ganz normal ansehen.

Viele GrĂŒĂŸe

Michael

Das kommt daher, weil die dortigen Trunks grĂŒne Schilder haben. Von daher fand ich zumindest fĂŒr Deutschland die blauen Autobahnen gar nicht so schlecht.

Diese Relation scheint nicht zu funktionieren. Auch auf allen inner-FlĂ€chen wachsen BĂ€ume. Weiß einer, wo hier das Problem liegt?

Klaro: wenn am Outer Way landuse=forest dran steht, dann ist das ein Wald. Da helfen auch keine Inner, die das Gegenteil behaupten.

Landuse an Outer entfernt und nun greift das Landuse vom Multipolygon - genau so ist es richtig. Und funzt sogar :wink:

Gruss
walter

Ich behaupte, daß das nicht der wahre Grund war
 :smiley: Es war am outer, als auch an der Relation landuse=forest. Wenn landuse=forest nur an einem von beiden ist, gibt es keine Probleme


Sven

Schon mal was von OGC-KonformitĂ€t gehört? Das Multipolygon (die Rel) beschreibt die FlĂ€che - nicht der Rand. Dass das bei OSM drunter und drĂŒber geht, hĂ€lt mich nicht davon ab, das “sauber” zu machen. Was dann bei OSM “irgenwie” gehen wĂŒrde, 
 ich schweig mal lieber.

gruss
walter

solange wir bei OSM keine echten OGC-konformen Datentypen in der Datenbank selbst haben, ist alles andere Interpretationssache und eine Disskussion darĂŒber unnötig
 das habe ich bei DSO gelernt. :frowning:

Die Verbreitung von (forest) MP’s mit Eigenschaft am outer statt an der Relation ist nicht gerade klein


Sven

Klar, wenn ich aber die Auswahl habe, solch einen Fehler zu korrigieren, gehe ich halt den OGC-Weg - auch weil der fĂŒr mich besser durchdacht und somit nachvollziebarer ist.

Und Mapnik scheint auch keine Schwierigkeiten damit zu haben. MMn sollte Mapnik immer pingeliger werden und damit helfen, alte MissstÀnde abzubauen.

Wie wird denn der Wald nun gerÀndert? Ich bin etwas verwundert, dass ich jetzt ueberall Mischwald habe - obwohl der Waldtyp angegeben ist. Das war doch vorher anders?

Ausserdem fĂŒhrt es zu merkwĂŒrdigen Ergebnissen, dass die Fusswege schon ab Zoomlevel 15 sichtbar sind, die Zufahrtswege aber erst ab Zoomlevel 16 - ob wohl die Zufahrtswege ja in der RealitĂ€t normalerweise viel grösser sind als die Fusswege.

Laub- und Nadelwald wurde vorher auch nicht unterschieden. Alle natural=wood waren grĂŒne FlĂ€chen. Alle landuse=forest wurden mit kleinen Fichten symbolisiert, unabhĂ€ngig von wood=* oder leave_type=*.
Jetzt wird wood und forest gleich behandelt und beide erhalten eine grĂŒne FlĂ€che und ab Zoom 13 zwei kleine Mischwald-BĂ€umchen.

Falls Du mit Zufahrtswege highway=service meinst: Das war vorher auch so. highway=service mit service=parking_aisle, service=drive-through oder service=driveway sieht man ab Zoom 16, andere service ab Zoom 14. path und footway sind ab Zoom 13 zu sehen.

Bei den befestigten und unbefestigten Wegen tut sich ĂŒbrigens was. Vielleicht wird das schöner


GrĂŒĂŸe, Max

Hi,

das Problem ist ja geklĂ€rt. Nur wenn sich jemand wundert, dass da immer noch Seen “bewaldet” sind: nicht alle Seen waren/sind “Inner”

gruss
walter

Viel Spaß wĂŒnsche ich den NordeuropĂ€ern. z.B. hier: http://www.openstreetmap.org/#map=13/59.7599/12.7277

Und wer jetzt noch sagt, das ĂŒberlasse ich dem Renderer, das Problem zu lösen, dem sage ich einfach:
“Der Renderer? :laughing: Der schwingt sich doch zum Oberlehrer auf. Von europĂ€ischer SolidaritĂ€t noch nichts gehört, oder?”

Na ja, sieht man ja auch bei anderen Angelegenheiten . (z.B. Migrantenproblematik)

Eigentlich bin ich immer noch dafĂŒr, daraus eine Wochenaufgabe zu machen (Außer der Sommeraufgabe war da ja in letzter Zeit auch nichts mehr). Muß ja keine Riesenbegleitung haben, wenn jemand eine gute Abfrage bastelt, reicht das ja.

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.