Question

I’m working with a Matlab API that loads data from a proprietary format into a series of structures. Here’s an example of what a dataset looks like after loading a file:

>>fieldnames(data(1))

ans =

'Grid_Point_ID'
'Grid_Point_Latitude'
'Grid_Point_Longitude'
'Grid_Point_Altitude'
'Grid_Point_Mask'
'BT_Data'

>> data(1).BT_Data

ans =

BT_Data: [1x66 struct]

>> fieldnames(data(1).BT_Data(1))

ans =

'Flags'
'BT_Value_Real'
'BT_Value_Imag'
'Pixel_Radiometric_Accuracy'
'Incidence_Angle'
'Azimuth_Angle'
'Faraday_Rotation_Angle'
'Geometric_Rotation_Angle'
'Snapshot_ID_of_Pixel'
'Footprint_Axis1'
'Footprint_Axis2'

I want to loop over all data(i).BT_Data(j). I’ve already got the length of data fine, but I can’t get the size/length of BT_Data (which varies for each data(i)):

>> length(data(1).BT_Data)

ans =

 1

>> size(data(1).BT_Data)

ans =

 1     1

My expected result here is ans = 66 (or equivalent array for size()).

I’m not terribly familiar with the structure data format, which may be part of my struggles. But length(data) worked fine, so I’m confused why it won’t work on BT_Data (I’ve also tried BT_Data(:)).

The most relevant previous answer I can find is 1757250, but I couldn’t get it to work (I think it doesn’t apply here). Thanks for any insight you can provide.

------ EDIT ------

Here’s a little more insight into how I have to use the API to even get to the point where I’m at:

>> system(‘ln -sf /opt/rwapi-matlab/lib/rwapi/smos/config/xml_rw_api.usr_conf.xml .’);
setenv(‘XML_RW_API_HOME’,’/opt/rwapi-matlab/lib/rwapi’);
path(path,’/opt/rwapi-matlab’);

>> prod = RWAPI.product(‘SM_OPEB_MIR_SCLF1C_20110202T013659_20110202T014642_346_060_1’)

Array SMOS Matlab Interface version 1.4
(c) 2010 Array Systems Computing Inc. of Canada (http://www.array.ca)
Distribution or modification of this software requires written permission from Array

prod =

RWAPI.product handle
Package: RWAPI

Properties:
     filename: 'SM_OPEB_MIR_SCLF1C_20110202T013659_20110202T014642_346_060_1'
       header: [1x1 struct]
xml_datablock: []

Methods, Events, Superclasses

>> data = prod.dataset(2)

data =

RWAPI.dataset handle with no properties.
Package: RWAPI

Methods, Events, Superclasses

>> data(1)

ans =

       Grid_Point_ID: 251721
 Grid_Point_Latitude: 25.5000
Grid_Point_Longitude: -102.2590
 Grid_Point_Altitude: 1.4714e+03
     Grid_Point_Mask: 2
             BT_Data: [1x66 struct]

>> data(1).BT_Data

ans =

BT_Data: [1x66 struct]

>> data(1).BT_Data(1)

ans =

                     Flags: 6229
             BT_Value_Real: 262.5275
             BT_Value_Imag: 0
Pixel_Radiometric_Accuracy: 6160
           Incidence_Angle: 31966
             Azimuth_Angle: 10299
    Faraday_Rotation_Angle: 65277
  Geometric_Rotation_Angle: 58605
      Snapshot_ID_of_Pixel: 65752530
           Footprint_Axis1: 19649
           Footprint_Axis2: 14625

>> whos
Name Size Bytes Class Attributes

ans 1×1 1 logical
data 1×19091 112 RWAPI.dataset
prod 1×2 112 RWAPI.product

Answer 1

Okay, I really suspect it’s an oddity in an overrridden subsref method in those RWAPI classes. I was able to reproduce all your observed behavior by defining a class with a slightly pathological subsref.

classdef stupidref
    %STUPIDREF Reproduce odd indexing behavior that jpatton saw. Buggy.
    properties
        BT_Data = repmat(struct('foo',42, 'bar',42), [1 66]);
    end
    methods
        function B = subsref(A,S)
            s = S(1);
            subs = s.subs;
            chain = S(2:end);

            switch s.type
                case '()'
                    B = builtin( 'subsref', A, s );
                    if ~isempty(chain)
                        B = subsref(B, chain);
                    end

                case '.'
                    % Non-standard behavior!
                    if ~isempty(chain) && isequal(chain(1).type, '()')
                        B = subsref(A.(s.subs), chain);
                    else
                        B = struct(s.subs, A.(s.subs));
                    end
            end
        end
    end
end

This is consistent with the weird difference between data(1).BT_Data and fieldnames(data(1).BT_Data(1)), and the tab-completion that repeatedly adds “.BT_Data”.

>> data = stupidref;
>> data(1).BT_Data
ans = 
    BT_Data: [1x66 struct]
>> fieldnames(data(1).BT_Data)
ans = 
    'BT_Data'
>> fieldnames(data(1).BT_Data(1))
ans = 
    'foo'
    'bar'
>> length(data(1).BT_Data)
ans =
     1
>> data(1).BT_Data.BT_Data.BT_Data.BT_Data.BT_Data.BT_Data % produced by tab-completion
ans = 
    BT_Data: [1x66 struct]
>> 

Your workaround is good – once you call a = data(1).BT_Data, you’ve got a normal struct, and the nonstandard subsref is out of the way. You can get the same effect in a one-liner with getfield.

>> btdata = getfield(data(1).BT_Data, 'BT_Data')
btdata = 
1x66 struct array with fields:
    foo
    bar

I would report this as a possible bug to the RWAPI library authors.

Feel free to just edit this code in to your own workaround answer; it’s not really an answer so much as supporting diagnostics.