May 2014 - mkgmap-dev - The mkgmap lists

Commit: r3261: simplify code, no functional change
by svn commit 07 May '14

07 May '14

Version mkgmap-r3261 was committed by gerd on Wed, 07 May 2014 simplify code, no functional change

1 0

Commit: r3260: improve throughput of DouglasPeuckerFilter
by svn commit 07 May '14

07 May '14

Version mkgmap-r3260 was committed by gerd on Wed, 07 May 2014 improve throughput of DouglasPeuckerFilter don't create copy of shape/line if no point was removed

1 0

Resource leaks
by Gerd Petermann 06 May '14

06 May '14

Hi programmers, Eclipse complains about a lot places in the source code., e.g. "Resource leak: 'fmt' is never closed SyntaxException.java /mkgmap/src/uk/me/parabola/mkgmap/scan line 45 Java Problem" The code looks like this: public String getMessage() { Formatter fmt = new Formatter(); fmt.format("Error: "); if (fileName != null) fmt.format("(%s:%d): ", fileName, lineNumber); fmt.format(super.getMessage()); return fmt.toString(); } The message disappears if I change the last line to this: String res = fmt.toString(); fmt.close(); return res; Does anybody know if this can really improve something? Gerd

3 2

--check-styles
by UliBaer 06 May '14

06 May '14

Hi, with the latest version (3248) of mkgmap i get a lot of following errors: SCHWERWIEGEND (StyledConverter): 66923125.o5m: Non-routable type 0x26 in combina tion with road_class/road_speed used for routable map. Try --check-styles to che ck the style. When i run checkstyles, it complains about types 26, 27, 2e and 2f used in the style file (kleineisel, btw.). The generated map works as expected on a Vista HCx and with version 3234 these errors do not occur? -- View this message in context: http://gis.19327.n5.nabble.com/check-styles-tp5805213.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 4

mkgmap ToDo list
by Gerd Petermann 06 May '14

06 May '14

Hi all, the last months brought a lot of improvements, but there is still a lot to do: Before summer I only plan to improve readability/stability and maybe performance of code:use one internal representation for vehicles (mkgmap:car, mkgmap:bicycle,...) and only translate it to the img format when writingCreate a new class that combines a converted Way, the reference to the GType, and fields required for the creation of MapRoad objects. I think ConvertedWay is a good name for this. This should be used in StyledConverter, WrongAngleFixer, and RoadMerger.The RuleIndex might be a lot faster if we search for keys first and in a 2nd step for values. This would avoid millions of temporary StringBuilder objects. Other ideas that should not be forgotton: improve handling of motor_vehicle=* and vehicle=* in default style (WanMil and Mario Hantschke are working on that) manage drive-on-left/drive-on-right in resources\LocatorConfig.xmldetect sharp angles at road junctions and either change the heading values or add small arcsconditional includes in style files and/or if else statements error handling : set non-zero return code if the map (or at least one tile) is not usableimprove reader for polish input data: correct handling of mulitple DATAx lines rewrite MapSplitter so that overlaps are kept small. This should improve rendering speed in the devices. rewrite classes that hold information about map objects, esp. shapes. Idea: store information about outer way and holes as lists of points, similar to mp-relationsimplement methods that return the simplified object for a given resolution. If the area enclosed by the outer line is not visible at resolution x, ignore the object. If a hole is not visible at resolution x, ignore it. If both are visible, connect the simplified outer and inner lines so that holes are displayed in the map. This should all be doable without complex area operations.merge shapes before splitting the map into sub areasoptimize wrong angles in shapes with the same algo that is used for lines Expected result: fewer and less distorted shapes, smaller img file. The order of the 2nd list represents my assumption regarding complexity, not importance. I think the last 3 (bold) points can only be done together, but I'd like to be proven wrong. Is something important missing? @Steve: Maybe we should keep this list somewhere at http://www.mkgmap.org.uk/ and try to maintain it? Gerd

8 53

Commit: r3258: merge the performance2 branch
by svn commit 06 May '14

06 May '14

Version mkgmap-r3258 was committed by gerd on Tue, 06 May 2014 merge the performance2 branch

1 0

message "There is not enough room ..."
by Gerd Petermann 05 May '14

05 May '14

Hi all, up to now mkgmap prints There is not enough room in a single garmin map for all the input data The .osm file should be split into smaller pieces first. to stderr without using the normal log format like this: Schwerwiegend (BufferedImgFileWriter): 63240006.o5m: There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. The latter version tells you what input file is causing trouble. I think that's much better, but maybe there is a reason for not doing this? Gerd

2 1

duplicate evaluation of tags
by Gerd Petermann 05 May '14

05 May '14

Hi all, there is still potential for optimisation: To be able to create an index which gives all rules for a tag like surface=gravel, we order the expressions in the rules so that they start with a tagkey=* or tagkey=value. We use the existing tags of an element to find the rules that have to be checked. Now, if we find two rule like surface=gravel | surface=cobblestone {...} surface=* & surface ~'(abc|xyz)' {...} after searching for rules with tagkey surface=gravel we should save the info that the 1st term in the expression is true. However, there is more to it: Other rules may delete or chang the tag surface=gravel, so this may require too much logic. Maybe it can be done with the new cacheId. Gerd

1 0

r3257 in performance2 branch
by Gerd Petermann 04 May '14

04 May '14

Hi all, today I've fixed one error and added a few more improvements. I've tested r3257 with the styles from Minko, Bernd, Henning and the default style and found no changes between trunk r3248 and the branch, but I only used some tiles from Germany to test. If I hear no complains (and don't find errors) I'll merge to trunk on tuesday. Gerd

1 0

error in performance2 branch
by Gerd Petermann 04 May '14

04 May '14

Hi all, I found an error in the branch regarding the detection of common expressions in or-combined expressions like this: landuse=abc | man_made = xyz [0x640c resolution 23 continue] I'm looking for a fix now... Gerd

1 1