March 2009 - mkgmap-dev - The mkgmap lists

Commit: r983: Add some point translations.
by svn commit 15 Mar '09

15 Mar '09

Version 983 was commited by steve on 2009-03-15 22:22:55 +0000 (Sun, 15 Mar 2009) Add some point translations. -Marko M?\195?\164kel?\195?\164

1 0

Commit: r982: Update to landuse polygon patch.
by svn commit 15 Mar '09

15 Mar '09

Version 982 was commited by steve on 2009-03-15 22:21:52 +0000 (Sun, 15 Mar 2009) Update to landuse polygon patch. -Marko M?\195?\164kel?\195?\164

1 0

Commit: r981: Add some landuse polygon types.
by svn commit 15 Mar '09

15 Mar '09

Version 981 was commited by steve on 2009-03-15 22:18:34 +0000 (Sun, 15 Mar 2009) Add some landuse polygon types. -Marko M?\195?\164kel?\195?\164

1 0

[PATCH] Splitter can read multiple input files
by Johann Gail 15 Mar '09

15 Mar '09

While playing with different regions from geofabrik I have extended Splitter to read multiple input files. The patch works as desired, it creates subtiles as if the input files would be merged external before given to splitter. Pay attention: If you use regions from geofabrik inter tile routing will not work. There are some small gaps in the roads near the borders.

1 0

[PATCH v3] - alpha patch to support road find by name
by Mark Burton 15 Mar '09

15 Mar '09

v3 - Now fills city field - thanks Bernhard for the quick response. ----------- Hi, The attached patch is for the current SVN trunk (r979) and it generates the sorted road data that is required by the gps to find roads/intersections by name. As for the number field, I haven't thought yet how that would get its data. Please test this patch and report success/failure. If it doesn't break anything for anyone, I would like to commit it fairly soon as I think that quite a few people will be happy to have street finding added to the trunk. Cheers, Mark

2 1

[PATCH v1] - alpha patch to support road find by name
by Mark Burton 15 Mar '09

15 Mar '09

Hi, The attached patch is for the current SVN trunk (r979) and it generates the sorted road data that is required by the gps to find roads/intersections by name. For me, it's basically working on the etrex in that find now gives you and option for finding addresses (and intersections but that hasn't been tested). The number and city fields don't work yet, just the road name field can be used. The patch does include support for the city field but it's not yet working because roads currently do not have a city assigned to them (yes, I know the RNPs do but they are points). Bernhard, could you please look at setting MapRoad's city object to the most applicable city? As for the number field, I haven't thought yet how that would get its data. Please test this patch and report success/failure. If it doesn't break anything for anyone, I would like to commit it fairly soon as I think that quite a few people will be happy to have street finding added to the trunk. Cheers, Mark

1 0

Commit: r979: errors down to warn as they do not stop the map being made.
by svn commit 15 Mar '09

15 Mar '09

Version 979 was commited by steve on 2009-03-15 09:38:54 +0000 (Sun, 15 Mar 2009) errors down to warn as they do not stop the map being made.

1 0

[PATCH v5] alpha support for motorway exits and service areas
by Mark Burton 14 Mar '09

14 Mar '09

Patch version 5 (based on r974) - exits are now findable! After many hours of experimentation, the exits are now findable. One oddity, on my etrex, when I find exits it always shows me exits defined on the base map in preference to the OSM map. If I then use the menu option to change map to the OSM map, it shows the exits on the OSM map. There's some priority mechanism in force there that doesn't seem to apply when searching for non-exits. In my example map, I only have two exits defined for the M53 but the basemap has a lot more, could it be that it's using the basemap because it has more exits defined for that road? Testers, please see if it will use the OSM map in preference to the base map by default. ---------------------- Hi, The attached patch provides basic support for processing motorway exits. It's still work in progress but I am posting it so that people can try it out, find what breaks and suggest improvements. Exits in the garmin world have to be associated with a motorway (sounds reasonable) but they don't have to coincide with a node on the motorway, i.e. the exit node doesn't have to be on the motorway! In the case where the exit is defined with a "motorway_junction" tag on one of the motorway's nodes, nothing needs to be done for an exit POI to be generated as mkgmap will work out the association itself (only for roads that are "motorway" or "trunk"). If your "motorway_junction" node is separate from the motorway (not very sensible, perhaps) or you are using a "highway=services" tag on a node (which probably will be near the road but not actually on it) you will need to add a "exit:road_ref" tag to specify the reference of the road that the exit is associated with. Here's example tags that associates a services with the road A41. name=Toy Town Services highway=services exit:road_ref=A41 Note, at this time "highway=services" for areas is not yet supported. Seems to me that it could be by using the new area POIs functionality to make a POI automatically. One attribute of exits is that they exit to somewhere and you need to be able to specify where the exit is going to because mkgmap can't guess that (well, not yet, anyway). To do this, use an "exit:to" tag. So you can say: highway=motorway_junction ref=5 exit:to=Telford East Garmin allow you to specify all sorts of facilities info for an exit and this is described in the cgpsmapper docs. Of course, there is no standard OSM means to express that so we have yet another tag "exit:facility" that should be set to a comma separated set of values that describe the facility. The syntax is exactly the same as used in mp files. Something like this (values are examples, not sensible): exit:facility=0x01,N,0x04,Hello World Yet more flexibility is introduced by the fact that the type code for the exit can be one of a huge range. At the moment, I am using: highway=motorway_junction { name '${ref} ${name}' | '${ref}' | '${name}' } highway=motorway_junction [0x2000 resolution 16] highway=services { name '${ref} ${name}' | '${ref}' | '${name}' } highway=services [0x210f resolution 16] 0x2000 means "exit no services" 0x210f means "exit (service") I played around with the codes and on my gps some codes make little symbols appear to show that the exit has food, hotel, etc. We can probably make it use a suitable code from the facilities info but I haven't looked into that yet. Oh yes, you must have a region defined for your map, if you don't, the exits will not be generated. All feedback is welcome. Cheers, Mark

4 13

[PATCH v9] alpha support for motorway exits and service areas
by Mark Burton 14 Mar '09

14 Mar '09

Patch version 9 (based on r977) - No big changes - no longer demands that the region be set to create a highway but it does still issue a warning. The problem of the GPS listing the basemap exits in preference to the OSM map exits still remains - I have tried everything I can think of but it still doesn't use the OSM map exits by default. What's really weird is that it can "see" the OSM map exits but decides to use the basemap exits instead. I could understand it using the basemap exits if the OSM map exits were not visible, but they are. The analogous situation is the cities. There, by default, the GPS shows the OSM map cities rather than the basemap cities. For both cities and exits, my gps lets me choose which map to use. For no other findable object is that option provided. I've run out of ideas for the moment. ---------------------- Hi, The attached patch provides basic support for processing motorway exits. It's still work in progress but I am posting it so that people can try it out, find what breaks and suggest improvements. Exits in the garmin world have to be associated with a motorway (sounds reasonable) but they don't have to coincide with a node on the motorway, i.e. the exit node doesn't have to be on the motorway! In the case where the exit is defined with a "motorway_junction" tag on one of the motorway's nodes, nothing needs to be done for an exit POI to be generated as mkgmap will work out the association itself (only for roads that are "motorway" or "trunk"). If your "motorway_junction" node is separate from the motorway (not very sensible, perhaps) or you are using a "highway=services" tag on a node (which probably will be near the road but not actually on it) you will need to add a "exit:road_ref" tag to specify the reference of the road that the exit is associated with. Here's example tags that associates a services with the road A41. name=Toy Town Services highway=services exit:road_ref=A41 Note, at this time "highway=services" for areas is not yet supported. Seems to me that it could be by using the new area POIs functionality to make a POI automatically. One attribute of exits is that they exit to somewhere and you need to be able to specify where the exit is going to because mkgmap can't guess that (well, not yet, anyway). To do this, use an "exit:to" tag. So you can say: highway=motorway_junction ref=5 exit:to=Telford East Garmin allow you to specify all sorts of facilities info for an exit and this is described in the cgpsmapper docs. Of course, there is no standard OSM means to express that so we have yet another tag "exit:facility" that should be set to a comma separated set of values that describe the facility. The syntax is exactly the same as used in mp files. Something like this (values are examples, not sensible): exit:facility=0x01,N,0x04,Hello World Yet more flexibility is introduced by the fact that the type code for the exit can be one of a huge range. At the moment, I am using: highway=motorway_junction { name '${ref} ${name}' | '${ref}' | '${name}' } highway=motorway_junction [0x2000 resolution 16] highway=services { name '${ref} ${name}' | '${ref}' | '${name}' } highway=services [0x210f resolution 16] 0x2000 means "exit no services" 0x210f means "exit (service") I played around with the codes and on my gps some codes make little symbols appear to show that the exit has food, hotel, etc. We can probably make it use a suitable code from the facilities info but I haven't looked into that yet. Oh yes, you must have a region defined for your map, if you don't, the exits will not be generated. All feedback is welcome. Cheers, Mark

1 0

[PATCH] Point additions to the default style
by Marko Mäkelä 13 Mar '09

13 Mar '09

The attached patch adds a few POI translations. I have commented out tags that I invented (unofficial tag=value pairs). My Edge 705 displays the symbols 0x650a,0x6511,0x6512,0x6513 as hollow white circles and does not list them on the POI menus. Can anyone check if other Garmin products actually use these symbol codes? Marko

1 0