Was ich an der ganzen Diskussion interessant finde ist, dass die Kritiker an den Änderungen und die Entwickler, die diese Änderungen initiieren, im Grunde sehr ähnliche Sicht- und Arbeitsweisen haben. Man schaut sich die Karte an, dort, wo man mit der Geographie vertraut ist und einen die Karte inhaltlich interessiert, sieht etwas, das suboptimal aussieht und ändert es so, dass es in dieser Konstellation (die jeweilige Gegend, der Betrachter mit seinen Interessen und seinem Informations-Hintergrund) besser wirkt. Oder eben man beobachtet eine solche Änderung und kritisiert sie, weil sie eben in der für einen interessanten Gegend und für die eigenen Ziele und Wünsche von Nachteil ist.
Eine Reflexion über die Gesamtsituation, darüber warum man die eine Darstellung als besser empfindet als die andere und unter welchen Umständen dies tatsächlich der Fall ist und wann eher nicht findet meiner Beobachtung nach nur sehr selten statt. Das ist jetzt nicht als überhebliche Kritik gemeint im Sinne von ‘wie könnt ihr euch nur äußern ohne darüber nachgedacht zu haben’ - sondern erst einmal einfach nur als Beobachtung.
Das Problem ist jedoch, dass wenn Ihr jetzt auf github Eure Kritik äußert (oder auch umgekehrt Eure Unterstützung für eine Änderung) - und Ihr solltet das durchaus tun - dann kommt leider kaum ein konstruktiver Diskurs zu Stande denn alle Seiten bleiben in ihrer subjektiven Sichtweise gefangen ohne dass das passiert, was eigentlich für eine erfolgreiche Kartengestaltung essentiell ist, dass man über den eigenen, subjektiven Blickwinkel hinaus wächst und man hoffentlich in die Lage versetzt wird, tatsächlich etwas zielgerichtet objektiv zu verbessern.
Betreffend
Abgesehen von den grundlegenden technischen Kenntnissen (vertraut werden mit den Werkzeugen und lernen, wie so ein Stil technisch funktioniert) ist die größte Hürde meiner Erfahrung nach, dass wenn man nicht nur Dinge entwickelt, die ausschließlich bei den höchsten Zoomstufen relevant sind, dass man üblicherweise eine Möglichkeit zum Testen auf globalem Maßstab braucht und dass das halt erhebliche Ressourcen benötigt. Hier hat der Standardstil durch die OSMF-Infrastruktur, die global Live-Updates bei den hohen Zoomstufen bietet und daneben bei einer neuen Version mal so eben in 1-2 Tagen z0 bis z12 neu berechnet, einen enormen Startvorteil.
Daneben gilt natürlich offensichtlich, dass eine Kartenstil-Entwicklung in Hinblick auf das Ergebnis und seine Qualität einfach enorm schwierig und anspruchsvoll ist.
Hi, ich muss sagen, dass ich mich inzwischen schon fast an den neuen Parkplatzstil gewöhnt habe.
Vor allem den Kritikpunkt aus #6 kann ich definitiv nicht mehr nachvollziehen:
Das Problem hier ist definitiv ein fehlendes landuse! Die allermeisten Parkflächen liegen entweder im Bereich von Wohn-, Gewerbe- oder Einzelhandelsgebieten und heben sich dort schon etwas von der Umgebung ab. Damit ist auf jeden Fall gegeben, dass man auch die Größe der Parkfläche noch ausreichend abschätzen kann.
Ich finde die Änderung der Farbe für Parkplätze absolut richtig, besonders auf niedrigeren Zoomstufen. In Denver, Colorado sind z.B. sehr viele Parkplätze gemappt, bis vor kurzem sah die Stadt auf OSM-Carto damit einfach nur grausig aus, weil alles gelb aussah…
Wenn dem so ist, dann scheinen mir die carton-Entwickler Wüstenbewohner zu sein,
die Wald nicht einmal vom Hörensagen kennen.
Anders kann ich es mir nicht erklären, dass es im Bereich “wood/forrest” dermaßen aussieht
(keinerlei Differenzierung aber trotzdem wirres Rendering).
Aber wahrscheinlich verstehe ich als kleiner waldbewohnender Mapper einfach nicht die Gedankengänge der global agierenden Cartoonisten - kann mich jemand aufklären?
die Radfahrerkarte rendert leisure=park nicht, im Gegensatz zur Standardkarte…
Die Standardkarte packt dann die Baumsymbole über leisure=park…
Mit leisure=dog_park sieht das aber auch “lustig” aus… Hier ein Teil des Grunewalds in Berlin: http://www.openstreetmap.org/#map=15/52.4517/13.2144&layers=N soweit ich mal geschaut habe, ist das wohl formal anscheinend korrekt… genaueres müssen die Berliner sagen, ich halte mich weitestgehend aus Berlin raus… Aber “schräg” sieht das aus… Der Grunewald ist aber seit einigen Releases so…
leisure=park|dog_park ect… wäre meiner Ansicht nach etwas, was auf eine Spezialkarte oder ein Overlay gehört…
Jein, Denn wenn der Wald vollflächig innerhalb liegt, dann wird sehrwohl Farbe UND Schraffur korrekt gerendert.
Insofern kann meinethalber gern leisure=park und alles mögliche dargestellt werden,
aber diese carto-Differenzierung von “ragt rein” vers. “liegt innerhalb” ist bei Wald schwer verständlich und läuft bei mir unter bug statt feature - ebenso wie das Aufsplitten von Farbe und Schraffur.
Die Darstellung von Land-Flächenfarben erfolgt in Reihenfolge der Größe mit den größten zuerst und den kleinsten zuletzt. Das Symbol-Muster bei Wäldern wird hingegen separat drüber gezeichnet.
Das bedeutet, dass wenn der Wald hier größer ist als der Park, dass dann bei Überlappungen der Park über die Flächenfarbe des Waldes gezeichnet wird, die Symbole des Waldes jedoch über den Park. Das ist Absicht, die Überlappung wird so deutlich sichtbar und der Mapper erhält die Rückmeldung, dass hier die Flächen überlappen. Wald bedeutet Wald im Sinne von hier wachsen Bäume und das soll sichtbar sein ungeachtet, was für kleinere Flächen der Mapper eventuell drin noch mappt - sprich: Spielplatz im Wald: bekommt Baum-Symbole. Wenn das falsch ist, der Spielplatz also eine Lichtung im Wald darstellt, dann muss der Mapper das als inneren Ring aus dem Wald-MP rausschneiden.
Meine persönliche Meinung ist hier, dass http://www.openstreetmap.org/relation/62809 kein besonders gut wartbares Polygon ist und man gut daran täte, das aufzuteilen und die Waldflächen innerhalb des Parks von denen außerhalb zu trennen. Dann würde der Wald im Park - weil kleiner als der Park selbst - auch wie vermutlich erwartet über die Park-Farbe gezeichnet werden.
Das mit der Auswahl der Farbei bei gestapelten Flächen ist keine Frage von “reinragen und innenliegen” sondern von “grössere oder kleinere Fläche”. “kleinere Fläche” trifft bei innenliegenden Flächen immer zu. Bei überlappenden Flächen kann beides zutreffen.
Diese Sortierung nach Flächeninhalt ist dem Umstand geschuldet, dass viele Mapper so mappen. Ein kleines Wäldchen in der grossen Wiese wird einfach drübergemappt statt mühsam Relationen zu basteln und der Renderer erfüllt halt die Erwartungen des Mappers, so gut er kann.
Da irrst du dich. Das wird sehr wohl unterschieden. Edit: konkret wird Laub-, Nadel-, Mischwald und nicht gemappt unterschieden. Wood und forest wird tatsächlich nicht mehr unterschieden.
Damit triffst Du genau ins Schwarze - und erst dann macht es ja wirklich Sinn, die ganzen unterschiedlichen Details zu mappen.
Viele Apps wie Orux im Zusammenspiel mit den openadroidkarten zeigen ja (im kleinen Umfang) schon, wie das aussehen kann. Ich finde es äusserst praktisch, die Hervorhebung von markierten Wanderwegen hier aus- und einschalten zu können.
Wer einen guten Artikel kennt, der die Hintergründe bleuchtet, wieso dass bei Webanwendungen technisch so schwierig ist: Ich freue mich über Links…
Suche einfach mal bei Google/YouTube nach “fossgis vector”
Technisch ist es überhaupt nicht schwierig … nur die große Datenmenge macht den Anwendungen Probleme bzw. auch nicht, es dauert halt einfach nur ein bisschen.
Beispiel: du willst Berlin angucken, mit Bitmap Tiles überschaubar … wenn du das aber auf Vektor und variabler Anzeige umstellen willst, musst du dem Browser eigentlich die/alle OSM Rohdaten für Berlin schicken, und das dürften ein paar MB sein, für ganz Deutschland halt schon GB
@imagico + maxbe: Danke für diese Infos, dann muss ich den Wald in carto-gerechte Stücke schneiden,
damit Bäume oberhalb der Park-Grasnarbe stehen und nicht umgekehrt,
aber diese Stücke müssen, soweit ich das verstehe, nicht zwingend vollflächig innerhalb der Parkfläche liegen - immerhin.
@Thomas8122: Zwischen natural=wood und landuse=forrest gibt es eine (farbliche+Schraffur-)Nuance,
allerdings tragen beide eine vergleichbare Schraffur.
Da wo ich herkomme sind derartige Schraffuren keine schmückende Deko,
sondern diese Schraffuren, Zeichen und Symbole transportieren Informationen, hier ist es diejenige für “Mischwald”.
So wie ich das sehe wertet carto den diesbezüglichen Tag “leaftyp” aber überhaupt nicht aus,
sondern deklariert mal locker verfälschend alles als “Mischwald”,
auch wenn der Mapper gar keine oder eine dezidiert andere Information abgelegt hat.
Mal angenommen, jemand wollte es extra so mappen, dass OSM-Carto das wunschgemäss anzeigt: Ja. Allerdings hätte das nur Einfluss auf die Farbe unter den Bäumchen. Die Signatur wird über die ganze Fläche verteilt, die als Wald eingetragen wird. Geht auch nicht bei allen Objekten. Häuser sind immer “über” Wiesen und Strassenflächen auch.
Allerdings ist das mit der Sortierung nach Flächeninhalt meines Wissens “schon immer” so und keine Neuerung in 4.5.0. Das mit den Bäumchen über anderen Flächen ist auch schon seit einiger Zeit so.
@Jo Cassel: und jetzt sollte dir eventuell auch klar sein, sofern vielleicht überhaupt schon bemerkt, warum die blaue “Unglücksteich”-Fläche auch “Bäume” im Wasser stehen hat
Ich würde sagen, dass müsstest du per MP ausschneiden…
Die grauen Parkplätze gefallen mir mittlerweile sogar.
Weniger gefallen mir dagegen im Bau befindliche Objekte (construction), die nun farblich kaum noch zu unterscheiden sind. Diese Änderung ist suboptimal!
Oder habe ich einen Augenpaul?
Ich meine landuse und building. Bei landuse war die Farbe nicht wirklich störend, aber das ist Ansichtssache. Die neue geht auch. Das ist auch abhängig vom Gerät bzw Display.
Bei building stört mich die nun fehlende farbliche Unterscheidung im Bau befindlicher Gebäude aber schon.
Mittlerweile habe ich aber gesehen, dass die farbliche Unterscheidung von Gebäudetypen (weitergehend) aufgegeben wurde (nicht nur bei construction). Das kann man gut finden, muss man aber nicht in jedem Fall.
Ein Vorteil ist, dass nicht spezifizierte Gebäudeteile nun nicht mehr unterschiedlich dargestellt werden. Das ist positiv und war wohl das Ziel.
Zur Erläuterung: Vor einiger Zeit wurde die Farbe von construction (gemeinsam mit brownfield) deutlich aufgehellt und ist damit sehr ähnlich zur Farbe von building - siehe hier. Die Gebäudefarben wurden von ursprünglich drei Typen (airport terminal, place-of-worship und der Rest) auf zwei Typen (airport terminal, place-of-worship und Bahnhöfe als ‘major’ und der Rest als ‘normal’) reduziert.
