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