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

Hallo Klaus,

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

Antwort: Jain

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 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 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.

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

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

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

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

Gruss
walter

In dem Patch ist eine (zugegebenermaßen recht einfach gehaltene) Logik umgesetzt, um Ways als Polygone erkennen zu können. Vielleicht sollten sich die Autoren des Patches an Overpass Turbo bzw. osmtogeojson orientieren. Die Logik dort ist um einiges ausgefeilter. Kannst du den Link zu Overpass Turbo mal im Thread nennen und dort anregen, diesen Patch besser nochmal auf Basis der Wiki-Seite zu überarbeiten? Overpass API arbeitet übrigens mit denselben Regeln zur Area-Bildung.

Wie dieser Patch zum Problem mit einem outer-Way zusammenpasst, kann ich mangels Testmöglichkeit nicht unmittelbar nachvollziehen. Immerhin liegen zwischen Patch und eurer Version mehr als 1,5 Jahre und dort sind bestimmt noch viele andere Änderungen eingeflossen.

Edit: Quote Quelle war falsch.

Deine Bemühungen haben in der Tat zu einer lesbaren Karte geführt. Mit dem Locus-Default-Theme “Stadt” sieht die Karte so aus (Klick auf die Grafik vergrößert):

Fragen (damit wir reproduzierbare Testergebnisse erzielen):

• Welche osmosis-Version hast du verwendet?
• Welche Mapwriter-Version hast du verwendet (Link wäre gut)?
• Welche tag_mapping.xml hast du verwendet?

Gruß Klaus

Prima, freut mich
erstmal der 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

und hier der log:

Sep 27, 2014 12:18:54 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Osmosis Version 0.42-6-gf39a160-dirty
Sep 27, 2014 12:18:55 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Preparing pipeline.
Sep 27, 2014 12:18:56 PM org.mapsforge.map.writer.osmosis.MapFileWriterTask <init>
Information: mapfile-writer version: mapsforge-map-writer-0.4.0
Sep 27, 2014 12:18:56 PM org.mapsforge.map.writer.osmosis.MapFileWriterTask <init>
Information: mapfile format specification version: 3
Sep 27, 2014 12:18:56 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Launching pipeline execution.
Sep 27, 2014 12:18:56 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Pipeline executing, waiting for completion.
Sep 27, 2014 12:18:56 PM org.mapsforge.map.writer.osmosis.MapFileWriterTask process
Information: start reading data...
Sep 27, 2014 12:20:04 PM org.mapsforge.map.writer.osmosis.MapFileWriterTask complete
Information: completing read...
Sep 27, 2014 12:20:56 PM org.mapsforge.map.writer.osmosis.MapFileWriterTask complete
Information: start writing file...
Sep 27, 2014 12:20:59 PM org.mapsforge.map.writer.MapFileWriter writeSubfile
Information: written 100% of sub file for zoom interval index 0
Sep 27, 2014 12:20:59 PM org.mapsforge.map.writer.MapFileWriter writeSubfile
Information: written 10.0% of sub file for zoom interval index 1
Sep 27, 2014 12:21:00 PM org.mapsforge.map.writer.MapFileWriter writeSubfile
Information: written 20.0% of sub file for zoom interval index 1
...snip...
Sep 27, 2014 12:23:43 PM org.mapsforge.map.writer.MapFileWriter writeSubfile
Information: written 90.0% of sub file for zoom interval index 2
Sep 27, 2014 12:23:48 PM org.mapsforge.map.writer.MapFileWriter writeFile
Information: JTS Geometry cache hit rate: 1.0
Sep 27, 2014 12:23:48 PM org.mapsforge.map.writer.MapFileWriter writeFile
Information: JTS Geometry total load time: 0
Sep 27, 2014 12:23:48 PM org.mapsforge.map.writer.MapFileWriter writeFile
Information: Finished writing file.
Sep 27, 2014 12:23:48 PM org.mapsforge.map.writer.osmosis.MapFileWriterTask complete
Information: finished...
Sep 27, 2014 12:23:48 PM org.mapsforge.map.writer.osmosis.MapFileWriterTask complete
Information: estimated memory consumption: 3.463,2MB
Sep 27, 2014 12:23:48 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Pipeline complete.
Sep 27, 2014 12:23:48 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Total execution time: 293425 milliseconds.
walter@wno-server:~/osm/MapWriter$ 

osmosis 0.43 (latest) Es ist wirklich osmosis 0.43, der meldet sich immer noch mit 0.42!
mapWriter 0.4.0 (auch die neuste Version)
xml: Nix, zumindest hab ich keines angegeben. Und in der Directory gibt es auch keines.

Gruss
walter

ps: mit meinem Problem “Flat-File lesen” bin ich schon einen Schritt weiter - ich kann jetzt aus Postgresql eigene C-Programme aufrufen (das Programm zum Lesen der Flat-Files liegt mir in C vor) Jetzt muß ich “nun noch” eine Shared Library daraus machen. Und das bei meinen C-Kenntnissen, die gegen Null tendieren.

Danach habe ich alle OSM-Rohdaten online und könnte etwas QA machen.

Nachtrag: Sorry, die Links fehlten

https://code.google.com/p/mapsforge/wiki/GettingStartedMapWriter und da bei Plugin Installation: http://ci.mapsforge.org/job/master/lastSuccessfulBuild/artifact/mapsforge-map-writer/build/libs/mapsforge-map-writer-0.4.0-rc1.jar

+1

Wurde ja schon öfters angemahnt. Interessiert aber wohl nicht.
Muss ja jeder Sch… in die eine Datenbank. Könnte man dies nicht per relationale Datenbank trennen (bin da kein Spezialist)?
Z.B. 3D, jegliche Grenzen, außer Staatsgrenzen usw.

Wenn du damit “Switch2OGC” meinen solltest, gebe ich dir voll Recht. Aber ist hier OT.
Zumindest ist mir jetzt ein hübscher Name dafür eingefallen - mal sehen, ob es was bringt

Die OSM-DB ist eine Relationale Datenbank, da bringt dein Vorschlag nix. Was du wohl meintest sind Layer (*), die gleichartige Objekte leichter erreichbar machen können.
Dazu müsste das DB-Schema, die API, wohl alle Editoren und alle Auswertungen umgestellt werden - und da schreckt Jeder vor zurück - mich eingenommen.

Gruss
walter

*) Bitte nicht mit OpenLayers verwechseln; das ist eine total andere Baustelle.

THX

Meine Erkenntnisse aus den Kartenbuilds der letzten beiden Tage: Mapwriter (0.4 / 0.3.1) ist zur Erkennung von MP-Problemen nicht geeignet!

Bei den Kartenbuilds mit Mapwriter 0.4 wurden für Deutschland, Dänemark und Polen keine Probleme ausgewiesen. Beim Gegentest mit der Version 0.3.1 wurde für Dänemark und Polen entsprechend auch nichts gefunden. Versuchsweise habe ich mal zwei “inkorrekte” MPs angelegt. Eines mit sich kreuzenden Wegen, und eines mit einer Überschneidung von inner und outer:

Auch für diese beiden Objekte wurden von keiner Version irgendwelche Fehler ausgewiesen. Die Verarbeitung zwischen 0.4 und 0.3.1 weist aber Unterschiede auf. Mit Mapsforge 0.4 werden die Linien an der sich kreuzenden Stelle einfach abgeschnitten, und mit 0.3.1 wird das outer-Objekt komplett verworfen.

Für die MP-QS schlage ich deshalb vor, bestimmte Fehlerbilder zu definieren und dann gezielt danach zu suchen. Zwei Fehlerbilder sind eingangs ja schon erwähnt. Ich lasse die Objekte (in Münster) erstmal so, dann sollte das Prüfprogramm auf jeden Fall etwas finden.

Gruß Klaus

PS: Warum der Mapwriter keinerlei Hinweise zu problematischen MPs ausgibt, werde ich auf der Mapsforge-Mailingliste mal erfragen.

Nachtrag: Bei der Verarbeitung für Deutschland (Dauer 6 Stunden) gab es lediglich dieses Problem:
WARNING: JTS cannot clip way, not storing it in data file: 262414510
com.vividsolutions.jts.geom.TopologyException: found non-noded intersection between LINESTRING ( 6.628166 51.448208, 6.628167 51.448209 ) and LINESTRING ( 6.628174 51.448212, 6.628165636363682 51.44820781818184 ) [ (6.628166000000001, 51.448208, NaN) ]

Moin,

ich habe gestern angefangen, die Linestrings (nicht geschlossene Ways) auf formale Richtigkeit zu überprüfen. Verwendet habe ich dazu die PostGis-Funktion ST_IsSimple(way), die Objekte auf Einhaltung des OGC-Standards überprüft. (*)

Vorläufige Ergebnisse:

• Schlangenbad: 10
• Rheingau-Taunus-Kreis: 139
• Hessen: > 5000
• Deutschland: geschätzte 70000

Ich versuche, diese fehlerhaften Ways zu klassifizieren, bin aber noch nicht allzu weit gekommen. Hier einige Beispiele:

Typ “Sperm” kommt mit Abstand am häufigsten vor, die genaue Anzahl muß ich noch berechnen. Sind wohl sehr oft Wendeschleifen.

Typ “A-B-C-B-C-D” (ist in QGIS noch nicht leicht zu erkennen, wo der Fehler genau liegt)

Typ “Crossover”:

Diesen Linestring musste ich selber erzeugen, da es im RTK sonst keinen gab.

Jetzt versuche ich, diese bisher drei Typen automatisch voneinander zu unterscheiden, da sie ja unterschiedliche Behandlung brauchen. Weiterhin wird die Analyse auf geschlossene Ways erweitert werden.

Diese Objekte bitte noch nicht korrigieren, ich brauche die noch. Außerhalb vom RTK: “Feuer frei!”.

Gruss
walter

*) Alle OGC-konformen Objekte können von allen OGC-Anwendungen problemlos verarbeitet werden; viele - aber nicht alle - der anderen Objekte schafft leider auch OSM. Und da liegt mMn der “Hund begraben”. Es tut niemanden bei OSM weh, wenn Objekte “simple” werden, umgekehrt ist das außerhalb der OSM-Welt inzwischen untragbar.

Hi, wie ich an der überwältigen Resonanz erkenne, herrscht hier ein wahnsinniges Interesse, die OSM-Daten sauber zu bekommen

Nun denn,

ich habe inzwischen herausgefunden, wo die meisten defekten Multipolygone und Boundaries von osm2pgsql kommentarlos hingeschoben werden:

Sie landen in planet_osm_line, genau dort wo auch richtigerweise lineare Relationen (Routen!) hinkommen. Ist im Nachhinein auch fast logisch, da diese aufgrund des Fehlers eben keine geschlossene Linien (Polygone) sind und dafür zu den einfachen Linen geschoben werden.

Da musste erst mal drauf kommen.

Der type (multipolygon oder boundary) wird natürlich nicht übernommen

somit werden aus dem defekten MP #4077706 und der Boundary #4077792 jeweils zwei Linien mit -RELID als Key.

  osm_id  |                   tags                    |         st_summary          |                                                      st_astext                                                      
----------+-------------------------------------------+-----------------------------+---------------------------------------------------------------------------------------------------------------------
 -4077706 | "landuse"=>"farmland"                     | LineString[b] with 5 points | LINESTRING(8.0948198 50.1052632,8.0946501 50.1050122,8.0937544 50.1051622,8.0940938 50.1056641,8.0948858 50.105404)
 -4077706 | "landuse"=>"farmland"                     | LineString[b] with 2 points | LINESTRING(8.0951168 50.105372,8.0950272 50.105239)
 -4077792 | "boundary"=>"region", "admin_level"=>"17" | LineString[b] with 5 points | LINESTRING(8.0948198 50.1052632,8.0946501 50.1050122,8.0937544 50.1051622,8.0940938 50.1056641,8.0948858 50.105404)
 -4077792 | "boundary"=>"region", "admin_level"=>"17" | LineString[b] with 2 points | LINESTRING(8.0951168 50.105372,8.0950272 50.105239)
(4 rows)

Da kommt richtig Freude auf - aber zumindest sehe ich jetzt einen Weg, defekte Flächenrelationen in der DB zu finden.

Gruss
walter

ps: Gerade auf OSM-DEV eingetrudelt:

MapQuest has spent some work converting osm2pgsql to C++, and have put
up a pull request to merge our work back upstream to osm2pgsql.

In theory, this should have no real impacts for anyone simply using
osm2pgsql, as any of the dependencies required will be found on any
rendering server using Mapnik 2. The main impacts will be for
developers, and some speed increases.

There is also a new backend, the multi-backend. This will have more
long-term impact, but is a new feature, and will only be of use to those
running multiple servers, or requiring multiple rendering databases with
different style files.

More information can be found on the pull request at
https://github.com/openstreetmap/osm2pgsql/pull/187

Also mindestens einen Interessen gibt es. Aus Post #47 ist mir aber nicht klar geworden, wie ich im Moment unterstützen kann. Vielleicht ist es Anderen ähnlich ergangen …

Zum vorherigen Post (#48):
Du hast jetzt Linien (Überreste von kaputten MPs) und IDs … eine Zuordnung der Linien zu einem “kaputten” MP ist aufgrund der fehlenden type-Info (multipolygon oder boundary) aber nicht mehr möglich. Richtig? Besteht die Möglichkeit die type-Info aus den unveränderten OSM-Daten zu extrahieren und über die IDs wieder mit den Linien zu korrelieren?

Gruß Klaus

Hallo Walter,

saubere Daten: +1

Polygone… und deren Probleme…: da scheint ein wenig eine Resignation zu herrschen… mangels einer sauberen OGC-konformen Definition und vor allem Implementierung in OSM…

zu mindestens in OSMI angezeigte Geometrie- und Multipolygonfehler schaue ich von Zeit zu Zeit mir in Brandenburg mal an… muß mich mal wieder ransetzen…

Sven…

…der zur Zeit aber eher das Wetter nutzt und in seinem Urlaub Wanderwege mit Fahrrad erfasst…

ja, mit dir hatte ich schon gerechnet

Mit einem Vorschlag, was man mit diesen streng genommen falschen Linestrings machen soll.

Klar: a-b-c-b-c-d und Crossover sind falsch und müssen korrigiert werden. Bei “Sperm” bin ich mir nicht so sicher, was wir damit machen sollen:

• so lassen?
• auftrennen in Ring und Anhängsel?

Mich würde mal interessieren was andere Programme wie MapsForge damit machen. Da könntest du mal nachsehen ob die “Sperm” verworfen werden oder doch ankommen.

Wenn sich einige Mapper dafür interessieren, könnte ich die Auswertung mal über Deutschland laufen lassen und eine Liste erstellen. Allerdings sollte ich dann nach den drei Typen trennen.

tl;dr: ich möchte einfach wissen, ob ich hiermit weiter machen soll.

Nicht ganz: für type=boundary + boundary=xxx (also für alle Grenzen) bekomme ich alle notwendigen Information und kann die Daten einander zuordnen.

\i find_missing_mp_in_polygon.sql
   id    |    name     | admin_level | #member 
---------+-------------+-------------+---------
 2177213 | Yakouren    | 7           |       1
 3544929 | Los Mimbres | 9           |        
 3544931 | Los Tilos   | 9           |        
 2284187 | Los Cocos   | 8           |       1
 2284223 | La Cumbre   | 8           |       1
(5 rows)

Das sind die ersten 5 defekten Grenzen, die ich in den Rohdaten (planet_osm_rels) habe, aber bei den fertigen Polygonen (planet_osm_polygon) nicht finden kann.

Das ist mMn schon die halbe Miete.

Der Type-Tag wird leider gnadenlos verworfen und kommt somit noch nicht einmal in den “Rohdaten” (planet_osm_rels) an. Da muß ich noch drüber nachdenken.

Gruss
walter