
Hi Steve, yes, it is an error. But how do you suggest to change mkgmap? 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 and 0x11f like 0x11f00 ? If yes, should this produce an error message like style abc, file lines, line xyz, interpreting type 0x3f00 as 0x3f style abc, file polygons, line xyz, interpreting type 0x11f as extended type 0x11f00. Or do you vote for a change so that the user always has to write 0xXYYZZ ? Gerd Steve Ratcliffe wrote
On 02/01/14 22:00, GerdP wrote:
got no answer on the question what mkgmap should do with a type like 0x11f in the lines file. The current behaviour is that it quietly ignores the error because it treats 0x11f like 0x1f.
I would say that it is an error.
I break the full type down as follows:
0xXYYZZ
X is a flag for 'extended type' (0 or 1) YY is the type ZZ is the subtype (max 0x1f)
I would always recommend using the full types, since the short forms cause so much confusion.
..Steve _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57915... Sent from the Mkgmap Development mailing list archive at Nabble.com.