Update OSM Carto

Ich kenne als nichtberuflicher GIS-Mensch nur den OGC Grundgedanken aber nicht die Einzelheiten. Könntest Du beschreiben, was das für das praktische Mapping bedeutet? Wird es schwerer oder leichter? Sind da Multipolygone wie beim See im Wald zwingend? Hat es in OSM Diskussionen gegeben, OGC-kompatibel zu werden?

Wir sind ein Projekt zur Erfassung von Geodaten per Community. Und daher muss es Community-gerecht bleiben, so dass größtmöglicher Input durch Mapper gegeben ist. Wenn OGC dazu im Widerspruch steht, dann kann es für die OSM-Datenbank nicht das Ziel sein. Es könnte dann höchstens eine zweite Datenbank abgeleitet werden, die OGC-kompatibel ist. Wenn OGC aber eine Erleichterung für Otto Normalmapper darstellt, dann kann ich Dir nur zustimmen.

Das muss nicht zwingend so bleiben. Das Thema Mapperfreundlichkeit muss dringend auf den nächsten Konferenzen thematisiert werden. Bisher habe ich das nur am Rande getan und einigen Zuspruch erfahren aber niemals Ablehnung. Aber wenn jetzt die Basiserfassung von Homeareas davon betroffen wird, muss das wohl mehr in den Vordergrund gerückt werden.

Schwierig zu sagen. Einfacher wird es bestimmt nicht aber anders. Wie das mit den Wälder mit landuse=* und den Seeen mit natural=water sein könnte, kann ich ehrlich gesagt auch nicht 100%-ig sagen. Wenn wir auch noch Layer in den Daten hätten, wäre das kein Problem mehr, aber das kann ich mir in den nächsten Jahren nicht vorstellen.

Es gibt die ewige Diskussion über die API v0.7, die ja alles besser machen soll. Inwiefern der Begriff OGC inzwischen da eingeflossen ist, muss ich mal nachsehen. Der dort besprochene AREA-Type wäre auf jeden Fall ein wichtiger Schritt in die Richtung.

Garbage in - Garbage out sagt man wohl dafür. Oder konkret an die Nicht-OSM-ler: “Wir erfassen alles was wir wollen, wir erfassen alles wie wir es wollen und wenn ihr was braucht, seht gefälligst selber zu, dass ihr das irgendwie aus OSM rausbekommt. Und kommt bloss nicht auf den Gedanken, dass das mit “euren” Programmen mal so eben geht.”

Wenn das ohne Kompatibilität zur GIS-Welt so weitergeht, ist OSM bald die grösste Datenmüllhalde des Planeten.

Nein, das halte ich nicht für sinnvoll. Das Synchronisieren der Dateninhalte - das wäre dann ein permanenter Datenstrom wie bei denn Diffs - kann langfristig nicht funktionieren. Eine v0.7-basierende DB sollte das nicht notwendig machen. Sollte - ich sage nicht “wird”.

Ich suche derzeit Programme/Editoren, die im OGC-Umfeld sowas wie Josm können, bin aber noch nicht fündig geworden. QGIS und der Geoserver können sowas aber es gibt sicher noch mehr. Es sollte deren aber sehr viel mehr Systeme geben. Ist halt “Neuland” - auch für mich.

Mapnik ist per se nur eine Demo-Anwendung, die dem Mapper und auch Nicht-OSM-lern zeigen soll, was man mit den OSM-Daten anstellen kann. Mapnik ist kein “OSM-Produkt”. Daraus jetzt die OSM-Referenz zu machen - in dem Sinne von “was Mapnik darstellt, ist korrekt” - halte ich für definitiv falsch.

Gruss
walter

Kann man sich die Layer mit Overpass nicht selbst bauen? Und überhaupt: Lädt überhaupt noch jemand ein Gebiet komplett herunter, um dann zu filtern, anstatt mit Overpass fertig gefiltert zu laden?

Also so schwarz wollen wir da doch nicht sehen. Wenn ich mir anschaue, was mit OSM so alles getrieben wird, z.B. beim Navi jetzt mit Spurassistent. Ich warte nur noch drauf, dass die Destination ausgewertet wird und mir gesagt wird, welchen Schildern ich folgen soll.

Wie gesagt, kommt es drauf an, ob OGC-kompatibel auch Mapper-kompatibel ist. Wenn nicht und wir führen es dennoch ein, kann man es vergessen, dass wir an der “Konkurrenz” kratzen können, was die Straßenerfassung angeht. Dann bleiben wir selbst in Deutschland eine OpenUncompletedStreetMap.

Ansonsten fällt mir da die Analogie zur letzten SOTM-EU auf, wo Alex Barth aus Sicht der Datennutzer gefordert hat, den share-alike aufzugeben. War natürlich völlig zwecklos. Die große Mehrzahl der OSMler will halt nicht, dass das Projekt vom großen Geld gekapert werden kann.

Nachdem Du so lange bei OSM bist, wie ich und quasi im Forum wohnst, hätte ich das jetzt nicht erwartet. Es geschehen noch Wunder. :wink:

Wird aber so gehandhabt, sonst gäbe es den Thread nicht. Insbesondere würde man dann nicht anlässlich dessen darüber diskutieren, die Wälder mit Seen in Multipolygone umzuwandeln.

Neuland insofern, dass ich einige Programme kenne, die auf dem OGC-Standard aufbauen oder ihn zumindest kennen, nur hab ich noch nichts gesehen, womit man diese Daten auch in die Systeme hineinbekommt. Immer nur Programme, die WFS, WMS, WCS und Sonstwas-Server sind und mit denen man das Tollste anfangen kann, nur ein Online-Editor zum Erfassen dieser Daten ist mit noch nicht vor die Füsse gekommen. Da hab ich halt ne Lücke, auch wohl, weil ich noch nie richtig danach gesucht habe. Da kommt dann die Anwenderfreundlichkeit ins Spiel.

Ja das ist so, weil das viele Mapper halt so “sehen”. Das Argument “OSM ist nur eine Datenbank” ist verdammt schwach. Selbst ich habe längere Zeit gebraucht, bis ich das geschnallt hatte. Kann mich noch daran erinnern, dass ich unbedingt die Josm-Icons für POI auf der Mapnik-Karte sehen wollte :wink:

Gruss
walter

Das ist wohl der Weg, den fast jeder von uns gehen muss. Dieser Weg geht aber noch weiter mit der Regel: “Wir mappen nicht für den Renderer (die Anwendungen).” Wenn auch der vom Kopf in den Bauch gerutscht ist, stellt man fest, dass die eigentlich auch nicht stimmt. Denn natürlich mappen wir für die Anwendungen. Was für einen Sinn macht eine Datenbank, für die es keine Anwendung gibt? Die Regel muss also heißen: Wir weichen nicht bewusst vom “Standard” ab, um eine bestimmte Reaktion in der Anwendung zu erzwingen.

Wenn dann noch einige Zeit ins Land geht, zündet noch eine weitere Stufe: Wir bauen immer ausgefeiltere Mapping Regeln, die auch noch den irrsinnigsten Ausnahmefall abdecken. Das macht die Regeln komplex. Und dann wird irgendwann klar, dass alles vorher Gesagte vollkommen sinnlos ist, wenn es kaum noch Mapper gibt, die das umsetzen können. Dies alles muss gegeneinander abgewogen werden. Viele hier kritisieren Wikipedia wegen der komplexen Regelflut und mögen deswegen nicht mehr daran mitschreiben. Folglich klagt Wikipedia über Autorenschwund. Aber im Grunde machen wir mit unseren immer komplexer werdenden Datenstrukturen nichts anderes.

Bezogen auf das Ursprungsziel, eine Geo-Karte/Datenbank durch eine Community erstellen zu lassen, muss dann auch die Frage gestellt werden, ob eine Datenstruktur, die für wenige Ausnahmefälle komplex sein muss, fallen lässt und einfacher gestaltet. Denn lieber auf wenige Ausnahmefälle verzichten, als ein paar tausend Standardfälle.

Eine weltweite Abdeckung des kommenden Straßenstils des Standardlayers: https://osm.rrze.fau.de/map-ll-osm?zoom=3&layer=RRZE%20tileserver%20osm.org%20style%20tiles

Aus: https://github.com/gravitystorm/openstreetmap-carto/pull/1736

Mir gefällt das blasse Layout überhaupt nicht. Ich denke jedes Mal, mein Monitor ist kaputt oder meine Brille ist beschlagen. Das Argument, eine Karte bereitzustellen für Leute, die ihre eigenen Daten darauf darstellen wollen, halte ich nicht für stichhaltig. Dies muss nicht auf der Hauptseite, dem Aushängeschild von OSM gemacht werden. Außerdem gibt es schon genügend Kartenstile für diesen Zweck, zum Beispiel bei Mapquest.
Das neue Straßenlayout finde ich auch nur mäßig, das aktuelle ist völlig ok.
Und nun einfach die Renderregeln für Flächen mit Löchern zu ändern, nachdem es jahrelang hieß, kleine Flächennutzungen kann man die große Nutzung ohne Relation hineinmalen, also einen Teich in einen Wald zum Beispiel, ist auch sehr mutig (ich habe trotzdem immer eine Relation angelegt, aber der mir bekannte Konsens lautete, ist nicht unbedingt notwendig).
Es gibt ganz andere dringende Baustellen. Zum Beispiel werden Flüsse gerne mal genau an der Stelle von Brücken benamt. Auf Brücken mit Straßenbahngleisen gibt es einen hässlichen Bug (kurzes fehlendes Schienenstück an den Brückenenden). Die Karte bei großen Maßstäben müsste dringend überarbeitet werden (irgendwo habe ich auch schon mal einen viel hübscheren Stil als Vorschlag gesehen). Straßentunnel werden äußerst häßlich gerendert. Das war schon mal viel besser.
Ja ja, ich habe schon gehört, die “Entwickler” hätten was gegen Transparenz, aber wer bitte hat die zwei Leute eigentlich dazu autorisiert, ihre private Meinung durchzudrücken?
Nein, ich habe keine Lust, auf Github mit den Leuten rumzudiskutieren, da ich mit den Entscheidungsträgern dort auch schon schlechte Erfahrungen gemacht habe. Daher bin ich auch etwas angefressen. Wollts nur mal gesagt haben.

Die Straßenfarbenänderungen sind übernommen wurden. Das aktuelle Release hat sie noch nicht, wird also noch ein paar Wochen dauern bis man es auf osm.org sieht.

Die Änderungen sind jetzt online. https://blog.openstreetmap.org/2015/10/30/openstreetmap-org-map-changing/

Yepp, es färbt sich alles um. :wink:
Autobahnen werden rot, Trunks werden orange.

Für mich sehen die Änderungen überraschend gut aus. Was mir insbesondere gefällt ist der Umstand, daß die Breite der Straßen jetzt realistischer geworden ist.

Der oben verlinkte Blog erwähnt auch die Verwendung einer neuen Mapnik-Version: "There is also an updated version of Mapnik, the underlying toolkit used to convert the written style rules in to the final map you see on the OSM website. "

Frage: Weiss da jemand genaueres?

Gruß Klaus

Gefällt mir auch. Jetzt müsst man nur noch die Ackerflächen von Zoom 10-11 weglassen, damit man da die highway=primary besser sieht.

Gruß Thomas

Mir ist kein Update von Mapnik bekannt (siehe auch https://github.com/openstreetmap/chef)). Ich nehme an, man wollte erwähnen, dass es in nächster Zeit ™ eines geben wird, weil das z.B. das Textrendering für nicht-lateinische Alphabete drastisch verbessern wird.

edit: Update von Mapnik

Schau hier: https://github.com/gravitystorm/openstreetmap-carto/releases
und hier: https://blog.openstreetmap.org/2015/10/30/openstreetmap-org-map-changing/

oder warte die nächste Wochennews ab :wink:

Gruss
walter

Sorry, war missverständlich. Meinte Update von Mapnik. Habs ergänzt.

Ok, hab ich auch falsch gelesen.

Dann halt Mapnik 3.0.8 : https://github.com/mapnik/mapnik/blob/master/CHANGELOG.md#308

Ist seit dem 23.10.2015 verfügbar. Welche konkrete Release die Kollegen allerdings einsetzen, müsste ich ein wenig suchen.

Gruss
walter

ach ja: Hier ist als “Spinoff” der Wochenews eine stets aktuelle Liste der mMn für OSM relevanten Software: http://osm.wno-edv-service.de/index.php/osm-software

Wenn was fehlt, bitte kurze Nachricht an mich, dann ergänze ich gerne meine Watchlist.

das die kreisstraßen (highway=tertiary) aber keine eigene farben mehr haben ist blöd, alles nur weiß. und für mich waren bundesstraßen immer schon rot, und jetzt orange? mir gefällts nicht …

+1
tertiary, unclassified, residential und service alles in der sleben Farbe. Da muss man ja mit der Lupe dran, um die unterschiedlichen Breiten zu erkennen :frowning:

Tatsächlich? Ich kann die Straßen gut unterscheiden. Frischer Wind ist immer gut! Mein Hauptkritikpunkt der grünen Schnellstraße und blauen Autobahnen ist nun hinfällig. Dies war damals einer der ausschlaggebenden Gründe, das Projekt OpenTopoMap zu starten. Natürlich stampfen wir es es jetzt nicht ein - im Gegenteil. Hinter den Kulissen bereiten wir seit mehreren Wochen schon eine komplett überarbeitete Version vor.

Die Überarbeitung des “Standard-Stils” zeigt aber, dass Veränderung in OpenStreetMap nicht ausgeschlossen ist.

Naja OSM-Carto ist nicht Openstreetmap, da sind die Änderungen in der Hand weniger.

Btw: Nochmal zur Unterscheidung weil das oben zu Verwirrung geführt hat: Mapnik ist der Renderer, Openstreetmap/OSM-Carto der Stil. Ggf. könnte man den Threadtitel noch ändern?