Hi,
I did not find a simple solution regarding a change in mkgmap.
But maybe a different approach:
What about using two layers like we do with contour lines?
I mean:
create a transparent map with the polygons for
seamark:type=fairway
and a normal map with all other elements and give them
[mailto:mkgmap-dev-
boun...@lists.mkgmap.org.uk] Im Auftrag von GerdP
Gesendet: Mittwoch, 20. März 2013 08:22
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Splitter Error
Hi,
I did not find a simple solution regarding a change in mkgmap.
But maybe a different approach:
What about
Hi,
I think I have enough info now to continue the work.
I use a variant of the default style for testing, the last for lines look
like this:
#include 'inc/water_polygons';
include 'inc/landuse_polygons';
seamark:type=fairway [0x10302 resolution 20]
waterway=riverbank [0x10303 resolution 20]
My
The use of the prepro changes something in the output file, but that seems
not to change the draw order. Reversing the order of the lines in wayorder
also changes something in the img file, but not the draw order.
Did you run the prepro after splitter on each tile? I use a script with a for
Hi,
please try the attached patch (which is just a quick hack). It implements a
special mode in the split algo (only for polygons).
Activate it with --x-marine-device=true and use it in combination with
--preserve-element-order
and your prepro.
Does that improve your map?
marine_device_v1.patch
RheinSkipper wrote
Many, many thanks for working on this problem.
Unfortunately I am not familiar with patches. I tried to apply it using
GNU patch 2.5.9 under Windows.
I suggest to use TortoiseSVN on windows. It is an easy interface for svn and
lets you apply patches with a mouse click.
RheinSkipper wrote
Tests can be done very easily as no marine device is needed for that.
Mapsource renders exactly the same draw order as a marine device (as long
as
there is no typ file of course).
I don't have Mapsource, only Basecamp. I assume that works as well?
Where should I find an
Do you see a chance to implement an option to control the order of data in
the img file?
Good question. I don't have any knowledge about the algorithm that is used in
your device,
so I have no idea what order we should keep (or establish).
Gerd
@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Splitter Error
Do you see a chance to implement an option to control the order of data in
the img file?
Good question. I don't have any knowledge about the algorithm that is used in
your device,
so I have no idea what order we should keep (or establish).
Gerd
RheinSkipper wrote
I want to establish the order I need via a preprocessing. This
preprocessor (programmed by Malcolm) is already working perfectly.
All I need from mkgmap is not to mix up this order.
OK, that is understood. With --preserve-element-order and mkgmap = r2507
the order is not
Gesendet: Dienstag, 12. März 2013 11:24
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Splitter Error
RheinSkipper wrote
I want to establish the order I need via a preprocessing. This
preprocessor (programmed by Malcolm) is already working perfectly.
All I need from mkgmap
I updated JRE from 1.6 to 1.7, updated osmosis to latest version and gave it
16 GB of memory.
With a small bbox left=8 right=9 bottom=49.5 top=50.5 osmosis still
produces 6 GB of bbox data.
And running splitter on this bbox always results in:
Exception in thread main java.lang.OutOfMemoryError:
Hi,
if you have no good reason to use resolution=16, remove this parm. That will
reduce the required memory
in this phase.
Gerd
RheinSkipper wrote
I updated JRE from 1.6 to 1.7, updated osmosis to latest version and gave
it
16 GB of memory.
With a small bbox left=8 right=9 bottom=49.5
I receive an error when running the current splitter version:
Exception in thread worker-6 java.lang.StringIndexOutOfBoundsException:
String index out of range: -3
at java.lang.String.getChars(String.java:860)
at
Hi,
probably an error in splitter. It seems to be caused by a long string in the
data.
Can you tell me how to reproduce it?
Gerd
RheinSkipper wrote
I receive an error when running the current splitter version:
Exception in thread worker-6 java.lang.StringIndexOutOfBoundsException:
@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Splitter Error
Hi,
probably an error in splitter. It seems to be caused by a long string in
the
data.
Can you tell me how to reproduce it?
Gerd
RheinSkipper wrote
I receive an error when running the current splitter version:
Exception
[mailto:mkgmap-dev-
bounces@.org
] Im Auftrag von GerdP
Gesendet: Montag, 11. März 2013 14:47
An:
mkgmap-dev@.org
Betreff: Re: [mkgmap-dev] Splitter Error
Hi,
probably an error in splitter. It seems to be caused by a long string in
the
data.
Can you tell me how to reproduce it?
Gerd
An:
mkgmap-dev@.org
Betreff: Re: [mkgmap-dev] Splitter Error
Hi,
probably an error in splitter. It seems to be caused by a long string in
the
data.
Can you tell me how to reproduce it?
Gerd
RheinSkipper wrote
I receive an error when running the current splitter version
Well, I used xml output just for some experiments. I tried to sort the output
to control the draw priority of polygons. According to
http://www.cferrero.net/maps/mkgmap_tiddlywiki.html#--preserve-element-order
this should work, but it didn’t. So I can switch back to pbf again for now.
Not
...@lists.mkgmap.org.uk] Im Auftrag von GerdP
Gesendet: Montag, 11. März 2013 16:37
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Splitter Error
Hi RheinSkipper,
I traced through the code and I fear I am not able to reproduce the problem.
Are you able to reproduce it? Maybe also
RheinSkipper wrote
I had the problem a couple of times. But when I run splitter again with
same input and same script, the problem is sometimes away. I will try to
reproduce it with smaller input.
Good luck!
I fear this might be a hardware problem. Or maybe some kind of multitasking
problem in
RheinSkipper wrote
Well, I used xml output just for some experiments. I tried to sort the
output to control the draw priority of polygons. According to
http://www.cferrero.net/maps/mkgmap_tiddlywiki.html#--preserve-element-order
this should work, but it didn’t. So I can switch back to pbf
Do you see a chance to implement an option to control the order of data in the
img file?
In our experiments tweaking the order of data in the osm file did have an
influence on draw order. But as you described the influence was more or less
random.
For rendering shaded depth areas in a sea map
For rendering shaded depth areas in a sea map it is absolutely
necessary to make sure that the depth area polygons are drawn on top
of sea or riverbank polygons and not below them.
If you use a typ file you can set the draworder of every polygon
Hello,
Running splitter with the following command line parameters,
java -Xmx896m -jar $FILEDIR/splitter.jar --cache=$cache --output=$output
--geonames-file=$geonames_file --max-areas=$max_areas
--max-nodes=$max_nodes --description=$description_splitter
--mapid=$mapid $CARTESDIR/$geofabrik_map
Hello Francois,
it seems that you use an out-aged version of the fastutil.jar lib.
The correct version is in the package, see
http://www.mkgmap.org.uk/download/splitter-r289.zip
Gerd
Francois wrote
Hello,
Running splitter with the following command line parameters,
java -Xmx896m -jar
On 19/02/2013 20:39, GerdP wrote:
Hello,
it seems that you use an out-aged version of the fastutil.jar lib.
The correct version is in the package, see
http://www.mkgmap.org.uk/download/splitter-r289.zip
Bingo. You're right. It works fine now. Thank you. Francois
Hello Francois,
thanks for the feedback. If you are interested in the latest parms, see
http://wiki.openstreetmap.org/wiki/Mkgmap/help/splitter
Gerd
Francois wrote
On 19/02/2013 20:39, GerdP wrote:
Hello,
it seems that you use an out-aged version of the fastutil.jar lib.
The correct
In running a macro I have used many times before with a new download
from geofabrik, splitter gave me the following error. (I realise that
there is no need to split the file in this particular case, but it has
never caused problems before.) I am not sure of the version of splitter
I am using,
Hello Roger,
you are running an out-aged version of splitter. Please update to the latest
stable version: r202
http://www.mkgmap.org.uk/splitter/
Ciao,
Gerd
Roger Calvert wrote
In running a macro I have used many times before with a new download
from geofabrik, splitter gave me the
Thanks, Gerd. That solved the problem.
I have another, more general, query: will the improvements currently
being made to Splitter to handle problem polygons remove or reduce the
need for pre-compiled sea (whose purpose seems to be to prevent flooding
resulting from faulty coastlines) in
will have point 1) left.
My understanding is that the precompiled sea data is somehow verified to be ok.
Besides that the precompiled files save CPU time.
Ciao,
Gerd
Date: Wed, 14 Nov 2012 14:48:39 +
From: ro...@rogercalvert.me.uk
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev
I was trying to split the europe.osm.pbf file from yesterday, but I got this
error:
java.util.zip.ZipException: invalid block type
Tried it with splitter r170 and r171, my OS is windows vista 32bits. I have
never have seen this error before, it continues splitting, but the process
isnt't
Le 27/02/2011 18:24, Henning Scholland a écrit :
I've downloaded splitter -r164, but got the same result. Do not know
where my mistake is Francois
Did you also copied lib directory next to splitter.jar?
Bingo, you did it. Now it works as before. Great and thank you. Francois
--
Hello,
Today, running splitter against the french osm.bz2 geofabrik file, I got
this error :
A total of 69 836 298 nodes, 8 242 531 ways and 178 671 relations were
processed in 1 file
Min node ID = 122626
Max node ID = 861772452
Time: Tue Aug 17 11:58:06 CEST 2010
Exact map coverage is
Hello Francois,
It looks like this is a bug that was introduced by some patches I applied
for Scott last night. I've rolled back the changes for now until I get a
chance to debug the problem further. If you grab the latest codebase (r121),
or alternatively use r118 or older, your problem
On Tue, Aug 17, 2010 at 7:12 AM, Chris Miller
chris_overs...@hotmail.com wrote:
Hello Francois,
It looks like this is a bug that was introduced by some patches I applied
for Scott last night. I've rolled back the changes for now until I get a
chance to debug the problem further. If you grab
Hello Scott,
Thanks for the quick patch, saves me digging in to figure out where things
were getting derailed. I'll try and take a look at your updated patch later
tonight.
Cheers,
Chris
On Tue, Aug 17, 2010 at 7:12 AM, Chris Miller
chris_overs...@hotmail.com wrote:
Hello Francois,
It
Le 17/08/2010 15:25, Scott Crosby a écrit :
Hello,
Again, my apologies,
Don't worry, there is no problem at all. that's so great to see you guys
giving your knowledge and time to help to give us the best program, and
you're so fast to give a fix. No, you don't have to apologize, I have to
thank
On 09/08/2009 09:21 PM, Chris Miller wrote:
It looks like there is a latitude value in your file that contains a large
number of significant figures (far more than is actually required) and the
parsing is failing on it. I just checked in a change that will hopefully
solve the problem for
Chris Miller wrote:
Thanks Paul, that would explain it for sure. The problem Ralf hit was
definitely
a bug in the splitter though, I had made one too many assumptions in some
custom code for parsing floating point numbers (Java's double parsing is
very slow). I figured if the code could
Hi Paul,
I'd used Ralf's osm file as a test case to solve this problem, but seems
like even that didn't go far enough. I have no idea why but the numbers in
your file contain several digits more precision than a 64bit floating point
number can even represent. I've added another check so that
Chris Miller wrote:
Hi Paul,
I'd used Ralf's osm file as a test case to solve this problem, but seems
like even that didn't go far enough. I have no idea why but the numbers in
your file contain several digits more precision than a 64bit floating point
number can even represent. I've
Heh, you're doing a great job testing various corner-cases in the splitter
- keep up the good work :) I have to wonder quite how that osm file you
have was generated though. Are there really nodes in the osm database that
are missing lat and/or lon values? Seems a bit worrying if so.
P That
Hi,
when I try to split a OSM file which contains only contour lines made
with srtm2osm (1.8.14.10) I get this error:
[splitter-r83]$java -Xmx2048M -jar splitter.jar --mapid=2101
--mixed=yes --cache=./cache/ --max-nodes=5 srtm_test.osm
Time started: Tue Sep 08 20:03:15 CEST 2009
mapid =
It looks like there is a latitude value in your file that contains a large
number of significant figures (far more than is actually required) and the
parsing is failing on it. I just checked in a change that will hopefully
solve the problem for you (r88) however I'd be interested in seeing the
Chris Miller wrote:
It looks like there is a latitude value in your file that contains a large
number of significant figures (far more than is actually required) and the
parsing is failing on it. I just checked in a change that will hopefully
solve the problem for you (r88) however I'd be
Thanks Paul, that would explain it for sure. The problem Ralf hit was
definitely
a bug in the splitter though, I had made one too many assumptions in some
custom code for parsing floating point numbers (Java's double parsing is
very slow). I figured if the code could parse the planet file it
Hi Carlos,
Try splitter r77, it should now behave the way you expect with caching and
--split-file. I decided to make it print a (perhaps too threatening?) warning
message if it detects that you want to build a cache even though it only
needs to make a single pass over the .osm file. I figured
Hi Carlos,
This is something I'm aware of but haven't yet had time to address. It's
because (currently) the cache can only be generated during the first stage
when the areas.list file is also being generated. If you supply areas.list
and use --cache at the same time, the splitter assumes the
Chris Miller escribió:
Hi Carlos,
This is something I'm aware of but haven't yet had time to address. It's
because (currently) the cache can only be generated during the first stage
when the areas.list file is also being generated. If you supply areas.list
and use --cache at the same
51 matches
Mail list logo
