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

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

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 :frowning:

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 :wink:

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

… oder bei kleinem Ring vielleicht highway=turning_loop?

Franz

Nein, das sind nicht alles genau erfasste Wendeschleifen; es gibt auch solche Konstrukte auf Parkplätzen oder in Siedlungen. Da hat man einfach eine Linie kreuz und quer gezeichnet (ich auch!)

https://www.openstreetmap.org/way/56695028

Man müsste den Way am Schnittpunkt aufbrechen, dann wäre alles “Simple”, d.h. OGC-Konform.

Ist aber bei geschätzten 70000 alleine bei uns eine Heidenarbeit; zudem kommen ständig neue “is_not_so_simple” Ways rein.

Gruss
Walter

ps: das schreit eigentlich nach einem Bot.

oder Wochenaufgabe XXL?

na, ich weiss nicht. Aber eventuell MapRoulette?

Wäre ganz reizvoll, falls wir Konsens haben sollten, aber das ist ja noch total offen.

Ich mach mich mal an’s Klassifizieren ran, damit wir die wirklich unwidersprochen defekten LS fixen können.

Gruss
walter

Auch wenn ich von dem ganzen Technik-Gedöns hier nichts kapiere:
Bei allem, was uns dem OGC-Standard näher bringt, bin ich dabei, wenn man mir zeigt, wo ich anpacken muss.

Da fälltt mir ein, dass ich nach OSMI mal wieder ein paar touching inner und so erledigen muss. Da muss ich das Kästchen malen und Adressen dran peppen mal etwas vernachlässigen. :sunglasses:

Moin,

Ich habe in dem Post vergeblich einen Link zu Listen mit den problematischen Objekten o.ä. gesucht, auf das man mit dem fröhlichen Reparieren anfagen kann.

Ist also nicht, dass es niemanden interessiert.

Bin noch nicht fertig mit den Programmen. Kann auch noch einige Zeit dauern, da mir eine wichtige Softwarekomponente in PostGis fehlt (Topology). Daher auch der Upgrade des Servers.

es wäre aber dennoch wichtig für mich zu wissen, ob diese Objekte überhaupt bei Mapsforge oder anderen Anwendungen ankommen oder ob die ignoriert werden. Dann kann ich die Dringlichkeit besser beurteilen.

Ich melde mich in einigen Tagen zu diesem Thema wieder.

Gruss
walter

Interesse schon, aber keine Zeit und nichts dazu zu sagen, drum siehst du auch kein Posting :wink:

Ich wäre für auftrennen in Ring und Anhängsel und den Ring nochmals auftrennen, sodass es kein Ring mehr ist.

Objekte vom Typ “Öse” werden sowohl mit Mapsforge (Android) als auch mkgmap (Garmin) korrekt angezeigt:

Gruß Klaus

Danke für die Info.

Dann werde ich die rausfiltern und ich stürze mich erstmal auf die anderen Linestrings - wenn ich damit fertig bin.

Gruss
walter

Kommen wir mit so etwas weiter?

FINE: constructed outer polygon in relation has no known tags: 3615429
Oct 09, 2014 4:39:57 PM org.mapsforge.map.writer.BaseTileBasedDataProcessor$RelationHandler execute
FINE: relation contains dangling ways which could not be merged to polygons: 32214
Oct 09, 2014 4:40:01 PM org.mapsforge.map.writer.util.JTSUtils repairInvalidPolygon
FINE: unable to repair invalid polygon
Oct 09, 2014 4:40:01 PM org.mapsforge.map.writer.util.GeoUtils mapWayToTiles
FINE: unable to create geometry from way: 253258437
Oct 09, 2014 4:40:02 PM org.mapsforge.map.writer.util.JTSUtils repairInvalidPolygon
FINE: unable to repair invalid polygon
Oct 09, 2014 4:40:02 PM org.mapsforge.map.writer.util.GeoUtils mapWayToTiles
FINE: unable to create geometry from way: 272940243
Oct 09, 2014 4:40:04 PM org.mapsforge.map.writer.util.JTSUtils repairInvalidPolygon
FINE: unable to repair invalid polygon
Oct 09, 2014 4:40:04 PM org.mapsforge.map.writer.util.GeoUtils mapWayToTiles
FINE: unable to create geometry from way: 190450852

Gruß Klaus

Bin nicht ganz sicher. habe mir die mal angesehen, die sind aber formal wohl ok.

Aber hallo!

der way 253258437 hat einige Nodes, die ganz nah beieinander liegen (zoom mal in josm ran). eventuell sind das Rundungsfehler bei fast gleichen Koordinaten.
bei way 272940243 das gleiche.

wenn dem so ist: in der Rel 32214 liegen einige Inner extrem nah beieinander. wenn er da rumrundet, gibt es eventuell probleme.

jau: auch der letzte way ist absolut korrekt, aber dennoch ein wenig “schräg”. das muß ein Rundungsproblem sein.

osm-lat/lon sind double precision - und mapwriter?

Gruss
walter

Hier mal die gesamte Liste für NRW … vielleicht läßt sich ja doch etwas “Verwertbares” finden:

https://dl.dropboxusercontent.com/u/1677057/Mapsforge-Probleme-NRW.txt

Gruß Klaus

Ich habe mir noch einige Rels mit Josm angesehen und kann wirklich nix Schlimmes finden. Josm-Validator ist auch happy.

Ich behaupte immer noch: Rundungsfehler. der mapwriter lügt sich was zusammen.

poste doch bitte mal den osmosis-script. prima idee, das so zu machen.

Gruss
walter

Hört sich ja doch nach etwas “Verwertbarem” an …

sh /home/kto/Freizeitkarte-Entwicklung-Android-1410c/tools/osmosis/bin/osmosis -v --read-pbf /home/kto/Freizeitkarte-Entwicklung-Android-1410c/work/Freizeitkarte_NORDRHEIN-WESTFALEN/Freizeitkarte_NORDRHEIN-WESTFALEN.transformed.osm.pbf --mapfile-writer file=/home/kto/Freizeitkarte-Entwicklung-Android-1410c/install/Freizeitkarte_NORDRHEIN-WESTFALEN/Freizeitkarte_NORDRHEIN-WESTFALEN.map bbox=‘50.31874,5.864417,52.5397 ,9.468311’ type=ram debug-file=false map-start-position=‘51.9613,7.6251’ map-start-zoom=12 tag-conf-file=/home/kto/Freizeitkarte-Entwicklung-Android-1410c/theme/tag_mapping.xml comment=“(c) Map: FZK project (free for private use); Map data: OpenStreetMap contributors; Contour data: U.S. Geological Survey or J. de Ferranti.”

java -Xmx24000M -Djava.io.tmpdir=/home/kto/Freizeitkarte-Entwicklung-Android-1410c/tmp -cp /home/kto/Freizeitkarte-Entwicklung-Android-1410c/tools/osmosis/lib/default/plexus-classworlds-2.4.jar -Dapp.home=/home/kto/Freizeitkarte-Entwicklung-Android-1410c/tools/osmosis -Dclassworlds.conf=/home/kto/Freizeitkarte-Entwicklung-Android-1410c/tools/osmosis/config/plexus.conf org.codehaus.classworlds.Launcher

Entscheidend ist dies: … osmosis -v …

Gruß Klaus

Nachtrag: Bin mir das jetzt nicht sicher … beantwortet das deine Frage?

Wie? nur Verify anschalten? Ich hab mal wieder viel zu viel erwartet.

Schaun mer mal.

edit: ja, ich bekomme die gleiche Fehlermeldung. ich teste mit Way 253258437, bitte nicht ändern.

hab mir mal eine lokale Kopie von dem Way gemacht, die ids verändert und alles rausgeschmissen, was nicht nötig ist:


<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.3.3 (31110 thorn-02.openstreetmap.org)" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">
 <bounds minlat="52.2897900" minlon="7.4183000" maxlat="52.2901000" maxlon="7.4187700"/>

 <node id="1" visible="true" version="1" changeset="19609120" timestamp="2013-12-23T22:31:37Z" user="hknk1" uid="118623" lat="52.2899751" lon="7.4184013"/>
 <node id="2" visible="true" version="1" changeset="19609120" timestamp="2013-12-23T22:31:37Z" user="hknk1" uid="118623" lat="52.2898922" lon="7.4183374"/>
 <node id="3" visible="true" version="1" changeset="19609120" timestamp="2013-12-23T22:31:37Z" user="hknk1" uid="118623" lat="52.2898601" lon="7.4184462"/>
 <node id="4" visible="true" version="1" changeset="19609120" timestamp="2013-12-23T22:31:37Z" user="hknk1" uid="118623" lat="52.2899432" lon="7.4185104"/>
 <node id="5" visible="true" version="1" changeset="19609120" timestamp="2013-12-23T22:31:37Z" user="hknk1" uid="118623" lat="52.2899751" lon="7.4184019"/>
 <node id="6" visible="true" version="1" changeset="19609120" timestamp="2013-12-23T22:31:37Z" user="hknk1" uid="118623" lat="52.2899760" lon="7.4184013"/>


 <way id="111111111" visible="true" version="1" changeset="19609120" timestamp="2013-12-23T22:32:00Z" user="hknk1" uid="118623">
  <nd ref="1"/>
  <nd ref="2"/>
  <nd ref="3"/>
  <nd ref="4"/>
  <nd ref="5"/>
  <nd ref="6"/>
  <nd ref="1"/>
  <tag k="building" v="yes"/>
 </way>

</osm>

Job:


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

$OSMOSIS -v 2 \
        --read-xml       file=253258437x4.osm \
	--mapfile-writer file=253258437x4.map

der fehler bleibt. bei -v 2 wird osmosis richtig geschwätzig.

Ratlose Grüße
walter