- mkgmap-dev - The mkgmap lists

Error on barrier
by Stéphane MARTIN 23 Oct '14

23 Oct '14

Hi, Compiling the map for France, I get this error (twice) : GRAVE (StyledConverter): 60000237.o5m: Found multiple points with equal coords as CoordPOI at http://www.openstreetmap.org/?mlat=43.859890&mlon=4.441025&zoom=17 - mkgmap-r3337 - splitter-r412 Do you think the problem is in my style files ? Regards. Steph

2 1

Rendering Tunnels
by Enrico Liboni 23 Oct '14

23 Oct '14

I'm having troubles on rendering tunnels properly on secondary ways. I have my typ file with a dark line (0x11), in the line's style file I set: highway=secondary & ( network=e-road | int_ref=* ) [0x04 resolution 18-19 continue] highway=secondary [0x04 road_class=2 road_speed=3 resolution 20 *continue*] highway=secondary *& tunnel=yes* [*0x11* road_class=2 road_speed=3 resolution 21] however I can't see those tunnels... what's is wrong in the logic? I though i fully understand the meaning of "continue". On the other side on primary roads, where I have 0x10202 and 0x03 defined in the typ file I can see tunnels properly: highway=primary & ( network=e-road | int_ref=* ) [0x10202 resolution 15-17 continue] highway=primary [0x10202 road_class=3 road_speed=4 resolution 18-21 continue] highway=primary & tunnel=yes [0x11 road_class=3 road_speed=4 resolution 22] highway=primary [0x03 roadclass=3 road_speed=4 resolution 22] Any hint is appreciated, thanks Enrico

3 11

gmappsupp size with 20% bigger when using latest splitter
by Enrico Liboni 23 Oct '14

23 Oct '14

I updated my splitter version from 314 to 412 - now, it's pretty late but I read about the new split algorithm that might cause some different sizes than before, maybe I searched too quickly but I can't seem to explain why the final gmapsupp went from 87MB to 107MB. Looking at the split output in 412 and 314, it's clear 412 creates bigger files. Strange enough the last 4 files have the same size... # splitter 412 10637241 oct 22 23:23 70600001.osm.pbf 12379309 oct 22 23:23 70600002.osm.pbf 12233125 oct 22 23:23 70600003.osm.pbf 12607475 oct 22 23:23 70600004.osm.pbf 14031652 oct 22 23:23 70600005.osm.pbf 12025643 oct 22 23:23 70600006.osm.pbf 9286836 oct 22 23:23 70600007.osm.pbf 11071432 oct 22 23:23 70600008.osm.pbf 11720495 oct 22 23:23 70600009.osm.pbf 11909440 oct 22 23:23 70600010.osm.pbf 12356777 oct 22 23:23 70600011.osm.pbf 11513810 oct 22 23:23 70600012.osm.pbf 11672847 oct 22 23:23 70600013.osm.pbf 11988497 oct 22 23:23 70600014.osm.pbf * 9209424 oct 22 22:28 70600015.osm.pbf 11793063 oct 22 22:28 70600016.osm.pbf 10161776 oct 22 22:28 70600017.osm.pbf 10080071 oct 22 22:28 70600018.osm.pbf* # splitter 314 7323072 oct 22 23:43 70600001.osm.pbf 8832797 oct 22 23:43 70600002.osm.pbf 9987720 oct 22 23:43 70600003.osm.pbf 8862868 oct 22 23:43 70600004.osm.pbf 7198648 oct 22 23:43 70600005.osm.pbf 9651244 oct 22 23:43 70600006.osm.pbf 10898020 oct 22 23:43 70600007.osm.pbf 9764169 oct 22 23:43 70600008.osm.pbf 8247811 oct 22 23:43 70600009.osm.pbf 9444801 oct 22 23:43 70600010.osm.pbf 8876247 oct 22 23:43 70600011.osm.pbf 9218641 oct 22 23:43 70600012.osm.pbf 7222814 oct 22 23:43 70600013.osm.pbf 9883513 oct 22 23:43 70600014.osm.pbf * 9209424 oct 22 23:43 70600015.osm.pbf 11793063 oct 22 23:43 70600016.osm.pbf 10161776 oct 22 23:43 70600017.osm.pbf 10080071 oct 22 23:43 70600018.osm.pbf* Does this sound right to you? Thanks! Enrico

2 2

mkgmap in NYC
by Brian Egge 21 Oct '14

21 Oct '14

Hi, I've been using a USA map from http://www.openmapchest.org/maps/united-states on my Garmin Nuvi 1450. In Connecticut it works quite well, but I drove into NYC yesterday and it couldn't find a single address. I was trying to find: 311 W 51 St. Nomination shows the address as: • House 311, West 51st Street, Midtown West, Manhattan, New York County, New York City, New York, 10019, United States of America http://www.openstreetmap.org/way/265329468 I tried finding it in both "New York" and "New York City". Manhattan and Midtown West are not listed as cities. I even tried the intersection search and nothing came up. NYC has a near complete set of street addresses, so I expected I would have good results using OSM data. I know the boundaries of NYC can be challenging at time, because the city has five boroughs, lots of neighborhoods and a ton of data. Today, I navigated to the approximate location on the GPS, and it decided the location was in Weehawken, NJ., (which is just across the Hudson). On my GPS, I did a reverse search, and it showed the address being in New Jersey! I didn't build the maps myself, and I don't know how the splitter works. Clearly Nomination has the address figured out correctly, but mkgmap does not. Brian

5 6

Commit: r3337: Fix problematic routing for ferry routes used by hikers
by svn commit 21 Oct '14

21 Oct '14

Version mkgmap-r3337 was committed by gerd on Tue, 21 Oct 2014 Fix problematic routing for ferry routes used by hikers

1 0

Problem with splitter r412: invalid bbox area in pbf file
by KeenOnKites 20 Oct '14

20 Oct '14

Gents, We run into a problem with the splitter about invalid bbox area in pbf file throwing the following error: java.lang.IllegalArgumentException: invalid bbox area in pbf file: (49.808900356292725,-179.95320081710815) to (73.79793405532837,180.00049352645874) But this is sort of strange as osmconvert tells me different values for the bbox. Additionally it has to be said that another file containing a larger area (while containing the complete dataset of the file that causes the trouble) works without troubles with the same call of splitter and the same set of precompiled sea files and so on... Any help/comments would be appreciated.... More Details: ============================================================ The file triggering the problem: -------------------------------------------------------------------------------------------------- http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf And here the call and the output of the splitter: -------------------------------------------------------------------------------------------------- java -Xmx1536M -jar /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar --max-threads=2 --geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip --no-trim --precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea --keep-complete=true --mapid=98600001 --max-nodes=800000 --output=xml --output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf Splitter version 412 compiled 2014-06-21T13:47:04+0100 boundary-tags=use-exclude-list cache= description= geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip keep-complete=true mapid=98600001 max-areas=512 max-nodes=800000 max-threads=2 mixed=false no-trim=true num-tiles= output=xml output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA overlap=auto polygon-desc-file= polygon-file= precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea problem-file= problem-report= resolution=13 search-limit=200000 split-file= status-freq=120 stop-after=dist write-kml= Elapsed time: 0s Memory: Current 479MB (5MB used, 474MB free) Max 1365MB Time started: Sun Oct 19 15:28:09 CEST 2014 Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units (0.0439453125 degrees) - areas are multiples of 0x800 map units wide and high Processing /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf Bounding box -179.9532 49.8089 180.00050000000002 73.79794000000001 java.lang.IllegalArgumentException: invalid bbox area in pbf file: (49.808900356292725,-179.95320081710815) to (73.79793405532837,180.00049352645874) at uk.me.parabola.splitter.BinaryMapParser.parse(BinaryMapParser.java:233) at crosby.binary.BinaryParser.handleBlock(Unknown Source) at crosby.binary.file.FileBlock.process(Unknown Source) at crosby.binary.file.BlockInputStream.process(Unknown Source) at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1380) at uk.me.parabola.splitter.Main.processMap(Main.java:878) at uk.me.parabola.splitter.Main.calculateAreas(Main.java:574) at uk.me.parabola.splitter.Main.split(Main.java:252) at uk.me.parabola.splitter.Main.start(Main.java:181) at uk.me.parabola.splitter.Main.main(Main.java:151) uk.me.parabola.splitter.SplitFailedException: ERROR: file /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf contains unexpected data at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1402) at uk.me.parabola.splitter.Main.processMap(Main.java:878) at uk.me.parabola.splitter.Main.calculateAreas(Main.java:574) at uk.me.parabola.splitter.Main.split(Main.java:252) at uk.me.parabola.splitter.Main.start(Main.java:181) at uk.me.parabola.splitter.Main.main(Main.java:151) osmconvert output containing the statistics about the file -------------------------------------------------------------------------------------------------- tools/osmconvert/linux/osmconvert32 work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf --out-statistics timestamp min: 2007-06-05T03:23:59Z timestamp max: 2014-10-18T11:48:05Z lon min: -180.0000000 lon max: -122.5122521 lat min: 48.6234931 lat max: 71.6048217 nodes: 4028420 ways: 171349 relations: 1803 node id min: 27207079 node id max: 3136662460 way id min: 4708608 way id max: 308379297 relation id min: 13971 relation id max: 4116925 keyval pairs max: 302 keyval pairs max object: relation 60189 noderefs max: 2000 noderefs max object: way 42394334 relrefs max: 739 relrefs max object: relation 3337277 File not causing any troubles (us-pacific, superset of ALASKA): -------------------------------------------------------------------------------------------------- http://download.geofabrik.de/north-america/us-pacific.html splitter 'bounds' running against us-pacific file: part of the output -------------------------------------------------------------------------------------------------- ... Exact map coverage is (15.920970439910889,-179.99648094177246) to (72.98844337463379,-129.79979753494263) Rounded map coverage is (15.908203125,-180.0) to (72.9931640625,-129.7705078125) ... Output of the osmconvert running against us-pacific file -------------------------------------------------------------------------------------------------- tools/osmconvert/linux/osmconvert32 work/Freizeitkarte_US_PACIFIC/Kartendaten_Freizeitkarte_US_PACIFIC.osm.pbf --out-statistics timestamp min: 2006-12-08T15:49:14Z timestamp max: 2014-10-18T18:10:31Z lon min: -180.0000000 lon max: -122.5122521 lat min: 15.5631200 lat max: 71.6048217 nodes: 4906880 ways: 233739 relations: 2417 node id min: 21442033 node id max: 3136662460 way id min: 4045672 way id max: 308379297 relation id min: 13971 relation id max: 4116925 keyval pairs max: 302 keyval pairs max object: relation 60189 noderefs max: 2000 noderefs max object: way 42394334 relrefs max: 739 relrefs max object: relation 3337277 Many thanks already in advance... Patrik

4 4

Incorrect runabout exit indication
by SPA 04 Oct '14

04 Oct '14

Greetings First of all, Im not sure if I am following the correct procedure by wring to this email address I found here on the mkgmap site? I use a Garmin Nüvi 55 with primarily maps of Denmark from OpenStreetMap (Lambertus) compiled with mkgmap. I have the latest revision of the Denmark map 09-09-2014. All other maps on my GPS are disabled. There is an error: For example, my journey takes me though a roundabout. It is a straight forward roundabout with 4 exists, 3, 6, 9 & 12 oclock. I enter the roundabout at 6 oclock and should exit it at 9 oclock to reach my destination. The voice prompt of my GPS navigates me though the roundabout correctly take exit number three, bla bla bla HOWEVER, the small icon to the top left of the navigation window on my Garmin, indicating the specific roundabout exit position, incorrectly indicates that I should exit the roundabout at 6 oclock. I find this to be the matter with all roundabouts the small icon to the top left of the navigation window, indicating the specific roundabout exit position, displays an exit later that the actual exit that I need to take. When I use a map from for example NZ Open GPS (http://gwprojects.org/) that compiles maps with cgpsmapper both the voice prompt and the icon indicating the specific roundabout exit position (top left of navigation screen) of my GPS is correct. I am not sure if this is a mkgmap compiler issue or a Garmin device firmware issue? Kind regards Johan

8 29

Incorrect runabout exit indication
by Johan van Niekerk 30 Sep '14

30 Sep '14

Greetings OK, I never realized in order to receive a mail one has to subscribe to the mailing first. I have now done so and will try to send my query again. Here is my previous mail: ********************* First of all, Im not sure if I am following the correct procedure by wring to this email address I found here on the mkgmap site? I use a Garmin Nüvi 55 with primarily maps of Denmark from OpenStreetMap (Lambertus) compiled with mkgmap. I have the latest revision of the Denmark map 09-09-2014. All other maps on my GPS are disabled. There is an error: For example, my journey takes me though a roundabout. It is a straight forward roundabout with 4 exists, 3, 6, 9 & 12 oclock. I enter the roundabout at 6 oclock and should exit it at 9 oclock to reach my destination. The voice prompt of my GPS navigates me though the roundabout correctly take exit number three, bla bla bla HOWEVER, the small icon to the top left of the navigation window on my Garmin, indicating the specific roundabout exit position, incorrectly indicates that I should exit the roundabout at 6 oclock. I find this to be the matter with all roundabouts the small icon to the top left of the navigation window, indicating the specific roundabout exit position, displays an exit later that the actual exit that I need to take. When I use a map from for example NZ Open GPS (http://gwprojects.org/) that compiles maps with cgpsmapper both the voice prompt and the icon indicating the specific roundabout exit position (top left of navigation screen) of my GPS is correct. I am not sure if this is a mkgmap compiler issue or a Garmin device firmware issue? Kind regards Johan

1 0

type numbers , again...
by nwillink 24 Sep '14

24 Sep '14

The latest impressively detailed manual tells us that: If the type is not extended, it must be >= 0x0100 for a point, I might be wrong but looking at the img structure I come to a different conclusion: Non extended POIs have their 8th bit set to denote the possible inclusion of a subtype. If so I make the maximum for a non extended POI to be &7F and not &FF as perhaps was implied? '< 0x3f for a line, and < 0x7f for a polygon.' Perhaps explain why non extended lines can't be &40+ ( ie bits used for direction & length of bitstream) Regards nick -- View this message in context: http://gis.19327.n5.nabble.com/type-numbers-again-tp5818050.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 6

multiple boundary lines
by nwillink 23 Sep '14

23 Sep '14

Hi I've across something interesting when plotting boundaries. It appears that boundary=administrative [0x1c resolution 24] gets plotted 2x ie I examined the subfile and noticed 2 identical bitstreams at different offsets, within the same subfile. Only the lbl pointers are different. I wonder if this doubling is necessary as it increases the img file? Regards Nick -- View this message in context: http://gis.19327.n5.nabble.com/multiple-boundary-lines-tp5817950.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 4