[OSM-dev] Issue with rendering chain (Tirex/Mapnik/Mod_tile)

Richard Ive richard.ive at metafour.com
Fri Jun 8 09:13:25 BST 2012


Hi All,

I have a Postgresql -> Mapnik - > Tirex -> Mod_Tile - > OpenLayers tile
rendering chain set up, but unfortunately I'm having an issue somewhere
along the line that I can't solve without help.

As I am using tirex I ran a batch render from 0 down to zoom 12 to try and
take some of the initial load off the server once it goes live. Once it had
finished I did a quick pan round the map starting in London and I found the
issue you can see below in my first screen shot. This section of map
refuses to render. It is a rectangle with its left edge running along GMT
down to the south of France and to the north of Scotland. Unfortunately
though I cannot find it's right edge because as soon as any tile in this
section is requested a block appears to happen for a good two minutes or so
somewhere along the rendering chain forcing it to hang. Mod_tile doesn't
serve any tiles, even at other zoom levels, and it doesn't send any new
rendering requests to tirex.

In my second screen shot you can see the two tiles that get requested just
before the freeze. I can consistently make this happen and resolve the
issue by restarting Tirex, which would suggest the problem is there,
however looking through all the logs I don't see anything related to this
issue.

When I ran osm2pgsql on my database server I did receive a
few TopologyExceptions, however the process ran though fine and the rest of
the map appears to render. I have attached the output from osm2pgsql for
you to look at.

I'd really appreciate any help. It may be that I'm just being silly, so
please let me know if I am! If you want to replicate the problem yourself
here's the URL to my tile server:  http://maptiles.cust.m4.net/

Kind Regards,
Richard Ive


[image: Inline images 3]

[image: Inline images 1]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20120608/dc49879d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 76809 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20120608/dc49879d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 676387 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20120608/dc49879d/attachment-0003.png>
-------------- next part --------------
Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
NOTICE:  table "planet_osm_point" does not exist, skipping
NOTICE:  table "planet_osm_point_tmp" does not exist, skipping
Setting up table: planet_osm_line
NOTICE:  table "planet_osm_line" does not exist, skipping
NOTICE:  table "planet_osm_line_tmp" does not exist, skipping
Setting up table: planet_osm_polygon
NOTICE:  table "planet_osm_polygon" does not exist, skipping
NOTICE:  table "planet_osm_polygon_tmp" does not exist, skipping
Setting up table: planet_osm_roads
NOTICE:  table "planet_osm_roads" does not exist, skipping
NOTICE:  table "planet_osm_roads_tmp" does not exist, skipping
Allocating memory for dense node cache
Allocating dense node cache in one big chunk
Allocating memory for sparse node cache
Sharing dense sparse
Node-cache: cache=12000MB, maxblocks=1536001*8192, allocation method=11
Mid: pgsql, scale=100 cache=12000
Setting up table: planet_osm_nodes
NOTICE:  table "planet_osm_nodes" does not exist, skipping
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_nodes_pkey" for table "planet_osm_nodes"
Setting up table: planet_osm_ways
NOTICE:  table "planet_osm_ways" does not exist, skipping
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_ways_pkey" for table "planet_osm_ways"
Setting up table: planet_osm_rels
NOTICE:  table "planet_osm_rels" does not exist, skipping
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_rels_pkey" for table "planet_osm_rels"

Reading in file: /usr/share/planet-file/planet-latest.osm.pbf
Processing: Node(1451697k 127.4k/s) Way(135258k 8.77k/s) Relation(562440 62.63/s)osm2pgsql SVN version 0.80.0 (64bit id space)


Standard exception processing way_id 1082366: TopologyException: side location conflict at 822832 8.30585e+06
Processing: Node(1451697k 127.4k/s) Way(135258k 8.77k/s) Relation(1102000 73.08/s)
Standard exception processing way_id 1792031: TopologyException: side location conflict at -734926 5.24355e+06
Processing: Node(1451697k 127.4k/s) Way(135258k 8.77k/s) Relation(1163730 73.78/s)
Standard exception processing way_id 1868906: TopologyException: side location conflict at 1.22428e+06 5.69149e+06
Processing: Node(1451697k 127.4k/s) Way(135258k 8.77k/s) Relation(1401260 75.28/s)  parse time: 45439s

Node stats: total(1451697049), max(1745404857) in 11397s
Way stats: total(135258238), max(162688056) in 15428s
Relation stats: total(1401266), max(2175120) in 18614s
Committing transaction for planet_osm_point
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Committing transaction for planet_osm_roads

Going over pending ways

Using 3 helper-processes
processing way (25737k) at 1.04k/s
Process 1 finished processing 25738620 ways in 24723 sec
processing way (25738k) at 1.04k/s
Process 2 finished processing 25738619 ways in 24723 sec

Process 0 finished processing 25738620 ways in 24723 sec

All child processes exited

77215859 Pending ways took 24724s at a rate of 3123.11/s
Committing transaction for planet_osm_point
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Committing transaction for planet_osm_roads

Going over pending relations

Using 3 helper-processes

Process 1 finished processing 0 relations in 2 sec

Process 0 finished processing 0 relations in 2 sec

Process 2 finished processing 0 relations in 2 sec

All child processes exited
0 Pending relations took 3s at a rate of 0.00/s

Sorting data and creating indexes for planet_osm_line
Sorting data and creating indexes for planet_osm_point
Sorting data and creating indexes for planet_osm_roads
node cache: stored: 1400392899(96.47%), storage efficiency: 89.03% (dense blocks: 1450917, sparse nodes: 43562601), hit rate: 96.20%
Sorting data and creating indexes for planet_osm_polygon
Stopping table: planet_osm_nodes
Stopping table: planet_osm_ways
Stopping table: planet_osm_rels
Stopped table: planet_osm_rels in 12s
Stopped table: planet_osm_ways in 128s
Stopped table: planet_osm_nodes in 172s
Analyzing planet_osm_polygon finished
Analyzing planet_osm_roads finished
Analyzing planet_osm_point finished
Analyzing planet_osm_line finished
Copying planet_osm_roads to cluster by geometry finished
Copying planet_osm_point to cluster by geometry finished
Creating indexes on  planet_osm_roads finished
All indexes on  planet_osm_roads created  in 3345s
Completed planet_osm_roads
Creating indexes on  planet_osm_point finished
All indexes on  planet_osm_point created  in 5251s
Completed planet_osm_point
Copying planet_osm_line to cluster by geometry finished
Copying planet_osm_polygon to cluster by geometry finished
Creating indexes on  planet_osm_line finished
All indexes on  planet_osm_line created  in 11419s
Completed planet_osm_line
Creating indexes on  planet_osm_polygon finished
All indexes on  planet_osm_polygon created  in 12064s
Completed planet_osm_polygon

Osm2pgsql took 82234s overall


More information about the dev mailing list