Wer könnte einige Problem-Polygone prüfen?

Moin Walter,

hast du deine Karte auch mal in Küstennähe angeschaut?

Gruss Christian

Nein, sorry, aber ich kenne und brauche das Zeug garnicht in der Praxis.

Ich habe nur den MapWriter installiert und bekomme keinerlei Fehlermeldungen beim Konvertieren von Niedersachsen. Einen Debug-Log krieg ich auch nicht.

tox-rox hält sich auch bedeckt und ohne mindesten einen nachvollziehbaren Fehler bei der Konvertierung der OSM-Daten kann ich nichts machen. Auf einer Karte, die ich nicht habe, nach komischen Stellen zu suchen und dann zu raten, woran das wohl liegen könnte, ist nicht mein Ding.

Wie soll ich einen Validator schreiben, wenn ich keine “falschen” Daten habe? Wäre wirklich ein interessantes und auch nützliches Projekt für mich und OSM :frowning:

Gruss
walter

mein Script:


#!/bin/bash
#
#set -x
#
cd /home/walter/osm/MapWriter
date

OSMOSIS=/opt/install/osmosis-latest/bin/osmosis

JAVACMD_OPTIONS="-Xmx4G"
export JAVACMD_OPTIONS

$OSMOSIS \
        --read-pbf file=/data4/import/tmp/niedersachsen-latest.osm.pbf \
	--mapfile-writer file=niedersachsen-latest.map \
                         debug-file=true

Moin Walter,

… hätt’ ja sein können. So wissen wir jetzt zwar, dass es keine Debug-Meldung gab, aber ob die Insel kommentarlos verarbeit oder auch noch die Debug-Meldungen-ausgeben Routine kaputt ist, wissen wir nicht.

Gruss Christian

Das Ticket hier riecht sehr nach eurem Problem: https://code.google.com/p/mapsforge/issues/detail?id=431

(Hervorhebung von mir)

stimmt, daher warte ich ja auch auf Input von Klaus. Bestimmt benutzt er auch eigene Styles, oder wie immer sowas bei MapsForge heisst, und da könnte auch alles Mögliche herkommen.

Ja, das ist bei Juist genau der Fall. Naja, das Ticket ist ja erst von März 2013 :frowning:

Das muss nichts bedeuten. Die Frage ist, welche Version da genau zum Einsatz kommt:

Also hier in der mit 0.3.1 getaggten Version ist der PatchFlicken aus dem genannten IssueTicket auf jeden Fall mal nicht drin, d.h. Problem besteht weiterhin.

Darum hab ich ja Klaus nach seiner eingesetzten Version gefragt und er meinte, es wäre nicht nötig auf 0.4 zu wechseln :frowning:

Ich habe natürlich MapWriter 0.4 benutzt, könnte mir aber zur Not auch master oder branch zusammenschustern.

Eigentlich will (und werde wohl) ich mich überhaupt nicht um MapsForge kümmern; ich brauche Beispiele für fehlerhafte oder auch angeblich fehlerhafte OSM-Daten, damit ich die in OSM finden und auch in OSM beseitigen kann. Das erscheint mir als der einzig richtige Weg.

Gruss
walter

Moin Walter,

Klaus kann nicht ohne weiteres updaten. Wir benutzen das hier → http://mapsforgecoastline.wikia.com/wiki/Mapsforge_%28Coastline-Enabled%29_Wiki

Das ist ein branch, der nicht zurück in den master geflossen ist. Daher auch meine Frage nach der Küste: Plain mapsforge-writer kann anno 2014 nix mit “coastline” anfangen und stellt Meer mit Hintergrundfarbe dar. Es gibt einen workaround, aber ob der schon im default-download implementiert ist - keine Ahnung.

Gruss Christian

Gut, die Sachen sind auf dem Stand von September 2012.


git clone git://git.assembla.com/mapsf_coastline.git
Klone nach 'mapsf_coastline'...
fatal: remote error: access denied or repository not exported: /mapsf_coastline.git

Klappt irgendwie nicht mit dem klonen. Egal.

Der Bug ist da auf jeden Fall noch drin: Link

Wenn ihr euch das zutraut, könnt ihr ja mal den vorgeschlagenen Patch manuell einarbeiten, das ganze kompilieren und nochmal probieren.

Dann soll er das auch gefälligst schreiben. Und nicht “das ist nicht nötig, weil sich nichts getan hat”. :frowning:

Toll, den werde ich aber nicht zusammenpfriemeln. Wenn es irgendwo ein JAR gibt, das osmosis 4.3 akzeptiert, her damit ansonsten ist hier Schluß.

ich besitze ein niedersachsen-latest.map, den ich gestern ohne Fehlermeldungen und ohne Log erzeugt habe. Hier ist er: https://osm.wno-edv-service.de/DataServer/osm/files/niedersachsen-latest.map 273 MB. Könnt ihr euch gerne ansehen, da ich die passende SW nicht installiert habe.

Ich finde, daß diejenigen, die ein Problem mit OSM-Daten haben, bitte vernünftigen Input liefern und nicht, dass ich die mir erst mühsam zusammenkratzen muß. Ich will die Fehler in den OSM-Daten beseitigen aber nicht MapsForge verbessern. Das ist nicht meine Baustelle - und war auch nicht vom Thread-Ersteller so angefragt. Also Butter bei die Fische.

Gruss
walter

ps: Ja, ich bin langsam leicht sauer :frowning:

Generelle Vorbemerkungen:
Mir geht es in erster Linie um eine Qualitätssicherung aller Multipolygone. Hierfür wäre eine programmgestützte, automatisierte Kontrolle auf Basis der unveränderten OSM-Daten sehr hilfreich. Also eine sehr anspruchsvolle Aufgabenstellung. Im ersten Schritt müßte man inkorrekte oder problematische MPs erkennen können. Die Basis der Kontrolle sollte eine umfassende und exakte Definition eines vollständig validen MPs sein. Frage: Gibt es ein solche Definition?

Mapwriter:
Für mich ist der Mapwriter nur (ein) Mittel zum Zweck. Also die Erkennung von Problem-MPs, die dann Ausgangspunkt für alles Weitere sein könnten. Am Wochenende werde ich mir mal die aktuelle Version 0.4 des Mapwriter installieren. Dann bin ich mal gespannt, welche Probleme sich dann für Deutschland ergeben.

@wambacher / @couchmapper:
Ich verwende aus bestimmten Gründen (Meerespolygone) derzeit die Version 0.3.1 des Mapwriter. Nach diesen Aussagen der Entwickler soll sich zur Version 0.4 nicht viel geändert haben: https://code.google.com/p/mapsforge/wiki/GettingStartedMapWriter

Changelog 0.4.0
There are no significant changes in 0.4.0 and the mapfile format has not changed.

  • Small adjustments in the tag-mapping.xml configuration
  • Updates to run with Osmosis 0.4.3.

Eure Findings (wambacher = (vermeintliches) Problem-MP “Juist”; couchmapper = möglicherweise passender Bugfix) habe ich mal auf der Mapsforge-Mailingliste gepostet: https://groups.google.com/forum/#!topic/mapsforge-dev/TeItJ4hdkNc Ein “handfestes” Ergebnis ist bei der Diskussion bislang nicht herausgekommen. Allerdings scheinen, entgegen der oben getroffenen Aussage, doch (fachliche) Veränderungen vorgenommen worden zu sein. Hingewiesen wurde auf diesen, möglicherweise zum Bugfix passenden, Change: https://code.google.com/p/mapsforge/source/detail?r=b3ddd8d7bc9503e2d5bee8fc8491f8bb6202db8c Bewerten kann ich das allerdings nicht … vielleicht kann couchmapper da was zu sagen.

BTW: Die Version 0.3.1 des Mapwriters unterstützt Küstenlinien und erzeugt Meerespolygonen. Die Version 0.4 enthält da keinerlei Unterstützung. Schon seit längerem möchte ich das Verfahren zur Erzeugung von Meerespolygonen ändern. Geplant ist die Verwendung der überarbeiteten Küstenlinien von Joch Topf: http://openstreetmapdata.com/data/coastlines Da der Autor die Daten nicht zusätzlich im OSM-Format anbieten möchte (ich hatte dies mal angefragt), müßte man die Shapefiles selbst ins OSM-Format überführen. An der dazu erforderlichen Toolchain bin ich (leider) bislang gescheitert.

Fazit: Die Aufgabenstellung “QS aller MPs” ist anspruchsvoll und wird sicher einige Zeit benötigen. Ich bin mal gespannt was dabei rauskommt. Auf den Nebenkriegsschauplatz “Mapwriter” sollten wir nicht allzuviel Energie reinstecken.

Gruß Klaus

PS: Ich poste die Ergebnisse des Mapwriterlaufs für Deutschland sobald ich sie habe.

Hallo Klaus,

Das ist inzwischen auch mein Anliegen - Finden und Bereinigen bestehender Geometriefehler in den OSM-Rohdaten.

Antwort: Jain :frowning:

Es gibt Geometriefehler, die offensichtlich und unwiderstritten vorhanden sind und es gibt - leider so gewollte - Abweichungen von dem sog. OGC-Standard. Zweitere bestreffen hauptsächlich das Zusammenspiel von Inner/Outer und die Berührungen von Teilen der Multipolygone. OSM ist da erheblich toleranter als der weltweite OGC-Standard und macht somit fast allen semi- und professionellen Anwendungen das Leben schwer.

Danke, wobei ich nicht beurteilen kann, ob das Coastline-Problem dort gelöst ist. Hat jemand mal “meine” Daten von NDS betrachtet? https://osm.wno-edv-service.de/DataServer/osm/files/niedersachsen-latest.map 273 MB

Ja, da bin ich auch mal gespannt - obwohl wir ja leicht vom Thema abkommen.

Sollte doch machbar sein. Ich hab da auch schon mal was versucht, bin mir aber nicht sicher, warum ich das gestoppt habe. Ich schau mal nach.

Ja, so sehe ich meinen Beitrag auch. Nur würde es mir ein wenig leichter fallen, wenn ich einige vom MapWriter “angemotzte” Daten hätte. Daher kommt wohl auch wohl ein wenig mein “Generve”.

Ich habe derzeit aber ein riesiges technisches Problem, das wohl einen eigene Thread verdient hat:

Ich benutzte beim Import der OSM-Files mittels osm2pgsql ein sog. Flat-File.

Das hat zur Folge, daß die Koordinaten aller Nodes (korrekt: aller taglosen Nodes) nicht in meiner PostGIS-Datenbank enthalten sind. Konkret: planet_osm_nodes ist leer. Das macht im praktischen Betrieb keinerlei Probleme, beschleunigt den Update mittels Diff-Files aber immens.

Nur brauch ich jetzt diese Nodes :frowning: Any ideas?

Bitte auch mit deinen Anpassungen (Script, style). Ich weiss immer noch nicht, wieso mein NDS-Lauf keine Fehlermeldungen und kein Logfile erzeugt hat.

Gruss
walter

Ich habe mir kurz mal die Situation angesehen. Wenn ich diese Aussage richtig verstehe “The data has been derived from OpenStreetMap ways tagged with natural=coastline. Some errors in the OSM data are repaired in the process.”, ist hier mMn genau der falsche Weg gegangen worden.

Hier wurden die Daten aus OSM extrahiert (prima, daher müssen die ja wohl bei einem OSM-Projekt kommen), lokal korrigiert und dann in Shapes umgewandelt. Und die korrigierten Daten werden dann so weitergegeben, daß sie nur sehr schwer wieder in OSM zurückfließen können.

Hier haben wir wieder das alte Problem: Die Basisdaten bleiben falsch :frowning: Oder zumindest enthalten die wohl etwas, was anderen Probleme macht.

Nebenbei halte ich den Weg OSM —> Shapes —> OSM-Files —> Anwendung (hier MapsForge) für krass gesagt, ein wenig hirnrissig. :frowning:

Gruss
walter

ps: Bold im Zitat von mir.

Wenn wir irgendwann bei den großen Playern dabei sein wollen, sollten wir endlich etablierte Standards akzeptieren und übernehmen. Bis dahin kommen wir aus unserer Hobbynische nie heraus. Aber das Einführen des OGC-Standards ist hier OT und gehört zum Teil in “Multipolygonwahnsinn” oder insgesamt in einen neuen thread. Für mich sind Standards wesentlicher Bestandteil einer Qualitätssicherung. Aber hier kann ja - frei nach F.-J. Degenhardt - jeder machen, was er will :roll_eyes:

Stimmt, das ist hier ein wenig OT, beschreibt aber dennoch eines der ständig auftretenden Probleme.

Einerseits macht OSM “was es will” und andererseits bemerken die gleichen OSM-Anwender dann, dass wichtige externe Anwendungen (hier MapsForge) das Spielchen nicht mitmachen und den “Schrott” einfach ignorieren.

Ein ziemlich pol. unkorrekte Zusammenfassung: “Keine Arme - keine Kekse”

Gruss
walter

Im wesentlichen werden Lücken in den Küstenlinien repariert. Diese führen dazu, daß später in einer Karte ganze Landstriche oder Länder “unter Wasser stehen”. Aus Sicht der Kartenbauer sind diese überarbeiteten Daten somit sehr wertvoll. BTW: Mapsforge 0.3.1 mit Küstenlinienunterstützung nutzt (intern) genau diese Daten; dito mkgmap (Compiler für Garminkarten).

Gruß Klaus

Jo, das hab beim nochmaligen Durchlesen der Anmerkungen auch gelesen; da war ich vorhin wohl ein wenig zu heftig.

Klaro

Ich habe da wohl irgendwas falsch verstanden und war der Meinung, dass MapsForge keine Shapes liest, sondern dafür OSM-Files braucht.

Sorry, für die Verwirrung

Gruss
walter

ps: Irgendwo hab ich gelesen, dass jemand dafür Shapes nach Osm konvertieren will und das halte ich weiterhin nicht für sinnvoll. Ich kann die Stelle aber nicht mehr finden :frowning:

Ich denke jetzt ist der Unterschied zwischen den Mapsforge-Versionen deutlich geworden. Die Version 0.3.1 liest intern die Küstenlinien-Shapes von Jochen Topf ein und macht daraus Meerespolygone. Die Version 0.4 macht das nicht. Man erhält statt Meer eine weisse Fläche. Die OSM-Küstenlinien zur Darstellung von Meer heranzuziehen führt in der Regel zu Überflutungen. Der geplanter Ansatz ist vereinfacht folgender: Höhenlinien nach OSM konvertieren, Küstenlinien nach OSM konvertieren, anschließend alles (lokal) mit den OSM-Basisdaten zusammen mischen, um dann daraus eine Karte zu erzeugen. Was mir fehlt ist die Konvertierung der verbesserten Küstenlinien nach OSM. Aber schließen wir das Thema “Mapsforge-Versionen” damit erstmal ab.

Gruß Klaus

Grummel Grummel, aber klären wir, wenn ich was konkretes habe :wink:

Yes, Sir

ich schlage mich eh schon mit dem Zugriff auf das Flat-File rum. Die Kollegen von osm2pgsql haben netterweise vergessen, den Tool nodecachefilereader auf 64 Bit umzustellen :frowning:

Gruss
walter