logo separator

[mkgmap-dev] check-styles

From Gerd Petermann gpetermann_muenchen at hotmail.com on Sat Apr 27 08:59:35 BST 2013

Hi Nick,

> I see what the problem is
> 
> I had 0x3d00 for this polygon  'meaning' 0x3d  
> 
> Strangely, I have encountered subtypes for types <&100 in some 'older' topo
> maps.
> 
> However, 0x3d00 can only mean 0x3d as the highest polygon seems to be
> 0x1ff1f

Welll, a type > 0x10000 is an extended type. This can be used with points, lines, and polygons
and is handled in completey different routines.

A good question is how mkgmap should interpret type 0x3d00 used with a polygon or a line.
Internally, mkgmap r2578 stores the value as 0x3d00, but it writes only 0x00 to the img file.

Note that points are different here: 0x3d00 is written as 0x3d to the img file (no sub type) If the last byte is
not 0, e.g. 0x3d05, mkgmap writes type 0x3d and sub type 0x05. 

Afaik there is no way to write a sub type for lines or polygons, so we may change mkgmap to read 
0x??00 as 0x?? when used with a line or polygon.

> have tested:
> 
> 0x03d   (invalid)  
> 0x03d0 (invalid)  
> 0x03d00 (invalid)  

please check: 
do you have an overlays file in your style? If yes, please wait for a fix, cause overlays is not 
correctly handled by the check function.
 if not: 0x03d should not cause trouble with a polygon, as it is equal to 0x3d, the other two should be flagged as invalid

> 
> The last one in my opinion could be valid as with pois and lines
see above

Gerd
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130427/fb7a850f/attachment.html 


More information about the mkgmap-dev mailing list