Hi!
I've been using r1625 for some time and it worked pretty well. Recenly,
however, I've found out r1688 was released and tried it out - it died on
the same data r1625 worked fine with.
Here's the data: http://gis-lab.info/data/osm/mosobl/mosobl.osm.bz2
Here's how I run it and what happens:
I believe this was fixed with r1692, from the changeset comment:
Version 1692 was commited by steve on 2010-09-15 12:25:41 +0100 (Wed,
15 Sep 2010)
Fix bug in constructing jar file introduced in 1688.
Causes problem like:
java.lang.IllegalArgumentException: InputStream cannot be null
at
On 16/09/10 01:46, Dmitry Marakasov wrote:
Hi!
I've been using r1625 for some time and it worked pretty well. Recenly,
however, I've found out r1688 was released and tried it out - it died on
the same data r1625 worked fine with.
Sorry about that - it was a bad build as Maning has already
Hi
The changes to read Scott Crosby's binary format are complete (for
mkgmap itself) and I will merge them back soon.
Before that it would be good for as many people as possible to try
it out on their existing XML files, with the options that they
normally use, since the code has been completely
Hi Steve,
that was a quick implementation!
I haven't tried so far the new binary format. I haven't found a download
for the osmprotobuf.jar. Is there any? Download links should be added to
the documentation and the website if the changes are merged back.
I had some thoughts if the splitter is
On Thu, Sep 16, 2010 at 12:33 PM, WanMil wmgc...@web.de wrote:
Hi Steve,
that was a quick implementation!
I haven't tried so far the new binary format. I haven't found a download
for the osmprotobuf.jar. Is there any? Download links should be added to
the documentation and the website if
On Thu, Sep 16, 2010 at 12:33 PM, WanMilwmgc...@web.de wrote:
Hi Steve,
that was a quick implementation!
I haven't tried so far the new binary format. I haven't found a download
for the osmprotobuf.jar. Is there any? Download links should be added to
the documentation and the website if
On Thu, Sep 16, 2010 at 01:34:20PM -0500, Scott Crosby wrote:
I've got a question though, why can't mkgmap generate different areas
in parallel? It seems like it should be possible and it would make it a
lot faster to render maps.
I thought that it already does, when you specify the parameter
Hi
I haven't tried so far the new binary format. I haven't found a download
for the osmprotobuf.jar. Is there any? Download links should be added to
the documentation and the website if the changes are merged back.
Merging back can happen when I am sure that there is no harm to the XML
Ok, that means we cannot use the common planet dumps for this and a
separate step (geographical sorting) is needed which maybe eats up the
advantage to skip the tile splitter step. Just keep the idea in mind and
give it a try when the geographical sorting is available.
I designed the format
Well, technically two passes; the first pass is needed to figure out
where to split.
A new set of patches and line of development in my tree.
Features:
About 1/3 of the RAM usage. An entire planet can be split into 1200
areas in one pass with -Xmx5000m --max-nodes=100 in one hour.
No
mkgmap already works in parallel if you specifiy multiple osm files
which are usually generated by the tile splitter (see parameter
--max-jobs). The advantage of my idea would be to skip the tile splitter
step.
Are you sure?
It is only reading the files that is serialised, the rest runs
Thanks Steve.
Markus_g
-Original Message-
From: mkgmap-dev-boun...@lists.mkgmap.org.uk
[mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of svn commit
Sent: Wednesday, 15 September 2010 10:42 PM
To: mkgmap-...@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Commit: r1694: This patch
2 tags exist for waterfalls:
natural=waterfall: 183 nodes, 8 ways
waterway=waterfall: 2183 nodes, 162 ways, 2 relations
I added them in my point styles
natural=waterfall [0x6508 resolution 21]
waterway=waterfall [0x6508 resolution 21]
Might be good to add them in default styles as well.
IMO,
14 matches
Mail list logo
