Hi all, I've not used mkgmap for a good while and am really impressed with all the features that've been added in recent months. I'm currently trying to create a map from a GB planet extract, and performance seems much slower than I remember. I've split the extract into six parts with splitter.jar (I'm using some big route relations so can't split it any further). The first .osm (36Mb) has been chuntering away for an hour and a half and the .img hasn't been produced yet - is this normal? The command line I'm using is: java -Xmx1000m -jar mkgmap-r1067/mkgmap.jar --style-file=/path/to/ cyclemap/ --route --net --no-sort-roads -c template.args The style file is reasonably complex and contains numerous 'set' instructions, plus a handful of relation 'apply's. My system is an Intel Mac mini, OS X 10.5, 1Gb. cheers Richard
there is nearly no chance that a gzipped 36Mb osm file file fit into a .img tile. you will need to split it into smaller tiles. On 27 Jun 2009, at 15:59 , Richard Fairhurst wrote:
Richard Fairhurst wrote:
The first .osm (36Mb) has been chuntering away for an hour and a half and the .img hasn't been produced yet - is this normal?
Just killed it after 12 hours and still no .img. :(
cheers Richard
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Apollinaris Schoell wrote:
there is nearly no chance that a gzipped 36Mb osm file file fit into a .img tile. you will need to split it into smaller tiles.
Thanks. I was going by the docs on http://www.mkgmap.org.uk/page/tile-splitter which suggest "The default [for max-nodes] is fairly conservative, I think you could increase it quite a lot". Clearly not by 50% though. ;) I've rerun it with the default split and it coped with a 9Mb .gz happily, a 17.5Mb slowly (approx 1hr30), an 8Mb happily, but is now choking on a 27Mb one. Guess I'll keep trying while reducing the max-nodes value in the splitter. What that does mean is that I'll need to write a relation splitter, as the whole reason I'm doing this is to show cycle routes, and two of them have bitten the dust (too many tiles) even on the default split. I presume there isn't one already out there? cheers Richard
What that does mean is that I'll need to write a relation splitter, as the whole reason I'm doing this is to show cycle routes, and two of them have bitten the dust (too many tiles) even on the default split. I presume there isn't one already out there?
Why is it a problem for relations to be in too many tiles? I do know that the splitter can't cope with it, but what has to be done to solve this problem of the splitter? I think it is much more reasonable to fix the splitter instead of creating a "relation splitter". Regards Thilo
Hi On Sun, Jun 28, 2009 at 08:52:03AM +0100, Richard Fairhurst wrote:
I was going by the docs on http://www.mkgmap.org.uk/page/tile-splitter which suggest "The default [for max-nodes] is fairly conservative, I think you could increase it quite a lot". Clearly not by 50% though. ;)
Yes that seemed to be true at the time. It all depends on the number of those nodes that are going to be displayed and the ratio of nodes to ways. To remain even slightly accurate across all parts of the world as more gets added to OSM it will probably have to look at the tags and the style to approximate better how much space will be needed.
What that does mean is that I'll need to write a relation splitter, as the whole reason I'm doing this is to show cycle routes, and two of them have bitten the dust (too many tiles) even on the default split. I presume there isn't one already out there?
When I get the time (which should be next week) I will re-write splitter to remove the limitation of 4 tiles per relation or way. And try to improve the size estimate too. Cheers, ..Steve
Steve Ratcliffe wrote:
When I get the time (which should be next week) I will re-write splitter to remove the limitation of 4 tiles per relation or way. And try to improve the size estimate too.
Sounds great - look forward to it. I'll hold off with my queries about the style rules until then. :) cheers Richard
Hi Richard
I'm currently trying to create a map from a GB planet extract, and performance seems much slower than I remember. I've split the extract into six parts with splitter.jar (I'm using some big route relations so can't split it any further). The first .osm (36Mb) has been chuntering away for an hour and a half and the .img hasn't been produced yet - is this normal?
It takes just under 4 minutes for me to do the GB extract split into 13 pieces with routing. So after an hour I'd imagine something is wrong.
The style file is reasonably complex and contains numerous 'set' instructions, plus a handful of relation 'apply's. My system is an Intel Mac mini, OS X 10.5, 1Gb.
A number of people run fairly complex styles, but still it could be a bug that is only shown with your style though. If you could send me it I will look at it and see if it is the problem. The only non-bug thing I can think of is the memory given to java. If you give an amount that is just not quite enough, it can slow the run down dramatically. That would be pretty unlucky though, normally it would work or you would run out of memory within a few minutes. ..Steve
participants (5)
-
Apollinaris Schoell -
Lambertus -
Richard Fairhurst -
Steve Ratcliffe -
Thilo Hannemann