- mkgmap-dev - The mkgmap lists

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

Commit: r1566: Drop all tags from the osm file that are not used
by svn commit 12 Feb '10

12 Feb '10

Version 1566 was commited by steve on 2010-02-08 12:33:09 +0000 (Mon, 08 Feb 2010) BRANCH: style-speed Drop all tags from the osm file that are not used in the applied style. Whether this makes a big difference or not depends on the country. In the UK which is mostly manually taged it doesn't make a great deal of difference. There are only an average of 2 tags per way and about zero per node. In countries with data imports, there are typically many tags per way (and even nodes) that refer back to the original data. Having tags on nodes is particularly bad for memory consumption since there are more nodes than ways and most are not POIs. We are forced to allocate a Tags object even though there is likely to be nothing to do as none of the tags are used. Denmark is the worst in this respect and so will show the best improvement with this patch. See also: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/003597.html For this to be successful you need an acurate list of all the tags that could be used. Tags are examined not just in the style itself, but there are hardwired tag lookups in the style system itself and there are non-style related usages as well. For the moment all the built in usages of tags are held in the builtin-tag-list file. I think I have got them all for normal use, but there may be options that require ones I've missed.

8 11