- mkgmap-dev - The mkgmap lists

disabling / removing the basemap on Garmin Etrex Vista
by Ben Konrath 18 Mar '09

18 Mar '09

Hi, I'm just wondering if it's possible to disable or remove the basemap on the Garmin Etrex Vista? I'm seeing Exits from the US while I'm in Costa Rica. I guess this is the same problem that Mark is having. Thanks, Ben

3 4

[patch] some tweaks to the default style
by Ben Konrath 18 Mar '09

18 Mar '09

Hi, Please find a patch that tweaks a few settings in the default style. The patch adds the following: * accepts leisure=sports_center or leisure=sports_centre This isn't consistent in the default style so it's probably not consistent in the OSM data. * add name / operator magic for banks, hotels and gas stations Comments are welcome. Cheers, Ben Index: /home/ben/workspace/mkgmap2/resources/styles/default/polygons =================================================================== --- /home/ben/workspace/mkgmap2/resources/styles/default/polygons (revision 984) +++ /home/ben/workspace/mkgmap2/resources/styles/default/polygons (working copy) @@ -39,7 +39,7 @@ leisure=park [0x17 resolution 20] leisure=pitch [0x19 resolution 20] leisure=playground [0x17 resolution 20] -leisure=sports_center [0x19 resolution 20] +leisure=sports_center | leisure=sports_centre [0x19 resolution 20] leisure=stadium [0x19 resolution 19] leisure=track [0x19 resolution 18] leisure=water_park [0x09 resolution 18] Index: /home/ben/workspace/mkgmap2/resources/styles/default/points =================================================================== --- /home/ben/workspace/mkgmap2/resources/styles/default/points (revision 984) +++ /home/ben/workspace/mkgmap2/resources/styles/default/points (working copy) @@ -4,6 +4,7 @@ aeroway=terminal [0x2f04 resolution 20] amenity=atm [0x2f06 resolution 21] +amenity=bank { name '${name} (${operator})' | '${name}' | '${operator}' } amenity=bank [0x2f06 resolution 21] amenity=biergarten [0x2d02 resolution 21] amenity=bus_station [0x2f08 resolution 21] @@ -20,6 +21,7 @@ amenity=drinking_water [0x5000 resolution 23] amenity=fast_food [0x2a07 resolution 21] amenity=fire_station [0x3008 resolution 21] +amenity=fuel { name '${name} (${operator})' | '${name}' | '${operator}' } amenity=fuel & shop=convenience [ 0x2e06 resolution 19 ] amenity=fuel [0x2f01 resolution 19] amenity=grave_yard [0x6403 resolution 21] @@ -59,7 +61,7 @@ leisure=marina [0x4300 resolution 21] leisure=park [0x2c06 resolution 21] leisure=pitch [0x2c08 resolution 21] -leisure=sports_centre [0x2d0a resolution 21] +leisure=sports_center | leisure=sports_centre [0x2d0a resolution 21] leisure=stadium [0x2c08 resolution 21] leisure=track [0x2c08 resolution 21] @@ -119,6 +121,7 @@ tourism=camp_site [0x2b03 resolution 20] tourism=caravan_site [0x2b03 resolution 20] tourism=hostel [0x2b02 resolution 20] +tourism=hotel { name '${name} ${operator}' | '${name}' | '${operator}' } tourism=hotel [0x2b01 resolution 20] tourism=information [0x4c00 resolution 20] tourism=motel [0x2b01 resolution 20]

1 0

splitter area list
by Torsten Leistikow 18 Mar '09

18 Mar '09

Moin, I would like to use splitter to cut tiles matching to my SRTM-tiles using the --split-file option, but I am not sure about the format of the area list. The list file generated by splitter looks like 63240001: 1583104,-1261568 to 2338816,-348160 # : 33.969727,-27.070313 to 50.185547,-7.470703 First line is the split command? What do the numbers mean? The second line is a comment-line? If I specify an area list, will splitter still check for max-nodes, or will the tiles be cut as specified? Gruss Torsten

4 4

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

18 Mar '09

v8 - now supports zip records for roads (data comes from addr:postcode tag). Also supports multiple ref names separated by ";" (e.g. ref="A123;B999") and also int_ref, nat_ref and reg_ref. Note that the limit is 4 labels max per road. I have commented out the statement in the lines file that sets the name to be ref if a name tag is not defined but have added code to do essentially the same thing except that it will only assign the first ref as the road name rather than all of the refs. i.e. if the name tag is undefined and the ref tag is "A1234;E 99" it will use A1234 as the road name. Feedback/comments welcome. ----------- Hi, The attached patch is for the current SVN trunk 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

1 0

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

18 Mar '09

v6 - Now based on r984 - Now uses separate labels for road name and ref so you no longer get "Foo street (A123)" - this allows roads to be searched for by name or by ref. If you are using your own style files make sure to change the line that sets the highway name to: # If highway has a name, use it, or if it has a ref, use that as the name highway=* {name '${name}' | '${ref}' } When entering an address, the road names are searchable incrementally but the city names are not. Interestingly, if you enter a city name or the prefix of a city name it will scroll the list of city names to the appropriate position - weird. As reported by a tester, if you select a city, it doesn't limit the roads in the list to only the roads in that city, you still get presented with a list of all the roads in the known universe. I have good reason to believe that these two issues will only be solved by supplying further index information (MDR file perhaps?) So, it may be that the current functionality is the best we can hope for until the MDR is cracked. ----------- Hi, The attached patch is for the current SVN trunk 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

Turn instructions
by Ralf Kleineisel 17 Mar '09

17 Mar '09

Hi, I'm testing mkgmap routing with a map made with r973. The progress made in the last few weeks is impressive, thanks! Most motorway exits and crossings give correct turn instructions on my eTrex Legend. This one here is an exception: http://data.giub.uni-bonn.de/openrouteservice/index.php?start=11.0232729,49… The purple route line goes all the way through the motorway junction correctly, but there is not a single turn instruction. Any ideas?

3 8

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

17 Mar '09

v5 - Now uses separate labels for road name and ref so you no longer get "Foo street (A123)" - this allows roads to be searched for by name or by ref. If you are using your own style files make sure to change the line that sets the highway name to: # If highway has a name, use it, or if it has a ref, use that as the name highway=* {name '${name}' | '${ref}' } When entering an address, the road names are searchable incrementally but the city names are not. Interestingly, if you enter a city name or the prefix of a city name it will scroll the list of city names to the appropriate position - weird. As reported by a tester, if you select a city, it doesn't limit the roads in the list to only the roads in that city, you still get presented with a list of all the roads in the known universe. I have good reason to believe that these two issues will only be solved by supplying further index information (MDR file perhaps?) So, it may be that the current functionality is the best we can hope for until the MDR is cracked. ----------- 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 4

Commit: r984: Add support for exits (motorway junctions & services).
by svn commit 17 Mar '09

17 Mar '09

Version 984 was commited by markb on 2009-03-17 12:11:14 +0000 (Tue, 17 Mar 2009) Add support for exits (motorway junctions & services). One major annoyance is that when finding exits, the GPS prefers to find the exits on the basemap rather than the OSM map. Don't know at this time how to fix that. Also included in this commit is support for building the POI Index. I originally thought this was needed for the exits but I don't think it is now but it may still be useful so I am leaving it in.

1 0

Commit: r980: Fix explicit setting of mapname when the file name is numeric.
by svn commit 16 Mar '09

16 Mar '09

Version 980 was commited by steve on 2009-03-15 22:01:57 +0000 (Sun, 15 Mar 2009) Fix explicit setting of mapname when the file name is numeric. Numeric filename set the mapname from the filename, unless a mapname argument is given. In that case all mapnames after that are determined by the set value and not by the filename.

2 2

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

15 Mar '09

v2 - now generates correct sized city ref (wasn't being used yet anyway!) ----------- 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

3 4