Hi Gerd
yes, it is an error. But how do you suggest to change mkgmap?
I'm not suggesting any change to mkgmap, apart from flagging errors wherever we currently silently truncate or mask out bits. I realise that all this is ambiguous, but this is how I see it: 0x1f means: normal, type 0x1f, no subtype 0x11f means: normal, type 0x1, subtype 0x1f 0x1011f means: extended, type 0x1, subtype 0x1f I seems that some people see 0x1011f as type 0x101 and subtype 0x1f, but extended types are in a completely separate area to normal types and 0x101 is not written to the img, just 0x01. Two things to note: 1. 0x100 would logically mean "type 0x1, subtype 0x00", but (in points) it is interpreted as "type 0x1, no subtype", and if I remember correctly that was a deliberate change as subtype 0x0 is not allowed or has reported problems. (subtype 0x0 is allowed for extended types so 0x10100 is fine and means "extended, type 0x01, subtype 0x00) 2. You can't express "normal, type 0x0, subtype 0xYY".
The default style uses 0xYY in lines and polygons file, as we don't use extended types, and the range for YY is 00 to 3f for lines and 00 to 7f for polygons, and sub types are not supported for them.
Should we interpret 0x3f00 like 0x3f I think it would be OK to be an error (especially since anyone who is using that currently is not getting what they expect), but it does seem a bit harsh to error on 0x3f00 as it is not confusing, so I don't mind if you make that change.
... and 0x11f like 0x11f00 ?
No. I think it is well established that extended types are written like 0x1xxyy, and as the subtype is typically not 0 the proposed shortened form would be only rarely usable. So I don't see the benefit of the extra ambiguity and confusion.
If yes, should this produce an error message like style abc, file lines, line xyz, interpreting type 0x3f00 as 0x3f Either make it an error or accept it without a message.
..Steve