I think this is due to the fact that borders are not seen as lines of a
larger width plotted below the matching highway lines, unlike Mapsource
Nick
--
From: Charlie Ferrero char...@cferrero.net
Sent: Saturday, February 13, 2010 9:23 AM
To:
Hi
I'm trying to convert a .kml (google earth) to .osm so I can use mkgmap
to convert to .img.
In the .osm file I've noticed that mkgmap appears to ignore the bounds
tag.
To simplify my conversion, are there any others that aren't utilized?
For instance, in the node node does it need to have
Charlie Ferrero wrotes *on* /Sat Feb 13 09:23:30 GMT 2010/
--Is this a known problem with TYPs, line definitions with borders and
--(certain?) Garmin GPS units or am I doing something silly?
It's the first time that i see this effect.
There are two ways of giving a definition for the drawing
On 02/13/2010 10:23 AM, Charlie Ferrero wrote:
Is this a known problem with TYPs, line definitions with borders and
(certain?) Garmin GPS units or am I doing something silly?
It looks like that on my topo map, too:
http://www.kleineisel.de/blogs/media/blogs/osmmap/6.png
If you zoom in a bit
Ralf Kleineisel wrote:
On 02/13/2010 10:23 AM, Charlie Ferrero wrote:
Is this a known problem with TYPs, line definitions with borders and
(certain?) Garmin GPS units or am I doing something silly?
It looks like that on my topo map, too:
On 02/13/2010 05:08 PM, Charlie Ferrero wrote:
I'm relieved to hear it's not just me. Maybe it depends on the GPS unit?
My screenshot is from an eTrex Legend HCx.
I see the same effect on an Oregon (Firmware 3.6).
WanMil
___
mkgmap-dev mailing
Version 1570 was commited by markb on 2010-02-13 22:42:24 + (Sat, 13 Feb
2010)
Now copes with up to 0x100 entries in Table B (limit was 0x40).
For Table B index values = 0x3f, the first index byte is 0x3f plus
whatever flags are set and the second index byte is the 8 bit index value.
Version 1571 was commited by markb on 2010-02-13 22:42:27 + (Sat, 13 Feb
2010)
Correct size of Table C size field when size is in the range 0x80 to 0xff.
Although nodes require 16 bit offsets into Table C when the table size is
larger than 0x7f, the table size field must not grow from 8
WanMil escribió:
Am 13.02.2010 17:56, schrieb Carlos Dávila:
WanMil escribió:
I have attached a patch for revision 1568. Hopefully this will
work...?!?
WanMil
I reply off list because of the size of the attachments.
Your patch seems to drop many of the multipolygons as you can see in the
You're very brave to think of translating kml into osm - in theory it
shouldn't be a problem as both are txt files ; it may be that ignoring
authorship/timestamps etc can affect the creation of an img file ; perhaps
start with one node ; the bounds tag are essential for defining the area
10 matches
Mail list logo
