Opened 18 years ago

Last modified 18 years ago

#1202 closed defect (fixed)

DBFReadStringAttribute can return garbage -- seen in QGIS and MapWindow

Reported by: cmichaelis@… Owned by: warmerdam
Priority: high Milestone:
Component: OGR_SF Version: unspecified
Severity: normal Keywords:
Cc: Markus Neteler

Description

It appears that DBFReadStringAttribute can sometimes return a string with
garbage in it when it should return either a blank string or a string of spaces.
This may be seen with the attached demonstration shapefile.

Also attached is a screen shot of how ArcMap handles these values, as well as a
screen capture from QGIS and from MapWindow.

This could be a problem with the shapefile as well. The user who reported this
bug to us originally has not explained how he generated this shapefile (using
what tool or mechanism), so it could be that the shapefile itself is flawed.

Thanks for your excellent work as always!
--Chris

Attachments (4)

fields.zip (873 bytes ) - added by cmichaelis@… 18 years ago.
Shapefile demonstrating the problem
arcview_dbf.gif (13.9 KB ) - added by cmichaelis@… 18 years ago.
Screen shot of how ArcMap handles this file
qgissceenshot.JPG (33.4 KB ) - added by cmichaelis@… 18 years ago.
Screen shot of how QGIS handles this file
mw_ss.jpg (22.6 KB ) - added by cmichaelis@… 18 years ago.
Screen shot of how MapWindow handles this file

Download all attachments as: .zip

Change History (5)

by cmichaelis@…, 18 years ago

Attachment: fields.zip added

Shapefile demonstrating the problem

by cmichaelis@…, 18 years ago

Attachment: arcview_dbf.gif added

Screen shot of how ArcMap handles this file

by cmichaelis@…, 18 years ago

Attachment: qgissceenshot.JPG added

Screen shot of how QGIS handles this file

by cmichaelis@…, 18 years ago

Attachment: mw_ss.jpg added

Screen shot of how MapWindow handles this file

comment:1 by warmerdam, 18 years ago

I have confirmed a problem, but it turns out to be due to non-zero values
in the "decimals of precision" value for many of the strings.  This was
being treated as a high order byte for the length in shapelib and causing
many fields to be consider as longer than they really were.  This later resulted
in values being pulled from chunks of memory far beyond the end of the 
physical record and corresponding problems.  

I have corrected this in Shapelib, and ported the fixes into OGR and now the
dataset works fine. 


Note: See TracTickets for help on using tickets.