October 2010 - mkgmap-dev - The mkgmap lists

Corrupt img directory on large image files
by Steffen Neumann 27 Oct '10

27 Oct '10

Hello, building my own maps with mkgmap I found a strange behavior, probably a bug. Phenomenon: I built an full-blown img from a single 46Mb source, let's say 63240090.osm.gz. No errors in mkgmap so far. Got the 63240090.img and the gmapsupp.img. The gmapsupp.img is empty - no maps in it. The 63240090.img seems fine but is invalid. I know that I could increase the block size to get rid of the large source but this is not the point. Analysis: The img starts with 0x400 bytes header. Then, due to the size of the source 2 header directory blocks follow. The normal directory blocks start subsequently at 0x800 with 63240090RGN. Unfortunately this first block at 0x800 contains size 0 and starts with sequence number 0x01. So I assume that the missing first block has been overwritten by the 2nd header block. Suggested code changes: In package uk.me.parabola.imgfmt.sys in file directory.java in function void sync() replace: int forHeader = (blocks + (blockSize - 1)) / blockSize; by: int forHeader = (blocks + DirectoryEntry.SLOTS_PER_ENTRY - 1)/DirectoryEntry.SLOTS_PER_ENTRY; The calculation of forHeader is obviously wrong what in turn causes the position needed for other blocks to be wrong too. 2 lines later there's an assert to ensure a forHeader of 1. This could be removed. The rest of the code seems to be aware of multiple header blocks. If someone tells me a place were I could store the sample source I will do so. I've no experience in respect of the code change procedures, so could one of you guys check-in the changes? By the way - I wonder why nobody else remarked this before. cheers, Steffen

2 4

Commit: r1725: Correct the calculation of the number of directory entries required to contain the
by svn commit 26 Oct '10

26 Oct '10

Version 1725 was commited by steve on 2010-10-26 21:24:06 +0100 (Tue, 26 Oct 2010) Correct the calculation of the number of directory entries required to contain the blocks for the header file. -Steffen Neumann

1 0

Option generate-sea buggy
by Josef Latt 25 Oct '10

25 Oct '10

Hi, I create my own map with OSM data for Germany from geofabrik (http://download.geofabrik.de/osm/europe/germany.osm.bz2) and the following setting. java -ea -Xmx2560M -jar mkgmap.jar \ --description=OSM_DE \ --country-name=Deutschland --country-abbr=DE \ --name-tag-list="name:de,name,int_name" \ --style-file=./mkgmap-style/ \ --generate-sea=multipolygon,extend-sea-sectors,close-gaps=1000 \ --family-id=1331 --product-id=1 \ --series-name=OSM_Deutschland \ --family-name=OSM_Deutschland \ --area-name=Deutschland \ --overview-mapname=OSM_Deutschland \ --tdbfile \ --draw-priority=25 \ --latin1 \ --ignore-maxspeeds \ --ignore-turn-restrictions \ -c template.args 1331.TYP As you can see in the attached screenshot, there is a region, which is overlapped by the sea. Is this a problem of mkgmap? Thanks Josef

4 9

Bug in --description
by NopMap 24 Oct '10

24 Oct '10

Hi! I am experiencing a bug with the description parameter in mkgmap 1625 (which is listed as the current stable version). When I use a description in quotation marks, e.g. --description="My own map" then mkgmap throws a NullPointerException. When the spaces are removed, e.g. --description="Myownmap" then it works. With previous versions, descriptions with spaces used to work. Since there has been quite some time since march my questions are: - has this problem already been fixed? - is there a more current recommended stable version? bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Bug-in-description-tp5667325p5667325.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 1

Missing ways part 1
by Adrian 23 Oct '10

23 Oct '10

I have noticed some missing ways in my Garmin maps. I investigated, as follows. I downloaded the France extract from Geofabrik in .pbf format; used osmosis-0.37 to extract a bounding box, bottom=49.4 left=1.3 top=51.3 right=4.4; and ran splitter-r123 on the extract with max-nodes=1500000. This is the resulting areas.list: 63240001: 2301952,141312 to 2347008,206848 # : 49.394531,3.032227 to 50.361328,4.438477 63240002: 2301952,59392 to 2347008,141312 # : 49.394531,1.274414 to 50.361328,3.032227 63240003: 2347008,141312 to 2371584,190464 # : 50.361328,3.032227 to 50.888672,4.086914 63240004: 2347008,59392 to 2392064,141312 # : 50.361328,1.274414 to 51.328125,3.032227 I loaded each .osm.gz tile into JOSM in turn. This takes a few minutes, and JOSM is very slow until you zoom well in. It needs about 1GB memory. [This generated many thousands of messages on stderr, along the lines of "WARNING: Normalizing value of attribute 'version' of element 552,829,105 to 1, API version is '0.5'. Got 0." Why does splitter downgrade the API to v0.5?] I found that way 31799814 (79 nodes) was missing. This is a 57km section of the high-speed railway line between Lille and Paris. The way should have been split between tiles 63240002 and 63240004. The way is present in the file which was input to splitter. Why does the way go missing?

4 6

[GeoNames] GarminID's GoogleDocs spreadsheet
by Sam Vekemans 22 Oct '10

22 Oct '10

Hi all. With thanks to Marcel Bokhorst, who created the gn2mp conversion script, I created the GoogleDocs chart listing all of the features https://spreadsheets.google.com/ccc?key=0Am70fsptsPF2dENGRWNOQ3lmeU5UbWlORF… I have cross-posted this message to the mkgmap developers, who are working on the conversion program which takes the OpenStreetMap Features and figures out exactly which Xml KEY/VALUE pairs match up with the GarminIDs. I'm still working on the charts, for example the detailed GarminIDs with the https://spreadsheets.google.com/ccc?key=0Am70fsptsPF2dGdSaEwwTUx5eGtzSFdPbm… And am currently working on finding a sample from GeoNames to show for each feature. So my 1 question for the geonames group is, what is the origional source for the map feature schema? Was it created from scratch or derived from somewhere? Thanks, Sam Vekemans Across Canada Trails --- Across Canada Trails - Beyond 2017 - The National Trails Network Victoria, BC Canada T

2 2

Commit: r1724: Disable dead-end-checks for oneways whose endpoints carry a FIXME tag.
by svn commit 22 Oct '10

22 Oct '10

Version 1724 was commited by marko on 2010-10-22 10:39:11 +0100 (Fri, 22 Oct 2010) Disable dead-end-checks for oneways whose endpoints carry a FIXME tag. This code was temporarily removed by the introduction of osm.pbf support.

1 0

Commit: r1723: Do not hide tunnels that carry any foot or bicycle attribute.
by svn commit 22 Oct '10

22 Oct '10

Version 1723 was commited by marko on 2010-10-22 10:34:21 +0100 (Fri, 22 Oct 2010) Do not hide tunnels that carry any foot or bicycle attribute.

1 0

Commit: r1722: Translate railway=preserved.
by svn commit 22 Oct '10

22 Oct '10

Version 1722 was commited by marko on 2010-10-22 09:53:00 +0100 (Fri, 22 Oct 2010) Translate railway=preserved.

1 0

Commit: r1721: Hide unaccessible tunnels.
by svn commit 22 Oct '10

22 Oct '10

Version 1721 was commited by marko on 2010-10-22 08:45:41 +0100 (Fri, 22 Oct 2010) Hide unaccessible tunnels. Hide railway tunnels based on tunnel=yes instead of layer<0.

1 0