Update OSM Carto

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

Eines wurde offensichtlich noch nicht verstanden. Hier wird immer noch mit allen Mitteln versucht, den Mapper ein Multipolygon erzeugen zu lassen. Mir ist klar, dass man Dinge wie ÖPNV Linien nicht ohne Relationen erschlagen kann. Aber hier haben wir ein Problem, bei dem es bisher ohne Relationen und Multipolygone funktionierte. Warum soll man das Bilden der Multipolygone nicht demjenigen überlassen, der sie versteht, nämlich dem GIS Anwender. Es hilft auch nicht, wenn der Editor das Bilden der Multipolygone übernimmt, wenn der Mapper deren Wesen nicht versteht. Selbst wenn er diesen Editor bedienen lernt, hat er das Problem bei Änderungen, bei dem er den Relationseditor und Relationen verstehen muss.

Bisher malte der Mapper einen Wald und dann den See, der darin liegt. Das war für ihn intuitiv. Es ist für ihn logisch, dass der Wald da aufhören muss, wo der See beginnt. Er hat damit mitgeteilt, was er über die Örtlichkeit weiß. Warum also muss er uns noch explizit mitteilen, dass im See kein Wald ist, und das bei jedem See im Wald aufs Neue? Als wenn das nicht genug wäre, fordern wir dazu das Verständnis eines Datenkonstuktes, den er ansonsten nicht braucht. Wozu? Um den Mapper mit unnötigem Firlefanz zu frusten? Denn wenn der alte Renderer das richtig interpretierte, kann es auch eine andere Software. Man könnte dafür Algorithmen angeben, so dass es dem GIS Datennutzer leichter fällt, dies richtig zu implementieren. Man könnte auch eine Datenbank vorhalten, in der alles GIS-gerecht von OSM abgeleitet ist, während es hier mappergerecht, also möglichst einfach zugeht.

Nicht nur bei diesem Problem sollte es unser zukünftiges Credo sein, das Mappen so einfach und intuitiv wie möglich zu gestalten, um möglichst vielen Mappern die Mitarbeit zu ermöglichen.

Ich hätte es nicht besser ausdrücken können. Die hier im Forum versammelte Mapper-Elite wird nie in der Lage sein, abseits der eigenen Hotspots - wo inzwischen jeder HKTS gemappt ist - eine Basisabdeckung in der Fläche zu schaffen. Schon im Berliner Speckgürtel ist teilweise weniger als die Hälfte aller regelmäßig genutzten Waldwege erfasst! Das wird nur mit Hilfe von “Laienmappern” möglich sein, für die a) die Zugangshürden möglich niedrig sein sollten und b) möglichst bald ein Erfolgserlebnis sichtbar sein sollte. Bäume im See/Teich sind wahrscheinlich kein Erfolgserlebnis.

Ändert es etwas, wenn das Wort geändert wird, nein.
Die Eindeutschung macht es auch nicht leichter. :wink:

Tretet mal den Leuten in den A…, die unnötige MPs und solche, die gar keine sind (MP mit 1 Element) produzieren. Wurde hier im Forum mehrfach angesprochen.

Ich würde mir ja zunächst saubere Begriffsdefinitionen wünschen…

http://www.opengeospatial.org/standards/sfa

Denn in vielen Fällen ist ein Multipolygon nicht das, was wir wollen (Wald-See-Problematik) sondern echte Polygone… Aber eh das soweit ist, wird noch viel Wasser die Spree herunterfließen… :expressionless:

Sven

Bei uns sind Multipolygone jene Dinge dies aus mehreren Elementen bestehen. Es ist dabei egal wieviele Flächen daraus nachher entstehen. Also wenn wie bei den Grenzen Ein land aus mehreren Wegen gebildet wird, ist das genauso ein Multipolygon wie wenn es nur ein Inner und ein Outer für einen Wald mit See gibt.

… und das ist das, was mich ärgert… Es spricht ja erst mal nichts dagegen, Polygone auf die eine oder andere Weise zu bilden.

OSM macht hier aber sein eigenes Ding, ohne sich an grundsätzliche Definitionen und Standards zu halten (vergleiche Datentypen-Definition bei: http://www.opengeospatial.org/standards/sfa

Es wird immer von freien und offen Daten geredet und gerne mal gegen unfreie Dinge gewettert (was ja auch durchaus berechtigt ist), dann sollte man aber auch mal den Mut beweisen und OGC-konform werden, so daß die eigenen Daten frei und offen verwendet werden können…

sorry die Luft mußte mal raus…

Sven

Es heißt Openstreetmap, nicht Openlandusemap. Da hat damals wahrscheinlich keiner dran gedacht. :confused:

falls du das nicht ironisch meinst:

Ja, das sind Altlasten, die vor vielen Jahren ( ~10!) entstanden sind und die wir nicht so einfach los werden können. Zu der Zeit gab es wohl noch kein OGC und es wurde danach leider die Chanche vertan, rechtzeitig auf den OGC-Zug zu springen.

Jeder ahnt was von der API-0.7 aber keiner traut sich ran. Weil im Vergleich zur lange überfälligen Anpassung der OSM-Datenstruktur der Lizenzwechsel ein Klacks war.

Eines macht den Wechsel aber mMn “einfach”: Das Ziel (OGC) ist klipp und klar definiert. Das ist ein internationaler Standard, an dem es nichts zu rütteln gibt. Man muss “nur noch” OSM darauf umstellen ohne das Rad neu erfinden zu müssen.

Irgendwie erinnert mich OSM an französische Autos. Alles ist irgendwie anders - sie fahren, aber keiner weiss, warum :wink:

Gruss
walter

ps: Ich fragen mich schon seit Tagen, was dieser Thread eigentlich soll. Mapnik ist geändert und das bleibt so. Punkt.

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.