- mkgmap-dev - The mkgmap lists

Capters 4.6.2 and 4.6.7 of doc style
by Ataro A 10 Jan '14

10 Jan '14

Capter 4.6.2 at the end of page 23, after 'Resolution ranges.' in the example i read type 0x06 and 0x07, but in subsequent description text i read type 0x08 and 0x09. In the capter 4.6.7 , the example [0x2 road_class=3 road_speed=5 level .... are too long and should divided on another row.

1 0

Capters 4.3.7 and 4.3.8 of style doc
by Ataro A 10 Jan '14

10 Jan '14

The text { add mkgmap:foot=no; ...... and { set mkgmap:foot=no; ...... have to be splitted in two row each one. Now is unreadable at end of line.

2 1

Commit: r2957: Documentation: some fixes
by svn commit 10 Jan '14

10 Jan '14

Version mkgmap-r2957 was committed by wanmil on Fri, 10 Jan 2014 Documentation: some fixes -- Ataro A

1 0

style doc capter 4.3.1
by Ataro A 10 Jan '14

10 Jan '14

In the capter '4.3.1 add' of style manual, the text and the examples after the row 'You can also use substitutions.' seems explain the set command, not the add one

1 0

NullPointerException when compiling a TYP file
by paco.tyson＠free.fr 10 Jan '14

10 Jan '14

Hi all, I created my TYP file with the latest TYPViewer. I can compile it using this tool. However, mkgmap fails with a NullPointerException : java.lang.NullPointerException at uk.me.parabola.imgfmt.app.typ.Xpm.writeImage(Xpm.java:43) at uk.me.parabola.imgfmt.app.typ.TypElement.writeImage(TypElement.java:206) at uk.me.parabola.imgfmt.app.typ.TypPoint.write(TypPoint.java:53) at uk.me.parabola.imgfmt.app.typ.TYPFile.writeSection(TYPFile.java:168) at uk.me.parabola.imgfmt.app.typ.TYPFile.write(TYPFile.java:70) at uk.me.parabola.mkgmap.main.TypCompiler.writeTyp(TypCompiler.java:145) at uk.me.parabola.mkgmap.main.TypCompiler.makeMap(TypCompiler.java:102) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:243) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:239) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:695) Exiting - if you want to carry on regardless, use the --keep-going option I found the culprit to be a blank POI : [_point] Type=0x02f03 String1=0x04,XXXXX String2=0x03, String3=0x02, String4=0x01,YYYYY ExtendedLabels=Y FontStyle=SmallFont CustomColor=Day DaycustomColor:#00008B DayXpm="0 0 0 0" [end] If I select the "Bitmap" checkbox, TYPViewer generates the POI like this : [_point] Type=0x02f03 String1=0x04,XXXXX String2=0x03, String3=0x02, String4=0x01,YYYYY ExtendedLabels=Y FontStyle=SmallFont CustomColor=Day DaycustomColor:#00008B DayXpm="16 16 2 1" Colormode=16 "! c #FFFFFF" " c none" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " ;1234567890123456 [end] This format compiles just fine. http://www.mkgmap.org.uk/doc/typ-compiler says : "In particular the files produced by TYPWiz and TYPViewer are supported." So, is this a bug in mkgmap or TYPviewer ? Thanks, Paco

3 3

Loops in roads
by GerdP 08 Jan '14

08 Jan '14

Hi Steve, I must confest that I don't fully understand why a loop is causing trouble with routing. Of course, a very simple loop without any exit point is a problem, but why also normal roundabouts? In NOD, we save only parts of the roundabout, so NOD doesn't "see" a loop. Is the reason that we save the way as one polyline in NET and that it has only one ref to NOD? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Loops-in-roads-tp5791854.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 3

Software design question
by Gerd Petermann 08 Jan '14

08 Jan '14

Hi, while working on the ShapeMergeFilter I found this because I wanted to add a field for the OSM id: MapShape extends MapLine which extends MapElement. I wonder if that makes sense as MapElement contains 8 fields which are not usable with shapes: private String zip,country,region,city,street,phone,houseNumber,isIn; Esp. with small shapes like small buildings these fields are quite a big memory overhead. Doesn't Java offer a better solution for this case? Gerd

1 0

Address (street) search for latin countries in plain gmapsupp.img
by Enrico Liboni 06 Jan '14

06 Jan '14

Hi, this is an old thread... until this is properly fixed in the index I'd like to share a trick I'm using to generate a gmapsupp.img file where it's convenient to search for a street name in latin countries (I'm a linux user, no mapsource/basecamp). The issue is, in most latin countries streets are named after real people and in OSM are entered with their full name, i.e. something like "Via Wolfgang Amadeus Mozart" (Via means Street): when looking for the street one need to type "Via Wol..." and the issue is usually one knows the most meaningful name of the street - Mozart in this case - rather than the full name. And it is boring to type always "Via..." The below does the job: the most meanigful street word (the last one) is set as first one just in the labels used for address search, i.e.: 'Via Wolfgang Amadeus Mozart' becomes 'Mozart, Via Wolfgang Amadeus' when doing address search while the label displayed on the map remains unchanged: # Add this in inc/address (just after mkgmap:country has been set) # Get the last full word if a \s (whitespace) exist in name ( mkgmap:country=ITA | mkgmap:country=FRA | mkgmap:country=CHE) & highway=* & name ~ '.*\s.*' { set last:word='${name|part: :-1}' } # if the last full word is a roman number - i.e. if a street has been named after a King or a Pope - get the last two words last:word ~ '(I|II|III|IV|V|VI.*|IX|X|XI.*|XV.*|XX.*)' {set last:word='${name|part: >-3}' } # set 3rd and 4th labels (used for address search only) with the last:word as 1st word last:word=* { set mkgmap:label:3='${last:word}, ${name|part: <-1}';set mkgmap:label:4='${last:word}, ${name|part: <-1}' } Hope it helps! Enrico

1 0

Diagnostic warnings for dead-end oneway highway=service
by Marko Mäkelä 06 Jan '14

06 Jan '14

There are some dead-end highway=service,oneway=yes that trigger dead-end-check warnings in mkgmap RouteNode.java. To allow suppressing most of the warnings, years ago I added a check that suppresses the warning if either end node of the way is tagged with fixme=* or FIXME=*, such as fixme=continue. This is not always applicable, for example when the oneway highway=service is leading to a tunnel, which is omitted from the map in order to avoid clutter (such as ways for underground parking) in city areas. I figured out that it would be nice to display all tags of the dead-end oneway, like we do in MultiPolygonRelation, so that my mkgmap wrapper script could filter out any oneway warnings for highway=service. Unfortunately, the RoadDef is in the Garmin domain, and there is no RoadDef.toTagString() method. Any ideas how to improve the diagnostics? Marko

3 28

Unit tests in trunk fail
by Gerd Petermann 06 Jan '14

06 Jan '14

Hi WanMil, please have a look, I don't fully understand why. Gerd

2 9