[mkgmap-dev] DEM subfile

Fri Feb 26 22:23:42 GMT 2010

Am 24.02.2010 20:53, schrieb Christian Gawron:
> Ronny Klier schrieb:
>
>>>
>>> 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)

Not sure about this anymore.

>>> 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)

I saw you wrote on the wiki page that 0x14 is the number of tiles in 
longitude direction and 0x18 is the number of tiles in latitude 
direction. This seems to be true: Moving a "line" of records results in 
moving the elevation shape in MapSource.

>>> 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)
>>
> In the files I analyzed the western/northern boundaries are coded with 3 bytes (as usual) and the first byte of these fields look like a separate field to me.
> Or are you saying the map unit is 360/232 in the DEM file?
>
Yes, it seems so. One extra byte does not matter. You will get the same 
result if the extra byte is zero.
>
>>> 0x2C	4		northern boundary
>>> 0x30	4		Pixel resolution latitude (py)
>>> 0x34	4		Pixel resolution longitude (px)
>>
> Are you sure these values are four bytes long?

Yes, I’ve seen maps where the pixel resolution is always 4 times the 
resolution of higher level. Last value needs at least 3 bytes. (0x0670 
-> 0x19E0 -> 0x6790 -> 0x019E40)

>
>    0x38	2		Minimum height in feet? (0x8e18=-29160 for files with sea/-8888m)
>    0x3A	2		Maximum height in feet? (always larger than the previous fields)
>

Unlikely, 0x38 < 0x3A only if values are read as signed. But why should 
negative values occur (beside 0x8e18)? Perhaps one of them is the 
minimum/average/maximum and the other defines the difference between min 
and max?

>
>>>
>>> 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.
>>
> I analyzed mostly tiles with much sea (shown with elevation -8888m in Basecamp) and I think the offset zero is used for "empty" block (with no corresponding data in section 2). If you ignore the zeros, the values are indeed continuously growing.
>
> Did you see record sizes other than 7 or 8? The variation in size me be due to the fact that for smaller files the offset into section 2 fits into 2 bytes.
>
> My guess is that the first 2 (size 7) or 3 (size 8) bytes of the records are an offset and the next two bytes are a "base height".

Seen every record size from 3 to 8. And you are right about the first 2 
or 3 bytes being an offset to data 2 (I just read in wrong byte order 
and got confused by zero offsets). I think the zero offsets maybe reused 
data. If you have a map with an island surrounded by water it is 
possible to use offset zero for all water tiles?
I saw different size schemes for offset:
Record size		Offset
7			3
6			2
5			1

But also:
6	3
5	2
4	2
3	1

May be the offset size is coded in lowest 2 bits of byte 0x1C. This bits 
where always "offset size -1".

Ronny