Der Datenimport bricht allerdings mit der folgenden Meldung ab:
Nov 16, 2015 5:30:40 PM org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager waitForCompletion
SCHWERWIEGEND: Thread for task 1-read-xml failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to load current nodes.
at org.openstreetmap.osmosis.apidb.v0_6.ApidbWriter.populateCurrentNodes(ApidbWriter.java:928)
at org.openstreetmap.osmosis.apidb.v0_6.ApidbWriter.populateCurrentTables(ApidbWriter.java:1029)
at org.openstreetmap.osmosis.apidb.v0_6.ApidbWriter.complete(ApidbWriter.java:1055)
at org.openstreetmap.osmosis.xml.v0_6.XmlReader.run(XmlReader.java:110)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.postgresql.util.PSQLException: FEHLER: doppelter Schlüsselwert verletzt Unique-Constraint „current_nodes_pkey1“
Detail: Schlüssel „(id)=(100)“ existiert bereits.
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:417)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:410)
at org.openstreetmap.osmosis.apidb.v0_6.ApidbWriter.populateCurrentNodes(ApidbWriter.java:925)
… 4 more
Ich habe das extrahieren des Ausschnitts ja bereits mit der Option completeRelations=yes gemacht, damit es nicht zum Durchtrennen von Wegen kommt, die dann ungünstiger Weise zwei mal im Datenbestand vorhanden sein können. Kann mir jemand helfen, das Problem zu lösen?
Nö, das musst du schon selber machen
…
…
…
indem du keine API-DB aufsetzt sondern eine “normale” DB. Die Api-DB ist dafür da, per OSM-Api “gefüttert” zu werden und nicht geeignet, per OSMOSIS modifiziert zu werden. Zudem ist die zu nichts nütze ausser die Exporte für die “normalen” DBs zu erstellen…
Abhänging von dem, was du damit machen willst, entweder
ich bewundere Deine Kompetenz in Sachen Datenbank und freue mich immer wieder über Deine allgemeine Hilfsbereitschaft -
aber wäre es nicht sinnvoller, erst einmal
zu klären, ob er vielleicht eine Api-DB z. B. zum zukünftigen Auswerten der Historie benötigt,
bevor man ihm
vor den Latz knallt?
Aktuelle Fragestellung ist doch, warum tauchen beim Schreiben in eine leere API-DB doppelte ID auf?
D. h. es geht hier doch um die Vorbereitung der Eingangsdaten.
Die Empfehlung, ob er je nach gewünschter Aufgabenstellung mit einem anderen Schema nicht glücklicher wird, sollte m. E. erst erfolgen, wenn seine Aufgabenstellung klarer ist.
Ich bin mir ziemlich sicher, dass das mit dem API-Schema nicht der richtige Weg ist, habe aber meine Schlussfolgerungen wohl etwas zu konkret formuliert.
Ich kann bestätigen, dass dieser Fehler tatsächlich auftritt (habe es selber nachgestellt), obwohl im Eingabefile definitiv nur einmal ein Node mit der id=100 auftaucht. Woran es liegt - keine Ahnung.
(Anmerkung - ich würde mit --read-pbf und --write-pbf arbeiten statt mit XML-Dateien. Ausserdem, wie Wambacher sagt - vorher sicher sein, dass APIDB wirklich das ist, was man will.)
Ich habe eine Instanz der OSM-Website laufen. Das Datenbank-Schema wird durch die Rails-Migration bestimmt. Insofern gibt es da keine Alternativen. Mir ist bisher kein besserer Weg für die Erstbestückung der Datenbank mit osmosis über die api-db in den Sinn gekommen. Außerdem hatte ich bisher gar keine Probleme, zumal es nicht das erste Mal ist, daß ich eine lokale Datenbank über diesen Weg bestückt habe.
Hätte ich jetzt nicht gedacht. Nun denn, das ist ja das Allerfeinste vom Feinen.
Nicht nur du - allerdings muss ich mangels Erfahrung mit der api-db aussteigen. Frederik hat ja auch einige Probleme der selben Art entdeckt. Da er, bzw seine Firma GeoFabrik, diese Exporte ja zur Verfügung stellen, sehe ich das Ganze in guten Händen.
Als nächstes würde ich einfach mal einen anderen Extrakt (irgend was Kleines wie Bremen, Berlin oder Saarland) nehmen und das nochmals kurz anlaufen lassen, ohne auch nur ein Bit an den Daten zu ändern. Und natürlich PBF, wie Frederik vorgeschlagen hatte.
100 ist zufällig auch die Paketgröße beim API DB-Writer in osmosis: Link. Des weiteren gibt es dort einen Patch für ein One-Off-Problem: Link. Ist dieser Patch bei euch drin?
Spaßeshalber würde ich den Wert mal hoch oder runtersetzen, neu kompilieren und dann nochmal testen. Wird dann ein anderer Knoten angemeckert, ist ziemlich klar, dass die Paketverarbeitung kaputt ist.
Ich hatte ursprünglich das im Debian-Repository ausgelieferte osmosis mit der Version 0.40.1 verwendet. Nun habe ich die letzte stable 0.44.1 verwendet: siehe da, es hat geklappt! Der Hinweis von mmd hat mich drauf gebracht, mal die Version zu kontrollieren. Danke an mmd, aber auch an alle anderen!
