December 2013 - mkgmap-dev - The mkgmap lists

Commit: r2907: allow bike and pedestrian access for barrier=gate, set speed to 0
by svn commit 23 Dec '13

23 Dec '13

Version mkgmap-r2907 was committed by gerd on Mon, 23 Dec 2013 allow bike and pedestrian access for barrier=gate, set speed to 0

1 0

Final call for merging the mergeroads branch
by WanMil 22 Dec '13

22 Dec '13

Hi all, I have added documentation for new actions and tags evaluated by the mergeroads branch. So from my point of view I am ready to merge it back. The documentation already seems to be online (http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf) I will merge to trunk on Sunday if noone vetos :-) Have fun! WanMil

4 8

Merge the mergeroads branch?
by WanMil 20 Dec '13

20 Dec '13

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

7 39

Route Restrictions
by Gerd Petermann 20 Dec '13

20 Dec '13

Hi Steve, I'd like to change the code for the --link-pois-to-ways option so that POI with access restrictions (e.g. barriers or gates) are converted to route restrictions instead of short way segments with limited access as this doesn't represent the real meaning of the POI. My problem: Current implementation doesn't support route restrictions that apply to pedestrians or emergency. On the other hand I found this link: wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/NOD_Subfile_Format#Table_C It claims that the exceptions for pedestrian and emergency is stored in the header bytes. On the other hand, it also claims that this header contains a number of ways, and I don't see that we write this. I guess mkgmap writes another format of the table C. Do you think this can be changed without much work? Gerd

3 3

Way.isClosed()
by Gerd Petermann 19 Dec '13

19 Dec '13

Hi, I think the method is incorrect. It should not use Coord.equal() to check if first and last point is equal, instead it should test if the points are identical. Sample where the current implementation fails: http://www.openstreetmap.org/way/59994654 The way has a closed loop, but first and last point are not identical because the way starts with a short segment that is not part of the loop. Gerd

4 16

why is this restriction relation ignored?
by Gerd Petermann 18 Dec '13

18 Dec '13

Hi, while debugging the I found this http://www.openstreetmap.org/relation/2560683 which seems to be ignored by mkgmap. I guess the problem could be that both ways http://www.openstreetmap.org/way/189568203 and http://www.openstreetmap.org/way/189568204 start at the via node? Gerd

3 5

Unit conversion part 2
by WanMil 18 Dec '13

18 Dec '13

Hi Steve, do you think it is possible to introduce parameters to style functions? Example: to_kmh($maxspeed) or to_mph($minspeed) This could solve the unit conversion by adding several conversion functions. WanMil

1 0

Unit conversion
by WanMil 18 Dec '13

18 Dec '13

Hi, I found the following part in the documentation: You will be able to compare quantities that have units too, for example ---- maxspeed > 30mph ---- If a different unit is given in the tag (say km/h) then it will be removed before comparison. Conversion of units is not implemented at the time of writing. I want to remove it because I think it is better not to document things which are not supported yet. Ok? WanMil

1 0

[Patch v1] distinguish equal and identical points
by GerdP 18 Dec '13

18 Dec '13

Hi, attached is a patch that should fix the remaining possible problems regarding the reported Way.isClosed() and Coord.equals() problems. It seems that the use of IdentityHashMap is a bit slower than HashMap, so throughput is a few percent slower. Open question: What is the expected result of the style function is_closed() ? @WanMil: Please test if it creates proper precompiled boundaries and sea data. @Marko: Please check if the "converting anti-island" messages are gone now. Gerd closed-equal-v1.patch <http://gis.19327.n5.nabble.com/file/n5790123/closed-equal-v1.patch> -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v1-distinguish-equal-and-identical-poi… Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 3

TYP-file can't be written
by Henning Scholland 18 Dec '13

18 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, just another problem: I got the message from mkgmap, that the TYP-file can't be written in CP1251 and CP1256. In the header of my txt-TYP-source I have written CP1252. Converting this to CP1250 and CP1254 is done without problems. So I don't understand, why it's a problem for CP1251 and CP1256. Any guesses? Henning -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSkShZAAoJEPFgsWC7jOeT/iwIAJM9g29e/69wwIer17x54nC6 u5zwjnZzIEV7vRIfmTHCe6ucFCLHjG+MDtTAq5vZVtDOQUTcvmXUYbF6AAkiXpsd tHp1UXyqcbKy6mQSY0HQkRRzRWqOyJpnQxKe76S4PI6BrARCXm4Rr+UpXLlkXQKe 2F1VELgTZoQ4MR1k4CwNdvuvxeTtMbCLloPBUIoIktutyOLKI+8gonQkiniuSSM0 7cDESCwXiJlS1SGNg7I3rGoHsBpmbceqd+8DZaFnpxnez2bHrnirp0c2hIo3x27N bSLnPSSaJO5ES7mEQkMHcXOFFNHQDee6znHuJmpyCwhzRXSdyUDVSYrsGesjxJg= =v9L8 -----END PGP SIGNATURE-----

4 10