[mkgmap-dev] Merge the mergeroads branch?

Tue Dec 10 16:59:01 GMT 2013

Hi Gerd,

great! I could not test yet but will do tomorrow.

I am thinking about if it is possible to move the handling to a place 
before the merger? The RoadMerger would not have to care about this 
option and could also merge roads that were splitted gratuitous by the 
link-poi-to-ways handling.

I encountered with r2868 that ways (at least sometimes) seems to be 
splitted twice on a POI.
Example:

x111x111x1111P111x11x111x
=>
x111x111x2222P333x44x444x

x = Point
P = POI which splits the way in the link-pois-to-way handling
n (number) = id of the way to visualize the splitting

This might be remerged by the RoadMerger
x111x111x2222P222x44x444x

WanMil

> Hi WanMil,
>
> I've committed a fix for the link-poi-to-ways option. With r2867 the POI
> of merged ways were ignored.
> (An alternative to the mkgmap:way-poi-node-ids tag would be
> a HashSet<Node> in class Way which is only initialised when used.
> Maybe that would be clearer?)
>
> I also tried to implement the solution that you suggested here:
> http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778414.html
> in the high-prec-branch.
>
> It looked simpler, but it turned out that the code to save the original
> positions of CoordPOI and later the restoring of the info was
> much more complex than the treatment in the replace routine.
>
> I think the only problem that can occur with the implementation in r2869
> is when two CoordPOI are merged. This is very unlikely, and the
> corresponding
> error is very small.
>
> Gerd
>
>  > Date: Mon, 9 Dec 2013 19:59:33 +0100
>  > From: wmgcnfg at web.de
>  > To: mkgmap-dev at lists.mkgmap.org.uk
>  > Subject: [mkgmap-dev] Merge the mergeroads branch?
>  >
>  > I think the mergeroads branch is "functional complete". I want to know
>  > if you are happy with all changes?
>  >
>  > In such a case I would start to document the changes which need to be
>  > done before merging the changes to the trunk.
>  >
>  > A short overview of the changes:
>  > * Roads are merged which reduces the number of road entries by 7-25%
>  > using the default style. This results in slightly better routing
>  > calculation times and slightly smaller img file sizes.
>  > * The four labels to pois/lines/roads/polygons are no longer assigned
>  > automatically. They must be assigned using the 'name' and 'addlabel'
>  > function. This also means that ref tags are no longer used as labels
>  > automatically.
>  > * Access restrictions of roads are now defined by setting special
>  > mkgmap:** access tags (e.g. mkgmap:car, mkgmap:foot, mkgmap:bicycle
> etc.).
>  > * mkgmap:carpool does no longer automatically set all access
>  > restrictions. In the trunk mkgmap:carpool=yes/1/true lead to set all
>  > access restrictions to "no" except emergency, bus and carpool.
>  > * The road speed is no longer automatically calculated using the
>  > maxspeed tag. New style functions maxspeedkmh() and maxspeedmph() allow
>  > style developers to perform the same by setting the
>  > mkgmap:road-speed-class tag.
>  > * Styles can now have a <finalize> block. This block is executed for
>  > each element if an element style definition matches. The finalize block
>  > must contain actions only.
>  >
>  > There is no need to convert the "old" style files instantly when adding
>  > compatibility include files to the finalize block. Example for the lines
>  > file:
>  > <finalize>
>  > include 'inc/compat_lines';
>  >
>  > Anyhow I strongly propose to use the new degree of freedom in assigning
>  > access restrictions etc. In case you are not convinced about the new
>  > features just open the compatibility includes and you will see that
>  > access handling in the trunk has some shortcomings.
>  >
>  > WanMil
>  > _______________________________________________
>  > mkgmap-dev mailing list
>  > mkgmap-dev at lists.mkgmap.org.uk
>  > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>