Maybe the word 'transparent' is a bit confusing. With transparent I don't mean
to omit line type 0x01 from the typ files at all. Like Henning said, you have
to use a bitmap pattern without colours (=transparent) in the TYP file. On top
of this, you use another bitmap with an arrow in the
On May 2, 2011, at 21:46, WanMil wrote:
So r1935 has fixed the bug. The compiled boundaries need not be
downloaded again. Additionally I committed the changes in the trunk up
to r1932.
So far my tests with r1935 have been quite good.
I do have one issue though: when I send the maps to a
Minko (ligfiet...@online.nl) wrote:
Maybe the word 'transparent' is a bit confusing. With transparent I
don't mean to omit line type 0x01 from the typ files at all. Like
Henning said, you have to use a bitmap pattern without colours
(=transparent) in the TYP file. On top of this, you
Hi,
I notice there is an extra - after /bin/osmosis --rx is that an error?
Markus_g
-Original Message-
From: mkgmap-dev-boun...@lists.mkgmap.org.uk
[mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of Lambertus
Sent: Wednesday, 4 May 2011 1:19 AM
To: Development list for mkgmap
On Wed, May 04, 2011 at 06:20:41PM +0930, Markus_g wrote:
I notice there is an extra - after /bin/osmosis --rx is that an error?
No, it tells osmosis to read from the standard input, which is being
piped from bunzip2 -c.
Marko
___
mkgmap-dev
Ok. Thanks
Markus_g
-Original Message-
From: mkgmap-dev-boun...@lists.mkgmap.org.uk
[mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of Marko Mäkelä
Sent: Wednesday, 4 May 2011 6:28 PM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Splitter output files are nearly
Hello
* Full GC *
Elapsed time: 18m 0s Memory: Current 135MB (106MB used, 29MB free) Max
MB
The 'Full GC' line is not a problem, it is a message printed by
splitter every so often before it attempts to force a garbage collect.
This is not usually a useful thing to do, but it
I have found a similar issue with the village of Achterveld, which boundaries
lies in two Provinces:
http://www.openstreetmap.org/browse/relation/302103
http://www.openstreetmap.org/browse/relation/310003
Only Achterveld in the province of Gelderland is listed on the device. Streets
in
On 2011-05-04 07:44, Marko Mäkelä wrote:
The processing time probably won't be reduced if the machine starts
swapping. Like Thorsten pointed out, it is good to leave some breathing
room for the computer.
Sure, but the machine has 8GB ram so it won't have to swap while doing
multiple things at
On 2011-05-04 11:51, Steve Ratcliffe wrote:
* Full GC *
Elapsed time: 18m 0s Memory: Current 135MB (106MB used, 29MB free) Max
MB
The 'Full GC' line is not a problem, it is a message printed by
splitter every so often before it attempts to force a garbage collect.
This is not
Hi
Just another thought ... could it be that C/H/S information should be
calculated dynamically based on the actual size of a .img-file?
Maybe this could save memory on a GPS when the tiles are loaded ... this
is speculation since I don't know exactly how this is implemented.
Yes it should be.
El 04/05/11 01:43, Francisco Moraes escribió:
On 5/3/2011 6:41 PM, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote:
Any place tagged as city/town/village should be in the cities list.
Not sure what that means. I searched for my street and it showed a near
by area with a different name than the
El 04/05/11 15:18, Steve Ratcliffe escribió:
Hi
Just another thought ... could it be that C/H/S information should be
calculated dynamically based on the actual size of a .img-file?
Maybe this could save memory on a GPS when the tiles are loaded ...
this
is speculation since I don't know
MarkS schrieb am 03.05.2011 22:58:
Would something like this work?
highway=motorway [0x01 road_class=4 road_speed=7 level 6 continue]
highway=motorway oneway=yes [0x10f01 level 6]
highway=motorway oneway!=yes [0x10f02 level 6]
Then style 0x01 with no style (so nothing is drawn) -
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg:
http://www.openstreetmap.org/browse/relation/28711
They belong to bounds_230_25.bnd but if I run the gpx converter they
are not in it.
And maybe add
België as variant to the locator LocatorConfig.xml, as
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg:
http://www.openstreetmap.org/browse/relation/28711
They belong to bounds_230_25.bnd but if I run the gpx converter they
are not in it.
And maybe add
België as variant to the locator
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg:
http://www.openstreetmap.org/browse/relation/28711
The multipolygon of the border is incorrect.
Way http://www.openstreetmap.org/browse/way/10674 is overlapping
with
I want to start to collect and commit your country specific rules. I
know some of you have already posted them on the list but I have lost
track of it.
So please post your country specific rules as an answer in this thread.
WanMil
___
mkgmap-dev
I'm sorry, i'm not familiar with those complex border relations, maybe someone
out there can fix it?
--
WanMil wrote:
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg:
http://www.openstreetmap.org/browse/relation/28711
The multipolygon of the border
Am 04.05.2011 18:40, schrieb WanMil:
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg:
http://www.openstreetmap.org/browse/relation/28711
The multipolygon of the border is incorrect.
Way http://www.openstreetmap.org/browse/way/10674 is overlapping
Netherlands:
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not
Am 04.05.2011 19:38, schrieb Minko:
Netherlands:
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
On 04/05/2011 16:11, Torsten Leistikow wrote:
MarkS schrieb am 03.05.2011 22:58:
Would something like this work?
highway=motorway [0x01 road_class=4 road_speed=7 level 6 continue]
highway=motorway oneway=yes [0x10f01 level 6]
highway=motorway oneway!=yes [0x10f02 level 6]
Then style
On Wed, May 04, 2011 at 07:02:41PM +0200, WanMil wrote:
I want to start to collect and commit your country specific rules. I
know some of you have already posted them on the list but I have lost
track of it.
So please post your country specific rules as an answer in this thread.
In Germany we have the same mess...
Actually I'm using this rules:
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level3=* { set
mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
Possibly not what you have in mind, but how about an automatic
drive-on-left for UK/Ireland/Japan/Australia/NZ/etc?
On 04/05/2011 19:02, WanMil wrote:
I want to start to collect and commit your country specific rules. I
know some of you have already posted them on the list but I have lost
This will not be fixed in the locator branch. But maybe someone else
implement such rules in the style processor.
WanMil
Possibly not what you have in mind, but how about an automatic
drive-on-left for UK/Ireland/Japan/Australia/NZ/etc?
On 04/05/2011 19:02, WanMil wrote:
I want to start
El 04/05/11 16:57, Carlos Dávila escribió:
El 04/05/11 15:18, Steve Ratcliffe escribió:
Hi
Just another thought ... could it be that C/H/S information should be
calculated dynamically based on the actual size of a .img-file?
Maybe this could save memory on a GPS when the tiles are loaded ...
Am 04.05.2011 20:32, schrieb Martin:
In Germany we have the same mess...
Actually I'm using this rules:
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level3=* { set
mkgmap:region='${mkgmap:admin_level3}' }
Am 04.05.2011 19:02, schrieb WanMil:
I want to start to collect and commit your country specific rules. I
know some of you have already posted them on the list but I have lost
track of it.
So please post your country specific rules as an answer in this thread.
WanMil
I took these out of
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
DSK_PRIVPARTITION.CPP-314-6.13.7.0
This is the same error I had when the mdr-file exceded the former fixed limit
of 256 MB.
Maybe one file is larger than the adjusted C/H/S values now specify.
Peter
___
mkgmap-dev mailing list
in addition to Minko: according to
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries
Belgium provinces should all be in admin_level 6
For Luxembourg: the cities are all in admin_level 8, the provinces (I
think the Luxembourg name 'district' comes closest) are in
El 04/05/11 21:42, Peter Lerner escribió:
DSK_PRIVPARTITION.CPP-314-6.13.7.0
This is the same error I had when the mdr-file exceded the former fixed limit
of 256 MB.
Maybe one file is larger than the adjusted C/H/S values now specify.
I don't think so. All my other maps, even the smallest
The Luxembourg country border been fixed in JOSM (nice to have
validator around!). However, still some validator errors for the France
border relations. Hopefully some French mappers step in to update these
borders.
Cheers Johan
On Wed, 04 May 2011 19:32:07 +0200, Josef Latt
Hi Wanmil, some problems using the country specific cities, maybe the
locator config has to be slightly changed:
(1) Boundary name OSM (2) Locator name (3) Result
(1) Deutschland (2) Deutschland (3) positive, can be found in Garmin
(1) Nederland (2) Nederland(3) positive,
Hi Carlos, it's my experience that skipping is_in, addr: and openGeoDB
works best for the Garmin index. What you'll then see is that some OSM
boundaries need to be improved. But getting that done will create a
perfectly working index (except for adresses, but it's always nice to
have some
Maybe one file is larger than the adjusted C/H/S values now specify.
I don't think so. All my other maps, even the smallest ones are broken
with the patched mkgmap. Did it fix the problem for you?
Can you get me a compiled jar including the fix? I'm not a dev guy ...
Peter
38 matches
Mail list logo
