December 2013 - mkgmap-dev - The mkgmap lists

Commit: r2889: added unit test to make sure that Java2DConverter now really
by svn commit 18 Dec '13

18 Dec '13

Version mkgmap-r2889 was committed by gerd on Wed, 18 Dec 2013 added unit test to make sure that Java2DConverter now really returns shapes with identical start and end points

1 0

Commit: r2888: now really make sure that returned shapes begin and end with identical
by svn commit 18 Dec '13

18 Dec '13

Version mkgmap-r2888 was committed by gerd on Wed, 18 Dec 2013 now really make sure that returned shapes begin and end with identical points. Added unit test to verify special cases with equal points

1 0

Commit: r2887: revert changes from r2885
by svn commit 18 Dec '13

18 Dec '13

Version mkgmap-r2887 was committed by gerd on Wed, 18 Dec 2013 revert changes from r2885 Can cause big empty triangles in sea, don't know yet why

1 0

Commit: r2886: Revert the part of r2762 where the command line code-page overrides the declared one.
by svn commit 17 Dec '13

17 Dec '13

Version mkgmap-r2886 was committed by steve on Tue, 17 Dec 2013 Revert the part of r2762 where the command line code-page overrides the declared one. The warning that the command line and declared CodePage are different is still printed although there may not be anything actually wrong with that. And you may still wish to know.

1 0

Commit: r2885: make sure that returned shapes begin and end with identical points
by svn commit 17 Dec '13

17 Dec '13

Version mkgmap-r2885 was committed by gerd on Tue, 17 Dec 2013 make sure that returned shapes begin and end with identical points This has an influence on routines like BoundaryRelation.

1 0

Style processing
by Gerd Petermann 17 Dec '13

17 Dec '13

Hi, I just wonder why we use the rules in polygons AND lines for a way that is not closed (in OSM) If I got that right, the way should only be processed with the rules in lines ? Gerd

2 2

[Patch v1] road-name-pois
by Gerd Petermann 17 Dec '13

17 Dec '13

Hi all, I am not sure if the --road-name-pois option is still used. The option tries to adds a poi for each road name. The code uses the Coord.equals() to detect whether to different road segments with equal names are connected or not. The test is not 100% correct, as it should test whether the points are connected in the road network. Interesting is that I found quite a lot of places in my test data where two such roads are NOT connected in the road network. I don't know if the mergeroads branch prints a warning for this case? Attached is a patch that writes warning messages to the log if it detects that special case, but I think it would be better to have that also without option --road-name-pois . What do you think? Gerd

2 1

Commit: r2883: Store CoordNode instead of nodeid in IdentityHashMap.
by svn commit 17 Dec '13

17 Dec '13

Version mkgmap-r2883 was committed by gerd on Tue, 17 Dec 2013 Store CoordNode instead of nodeid in IdentityHashMap. This avoids the creation of different CoordNode instances with equal ids. It also reduces memory requirements a little bit as we don't have to create many thousands of additional Integer instances for a typical road network. No change in output expected.

1 0

Questions about carpool handling
by WanMil 09 Dec '13

09 Dec '13

Hi, I am still very irritated about the meaning of the carpool bit of every road. The handling in the trunk is not consistent. It is handled in the following way and order: access=yes/1/true => carpool bit is cleared access=no/private => carpool bit is set carpool=yes/1/true => carpool bit is cleared carpool=no/private => carpool bit is set mkgmap:carpool=yes/1/true => carpool bit is cleared (emergency and bus is also cleared, all other bits are set) Some examples: highway=primary;access=yes the carpool bit is not set highway=primary the carpool bit is set highway=primary;carpool=yes the carpool bit is not set highway=path;access=no;foot=yes the carpool bit is set highway=secondary;mkgmap:carpool=yes the carpool bit is not set Can anybody explain how the carpool bit works? And how mkgmap should handle this bit? It should be handled correctly in the mergeroads branch. I found some threads which did not give the complete solution for me: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q4/005873.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/006277.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q4/012919.html Also a lot of threads complaining about non reliable carpool handling. I think above examples are a good explanation for this. WanMil

3 10

Commit: r2852: revert unintended change
by svn commit 01 Dec '13

01 Dec '13

Version mkgmap-r2852 was committed by gerd on Sun, 01 Dec 2013 revert unintended change

3 2