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)
Change History (3)
by , 6 years ago
Attachment: | aig_vat.7z added |
---|
comment:1 by , 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:
COLUMN | ITEM NAME | WIDTH | OUTPUT | TYPE | N.DEC |
1 | VALUE | 4 | 10 | B | - |
5 | COUNT | 4 | 10 | B | - |
9 | ITEM_B | 2 | 5 | B | - |
11 | ITEM_C | 10 | 10 | C | - |
21 | ITEM_D | 8 | 8 | D | - |
29 | ITEM_F | 4 | 10 | F | 3 |
33 | ITEM_I | 6 | 6 | I | - |
39 | ITEM_N | 9 | 9 | N | 3 |
It's attached to the ticket.
comment:2 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
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.
Test AIG raster with all allowable item types