- mkgmap-dev - The mkgmap lists

Commit: r3175: merge from via_ways branch
by svn commit 10 Apr '14

10 Apr '14

Version mkgmap-r3175 was committed by gerd on Thu, 10 Apr 2014 merge from via_ways branch adds support for restriction relations with - via way - restriction no_entry or no_exit - specific vehicle type, e.g. type=restriction:motorcar or restriction:motorcar=no_u_turn - fixes possible error if different roads connect the same nodes (old code possibly saved the restriction for the wrong road) - detects obsolete restrictions, e.g. when a oneway doesn't allow to enter the road or when the restiction applies to motor_vehicles only and the road is a cycleway. - if the style creates multiple routable ways for one OSM way, the restriction is added for all needed combinations

4 3

make-cycleways and make-opposite-cycleways
by Gerd Petermann 10 Apr '14

10 Apr '14

Hi all, Mario Hantschke pointed out that these tags are not yet evaluated in the --make-opposite-cycleway option: cycleway:left=* and cycleway:right=* http://taginfo.openstreetmap.org/keys/cycleway:left?filter=ways#values While looking at the code I noticed that (for a oneway) the tags bicycle:oneway=no and oneway:bicycle=no are only evaluated if the way also has the tag cycleway=* , which was not intended and is an error. I think all agreed that it only makes sense to add a cycleway if the way is a oneway, so the options --make-cycleways and --make-all-cycleways are obsolete and should be ignored. This leaves option --make-opposite-cycleways which only applies to oneways which do not already have a highway=cycleway tag. My understanding is now that mkgmap should add an additional cycleway if a oneway also has oneway:bicycle=no | bicycle:oneway=no | cycleway=opposite |cycleway=opposite_lane | cycleway=opposite_track | cycleway:left=opposite_lane | cycleway:right=opposite_lane | cycleway:left=opposite_track | cycleway:right=opposite_track Attached is a patch that implements these changes. If I hear no complains I'll commit it on sunday. I'd still prefer to remove also the --make-opposite-cycleways option and change the default style, but I don't know how to change the lines file so that the additional cycleway is added after(!) the normal highway and bicycle traffic is forbidden on that normal highway :-( Gerd

1 0

improvements installer template
by Minko 10 Apr '14

10 Apr '14

For Lambertus generic maps I examined the installer he used (the default one) and noticed some issues. If the installer detects a previous version, it asks for permission to remove it (which is fine). Then it opens a separate uninstaller window. There you need to enter again if you want to proceed. This 2nd step is imho not needed. The installer window disappears in the background which is confusing. I changed the Function myGUIInit so this step is skipped, after ok the uninstalling process is carried out in the background and the user will stay in the installer window. Another issue is that the uninstaller does not remove the mapfiles if a user has entered another folder than the default c:\garmin\maps\folder. Besides this, it does not remember what the custom folder was after removal, you will get the default c:\garmin\maps\folder prompted. I also changed this, it first looks if a map already is installed, and it stores this info. After removal the default folder is the custom folder, not the default c:\garmin\maps\folder. I've used this procedure already for a few years without complains ;-) Please test it and add it to the default style if it's ok?

2 1

report-dead-ends not working
by Carlos Dávila 09 Apr '14

09 Apr '14

An osm contributor who usually downloads the errors files I serve with my maps has reported that since a long time there are no "oneway errors" for the whole Spain, which is certainly estrange. I checked the map generation log and it seems mkgmap is not reporting dead ends. I have tried with a very simple osm file, containing just two oneway residential ways joined like this ---><---- and mkgmap doesn't report anything, neither with --report-dead-ends=1 nor =2 What am I doing wrong?

2 5

r3174 in via_ways branch
by Gerd Petermann 09 Apr '14

09 Apr '14

Hi all, I think the branch is ready for trunk now. See also http://gis.19327.n5.nabble.com/r3165-in-via-ways-branch-tp5802056.html Improvements since r3165: - fixed errors in evaluation of restricted / allowed vehicles - improved logging: more detailed messages when restriction was ignored, info message for used restrictions - the relations style file can be used to modify restrictions, e.g. vehicles can be added / removed. Use this if you "abuse" car routing for bicycle only maps. See also http://gis.19327.n5.nabble.com/vehicles-in-restriction-relations-tp5801618p… I did a few more tests regarding turn restrictions with via ways. It seems that they are working, but the effect is minimal. In Finland, they are (now) used only in no_u_turn restrictions, and the Garmin algo seems to avoid these u-turns anyway if alternatives are available. Gerd

2 2

Sharp angles in cycle ways
by Gerd Petermann 08 Apr '14

08 Apr '14

Hi all, a few days ago Felix suggested to add code to improve routing for bicycles: http://gis.19327.n5.nabble.com/r3165-in-via-ways-branch-tp5802056p5802063.h… If I got that right, mkgmap should detect cases where two arcs meet at with a sharp angle and the arcs are only accessible by bicycle or foot. In such a case, mkgmap should "manipulate" the angle so that the routing algo doesn't add too much time penalty, as we can assume that the real angle is not that sharp. Or mkgmap should assume that the created map is for cyclists only, so that car access means something like racing bike. Optimization would work like this: 1) at an y-shaped node, find the two arcs which are closer to a straight line and modify the initial heading of the other arc so that Garmin sees a right angle (90°) . 2) at an x -shaped node, try to make all angles 90° 3) at nodes with more than 4 arcs, do nothing. If the style adds multiple routable ways for one OSM way, the corresponding multiple arcs between nodes on that way should be counted like one . If that can be coded, it has only to be done if a new option like --optimize-cycle-ways is given. Did I get that right? @Felix: Please provide a test case (the OSM id of a node ) Gerd

2 3

vehicles in restriction relations
by GerdP 08 Apr '14

08 Apr '14

Hi all, I've just modified a routine that translates the vehicle types used in OSM to the ones used in Garmin restrictions: if(vehicle.equals("motorcar") || vehicle.equals("motorcycle") || vehicle.equals("motor_vehicle")) flag = RouteRestriction.EXCEPT_CAR; else if(vehicle.equals("psv") || vehicle.equals("bus")) flag = RouteRestriction.EXCEPT_BUS; else if(vehicle.equals("taxi")) flag = RouteRestriction.EXCEPT_TAXI; else if(vehicle.equals("delivery") || vehicle.equals("goods")) flag = RouteRestriction.EXCEPT_DELIVERY; else if(vehicle.equals("bicycle")) flag = RouteRestriction.EXCEPT_BICYCLE; else if(vehicle.equals("hgv") || vehicle.equals("truck")) flag = RouteRestriction.EXCEPT_TRUCK; if (flag == 0){ log.warn(messagePrefix, "ignoring unsupported vehicle class '" + vehicle + "' in turn restriction"); return false; } else { ...} I think that this should better be done in the style? I also wonder why the wiki lists different kinds of vehicles for restriction:<vehicle>=<turn> , type=restriction:<vehicle> , and except=* I hope it is okay to use the same code for all of them? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/vehicles-in-restriction-relations-tp5801618.… Sent from the Mkgmap Development mailing list archive at Nabble.com.

6 21

Public transport
by Adrian 07 Apr '14

07 Apr '14

I have entered some public transport data into OSM. I have made every effort to enter the data in accordance with the new public transport schema. Some 'old' tags are also present because I started mapping the data before the new schema was approved. For testing purposes I used the extract from Geofabrik of the Languedoc-Roussillon region of France. I used r3160 with the default style and these options: --max-jobs --code-page=1252 --add-pois-to-areas --route --link-pois-to-ways --precomp-sea=sea_20140324.zip --generate-sea --index --bounds=bounds_20140324.zip --location-autofill:bounds,is_in,nearest --housenumbers. Looking at the results, I noticed a number of things. (1) Names of railway stations The names of many railway stations appear in the form SNCF: Agde. https://www.openstreetmap.org/way/72614628 This is the result of generic processing of names in the style file inc/name. There are about 3500 railway stations in France and more than half of them are tagged operator=SNCF. I would prefer to see the name in the form Agde SNCF, which was produced by earlier versions of the default style, before the file inc/name was introduced. This is more convenient for searching on a device. (2) Names of bus stops This is an example of the name of a bus stop as it appears in the generated map: Agglo Hérault Méditerranée: (1;2;3;4;5,4,4,3,3)+ Gare SNCF https://www.openstreetmap.org/node/1424432523 The Garmin software and the device will only display the first part of the string. I used QLandkarte GT to see the complete string. (For legibility, I have used lower case in the strings, although they are in upper case in the generated map.) Earlier versions of the default style produced the result Gare SNCF (1;2;3;4;5,4,4,3,3)+Agglo Hérault Méditerranée, which I prefer. "Gare SNCF" is the name of the bus stop. The earlier version would be essential, to allow you to see the name of the bus stop on a device. What do others think? The solution which I use for my own maps, is as follows. Before line 5 of file inc/name (ref=* & (operator!=* & brand!=*) { name '${ref} ${name}' | '${ref}' }), insert this line ref=* & (operator!=* & brand!=*) & (highway=bus_stop | railway=tram_stop | railway=halt | railway=station) { name '${name} ${ref}' | '${ref}' } Before line 16 of file inc/name (operator=* & brand!=* {), insert these 6 lines operator=* & brand!=* & (highway=bus_stop | railway=tram_stop | railway=halt | railway=station) { name '${name} ${ref} ${operator}' | '${name} ${operator}' | '${ref} ${operator}' | '${operator}' } I will leave further questions about public transport for another thread.

1 0

separate level2 boundary files
by Michał Rogala 07 Apr '14

07 Apr '14

Hi! I have a suggestion for additional functionality of mkgmap. It would be great if it was possible to provide separate directory with level 2 boundaries. Very often I need to create an OSM extract that covers parts of a few countries in Europe - level2 boundaries generated from such extract are incomplete and therefore country assignment for POIs/streets doesn't work. To solve such problem I could generate boundaries for whole Europe, but only for level2 and add/merge it with local boundaries. best regards Michal Rogala

2 2

r3165 in via_ways branch
by Gerd Petermann 06 Apr '14

06 Apr '14

Hi all, I think r3165 is ready for a deeper test. Changes compared to trunk: - handling of RouteRestrictions was mostly rewritten to make sure that mkgmap doesn't write wrong restrictions to the img file (this was possible when different roads connected the same points with direct arcs) - added support for restrictions with one via way (see below) - added support for tag type=restriction:* , e.g. type=restriction:motorcar - added support for tag restrection:*=<turn> , e.g. restriction:motorcar=only_left_turn - added support for no_entry and no_exit restrictions - improved log messages for invalid or possibly obsolete restriction relations Reg. via ways: According to NodCheck in the display tool the data written by mkgmap r3165 is correct, but I found no effect on routing :-( Up to now mkgmap adds a 4 node restriction to both end points of the via way. Maybe there is a bit in a header which has to be (un)set, but I can't find any. Multiple via ways are not yet supported, but partly verified to be correct. Maybe I'll look at that when we see an effect on routing for a single via way. @Steve: Do you see any effect of them in your maps? If yes, what might be wrong with the data written by mkgmap? Gerd

5 12