- mkgmap-dev - The mkgmap lists

[Patch v2] set program return code and improve logging
by Gerd Petermann 07 May '14

07 May '14

Hi all, attached is version 2 of the patch. Changes to v1: - change Main.main to Main.mainStart() which returns an int - let Main.main call mainStart() and use System.exit(1) in case of errors - let unit tests call Main.mainNoSystemExit() which doesn't call System.exit(). - synchronized -> volatile for access of field programRC For version 1 see http://gis.19327.n5.nabble.com/Patch-v1-set-program-return-code-and-improve… If I hear no complains I'll commit it on friday. Gerd

1 0

[Patch v1] set program return code and improve logging
by Gerd Petermann 07 May '14

07 May '14

Hi all, attached is a patch the should set program return code to 1 in case of severe errors. It also changes the handling of so called MapFailedExceptions like "There is not enough room in a single garmin map..." or "Overflow of the NET1. The tile ..." These messages are now printed as severe messages via the logging system (showing the input file): Severe (MapFailedException): \ld_sp\63240003.o5m: (thrown in BufferedImgFileWriter.ensureSize()) 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 stdout contains two new messages: Number of MapFailedExceptions: 3 Number of ExitExceptions: 0 If any of the two shows a non-zero value, the program exits with return code 1. @WanMil, Steve: Please review. In Main.java I use "synchronized" to make sure that concurrent updates are handled. The System.exit() method is only used if the program is not called from another java program. The code In MapFailedException.log() tries to determine the code that caused the Exception. I hope this works in all environments? Gerd

3 5

Commit: r3262: small performance improvements: use compiled tags in a few more places
by svn commit 07 May '14

07 May '14

Version mkgmap-r3262 was committed by gerd on Wed, 07 May 2014 small performance improvements: use compiled tags in a few more places

1 0

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