January 2014 - mkgmap-dev - The mkgmap lists

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

Commit: r2946: Write the node count for a road in the NET1 section.
by svn commit 05 Jan '14

05 Jan '14

Version mkgmap-r2946 was committed by steve on Sun, 05 Jan 2014 Write the node count for a road in the NET1 section. This is used for house numbers and perhaps other things. It is set regardless of whether the road actually has house numbers. Fix a bug where the wrong bit was set if the house number bit stream was longer than 255 bytes. Likely a very rare occurrence with OSM data.

1 0

Commit: r2944: move code for report-dead-ends option to StyledConverter.
by svn commit 05 Jan '14

05 Jan '14

Version mkgmap-r2944 was committed by gerd on Sun, 05 Jan 2014 move code for report-dead-ends option to StyledConverter. This corrects problems that were introduced with the merge from the mergeRoads branch Improvements: - the real OSM way is reported - all tags of the way are reported - p-shaped oneways are reported if they are not connected to other roads - The mkgmap:dead-end-check=false tag is correctly used again - the oneway=* tag is simplified after style processing. If it is "true" or "1" it is changed to "yes", if it is "-1" or "reverse", the points of the way are reversed and the tag is changed to "yes". If finally the tag is not "oneway=yes" the tag is removed from the way. This is also done for (overlaying) lines, and it improves the RoadMerger as it allows a few more merges. - simplified "oneway=*" handling in RoadMerger

1 0