February 2010 - mkgmap-dev - The mkgmap lists

Confusing results when uploading.
by Dave F. 15 Feb '10

15 Feb '10

Hi When using this command line: java -Xmx512M -ea -jar mkgmap.jar --transparent --style-file="c:\dwgs\Programs\GPS All\Garmin Profile" --family-id=42 M000002.TYP 63272002.gz it creates a 63272002.img using my customized styles & when uploaded appears as I would expect. But when I use the same file to be included in the gmapsupp file in this command the 63272002.img displays as if it was created using the built in style of mkgmap: java -Xmx512M -ea -jar mkgmap.jar --remove-short-arcs --gmapsupp "Contours.img" "63272002.img" --generate-sea:polygons --transparent --style-file="c:\dwgs\Programs\GPS All\Garmin Profile" --family-id=42 M000002.TYP MyTown.osm move "C:\dwgs\Programs\GPS All\mkgmap\gmapsupp.img" "L:\Garmin" Any ideas as to why this is? Cheers Dave F.

3 3

Contour lines always visible
by Carlos Dávila 15 Feb '10

15 Feb '10

1 1

administrative borders (was: multipolygon with outer polygon within inner polygons)
by Minko 14 Feb '10

14 Feb '10

Hi all, It looks like I managed a way to render those complex multipolygon administrative borders correctly now. In the relation style file, I changed administrative borders statements like this: # country borders (type=boundary | type=multipolygon) & boundary=administrative & admin_level=2 { apply { set boundary2=yes; set mkgmap:boundary2_name='$(mkgmap:boundary2_name)/${name}' | '${name}'; } } For my map of the Netherlands, I'm only interested in admin levels 2,4 and 8 (country/province/municipality) so I copied those lines for provinces (set boundary4=yes for the lines and boundary4_name for the names) and municipalities (set boundary8=yes and boundary8_name) too. I'm not sure if mkgmap: has any function, maybe without this it will function as well? In the line style file, I removed all the statements regarding to the admin. borders and replaced it with these lines: boundary2=yes { name '${mkgmap:boundary2_name}' } [0x1e resolution 16] boundary4=yes { name '${mkgmap:boundary4_name}' } [0x1d resolution 18] boundary8=yes { name '${mkgmap:boundary8_name}' } [0x1c resolution 20] I tested it with the complicated area, and it seems rendering fine now :-)

3 3

Re: [mkgmap-dev] Wrong multipolygon warnings
by Carlos Dávila 14 Feb '10

14 Feb '10

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 >> screenshots. Also those supposed to be corrected during compilation are >> missing, for example this one: >> Polygon 4611686018427389034 intersects itself. It is splitted into 3 >> polygons. >> (MultiPolygonRelation): 63240002.osm.gz: The polygon is composed of >> (MultiPolygonRelation): 63240002.osm.gz: - >> http://www.openstreetmap.org/browse/way/4889848 >> >> I also attach the log from compilation, unpatched and patched. >> >> Carlos >> > Carlos, > > thanks for your feedback. I added a very silly error to patch 2 which > was not in patch 1. At some point long and lat was exchanged. Sorry > for that! > > Attached is version 3 of the patch which works for me. I have tested > spain and had a look on mp 319017 which does not have any warnings now. > > Please give feedback if you find any other issues. Back to the list. This new patch worked fine. Now all multipolygons are where they are supposed to be and most warnings have disappeared. I attach your patch to share it with the list. Carlos

2 1

Which .osm nodes/elements/attributes does mkgmap use & ignore?
by Dave F. 14 Feb '10

14 Feb '10

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 the user, usid, version or changeset attributes? Is there a wiki page that I've missed, that lists this info? Cheers Dave F.

3 3

Commit: r1571: Correct size of Table C size field when size is in the range 0x80 to 0xff.
by svn commit 13 Feb '10

13 Feb '10

Version 1571 was commited by markb on 2010-02-13 22:42:27 +0000 (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 to 16 bits until the table size reaches 0x100.

1 0

Commit: r1570: Now copes with up to 0x100 entries in Table B (limit was 0x40).
by svn commit 13 Feb '10

13 Feb '10

Version 1570 was commited by markb on 2010-02-13 22:42:24 +0000 (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.

1 0

Slightly OT: TYP files, lines with borders
by Charlie Ferrero 13 Feb '10

13 Feb '10

Hi all, Many people have created TYP files that define lines to have borders, to make them look more like paper maps (e.g. the UK's OS series). This looks fine in Mapsource, but in the GPS unit things go horribly wrong (see screencap). In effect, the GPS draws the border *perpendicular* to the way in question every time it encounters the end of a wayed segment. Given that in OSM ways are usually composed of multiple segments joined together, this means that ways on the GPS are a horrible collection of little "worms" all joined together. The resulting effect is unusable. But as I say, this doesn't happen at all in MapSource (second screenshot). Is this a known problem with TYPs, line definitions with borders and (certain?) Garmin GPS units or am I doing something silly? -- Charlie

6 7

Re: [mkgmap-dev] Slightly OT: TYP files, lines with borders
by Minko 13 Feb '10

13 Feb '10

I have the same "worms" like Charlie describes on my Etrex Venture Cx, it looks better when you dont use borderlines in your TYP file alongside the roads (so no bitmap, just lines of x pixels wide. On the Nüvi or on a Garmin Dakota, those "worms" are not visible at all, so with those units the maps look better with borderlines, just like in Mapsource.

1 0

Wrong multipolygon warnings
by Carlos Dávila 12 Feb '10

12 Feb '10

2 8