OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#576 2018-04-16 21:48:28

derstefan
Member
From: OpenTopoMap
Registered: 2010-03-28
Posts: 470
Website

Re: OpenTopoMap

Mit folgendem Befehl wurde die Datenbank importiert, nachdem der Tablespace "hdd" zuvor auf eine HDD gelegt wurde:

osm2pgsql --slim -d gis -C 12000 --tablespace-slim-data hdd --tablespace-slim-index hdd --number-processes 10 --flat-nodes /mnt/database/flat-nodes/gis-flat-nodes.bin --style ~/OpenTopoMap/mapnik/osm2pgsql/opentopomap.style ~/data/planet-latest.osm.pbf

Dadurch liegen nur noch ca. 280 GB auf der SDD, die Slim-Indices auf der HDD benötigen dafür 340 GB! Mit dem Parameter "drop" (und Slim-Index-Tablespace unverändert auf SDD) bricht der Import ab. Das lässt darauf schließen, dass die Indices erst vollständig angelegt werden müssen, um dann wieder gelöscht zu werden. Weil HDD-Platz nicht Mangelware ist, haben wir bisher auf "drop" verzichtet.

Natürlich würden wir gerne laufende Updates einspielen! Wir können es aber nicht mehr. Für mich ist das halb so schlimm - allerdings bekomme ich ständig E-Mail-Nachfragen, wann denn endlich wieder aktualisiert wird... hmm

Offline

#577 2018-04-17 00:19:41

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 15,097
Website

Re: OpenTopoMap

derstefan wrote:

Natürlich würden wir gerne laufende Updates einspielen! Wir können es aber nicht mehr.

Das Problem hab ich noch nicht richtig verstanden. Warum könnt ihr das nicht?

Und warum überhaupt die Slims erzeugen, wenn ihr die eh nicht verwenden wollt?

Macht entweder einen Import ohne Slim - dann müsst ihr den nur immer wieder machen. Der dauert beim Full-Planet allerdings Tage und zu der Zeit ist die DB offline.

Oder ihr macht einen Differential Update, dafür braucht ihr aber den Platz für die Slim-Files. Meiner Erfahrung nach könnt ihr den allerdings vergessen wenn die Slim-Files auf HDD liegen.

ym2c
walter

Offline

#578 2018-04-17 06:45:13

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 1,801
Website

Re: OpenTopoMap

derstefan wrote:

Dadurch liegen nur noch ca. 280 GB auf der SDD, die Slim-Indices auf der HDD benötigen dafür 340 GB!

Bei mir belegt die DB (keine Slim-Indizes) für den Europaextrakt (Ausgangsdaten 20.4 GB) circa 130 GB. Die Einlesedauer beträgt 20 Stunden. Eingelesen wird mit diesem Kommando:

nohup ./osm2pgsql --username postgres --multi-geometry --hstore --slim --drop --create --cache 32000 --number-processes 8 --database osmtest --style openstreetmap-carto.style --tag-transform-script openstreetmap-carto.lua europe-latest.osm.pbf 1>load_osmtest.out 2>&1 &

Es wird auf der HDD eine temporäre DB erzeugt. Erst wenn der Import erfolgreich abgeschlossen ist, erfolgt ein Rename auf die produktive DB:

psql --username=postgres --command='ALTER DATABASE osmcarto4 RENAME TO osmcarto4old;'
psql --username=postgres --command='ALTER DATABASE osmtest RENAME TO osmcarto4;'

Eure DB ohne Slim-Indizes hat eine Größe von 280 GB. Bei einer Ausgangsdatenmenge von circa 40 GB für den Full-Planet korreliert das eigentlich ganz gut.

Ich werde den Full-Planet-Import mal ausprobieren (geschätzte Einlesedauer: 48 Stunden). Ich berichte dann.

PS: Bezüglich des Absturzes bei eurem Import mit der drop-Option, könntet ihr ein GitHub-Ticket eröffnen. Und hier hat der Entwickler (Paul Norman) auch etwas zum Planet-Import veröffentlicht: http://paulnorman.ca/blog/2018/01/loading-the-data/

Offline

#579 2018-04-17 09:09:36

Chrysopras
Member
From: Germany
Registered: 2015-04-01
Posts: 1,186

Re: OpenTopoMap

derstefan wrote:

Natürlich würden wir gerne laufende Updates einspielen! Wir können es aber nicht mehr. Für mich ist das halb so schlimm - allerdings bekomme ich ständig E-Mail-Nachfragen, wann denn endlich wieder aktualisiert wird... hmm

Um Euch den Stress mit den ständigen Nachfragen zu ersparen:

Wäre es evtl. möglich, zu mehr oder minder regelmäßigen Updates überzugehen, z.B. „gegen Ende jedes Quartals“ oder so? Auf ein paar Tage hin und her käme es ja nicht an. Dann könntet Ihr das auf der Website so schreiben und auf etwaige drängelnde Nachfragen einfach mit einem Formbrief antworten. wink Der Vorteil wäre auch, dass wir als Mapper und/oder Nutzer Eurer Karte uns das leicht merken könnten und schon wüssten, wann es sich wieder lohnt, die eigenen Änderungen mit OTM zu kontrollieren …

Offline

#580 2018-04-17 23:44:42

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 39

Re: OpenTopoMap

Ich habe zwei Probleme mit dem neuen Sportplatz-Rendering:

* auf meinem öffentlichen Server sind alle Sportplätze im 90° gedreht:

Siehe zB. topo1.png

Sven Geggus erwähnte auf der FOSSGIS in Bonn ein ähnliches Problem, und dass es an einer PostGIS-Änderung liegen könnte.

Versionen auf dieser Maschine sind:

gis=# select version();
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 9.6.6 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406, 64-bit
(1 row)

gis=# SELECT PostGIS_full_version();
                                                                         postgis_full_version                                                                         
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 POSTGIS="2.3.1 r15264" GEOS="3.5.1-CAPI-1.9.1 r4246" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.1.2, released 2016/10/24" LIBXML="2.9.4" LIBJSON="0.12.1" RASTER
(1 row)

* auf meiner Testinstanz bekomme ich statt dessen einen Datenbank-Fehler:

RuntimeError: Postgis Plugin: ERROR:  lwpoly_from_lwlines: shell must be closed
CONTEXT:  SQL statement "SELECT osm_id FROM planet_osm_line
              WHERE planet_osm_line.way && ST_EXPAND(myway,trackdist/labelsizefactor) 
              AND   leisure='track' 
              AND   ST_ISCLOSED(planet_osm_line.way)
              AND   ST_CONTAINS(ST_MakePolygon(planet_osm_line.way),myway)
              LIMIT 1"
PL/pgSQL function getpitchicon(geometry,text) line 114 at assignment
in executeQuery Full sql was: 'SELECT ST_AsBinary("way") AS geom,"angle","icon","labelsizefactor","pitch_area" FROM (SELECT way,(pitchdata).icon AS icon,(pitchdata).angle AS angle,(pitchdata).pitch_area AS pitch_area,(pitchdata).labelsizefactor AS labelsizefactor FROM (select way,getpitchicon(way,sport) as pitchdata FROM planet_osm_polygon WHERE leisure='pitch' AND (building IS NULL OR building = 'no')) AS pitches) AS symbols WHERE "way" && ST_SetSRID('BOX3D(947175.1092843327 6805427.473887814,948748.8907156673 6806651.526112186)'::box3d, 3857)'

DB-Versionen hier:

gis=# select version();
                                                    version                                                    
---------------------------------------------------------------------------------------------------------------
 PostgreSQL 10.3 (Ubuntu 10.3-1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.3.0-5ubuntu1) 7.3.0, 64-bit
(1 row)

gis=# select postgis_full_version();
                                                                                           postgis_full_version                                                                                           
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 POSTGIS="2.4.3 r16312" PGSQL="100" GEOS="3.6.2-CAPI-1.10.2 4d2925d6" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.2.3, released 2017/11/20" LIBXML="2.9.4" LIBJSON="0.12.1" LIBPROTOBUF="1.2.1" RASTER
(1 row)

Offline

#581 2018-04-17 23:56:33

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 39

Re: OpenTopoMap

Hatte auf dem öffentlichen Server pitchicon.sql wohl noch nicht neu eingespielt ... jetzt bekomme ich auch dort den "shell must be closed" Fehler ...

Offline

#582 2018-04-18 00:25:51

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 39

Re: OpenTopoMap

Weiteres Detail: ich benutze nicht einen osm2pgsql Import mit opentopomap.style, sondern Svens hstore-only Variante des OsmCarto v4.x Schemas mit eintsprecheden Views die das v4 Schema emulieren.

Offline

#583 2018-04-18 07:24:36

maxbe
Member
Registered: 2010-01-19
Posts: 2,907
Website

Re: OpenTopoMap

Hartmut Holzgraefe wrote:

* auf meinem öffentlichen Server sind alle Sportplätze im 90° gedreht:

Jo, das Problem haben wir auch. Auf jedem Rechner sind die blöden Plätze gedreht. Wir vermuten auch ein Problem der PosGIS-Version und lassen uns jedes Mal überraschen, wie es heute ist. Die Zeile 79 wird dann passend gemacht: "angle:=90+(a12+a23+90)/2;" oder "angle:=(a12+a23+90)/2;"

Hartmut Holzgraefe wrote:

lwpoly_from_lwlines: shell must be closed

Mal suchen, wir hatten schon mal Probleme mit besonders kreativ gestalteten Plätzen. Vielleicht gibts noch Geometrien, für die wir noch kein Gegengift haben wink

Grüße
Max

Offline

#584 2018-04-18 08:43:33

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 39

Re: OpenTopoMap

Mal suchen, wir hatten schon mal Probleme mit besonders kreativ gestalteten Plätzen. Vielleicht gibts noch Geometrien, für die wir noch kein Gegengift haben wink

Ich hab das Problem leider auch bei einfachen Plätzen wie diesem, und der nächste

  leisure=track

ist da über einen Kilometer entfernt.

Ich fürchte gerade so etwas wie dass da die PostgreSQL Evaluations-Reihenfolge durcheinandergekommen ist und

  ST_CONTAINTS(ST_MakePolygon(...))

*vor* ST_ISCLOSED(...) und leisure='track' ausgewertet wird.


https://opentopomap.org/#map=16/52.13705/8.50973

Offline

#585 2018-04-18 08:52:33

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 39

Re: OpenTopoMap

Und um es wirklich abstrus zu machen: in dem letzten Beispiel funktioniert die SELECT-Abfrage aus der Fehlermeldung wunderbar wenn ich sie von Hand ausführe:

gis=# SELECT ST_AsBinary("way") AS geom,"angle","icon","labelsizefactor","pitch_area" FROM (SELECT way,(pitchdata).icon AS icon,(pitchdata).angle AS angle,(pitchdata).pitch_area AS pitch_area,(pitchdata).labelsizefactor AS labelsizefactor FROM (select way,getpitchicon(way,sport) as pitchdata FROM planet_osm_polygon WHERE leisure='pitch' AND (building IS NULL OR building = 'no')) AS pitches) AS symbols WHERE "way" && ST_SetSRID('BOX3D(946391.7746615087 6824165.102514506,948298.2253384913 6825647.897485494)'::box3d, 3857);

geom|angle|icon|labelsizefactor|pitch_area
\x010300000001000000060000004624d924afe72c414f0677bff8085a41ae35e001d1e72c41000baaafe5085a412f10c3fef9e72c41ee31fb9ece085a41a9148696e3e82c41fa0cd51ad5085a418512e9b698e82c41e9e5823cff085a414624d924afe72c414f0677bff8085a41|257.479093497687|soccer|1.62922547423053|7762.78037903196
(1 row)

Offline

#586 2018-04-18 09:07:54

maxbe
Member
Registered: 2010-01-19
Posts: 2,907
Website

Re: OpenTopoMap

Hartmut Holzgraefe wrote:

Ich fürchte gerade so etwas wie dass da die PostgreSQL Evaluations-Reihenfolge durcheinandergekommen ist

Könnte passen. Ich hab nicht dran gedacht, dass Postgresql "A AND B" auch als "B AND A" auswerten könnte, wenns grad Lust dazu hat. Mal sehn, wie man das erzwingt oder anderweitig rausbekommt, ob ein Fussballplatz eine (vielleicht geschlossene) Rennbahn aussen rum hat.

Offline

#587 2018-04-18 09:37:39

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 39

Re: OpenTopoMap

Ich vermute mal lazy evaluation ist da nicht unser Freund:

"The order of evaluation of subexpressions is not defined. In particular, the inputs of an operator or function are not necessarily evaluated left-to-right or in any other fixed order."

"Note that this is not the same as the left-to-right "short-circuiting" of Boolean operators that is found in some programming languages."

https://www.postgresql.org/docs/9.6/sta … PRESS-EVAL

Klärt immer noch nicht warum das mal funktioniert (bei euch, bei mir von Hand) und mal nicht (bei mir aus Mapnik heraus), aber ist immerhin schon mal eine Idee ...

Offline

#588 2018-04-18 11:12:50

maxbe
Member
Registered: 2010-01-19
Posts: 2,907
Website

Re: OpenTopoMap

Kennt sich jemand mit Postgresql aus?

Könnte man diese hier:

 SELECT osm_id FROM planet_osm_line
              WHERE planet_osm_line.way && ST_EXPAND(myway,trackdist/labelsizefactor) 
              AND   leisure='track' 
              AND   ST_ISCLOSED(planet_osm_line.way)
              AND   ST_CONTAINS(ST_MakePolygon(planet_osm_line.way),myway)
              LIMIT 1

durch das hier ersetzen:

 SELECT osm_id FROM planet_osm_line
              WHERE planet_osm_line.way && ST_EXPAND(myway,trackdist/labelsizefactor)
              AND   leisure='track'
              AND CASE WHEN  ST_ISCLOSED(planet_osm_line.way)
                     THEN ST_CONTAINS(ST_MakePolygon(planet_osm_line.way),myway) 
                     ELSE FALSE 
                    END
              LIMIT 1;

Im Test läufts, aber das sagt nach Hartmuts Ergebnissen ja nichts...

llärt immer noch nicht warum das mal funktioniert (bei euch, bei mir von Hand) und mal nicht (bei mir aus Mapnik heraus), aber ist immerhin schon mal eine Idee ...

Kann nur raten... Dieser Optimisierer entscheidet ja auch nach Kriterien, die er auch aus seiner Erfahrung der letzten Anfragen bezieht ("nach leisure brauche ich nicht als erstes fragen, da bekomme ich immer die halbe Datenbank zurück. Nehme ich lieber dieses ST_CONTAINS() zuerst, nutze meinen Index über die Koordinaten und sortiere dann aus den wenigen Ergebnissen die leisure=track aus"). Da könnte echt viel Zufall im Spiel sein.

Last edited by maxbe (2018-04-18 11:13:14)

Offline

#589 2018-04-18 13:04:55

gormo
Member
Registered: 2013-08-01
Posts: 1,769
Website

Re: OpenTopoMap

maxbe wrote:

Kennt sich jemand mit Postgresql aus?

Nicht wirklich, aber ich würds mal versuchen. Allerdings könnte ich mir vorstellen, dass das case den Ausführungsplan nochmal durchnanderbringt und evtl. die Performance einbricht, aber das kann man (also ich ;-) ) nur im Test sehen.

In einem anderen(oder hier?) Thread wurde ja auch mal über ein neues "OpenTopoMap selbst rendern"-Tutorial berichtet - gibts da nen aktuelles Skript/HowTo zu?


OSM hat nicht das Ziel bis Ende des Monats einen vollständigen Datensatz der Welt zu enthalten.
(nach S.W.) - Aber weil die Welt vielfältig ist, weil sie auch im Detail interessant ist, mag ich genaue Karten (nach C.)

Offline

#590 2018-04-18 17:57:24

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 39

Offline

#591 2018-04-18 18:38:48

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 39

Re: OpenTopoMap

Nehme alles zurück, man sollte die Funktion natürlich nach einem git pull auch neu einspielen ...

Jetzt habe ich ein Performance-Problem mit Query-Laufzeigen von mehreren Minuten.
Ich vermute mal ihr habt da einen Index auf der leisure-Spalte?

Das ist bei hstore-only ein klein wenig schwieriger, aber machbar ...

Offline

#592 2018-04-18 18:48:55

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 39

Re: OpenTopoMap

sad

Tut mal wieder direkt aus psql, aber Mapnik rennt nun in:

RuntimeError: Postgis Plugin: ERROR:  Shell is not a line
CONTEXT:  SQL statement "SELECT osm_id FROM planet_osm_polygon
              WHERE planet_osm_polygon.way && ST_EXPAND(myway,trackdist/labelsizefactor) 
              AND   leisure='track' 
              AND CASE WHEN  ST_ISCLOSED(planet_osm_polygon.way)
                     THEN ST_CONTAINS(ST_MakePolygon(planet_osm_polygon.way),myway) 
                     ELSE FALSE 
                  END
              LIMIT 1

Offline

#593 2018-04-18 18:55:13

maxbe
Member
Registered: 2010-01-19
Posts: 2,907
Website

Re: OpenTopoMap

Hartmut Holzgraefe wrote:

Ich vermute mal ihr habt da einen Index auf der leisure-Spalte?

Nö, OTM ist eine praktisch indexlose Datenbank: gist(way) und btree(osm_id) sind die einzigen für planet_osm_polygon -line und -point. An der Performance hab ich bei mir nichts gemerkt, offensichtlich sind unsere Datenbanken unterschiedlicher Ansicht, wie rum man das optimieren sollte.

gormo wrote:

In einem anderen(oder hier?) Thread wurde ja auch mal über ein neues "OpenTopoMap selbst rendern"-Tutorial berichtet - gibts da nen aktuelles Skript/HowTo zu?

Hat wima75 freundlicherweise verfasst.

Offline

#594 2018-04-18 19:01:43

maxbe
Member
Registered: 2010-01-19
Posts: 2,907
Website

Re: OpenTopoMap

Hartmut Holzgraefe wrote:

untimeError: Postgis Plugin: ERROR: Shell is not a line

Ich hätts auch nur bei der Abfrage nach planet_osm_line ersetzt (der PR dazu). In planet_osm_polygon liegen ja nur Polygone. Wobei... naja... man weiss ja nie, welch wunderlichen Gebilde einen erwarten... wink

Offline

#595 2018-04-18 19:18:17

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 39

Re: OpenTopoMap

Offline

#596 2018-04-18 19:22:34

maxbe
Member
Registered: 2010-01-19
Posts: 2,907
Website

Re: OpenTopoMap

Kurz zur Unterhaltung der Mitleser. Hier gehts drum, dass die OTM Sportfelder in Zoom 13 und 14 unterschiedlich rendert. Das hängt davon ab, ob sie nur ein Fussballplatz sind oder eine Rennbahn aussen rum haben. Diese Rennbahn kann eine geschlossene Linie sein, oder eine Fläche. Die Funktion, die hier abschmiert ist das Teil, das eben prüft, ob so ein Ding (a) in der Nähe ist und (b) ein leisure=track ist und (c) ein geschlossener Ring ist und (d) den Sportplatz umschliesst (weil "in der Nähe" kann ja auch eine Bahn daneben sein)

Beim Programmieren ging ich davon aus, dass (a)...(d) in dieser Reihenfolge abgearbeitet wird. "Umschliesst?" ist also die letzte Frage, die beantwortet wird. Ist ein blöder Fehler, weil man weiss ja, dass Postgresql das noch optimiert und wenn es das für gut hält auch gerne die Frage (d) zuerst abarbeitet. Allerdings funktioniert "umschliesst das Ding den Platz?" nicht, wenn die Frage (c) "ist das überhaupt ein geschlossener Ring?" nicht zuvor mit "Ja" beantwortet wurde.

Last edited by maxbe (2018-04-18 19:28:42)

Offline

#597 2018-04-19 11:24:02

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 1,801
Website

Re: OpenTopoMap

toc-rox wrote:

Ich werde den Full-Planet-Import mal ausprobieren (geschätzte Einlesedauer: 48 Stunden). Ich berichte dann.

Der Full-Planet-Import hat 48 Stunden gedauert und belegt schlußendlich 231 GB. Die drop-Option wird erst am Ende des Imports wirksam, sodass zwischenzeitlich die DB-Größe auf circa 630 GB angestiegen ist. Die temporäre DB-Größe fällt etwas 'happig' aus, da ich die (empfohlene) flat-nodes-Option nicht verwendet habe.

nohup ./osm2pgsql --username postgres --multi-geometry --hstore --slim --drop --create --cache 48000 --number-processes 8 --database osmtest --style openstreetmap-carto.style --tag-transform-script openstreetmap-carto.lua planet-latest.osm.pbf 1>load_osmtest.out 2>&1 &

Jetzt fehlen mir für Printmaps nur noch weltweite Höhendaten. Aber diesbezüglich sieht es nicht so schlecht aus.

Offline

#598 2018-04-19 19:34:56

Skinfaxi
Member
From: Blackstad, Sweden
Registered: 2013-07-30
Posts: 873

Re: OpenTopoMap

Wahrscheinlich offtopic, aber wenn ihrs schon von Sportplätzen habt: Ich finde Sportplätze wie diesen https://opentopomap.org/#marker=17/48.17417/11.60795 immer ein wenig suspekt (Höhenliniendarstellung) da ich eigentlich erwarte, dass sie relativ eben sind smile.

Offline

#599 2018-04-19 20:41:22

maxbe
Member
Registered: 2010-01-19
Posts: 2,907
Website

Re: OpenTopoMap

Skinfaxi wrote:

: Ich finde Sportplätze wie diesen immer ein wenig suspekt

Das ist sicher auch der Grund dafür dass er aufgegeben wird. Is halt immer das gleiche Problem: Keine guten Höhendaten. Nebenan gibts nen Fluss, der die 500m-Linie 5x schneidet...

Offline

#600 2018-04-20 06:45:19

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 2,957
Website

Re: OpenTopoMap

maxbe wrote:

Is halt immer das gleiche Problem: Keine guten Höhendaten. Nebenan gibts nen Fluss, der die 500m-Linie 5x schneidet...

Es liegt aber auch an der Zeichenreihenfolge... so müssten Gewässerflächen (Standgewässer und Fließgewässer) sowie Sportplätze und Gebäude über den Höhenlinien gerendert werden. Straßen werden ja über den Höhenlinien gerendert...

Ob das aber hier so ohne weiteres geht, vermag ich nicht zu sagen.

Sven

Offline

Board footer

Powered by FluxBB