January 2010 - mkgmap-dev - The mkgmap lists

Commit: r1524: Let the background polygon (type 0x4b) cover the whole map area.
by svn commit 10 Feb '10

10 Feb '10

Version 1524 was commited by markb on 2010-01-28 13:25:35 +0000 (Thu, 28 Jan 2010) Let the background polygon (type 0x4b) cover the whole map area.

4 5

Text format for TYP files
by Marko Mäkelä 07 Feb '10

07 Feb '10

This may be slightly off-topic, I think that it could be useful to have a repository of TYP files and associated style definitions. For example, a TYP file would be necessary to define a custom line style for displaying bus route information on a separate map layer. It seems that http://cypherman1.googlepages.com/genTYP is the "de facto" text format of TYP files. According to the home page, the latest release was about 3 years ago. The web based TYP file editor at http://ati.land.cz/gps/typdecomp/ is more recent, but its text output does not seem to be able to export all the definitions that the editor is able to create. Some of the source code is available, but there are very few comments (some in Chech) and no example of usage. I was not enough of a Perl expert to figure out how to input the binary TYP data for decompilation. For what it is worth, I tried the following, but my call signature of the as_string method is obviously wrong. #!/usr/bin/perl require "source.cgi"; undef $/; $_=<>; print Garmin::TYP::as_string($_); I wonder if there are any other tools that make use of the genTYP format. A textual format like genTYP's (with XPM graphics) would be ideal for a TYP file repository. It would be easy to change parameters (such as Family ID) and copy definitions between TYP files with any text editor. Any thoughts? Would it be worthwhile to reimplement the genTYP txt/TYP encoder/decoder in Java? It should not be too hard, given that an XPM library already exists at <http://www.bolthole.com/java/Xpm.html>. Marko

6 17

some comments on mkgmap default style
by maning sambale 06 Feb '10

06 Feb '10

Hi, some observation about the default style: 1. Coastlines are shown as thin blue lines, is it possible to render coastline as polygon, where sea areas are shaded as blue. A work around I did before is to manually edit all sea-areas and then add a natural=water tag (bad data edit) . 2. Administrative boundaries clutter the map. They appear like roads and can be confusing while driving. Suggestion is to make the admin boundaries thinner. Hope it helps improving the default stylesheet. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

5 8

Missing cities in mapsource search entry field
by Mark Burton 02 Feb '10

02 Feb '10

Hi Steve, I don't really use the search facility in mapsource much so I can't say if it's always been like this (since the MDX stuff arrived) or whether it's due to the latest changes but I notice that when searching for cities in the UK map (no funky accents in the names to confuse the issue) that great swathes of names are not recognised in the name entry box (mapsource just goes 'bong' and ignores your input) even though the names are in the map. For example, if I type 'm' it shows a list of names and the first entry is 'Mod Abbey Wood' and the next entry is 'Mabe' which can't be right if they are meant to be in alphabetic order. If you then type 'o' it shows a list of names with the 'mo' prefix but, interestingly 'mod abbey wood' isn't among them. So that's weird. If you type 'a' after the 'm', it goes bong and you don't get any names. It's as if the 'mod abbey wood' is in the wrong position in the list? If I type 'ba' and then find, it pops up a "mapsource app error dialog". Mark

6 15

Commit: r1537: Initial code for the SRT file.
by svn commit 01 Feb '10

01 Feb '10

Version 1537 was commited by steve on 2010-01-29 13:26:12 +0000 (Fri, 29 Jan 2010) Initial code for the SRT file. Not used by anything else yet.

3 3

Patch for splitter rounding
by Mark Burton 01 Feb '10

01 Feb '10

I tried to commit the attached patch that changes the splitter's area rounding to match mkgmap's new behaviour when rounding the overview map bounding box but I wasn't allowed to do it. Could someone please commit this for me. Mark

2 2

Commit: r1543: More specific warnings for multipolygons
by svn commit 31 Jan '10

31 Jan '10

Version 1543 was commited by marko on 2010-01-31 22:16:31 +0000 (Sun, 31 Jan 2010) More specific warnings for multipolygons (intersections, exchanged inner/outer roles). Self intersecting polygons are now handled as multiple polygons instead of using only the first polygon Inner polygons that are not contained by any outer polygons are dismissed now. There is a high probability that inner/outer roles are exchanged or that the inner polygon does not belong to the multipolygon. Remove polygon tags from unclosed ways because sometimes they are closed later in mkgmap. WanMil

1 0

[PATCH v1] More specific log messages in mp
by WanMil 31 Jan '10

31 Jan '10

* More specific warnings for multipolygons (intersections, exchanged inner/outer roles) * Self intersecting polygons are now handled as multiple polygons instead of using only the first polygon * Inner polygons that are not contained by any outer polygons are dismissed now. There is a high probability that inner/outer roles are exchanged or that the inner polygon does not belong to the multipolygon. * Remove polygon tags from unclosed ways because sometimes they are closed later in mkgmap. WanMil

2 2

Bug in rounding when using level 0 with resolution 23
by Felix Hartmann 31 Jan '10

31 Jan '10

When using resoluton=23 for level=0 rounding of streets and other objects can go pretty wrong. Or is this just the general rounding problem we have? Principally I think resolution23 should be enough (4.8m accuracy, vs 2.4m accuracy on resolution24) for general use. Using resolution24 I have never seen points getting rounded wrongly (so that a street seems to be broken). Routing is not affected however (no difference at all). I don't understand how one point (a junction of a way is certainly one point), gets rounded to two different places. Neither of the two following options helps/changes anything here: It is not related to the Douglac Peucker algorithm: --reduce-point-density=0 --reduce-point-density-polygon=0 (results in no visual change). It is also not related to --adjust-turn-headings

1 0

Commit: r1540: Change the signature of resolveType so that continue
by svn commit 31 Jan '10

31 Jan '10

Version 1540 was commited by steve on 2010-01-30 13:52:44 +0000 (Sat, 30 Jan 2010) BRANCH: style Change the signature of resolveType so that continue can be implemented. Continue works. But not without actions (ie it is as if without_actions is always given).

5 5