[mkgmap-dev] DEM subfile

Mon Feb 22 21:42:27 GMT 2010

A friend and I spend some time on research the DEM subfile too. While 
still not knowing the real data encoding, I think we found some 
additional information about the structure.

In general a DEM subfile consists of a common header, a specific header 
(so far as all subfiles), a block of two data sections per zoom level 
and a block of descriptions for each zoom level:

	Header
	- Common
	- Specific
	Zoom level data block
	- Block 1
	-- Data 1
	-- Data 2
	- Block 2
	-- Data 1
	-- Data 2
	....
	Zoom level description block
	- Description 1
	- Description 2

There exist at least to versions of the specific header (0x25 byte - old 
version? - and 0x29 byte). The headers differ only slightly, the 
additional bytes are (always?) zero.

Offset	Length
0x00	 0x15 		common header
0x15	 1		different values (MapSource crashes if second
					  bit is set)
0x16	 3		all 0 for 0x29 version, different for 0x25
			version
0x19	 2		number of zoom levels
0x1B	 4		0
0x1F	 2		size of single description (seen only 3c00 = 60
			byte)
0x21	 4		Offset of first description block
(0x25)	 4		All zero

The single description blocks describe the structure and position of 
Data blocks.

Offset Length
0x00	2		Index of description block, starting with 0000.
			This differs between both versions: While 0x25 	
			version counts in high byte (0001), 0x29
			version increments lower byte (0100). Maybe
			this has different meaning.
0x02	4		Unknown (seems to be always 40000000)
0x06	4		Unknown (seems to be always 40000000)
0x0A	4		Values in latitude dimension (vy)
0x0E	4		Values in longitude dimension (vx)
0x12	2		Unknown (always 0)
0x14	2		Block size in data section 1 (add 1)
0x16	2		Unknown (always 0)
0x18	2		Block count in data section 1 (add 1)
0x1A	4		Unknown value (Last byte not zero)
0x1E	2		Record size in data section 1
0x20	4		Offset of data section 1
0x24	4		Offset of data section 2
0x28	4		western boundary (I know this is unusual but
			non of the bytes has to be zero and the result
			still fits)
0x2C	4		northern boundary
0x30	4		Pixel resolution latitude (py)
0x34	4		Pixel resolution longitude (px)
0x38	4		Unknown

Using these values the size of data section could be calculated as
	Block size * Block count * Record size

Data section 1 could be read as having Block count blocks. Each of them 
containing Block size records of Record size. In our opinion the records 
don't hold offset to data section 2: They are often zero and not 
continuosly growing, which I would expect them to do.

For the two lowest zoom levels the bounding box/size for the covered 
area could be calculated by
	(vx * px, vy * py)

We don't have any glue what to do with data section 2. But this has to 
be some picture format, because through removing some layers you will 
get a lower resolution elevation shading in MapSource. Not knowing much 
about picture formats, data section 2 (in combination with data section 
2) may be a header less GeoTiff or Jpeg (or whatever)

Hope there's someone out with good ideas
Ronny