[gdal-dev] AIG field types erroneously classified as GFT_String

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] AIG field types erroneously classified as GFT_String

Gregory, Matthew
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.

thanks, matt
 

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: AIG field types erroneously classified as GFT_String

Even Rouault-2

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

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: AIG field types erroneously classified as GFT_String

Gregory, Matthew
Hi Even,

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

I've opened a ticket on this (https://trac.osgeo.org/gdal/ticket/7211) as I don't think it's as simple as I first thought.  I'd be happy to continue working on this, but might do more harm than good ...

My main use case is creating a new raster from an item in a RAT and I'm verifying that the type is allowable before proceeding.  I had hoped to use the GFT type to determine this.

thanks, matt
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev