Opened 6 years ago

Closed 5 years ago

#7211 closed enhancement (wontfix)

AIG field types for fixed integer / fixed numeric treated as strings

Reported by: grovduck Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords: AIG, RAT, data types
Cc:

Description

Initial thread on GDAL listserv:

On mercredi 24 janvier 2018 19:10:13 CET Gregory, Matthew wrote:

Hi all,

I came across what I think is a bug on reading in VAT tables using the AIG driver. I have a raster attribute table that has fixed numeric types for some items and when using the GetTypeOfCol method (in Python), I'm getting back GFT_String (2) values. I think I can trace it to lines 463-480 in aigdataset.cpp. As it's looping through the fields, the type is set to GFT_String by default and only AVC_FT_BININT and AVC_FT_BINFLOAT are checked to possibly change type. It seems like there should also be these checks/conversions:

AVC_FT_DATE -> GFT_Date(?)

AVC_FT_FIXINT -> GFT_Integer

AVC_FT_FIXNUM -> GFT_Real

I could be missing the reasoning of why these types shouldn't crosswalk to the suggested GFT_* values, so I haven't submitted as a bug.

If you can submit a patch implemting the missing mappins, as well as some testing data, that would be welcome Best regards, Even

Attachments (1)

aig_vat.7z (1.6 KB ) - added by grovduck 6 years ago.
Test AIG raster with all allowable item types

Download all attachments as: .zip

Change History (3)

by grovduck, 6 years ago

Attachment: aig_vat.7z added

Test AIG raster with all allowable item types

comment:1 by grovduck, 6 years ago

Now that I'm reading through aigdataset.cpp a bit closer, it feels like there would be some unintended consequences of forcing AVC_FT_FIXINT to GFT_Integer and AVC_FT_FIXNUM to GFT_Real (to say nothing of what to do with AVC_FT_DATE - which seems safest as a GFT_String right now).

Looking at the switch statement on lines 494-525, Frank W. looks to be intentionally treating these fields as strings rather than casting them to numeric. So by changing their data types explicitly in the code just above, there would be a mismatch between how we've defined the field and the actual data, right?

I did create a simple AIG raster for testing that has all allowed item types in it:

COLUMNITEM NAMEWIDTHOUTPUTTYPEN.DEC
1VALUE410B-
5COUNT410B-
9ITEM_B25B-
11ITEM_C1010C-
21ITEM_D88D-
29ITEM_F410F3
33ITEM_I66I-
39ITEM_N99N3

It's attached to the ticket.

comment:2 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.

Note: See TracTickets for help on using tickets.