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 -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Oh, so it's a splitter bug? 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... 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
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. 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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Thorsten, a quick look shows some places where nodes are counted with a int value, so this will overflow. The negative value is reported with a formatting routine, I assume this converts the wrong value again. I'll try to post a fix tomorrow. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Bug-in-splitter-tp5610856p5610988.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (3)
-
Felix Hartmann -
GerdP -
Thorsten Kukuk