[mapserver-users] Ack! shptree bug????

[Frank Warmerdam]

Stephen Woodbridge wrote:
> That is a possibility, but when I ran shptreevis on the bad index it had
> a depth of over 150,000,000 which is a problem. when I ran shptree
> tileindex 13 NM I get a good file.
> 
> [woodbri at linus mdata]$ shptree tgrindex
> creating index of old native format
> [woodbri at linus mdata]$ shptreevis tgrindex tgrindex-new
> This old MSB index supports a shapefile with 524288 shapes, 150994944
> depth 
> 
> [woodbri at linus mdata]$ shptree tgrindex
> 13                                                
> creating index of old native format
> [woodbri at linus mdata]$ shptreevis tgrindex tgrindex-new
> This old MSB index supports a shapefile with 524288 shapes, 218103808
> depth
> 
> [woodbri at linus mdata]$ shptree tgrindex 13
> NM                                                        
> creating index of new MSB format
> [woodbri at linus mdata]$ shptreevis tgrindex tgrindex-new
> This old LSB index supports a shapefile with 2048 shapes, 13 depth 
> 
> This looks more and more like shptree bug. It is possible that I have
> created a bad record with my compression utility. I'll check on that,
> but if that is the case, it would be nice if shptree did some basic data
> checking. 

Stephen,

Are you working with a recent MapServer and tools from CVS?  There was a
bug related to correctly determining the byte order of "old native format"
quadtrees that was fixed Jan 22 in maptree.c version 1.8.  If you don't have
that 1 in 256 old style quadtree indexes will be read as "corrupt" because
of a mistake in guessing the byte order.  The problem is not encountered
in the new format indexes and is fixed in CVS.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent