[mkgmap-dev] splitter exception with SRTM data for USA

Fri Apr 12 15:44:03 BST 2013

Hi Henning,

Henning Scholland wrote
> With these parameters and splitting the complete planet I got the 
> following values:
> 
> Length-1 chunks: 5.547.829, used Bytes including overhead: 57.051.176
> 
> Afterwards I generated a new areas.list file, containing all my (partly 
> overlapping) maps also with max-nodes=1600000 and let splitter split 
> them out of the planet. The result is again a value about 10.000.000.

OK, these values make perfectly sense to me. When you split planet without
split-file,
the gen-problem-list pass distributes the data to > 1000 areas. That means
that it is more likely 
that a list of nodes with ids x,x+1,x+3,x+7,x+8,...,x+63 fall into more than
one different areas.
If that is the case, the corresponding value is not stored in a Length-1
chunk.
On the other hand, with your areas.list, splitter creates large
"pseudo-areas" so that the whole 
planet is covered. With these large areas it is likely that a list of nodes
falls into the same 
(pseudo-) area and thus is saved in the Length-1 chunk.

By the way, with my old planet.osm.pbf and your old areas.list I get
Statistics for coords map:
Length-1 chunks: 8.757.219, used Bytes including overhead: 90.717.976

which means it will take a while to reach the limit, but it will not work
for many years.

And if you reduce your areas.list to a single small tile, you may already
hit the problem.

If I can't find a better solution in the current implementation I'll
probably add a parm
like --allow-huge-data which enables the older structure. 

Gerd

--
View this message in context: http://gis.19327.n5.nabble.com/splitter-exception-with-SRTM-data-for-USA-tp5756629p5756820.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.