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
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
