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

Die in der ersten Zeile aufgeführte Warnung sollte eigentlich gemäß folgendem Code bereits die Way id enthalten. Das sollte die Fehleranalyse vereinfachen.

http://code.google.com/p/mapsforge/source/browse/mapsforge-map-writer/src/main/java/org/mapsforge/map/writer/util/GeoUtils.java#350

Ausgegeben werden m.E. interne IDs … eine Korrelation mit OSM-IDs ist mir noch nicht gelungen.
Die vollständigen Meldungen sehen dann so aus:

WARNING: outer way of multi polygon is not a polygon, skipping it: 1202782060
WARNING: cannot create geometry for way with id: 1202781353

Gruß Klaus

Hallo Klaus

Am Besten wäre es, wenn der Mapwriter dazuschreiben würde, welches OSM-Objekt diese Fehlermeldung verursacht hat. Wenn das nicht geht, z.B. weil diese Information beim entsprechenden Verarbeitungsschritt nicht mehr vorhanden ist, dann hilft z.B. JOSM. Dort kannst du die Koordinaten von zwei Punkten als Bounding-Box zum Download angeben.

Wenn du nun zwei benachbarte Punkte auswählst, bekommst du eine BBox in der eine diagonale Linie liegt. Eine der Relationen, die diese Linie verwenden muss der Übeltäter sein. Du solltest dann die Relationen komplett runterladen, um sie dir anzusehen.
Wie du vermutest hast, geht es um die PLZ-Relation 1.443.899 (25881 Tating), die aus zwei getrennten Outer mit einem gemeinsamen Punkt besteht. Es ist der Punkt mit den Koordinaten 54.319278, 8.6900598 und der Objekt-ID 1.123.423.767. JOSM kommt mit der Überschneidung klar, MapWriter offensichtlich nicht.

Im konkreten Fall gibt es diesen gemeinsamen (Kreuzungs-)Punkt nur bei der Postleitzahl (25881 Tating). Die Admin-Grenzen sind jeweils disjunkt, überschneiden sich also nicht.

Ganz schön umständlich
Edbert (EvanE)

Das dürfte in der Tat der Fall sein. Augenscheinlich werden alle äußeren Wege (einer oder mehrere) zu einem neuen “TDWay” zusammengesetzt. Die TDWay-Objekte werden bei ihrer Erzeugung mit einer fortlaufenden Nummer versehen, die mit der Nummer des ursprünglichen Wegs nichts zu tun hat.

outerWay = new TDWay(++BaseTileBasedDataProcessor.this.maxWayID, relation.getLayer(),
                     relation.getName(), relation.getHouseNumber(), relation.getRef(), relation.getTags(),
                     shape, waynodes);

Man könnte wie folgt ansetzen: die TDWay-Klasse dahingehend erweitern, daß sie die Nummern der Wege speichert, aus denen sie erzeugt wird; im Fehlerfall diese ausgeben. Das wird toc-rox allerdings selbst machen müssen, da Mapsforge offenbar nicht mehr gepflegt wird.

Da ich an den Sourcen nichts ändern möchte, werde ich die Variante via JOSM verwenden. Danke für eure Hinweise.

Gruß Klaus

PS: Die Mapsforge-Entwickler arbeiten seit längerem an der Version 0.4, die dann auch ein (plattformunabhängiges) Swing-Interface beinhaltet.

Hätte da jemand Interesse sich der Problemfälle anzunehmen (mir wird das etwas zu viel). Aktuell (10.10.2013) ist z.B. der Wald um den Brocken (Harz) verloren gegangen.

Gruß Klaus

Beim letzten Build der Freizeitkarte-Android sind wieder einige Problem-Polygone aufgefallen. Vielleicht hat ja jemand Lust (und Zeit) sich das anzusehen …

What does Mapsforge cause to fail (von ChristianK):

  • intersections (crossing lines, touching lines, 2 points at the same position)
  • self backing up lines (loops) = extreme hard to find, a common issue with self snapping editors like Potlach and ID.
    Self backing up lines mean a line returning by 180° to its previous point = A-B-C-B-….

Die Daten finden sich hier: https://dl.dropboxusercontent.com/u/1677057/DebugFile.zip

Gruß Klaus

Hi,

ich hab mir mal den fünftletzten Eintrag (Way 158746691) angesehen:

Keines dieser Probleme liegt da vor.

Aber vielleicht liefert dieses MP 2125165 Hinweise. Es besteht aus 33 jeweils in sich geschlossenen “outer”, einem zweiteiligen “outer” und nur zwei “inner”.

Interessant ist jetzt, dass nur zwei der 34 “outer” in der Liste stehen: Die beiden sind in sich geschlossen und enthalten jeweils ein inner. Da wäre jetzt also die Frage, ob Mapsforge Probleme mit der Zuordnung von “inner” zu “outer” hat.

Weide

PS:

Ein zeitweiliges Hinzufügen von waterway=river lässt eine Prüfung durch JOSM zu.

Zum einfacheren Debuggen habe ich mit folgendem Befehl das jeweils erste Koordinatenpaar in einen OSM-Link umgewandelt:

for i in DebugOuterWay_*; do echo "http://www.osm.org/#map=18/"$(less "$i"| awk -F ", " '{print $2 }'| awk '{print $2"/"$1}'); done|nl -n rz| sed s/0000//g

Resultat:

Edit hat die vertauschten Koordinaten umgedreht. (Wenn jemand Hilfe wünscht, sollte er potentiellen Helfern mögliche Stolpersteine aus dem Weg räumen…)
Die zweite Edit hat Duplikate aufgeräumt und so die Anzahl der Links von 46 auf 22 reduziert.

PS: Zwischen 01 und 10 fand ich nur bei Nummer 6 ein Loch in einer Grenze. Den Rest überlasse ich anderen Arbeitswütigen.

Hi Klaus,

da es (bei dir) wohl immer noch Probleme dieser Art gibt: Welche Version setzt du aktuell ein und was hat sich geändert?

25881 Tating ist offensichtlich inzwischen sauber und sollte keine Probleme mehr machen.

Gruss
walter

Hi,

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.

Gruss
walter

edit: Tüpo

Nahmd,

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.

Gruß Wolf

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