nach einer längeren Mail-Kommunikation mit Klaus (die ich lieber im Forum geführt hätte), versuch ich mal die Problematik ein wenig zusammenzufassen:
Statement: Wir haben “komische” Daten in der OSM-Datenbank. Punkt.
Diese stammen in der Regel von schlampigen Editoren (sowohl Programmen als auch Menschen) und sind u.A.
sich überschneidende Linien
sich berührende Linien
doppelte Punkte
a-b-c-b-d Linien
Zudem Multipolygone, die nicht sauber sind. (inner/outer falsch, Missachtung des OGC-Standards)
Es gibt nun die verschiedensten Programme, die in irgend einer Form diese Rohdaten verwenden (müssen):
osm2pgsql baut daraus eine lokale DB zum Rendern oder auch für Nominatim
OverPass liefert vorverarbeitete OSM-Daten für den Anwender
Die API liefert alle unveränderten Daten nach Bedarf
Die Editoren arbeiten natürlich mit der API
und wohl auch MapsForge
Jede dieser Anwendungen muß sich nun mit den offensichtlichen Fehlern herumschlagen:
osm2pgsql (mein Favorit) versucht, alles Mögliche zu korrigieren oder ignoriert manche Daten einfach - und das ohne den geringsten Kommentar.
was die OverPass ausbügelt, ist mir nicht bekannt
die API macht nix
die Editoren bekommen den Schrott halt so geliefert, wie er ist; Josm “motzt” allerdings vor dem Hochladen über manche Fehler.
MapsForge “motzt” ohne vernünftige Hintergrundinformationen und ignoriert die falschen Daten einfach.
u.s.w.
Aus diesem Grunde verstehe ich (inzwischen) die Frage von Klaus, ob man das Übel nicht endlich mal an der Wurzel anfassen kann.
Gibt es von euch dazu irgendwelche Ideen? Mir ist da Keepright und auch der OSMI durch den Kopf geschossen.
**Irgendwie fehlt da noch Feedback von den Anwendungen/Konvertern, der auch wirklich in die OSM-DB einfließt. **
Frage: Erstellt KeepRight eigentlich Reports, die der Betreuer uns zur Verfügung stellen kann? Eine Liste bringt oft mehr als “Geh mal in deine Ecke und räume da auf”
Ich mach mir mal Gedanken, was ich aus meiner DB rauskitzeln kann. Für die DB-Profies: Die Rohdaten stehen ja auch in der lokalen DB drin, nicht nur das von osm2pgsql bereinigte Zeug.
saubere Lösung: der OSM-DB-Server setzt Integritätsbedingungen durch: verweigert das Upload defekter Daten → der Leidensdruck “das Heulen und Zähneknirschen” ist bei den Erstellern der defekten Daten — bei denen, die auch was dran tun können — und nicht bei den Auswertern.
Banales Beispiel: bei type=multipolygon müssen alle Ways als Rolle inner oder outer tragen, die Outer müssen vorne stehen, und die Ways zu jedem Teilring fortlaufend in der Relation stehen. Ist für einen Editor einfach zu gewährleisten, und für den OSM-DB-Server mit Minimalaufwand nachzurechnen.
Wird aber nicht passieren. Schon weil der Id dafür angepasst werden müsste.
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
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.
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?
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:
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.
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?
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
… 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.
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.
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
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.
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.
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.
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.
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.
