Hi all,
I am still struggling with the NET 4 structures. Whenever I find a pattern I
also find exceptions to it ;)
Reg. NET 5:
It is a replacement for NET 3 (sorted roads)
- first two bits give the label number
- next n bits give the offset, n is the minimal number of bits needed to
address all bytes in NET 4. Something like this
n = Integer.numberOfTrailingZeros(Integer.highestOneBit(<bytes in NET 4>)) +
1;
- the remaining bits are not yet clear to me.
Gerd
________________________________________
Von: mkgmap-dev<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gerd
Petermann<gpetermann_muenc...@hotmail.com>
Gesendet: Samstag, 5. März 2022 11:40
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] some findings about NT format
Hi all,
I think today I've now identified most of the structures of the NET file. Quite
a lot of fields and bitstreams and I still don't know much about the meaning of
them.
Most of the findings described before were correct as long as some more flags
are considered, but there is much more. Bit 0x20 in the first flag byte signals
another
bunch of possible structures following.
I think this allows to read NET4 without looking at NOD, and there are some
roads which are not referenced in RGN (and ignored by GPXSee). They possibly
have no extra lines
or the same lines as they preceding road.
I've not yet made up my mind if I can add code to the existing NetDisplay in
display tool or if we need a new GmpDisplay program.
Reg. NET5:
Sample from NET header:
000006d9 | 2d 10 1f 00 | NET5 ???, offset 1f102d
000006dd | c4 9d 01 00 | NET5 ???, length 105924
000006e1 | 27 00 | ???
The header has a record length (0x27 =39) but that seems to give the number of
bits, not bytes. At least I see some patterns when I print the bitstreams with
that length.
In general the record size seems to depend on the number of roads, the more
roads the larger the record size.
I guess there is a header which tells us what the bits mean. Todo...
ciao,
Gerd
________________________________________
Von: mkgmap-dev<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gerd
Petermann<gpetermann_muenc...@hotmail.com>
Gesendet: Mittwoch, 23. Februar 2022 09:45
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] some findings about NT format
Hi all,
I've identified a few more bytes following the road labels.
If there are labels there is always an additional byte array.
This starts with a length field (varying number of bytes).
First byte in the array is a flag byte, the lower 4 bits each indicate the
existance of another byte array with length prefix.
Example:
buf=[1d, 07, 07, 04, 01, 39, 07, 04, 01, 5b, 09, 2a, f1, 46, 66]
1d == 29 -> length 14
07 flag byte
07 1st array length -> 3
array1=[04, 01, 39]
07 2nd array length -> 3
array2=[04, 01, 5b]
09 3rd array length -> 4
array3=[2a, f1, 46, 66]
The top 4 bits are probably also flags. I've not yet understood what they mean,
each seems to flag the existence of further bytes, but the number of those
bytes vary.
The flag byte might be 0:
buf=[03, 00]
array1 and array2 are more often found for major roads, but also on some minor
ones. No idea yet what they mean.
I am pretty sure that array3 contains the house numbers, because this array
never shows up on motorways.
Our code to read them doesn't (always) work. It seems to extract the base
number correctly but then often fails.
So I guess Garmin has extended the format. Maybe Numbers like 1a,1b are
supported now?
Another example:
buf=[11, 84, 09, 2a, 30, 00, 27, 02, 57]
11 (=17) -> length 8
84 flag byte : (only) array4 exists, and 0x80 is set
09 array4 length -> 4
array4=[2a, 30, 00, 27]
The remaining bytes x02,x57 are probably a flag and a counter (or id). The flag
probably indicates if the counter fits into one or two bytes.
The counter itself simply increases for all roads with labels and the 0x80 bit
in the flag byte set. No idea yet where this is used.
I'll soon have access to a Garmin Nüvi. I hope that allows me to load the map
in Mapsource or Basecamp. Maybe this will tell me what
additional data we can find.
Gerd
________________________________________
Von: mkgmap-dev<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gerd
Petermann<gpetermann_muenc...@hotmail.com>
Gesendet: Mittwoch, 16. Februar 2022 17:45
An:mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] some findings about NT format
Hi all,
my findings so far which are not used / needed in GPXSee. Maybe it helps
someone else:
- method linkLabel() could extract further road labels, bit 0x800000 flags the
last of up to 4 labels.
- method linkLabel() extracts a flag, the bit 0x08 in this flag seems to
signal a tunnel. No idea yet what the other bits mean.
- the flags field in struct LinkInfo is used like this (netfile.cpp)
bool firstIsShape = (linkInfo.flags >> 10) & 1;
bool singleTopology = (linkInfo.flags >> 9) & 1;
bool hasLevels = (linkInfo.flags >> 11) & 1;
My guesses about the meaning of the lower bits:
// int road_speed = linkInfo.flags & 7;
// bool oneway = (linkInfo.flags >> 3) & 1;
// int road_class = (linkInfo.flags >> 4) & 7;
- The NET header can have two more sections, e.g. I see
00000684 | f6 cb 13 00 | NET5 ???, offset 13cbf6
00000688 | 96 0a 01 00 | NET5 ???, length 68246
0000068c | 23 00 | ???
0000068e | 8c d6 14 00 | NET6 ???, offset 14d68c
00000692 | 28 05 00 00 | NET6 ???, length 1320
00000696 | 03 00 | NET6 ??? record size 3
00000698 | 02 00 00 00 | ???
NET6 contains a list of offsets into NET4, they are in sorted order
and each offset points to the byte following the flag byte that is read in
linkLabel()
I see 440 recrods here, and 441 NOD6 records in the corresponding NOD file,
so they are obviously related (field blockIndexId).
I've not yet found where the address info like city name, zip name, and house
numbers are
stored. Maybe that's in NET5.
I think in the old non-NT format there is no need to know NOD data to be able
to read NET, so
I woulld expect that this is also possible with NT maps.
Gerd
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev