[mkgmap-dev] mkgmap ToDo list

Wed Apr 16 07:08:35 BST 2014

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140416/2492d208/attachment.html>