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

Vielleicht hilft es ja weiter … diese Polygone wurden beim Build (Mapsforge) der Karte für Niedersachen (geofabrik-Extrakt vom 24.09.2014) ausgeworfen:

-rw-r–r-- 1 kto kto 28K Sep 24 19:04 DebugOuterWay_1200045271.txt
-rw-r–r-- 1 kto kto 25K Sep 24 19:04 DebugOuterWay_1200047706.txt
-rw-r–r-- 1 kto kto 9.3K Sep 24 19:04 DebugOuterWay_1200047707.txt
-rw-r–r-- 1 kto kto 1.5K Sep 24 19:04 DebugOuterWay_29413042.txt

Link: https://dl.dropboxusercontent.com/u/1677057/Problem-MPs-Niedersachsen.zip

Angesehen habe ich mir die Daten aber noch nicht.

Gruß Klaus

Nachtrag: Hier noch die wenig ausagekräftigen Warning des Mapwriters:

WARNING: outer way of multi polygon is not a polygon, skipping it: 1200045271
WARNING: outer way of multi polygon is not a polygon, skipping it: 1200047707
WARNING: outer way of multi polygon is not a polygon, skipping it: 1200047706
WARNING: outer way of multi polygon is not a polygon, skipping it: 29413042

Eigentlich der richtige Weg, aber wohl nur bei banalen Fehlern bei einzelnen Objekten machbar. Sobald es um diejenigen Geometrien geht, bei denen mehrere OSM-Objekte gleichzeitig beteiligt sind, muß das die Performance beim Update massiv runterziehen.

Banal aber ziemlich falsch:

Inner/Outer an fast allen Ways sind derzeit wegen bestehender Konventionen zwingend, obwohl diese Rollen zumindest von osm2pgsql total ignoriert werden, da sich das bei der Konvertierung in ein OGC-Objekt automatisch ergibt - rein aus der Geometrie.
Zudem gibt es admin_centre, die aus einem Building bestehen und somit ein geschlossener Way sind (genau so wie ein Mini-Inner)
Und die Reihenfolge der Member innerhallb einer Relation sind ebenfalls total unwichtig bis auf Buslinien - aber das ist ein anderes Thema.

Hast halt ein unpassendes Beispiel genommen :frowning:

Gruss
walter

Sorry, daß ich nerve: Welche Version und was sagen die Autoren dazu? In der 4.x wurde doch Besserung versprochen.

Schau’n mer mal.

Gruss
walter

Für den Kartenbuild wurde der Mapwriter in einer Version 0.3.1 genutzt. In der Version 0.4 des Mapwriters wurden m.W. nur technische Änderungen vorgenommen, damit das Plugin mit der aktuellen osmosis-Version klar kommt. Fachlich wurde, soweit ich weiss, nichts geändert. Hast du da anderes gelesen?

Gruß Klaus

so, ich hab mit mal DebugOuterWay_29413042.txt angesehen, da es das kürzeste File war.
Mit eine wenig Editieren hab ich daraus ein Poly-File gemacht und dieses in Josm geladen:

Siehe, es ist Juist.

Das die Grenze beschreibende Multipolygon ist die Relation https://www.openstreetmap.org/relation/897895. Diese enthält nur den Way https://www.openstreetmap.org/way/29413042 und der ist total in Ordnung - sagt zumindest der Josm-Validator.

Meine DB stimmt da zu:


select osm_id,ST_Summary(way),ST_IsSimple(way), ST_IsValid(way) 
  from planet_osm_line
 where osm_id=29413042;

  osm_id  |          st_summary          | st_issimple | st_isvalid 
----------+------------------------------+-------------+------------
 29413042 | LineString[b] with 73 points | t           | t

Da diese Daten bereits durch die “Hände” von osm2pgsql gegangen sind, schaue ich mit jetzt noch die Rohdaten an.

Warum um Himmels willen zickt Mapsforge da rum? Frage bitte mit diesen Infos den Autor.

Gruss
walter

Nachtrag: Eine Möglichkeit wäre noch, daß mapsForge eine der anderen Relationen, die diesen Way enthalten, nicht gefällt. Aber dazu soll der Autor (endlich) was sagen.

Nö, nur das es eine neue Version gibt (4.3 ?)

also benutze die und danach reden wir weiter.

Ich verstehe langsam nicht, wieso du die Mapsforge-Leute da nicht mehr einspannst. Christoph mag ja ein liebes Kerlchen sein, aber alles auf die “schlechten OSM-Daten” zu schieben ohne vernünftigen Feedback zu lifern, ist mMn nicht die feine Art.

Gruss
walter

ps: Nur zu meiner Sicherheit: MapWriter ist doch wohl integraler Bestandteil von MapsForge? Oder liege ich daneben?

EDIT: Jo, scheint Bestandteil zu sein. Nur: Download des Plugins funktioniert nicht (File not found). Klasse! auf einer anderen Seite funzt es.

Nachtrag:
hab MapWriter 0.4 am Laufen. Verarbeitet Niedersachsen in 3-4 Minuten ohne Fehler und erzeugt kein debug-file, trotz Option. Und nu?

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.