[mkgmap-dev] Bug in splitter?

Sun Apr 1 21:13:27 BST 2012


On 01.04.2012 22:06, Thorsten Kukuk wrote:
> Hi,
>
> On Sun, Apr 01, Felix Hartmann wrote:
>
>> Oh, so it's a splitter bug?
> Since osmconvert and osmosis have no problems with
> the data, I assume it's a splitter bug. At least the
> message about the number of nodes looks wrong to me.
>
>> I tried splitting SRTM data from phyghtmap
>> with the following command unsuccessfully:
>> phyghtmap --jobs=1 --osm-version=0.6 --step=25 --output-prefix=as2
>> --line-cat=1000,200 --source=view1,view3,srtm1,srtm3
>> --area=80:-11.01192:129.99999:83.20162 --max-nodes-per-tile=0
>> --max-nodes-per-way=250 --pbf
>>
>>
>> BTW -- how can I make sure with phyghtmap that multiple input files
>> don't overlap, nor miss data? 129.99999 is already interpreted as 130...
> I don't know, luckily I didn't needed this.
Well for Asia there is no way around, at least without 16GB RAM. With 
8GB one has to resort to at least 3 parts...

I'll ask on Panarchos site...
>
>    Thorsten
>
>> On 01.04.2012 21:48, Thorsten Kukuk wrote:
>>> Hi,
>>>
>>> I try to split SRTM data with splitter r200, but splitter only
>>> creates one big tile.
>>>
>>> Some interesting statistics from osmconvert:
>>> nodes: 2518069911
>>> ways: 27074150
>>> node id min: 1
>>> node id max: 2679465052
>>>
>>> Ok, I'm a little bit above a 32bit signed integer, but:
>>> Splitting nodes into areas containing a maximum of 6.000.000 nodes each...
>>> Area (30.8935546875,-125.0244140625) to (50.2294921875,-101.9970703125) contains
>>>    -1.776.905.107 nodes. DONE!
>>>
>>> This looks like an overrun somewhere. At first I thought it's
>>> the 32bit int overflow, but for this the number is far too high.
>>>
>>> Any ideas what's going wrong here?
>>>
>>>     Thanks,
>>>       Thorsten
>>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev