[mkgmap-dev] mkgmap ToDo list

Wed Apr 16 20:52:47 BST 2014

Hi Gerd,

Bugfix: Internal oneway handling
At the moment all oneway ways are normalized to onway=yes (they are 
reversed when they are tagged with oneway=-1). But all other tags are 
left untouched. So that will be something like 
http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayTagCorrector.java

RFE: Parameters for style functions
maxspeedkmh() evaluates the maxspeed tag only.
It might be useful to have something like kmh(${maxspeed:forward}).

WanMil

> 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:
>
>      1. use one internal representation for vehicles (mkgmap:car,
>         mkgmap:bicycle,...)
>         and only translate it to the img format when writing
>      2. Create 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.
>      3. 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.xml
>   * detect sharp angles at road junctions and either change the heading
>     values or
>     add small arcs
>   * conditional 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 usable
>   * improve 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:
>       o store information about outer way and holes as lists of points,
>         similar to mp-relations
>       o implement 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.
>       o merge shapes before splitting the map into sub areas
>       o optimize 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
>
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>