SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

Communities Deutschland (Germany)
1

Ersteinmal ein liebes …
Hallo an die deutsche OSM Foren-Gemeinde,
ich werde mich wohl zukünftig etwas mehr mit OSM auseinandersetzen.
Mein Ziel ist es, ein eigenen Tiles-Server aufzusetzen inkl. Nominatim (oder Vergleichbares) für die Adresss-Geokodierung.

Begonnen habe ich mit der Anleitung SWITCH2OSM, für Ubuntu 12.04(.04 LTS) und sie verlief bis zu einem gewissen Punkt ziemlich reibungslos.
Hier oder da musste ich etwas nachschlagen und aktuallisieren/nachinstallieren.

Nun bin ich beim importieren der Daten angekommen…


Reading in file europe-latest.osm.pbf
Processing: Node(1205159k 160.1k/s), Way(148459 1.11k/s) Relation(42290 5.68/s)...

und … es kam zu einen Fehler, mit nachfolgenden Abbruch des Import, grummel.


osm2pgsql: PolygonBuilder.cpp:261: geos::geograph::EdgeRing* geos::operation::overlay::PolygonBuilder::findShell(std::veector<geos::operation::overlay::MinimalEdgeRing*>*): Assertion 'shellCount <= 1' failed

Meine Kenntnisse in dem Bezug auf Linux sind etwas veraltet, ich war daher aucht recht überrascht wie gut bis jetzt alles verlief.
Laut google ist dieses ein bekannter BUG der bereits behoben wurde, nur wie komme ich an die aktuelle Version?
Bei einigen Benutzer lass ich etwas von src-Code runterladen und selbst kompilieren, sicher bin ich mir aber nicht.
Im Laufe der Installation hatte ich ja bereits Pakete rungeladen und kompiliert und anschließend installiert, das Ganze aber nur nach Anleitung.
Dieser Fehler bringt mich aber fast schon zu Verzweiflung.

Über jeglich Unterstützung würde ich mich natürlich freuen…

2

falls das wirklich an osm2pgsql liegen sollte: selber maken, siehe https://wiki.openstreetmap.org/wiki/Osm2pgsql#From_source

hab ich auch gemacht, da ich einige kleine Änderungen eingebaut habe. Musst beim Installieren nur darauf achten, dass das bereits installierte osm2pgsql auch wirklich ersetzt wird (machte bei mir am Anfang Problemchen). Oder vorher das Paket löschen.

Gruss
walter

3

Hallo Walter, vorab, danke für deine Unterstützung…

Es liegt nicht direkt an osm2pgsql, eher an den verwendeten Bibliotheken von postgis, siehe u.a. hier: http://gis.stackexchange.com/questions/74382/problem-with-loading-osm-planet-into-postgresql

Ich habe den dort beschrieben Weg mir mal angeschaut, im Grunde gleicht dieses ja dem Weg auf switch2osm. Lediglich das Kompilieren von osm2pqsql ist hier ein gesonderter Part.
Ärgerlicherweise tritt dieser Fehler serh spät, am Ende des Datenimports/-generierung auf. Das Ergebnis eine Veränderung an der Installation ist erst “Tage später” erkennbar.
Ich komme mir vor wie ein Labroant, mit unendlich viel Zeit.

Aus diesem Grund werde ich mich ersteinmal mit der Perfomance aus einandersetzen, das ganze System ist auf eine Virtueller-PC mit einer Zuteilung von 2 Quad-Core-CPUs a 3.4 GHz und 4 GB Arbeitsspeicher.
Der Festplattenspeicher liegt in einem Hochgeschwindigkeits-(…?!) SAN. Starten kann ich osm2pqsql nur im “–slim” Modus, ich drifte aber ab, sollte ich vieleicht ein neuen Thread aufmachen … ? :slight_smile:

Gruß…
Erik

4

Wenn du meinst - mir sieht das ein wenig spekulativ aus. Nun denn, hier ist meine Version:

Ganz normal über die Paketverwaltung (synaptic oder apt-get) installiert.

Mein letzter Import des Full-Planets war am 15.10.2013 unter ubuntu 13.04 oder 13.10 und lief - natürlich - reibungslos.


osm2pgsql --verbose -c -s --style wno.style -d osm -l -U postgres \
          --hstore-all --hstore-add-index \
          --number-processes 8 \
          --keep-coastlines \
          -G \
          -C 4000 \
          /data4/import/tmp/planet-131009.osm.bz2

Gruss
walter

Ach ja: Muß es am Anfang gleich der Full Planet sein?

5

Hallo Walter,
ich muss mich erst wieder einlebe in die Linux-Welt (inkl. OSM), von daher ist so manches von mir noch spekulativ…sorry.


postgres@osm-server:~$ dpkg -l | grep libgeos
ii  libgeos-3.2.2                            3.2.2-3ubuntu1                    Geometry engine for Geographic Information Systems - C++ Library
ii  libgeos-c1                               3.2.2-3ubuntu1                    Geometry engine for Geographic Information Systems - C Library
ii  libgeos-dev                              3.2.2-3ubuntu1                    Geometry engine for GIS - Development files
postgres@osm-server:~$

Deine 3.3.x Version beinhaltet laut einem gestern gefundenem Posting (wo auch immer das war) die BUG Korrektur.
Ich gehe mal daran und werde versuchen die Kernkomponenten zu vergleichen, was habe ich und was ist aktuell.
Entsprechend werde ich dann Versuchen die aktuelle Versionden über apt-get zu installieren.
Mal sehen ob ich das mit meinen (noch) veralteten Kenntnissen hinbekommen, oder ob ich die src herunterlade und neugeneriere (kompilieren/konfigurieren/installieren).

Es sah alles so einfach aus :slight_smile:

6

Ich importiere … europe-latest.osm.pbf.

7

jau, wer lesen kann (und das auch tut), ist echt im Vorteil. :wink:

8

Linux ist einfach - nur will das kein Windows-Anwender glauben.

apt-get install libgeos-dev sollte es bringen.

eventuell noch vorher?/nachher?:

apt-get update
apt-get upgrade

Falls er fragt, ob das OS (12.04 → 14.04) hochgezogen werden soll, erst mal verneinen.

Gruss
walter

9 
root@osm-server:~# apt-get install libgeos-dev
....
Die folgenden zusätzlichen Pakete werden installiert:
  libgeos-3.2.2 libgeos-c1
Vorgeschlagene Pakete:
  libgdal-doc
Die folgenden NEUEN Pakete werden installiert:
  libgeos-3.2.2 libgeos-c1 libgeos-dev
0 aktualisiert, 3 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
...

Und wieder nur die 3.2.2 Version, irgendwie schaue ich nicht in das richtige Paket-Repository.
(siehe auch http://packages.ubuntu.com/precise/libgeos-dev)

Werde mal weiter suchen, nach …: install precise libgeos-dev 3.3.3 src

10

Precise (12.04) hat nur die alte 3.2.2er Version:
http://packages.ubuntu.com/search?suite=precise&searchon=names&keywords=libgeos-dev
Da brauchst du ein PPA, ich habe gerade dieses gefunden, weiß aber nicht ob es das richtige ist. Immerhin hat es das gewünschte Paket:
https://pgdgbuild.dus.dg-i.net/repos/apt/

11

So gefunden, ich habe die /etc/apt/source.list erweitert um …

deb http://de.archive.ubuntu.com/ubuntu/ saucy universe
deb-src http://de.archive.ubuntu.com/ubuntu/  saucy universe
deb http://de.archive.ubuntu.com/ubuntu/ saucy-updates universe
deb-src http://de.archive.ubuntu.com/ubuntu/ saucy-updates universe

Dann das alte Paket entfernt und das neue Paket hinzugefügt …


sudo apt-get purge --auto-remove libgeos-dev
apt-get install libgeos++-dev

ich glaube das war es (wenn ich mich recht erinnere).

Walter, ich bin jetzt auf deinem Stand …


ii  libgeos++-dev                            3.3.3-1.1ubuntu1                  Geometry engine for GIS - C++ development files
ii  libgeos-3.3.3                            3.3.3-1.1ubuntu1                  Geometry engine for Geographic Information Systems - C++ Library
ii  libgeos-c1                               3.3.3-1.1ubuntu1                  Geometry engine for Geographic Information Systems - C Library
ii  libgeos-dev                              3.3.3-1.1ubuntu1                  Geometry engine for GIS - Development files

Dann wurde osm2pgsql nochmal entfernt und neu installiert, lt. switch2osm (10.04).
Der VM wurde mehr Speicher zugewiesen: 16 GB

Der erneute Import wurde wie folgt gestartet…

sudo nice -n -10 sudo -u $USER osm2pgsql -d gis -C 20000 --number-processes 8 europe-latest.osm.pbf

Die Node (1205159k 1274.0k/s) haben den kompletten Speicher gefressen, Way(aktuell 9665k von 148459) und die Relation werden nun über den Swap (6 GB) bedient.
Das sieht aber nicht gut aus … 3108 von 5117 MB sind nur noch frei, grummel…
Ich habe angenommen, das nur die Nodes im Speicher gehalten werden, der Rest wird berechnet und gespeichert??? Fehlannahme…
Mal sehen ob ich noch irgendwo weitere 16 GB herbekomme…

12

sieht gut aus.

20 GB Cache bei 16 GB Vmem? nimm 10000

nicht nötig:

füge noch diese Option hinzu: –flat-nodes … mit beliebigen Filenamen. Dann legt osm2pgsql die Nodes nicht in der DB ab und performiert erheblich besser.

Achtung: Das File ist wichtig und wird später bei jedem Update der DB gebraucht. Nicht löschen! Beim Full-Planet ist das Teil 22 GB groß, Europa dürfte “etwas” kleiner sein. ~10 GB?

Gib den restlichen Speicher besser an Postgresql (in postgresql.conf anpassen, ist aber nicht so einfach); SSD würden auch viel bringen.

Mein Planet-Import hat übrigens 5 Tage gedauert (8-Core 4 GHz, 32 GB Mem, 500 GB Disk für die OSM-DB)

Gruss
walter

13

Noe.

Der Hinweis auf switch2osm.org ist nicht aus Blödelei da, es ist sogar so das aktuell (da wir ja mehr Nodes haben als die Anleitung geschrieben wurde) man deutlich mehr nehmen sollte (um den Jahreswechsel war das 18000). Natürlich fängt die Maschine bei zu wenig Memory an zu swappen (und deshalb sollte genügend Swap konfiguriert sein), dass ist aber immer noch deutlich schneller als ein zu kleiner Nodecache.

PS: 5 Tage ist deutlich zu lang, siehe z.B. http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks#Hetzner_:Root_Server_EX_4S.28stock.29

14

Fehlt hier die --slim option? Ohne slim versucht osm2pgsql den gesamten Import im ram durchzufuehren. Das ist bei den heutigen Planet groessen ohne gigantische Mengen an RAM nicht mehr moeglich. Wenn man nicht gerade nur ein Extrakt der Groesse Luxenburgs verarbeitet, wuerde ich generell die --slim option empfehlen. Wenn man die Daten per diff aktualisieren will, benoetigt man diese Option ohnehin. Und wenn man das nicht will, wuerde ich die Optionen “–slim --drop” vorschlagen.

15

Die Datei ist immer gleich gross, unabhaengig was man importiert. Das heist selbst wenn man nur Luxenburg importiert wird sie mindestens 21GB gross sein. Die Groesse berechnet sich aus der hoechsten node ID * 8 Byte. Derzeit ist die hoechste NodeID bei ca. 2855851760, was eben 21788MB ergibt.

Flat-nodes berechnet die Position in der Datei einer Node anhand ihrer NodeID. Damit spart man sich jedwedige indexierung in der Datei und kann ein lookup in O(1) durchfuehren. Allerdings basiert das darauf das fast alle node ids auch tatsaechlich benoetigt werden. Im full planet sind ca 80% der node ids auch aktuell gueltige nodes. Bei kleinen extrakten wird --flat-nodes hingegen extrem ineffizient (und langsam) und ist somit nur bei full planet imports, bzw sehr grossen Extrakten zu empfehlen, dort wiederum ist es deutlich besser. Ab wann sich --flat-nodes genau lohnt weis ich nicht, aber europa.osm.pbf duerfte wohl von der groesse her in etwa an der Grenze liegen. Da nehmen sich die beiden Optionen wahrscheinlich dann nicht uebermaessig viel.

16

Kann auch 3 Tage gewesen sein aber mit allen Drum und Dran hat das mehrere Tage gedauert. Hatte auch noch keine SSD.
Dann auch noch den ganzen Hstore mit drin und einige wichtige Indices - wollte halt nur nicht die Erwartungen zu hoch schrauben.

17

Wo du recht hast, hast du recht: Für alle Imports gleich, derzeit

 
ls -la /data5/osm/db/planet2/nodes.flat
-rw------- 1 walter walter 22845317128 Mai 13 18:38 /data5/osm/db/planet2/nodes.flat
ls -lah /data5/osm/db/planet2/*
-rw------- 1 walter walter 22G Mai 13 18:38 /data5/osm/db/planet2/nodes.flat

und das mit dem Slim hab ich auch übersehen.

Gruss
walter

18

Kurze Rückmeldung und vielen Dank an @amm, @Theodin und @SimonPoole das Ihr euch beteiligt.

Etwas Hintergrundwissen, in dem Bezug auf die Einrichtung der Hardwareleistungsmerkmale der VM habe ich nur ein eingeschränkenten Zugriff.
Mir stehen zur Zeit 16 GB RAM und 6 GB SWAP zur Verfügung, ggf. erweitere ich über ein SWAP File.

…

Kommen wir zum jetzigen Stand:

Start gestern in der Früh (bei dem Stand “Relation (42000 …)” bin ich gestern in froher Erwartung in den den Feierabend gegangen):

osm2pgsql --flat-nodes /osm/planet/europe-altest.flat -r pbf --slim -C 10000 --number-processes 4 /osm/planet/europe-latest.osm.pbf

Für mich zum besseren Verständnis unterteile ich die Verarbeitung von osm2pgsql in zwei (scheinbare) Phasen, die erste Phase endet mit der Auflistung/Statistik von Node/Way/Relation.
Bis dahin hat der Prozess das komplette RAM (16GB) und etwas SWAP verschlungen, soweit so gut…

Heute Morgen sah ich dann das Ergebnis …

Processing: Node(1205159k 1087.7k/s) Way(148459k 7.98k/s) Relation(1840780 43.93/s)  parse time: 61615s

Node stats: total(1205159819), max(2840683400) in 1108s
Way stats: total(148459463), max(279890005) in 18601s
Relation stats: total(1840788), max(3722607) in 41906s
Committing transaction for planet_osm_point
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Committing transaction for planet_osm_roads

Plus …


Going over pending ways...
Maximum node in persistent node cache: 2841640959
        108569071 ways are pending

Using 4 helper-processes
WARNING: Failed to fork helper process 1: Cannot allocate memory. Trying to recover.
WARNING: Failed to fork helper process 2: Cannot allocate memory. Trying to recover.
WARNING: Failed to fork helper process 3: Cannot allocate memory. Trying to recover.
Mid: loading persistent node cache from /osm/planet/europe-altest.flat
Maximum node in persistent node cache: 2841640959
Helper process 0 out of 1 initialised
processing way (27085k) at 1.28k/s (done 0 of 1)

Dann in der zweiten Phase hat der Prozess, weiteren Swap Speicher angefordert und fiel dabei irgendwann auf die Nase, zur Zeit leigt der SWAP bei 2558 von 5117 MB.
Anscheint beginnt er erneut mit der Weg- und Relationsberechnung und wird mir Sicherheit wieder beim Schreiben in die die Datenbank (?) abbrechen?!
Gibt es irgenwo eine tiefergreifende Erläuterung zu dem Verarbeitungsablauf von osm2pgsql?

Ich sehe es schon kommen, das ich bei meinem VMWare Admin weitere 16 GB und mehr SWAP (HD-) Speicher erflehen muss.
Selbstverständlich muss ich den SWAP dann auch noch einrichten, “back to the roots” kann ich da nur sagen…super!

Edit: unwichtiges rausgenommen, Text etwas klarer,11:03 15.05.2014

19

außer source-code nicht viel.

laß es. dreh den Cache auf 2000 runter, der wird bei --flat-nodes eh nicht gebraucht.

soweit mir langsam dämmert, legt er ohne flat-nodes alle Nodes im Memory-Cache ab - und das sind bei Europa (*) oder gar Full Planet verdammt viele. Dazu kommt wohl ein Design-Bug, daß die Helper genau soviel Memory bekommen sollen, obwohl sie den garnicht benötigen (?). Da nun alle Helper-Prozesse ebenfalls vollen Zugriff auf alle im Memory-Cache stehenden Nodes brauchen, wird bei deren Start eine Memory-Kopie gemacht - und dann knallt es halt.

Es ist wohl so: Kleiner Import (maximal ein Land) ohne --flat-nodes und mit ausreichend Cache / großer Import mit --flat-nodes und kleinem Cache.

gruss
walter

*) Europa alleine machte 2013 ca 50% vom Planeten aus.

EDIT: Cache und Helper überdacht.

20

Ausser der Code hat sich sehr geändert in letzter Zeit stimmt das nicht. Die Idee hinter den node cache im File war, a) weniger Platzverbrauch (braucht die DB Tabellen nicht mehr) b) schnelleren Zugriff beim Updaten.