Garvan wrote:
java -jar mkgmap.jar --help=options
reports
--levels=levels code
Change the way that the levels on the map correspond to the
zoom levels in the device. See customisation help. The default
is the equivalent of: 0=24, 1=22, 2=21, 3=19, 4=18, 5=16
although this may
On 03/13/2010 11:04 PM, Daniela Duerbeck wrote:
I tried on several maps, a small one, that contains just Munich (there I
could not find bugs concerning the address search), but also larger
areas like upper Bavaria or Bavaria. There it seems to be dependent from
where I am. A road which is
Version 1602 was commited by steve on 2010-03-14 10:23:58 + (Sun, 14 Mar
2010)
The attached little patch fixes the text of the options help.
Garvan
(I also added a note that a style can set its own default ..Steve).
___
mkgmap-dev mailing list
On Mar 14, 2010, at 1:09, Apollinaris Schoell wrote:
I have tried the patch and it's the first time generate-sea=multipolygon is
working for all my tiles.:)
highly recommended and should be commited
Although I see that the patch has already been committed, I can also confirm
that it appears
The patch improves the handling of roles and warning messages in
multipolygon.
- A reasonable warning message for nested outer and nested inner
polygons is given
- nested inner polygons are processed anyhow
WanMil
P.S.: This is an updated patch to r1602.
Index:
Hello,
Not sure if this is directly related to mkgmap but I thought I would
seek advice here. I have a strange behavior with mkgmap.
When I generate my maps one by one, everything works fine. When I try to
generate all at once, java segfaults.
When I say one by one, I mean:
for FILE in
Hi Nakor,
I don't know what is causing the SEGV but have you tried using another
runtime? Perhaps, it's a problem in OpenJDK.
# Java VM: OpenJDK 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 )
Mark
___
mkgmap-dev mailing list
Stylists,
Just noticed that in the UK map, points tagged natural=peak that don't
have a name are showing a name of '6140565'. I guess it's something to
do with this rule from the points file:
natural=peak {name '${name|def:}${ele|height:m=ft|def:}' } [0x6616 resolution
18]
The style language
On 12.03.2010 20:39, Mark Burton wrote:
Felix,
I have grabbed your style stuff from the SVN site and using that
style it takes less than 2 min to process kosovo.osm.gz. Here's the
options I used:
java -Xmx2000m -Dlog.config=/home/markb/OSM/logging.properties -ea
-jar
Templates.arg attached. this time
On 12.03.2010 20:39, Mark Burton wrote:
Felix,
I have grabbed your style stuff from the SVN site and using that
style it takes less than 2 min to process kosovo.osm.gz. Here's the
options I used:
java -Xmx2000m -Dlog.config=/home/markb/OSM/logging.properties
Mark Burton wrote:
Just noticed that in the UK map, points tagged natural=peak that don't
have a name are showing a name of '6140565'. I guess it's something to
do with this rule from the points file:
natural=peak {name '${name|def:}${ele|height:m=ft|def:}' } [0x6616
resolution 18]
Is
Hi WanMil,
could you please try with patch v4 I posted 5 days ago?
Sorry, I was busy with other things (among others, JOSM WaySelectorPlugin
that I can use for cleaning up the Finnish west coast).
I see that your patch was already committed, and it makes a huge difference
in terms of execution
Felix,
Ups, sorry. I don't understand why it ran through using the default
style, but it is hanging on the templates.args file which seems to be
the real culprit.
If I run mkgmap with *.osm.gz for map input, it runs through fine. If
however I use -c template.args then it gets stuck
Sorry, I was wrong again. Its the --location-autofill=2 option in
combination to my style-file. If I use --location-autofill=1 there is no
problem. So clearly there is a bug in --location-autofill=2, previously
I always used --location-autofill=1 therefore I had not problems with
mkgmap
On 14.03.2010 23:18, Mark Burton wrote:
Felix,
Ups, sorry. I don't understand why it ran through using the default
style, but it is hanging on the templates.args file which seems to be
the real culprit.
If I run mkgmap with *.osm.gz for map input, it runs through fine. If
however I use
Hi Someoneelse,
Is 6140565 the last name in the .osm file being processed at that
time? I've seen a similar effect with all unnamed natural=peak being
named YHA Ravenstor (which happened to be the last name in the file
that I was processing at the time). As to how to fix it; haven't a
Chill Felix,
Sorry, I had a syntax error here that caused mkgmap to pass when not
using template.args (and outputting a 0kb map). It's using
location-autofill=2 and my style-file which will cause mkgmap to get
stuck on kosovo (as well as on some more countries like recently Slovakia).
I
Felix,
The problem is triggered by the fact that in your style file you give
anonymous roads of the same type, the same name i.e. 'rd', 'trk',
'ucl', etc. So the map ends up containing lot's of roads with the same
names. The kosovo map contains a huge number of anonymous roads.
The code that is
Mark,
I don't know what is causing the SEGV but have you tried using another
runtime? Perhaps, it's a problem in OpenJDK.
# Java VM: OpenJDK 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 )
Indeed, I tried Sun JVM and everything went fine.
Thanks,
N.
running on linux?
Java is crashing a lot more for me there. mkgmab does well but running multiple
jobs in parallel produces random crashes. also osmosis crashes on one special
use case but runs fine on a Mac.
and it happens on the Sun and OpenJDK virtual machine.
On 14 Mar 2010, at 8:41 , Nakor
20 matches
Mail list logo
