Animation causes legend to disappears for ESGF data sets

[benbu]

@aashish24 and I ran into this issue before and I believe we fixed it by using the resultCache in lib/geo/wfl/layerSource.js subclass. I'm not sure why it would be different for esgf datasets.

[benbu]

I'm also noticing that the number labels on the legend seem to be off (both 0.00 for me, could they be really small numbers and getting truncated?)

[aashish24]

Yes we truncate to two decimal places. We can change this behavior though. I don't know if we want to show those many numbers to the general public....that's why.

[aashish24]

You are right.. resultCache was the fix. May be it get invalided somehow?

[benbu]

This appears to be related to time. For the precipitation esgf dataset variable pr, when it first runs it doesn't pass any time value, in which case the server just selects the first one. Then, when you start to animate, the first time step that it sends does not return any data, and this causes the legend to be deleted via these calls in featureLayer.js:262 (update function)

    data = this.dataSource().getData(time);
    if ((data && data.length < 1) || !data) {
      this.deleteLegend();
      return;
    }

This deleteLegend() call is never made when running animations on local clt variable.

Still investigating.

[benbu]

It appears that the first time value that is requested by the animation does not return any data. I just tried the same value directly in python.

import reader
file = '/Users/benbu/src/climatepipes/opengeoscience-data/documents/esgf/pcmdi9.llnl.gov/esgf-idp/openid/cjh1/esgdata1.nccs.nasa.gov/thredds/fileServer/obs4MIPs/NASA-GSFC/GPCP/observations/atmos/pr/mon/grid/NASA-GSFC/GPCP/V2.2/pr_GPCP-SG_L3_v2.2_197901-197912.nc'
varname = 'pr_GPCP-SG_L3_v2.2_197901-197912.nc'

a = reader.read(file, varname, 289440000000)
b = reader.read(file, varname, None)

a ends up with no data, b has data

Could it be the range is not returning the correct value in the first slot?

[aashish24]

what is the last argument?

[aashish24]

289440000000 or None. That will make a difference

[benbu]

It is the time value, if None, the reader selects the first time. That 289440000000 value is the first time that the animation requests for the precipitation pr variable, which returns no data and seems to be what's causing the legend to disapeer. The following animation requests send time values that do return data, so the rest of the animation works.

[benbu]

I can get around the legend disappearing problem by commenting out the this.deleteLegend(); line.

The real issue however is that the first time step of the animation is an invalid time, and thus returns no data.

Another issue is that the legend doesn't get recreated, even though it appears that there are calls to regenerate it if it doesn't exist.

Should I push the temporary fix for now?

[aashish24]

The time value 289440000000 is wrong. Whoever sending it should not send it. Or if we are making an extra call with no reason then may be we should not?

[aashish24]

I can get around the legend disappearing problem by commenting out the this.deleteLegend();

This won't work because if our app failed to load the data then it will still show the legend. That was the bug I tried to solve.

[aashish24]

@cjh1 You updated the animation code. Can you help @benbu with this? Its important to fix this asap.

[benbu]

If it's any help, this is the data that is returned for the pr variable, queried from the database. The "timeinfo" section might be of interest.

{
    "result": {
        "count": 1,
        "data": [{
            "basename": "/Users/benbu/src/climatepipes/opengeoscience-data/documents/esgf/pcmdi9.llnl.gov/esgf-idp/openid/cjh1/esgdata1.nccs.nasa.gov/thredds/fileServer/obs4MIPs/NASA-GSFC/GPCP/observations/atmos/pr/mon/grid/NASA-GSFC/GPCP/V2.2/pr_GPCP-SG_L3_v2.2_197901-197912.nc",
            "variables": [{
                "units": "kg m-2 s-1",
                "dim": [],
                "range": [0.0, 0.0005209979135543108],
                "name": "pr",
                "tags": []
            }],
            "timeInfo": {
                "numSteps": 12,
                "dateRange": [
                    [1979.1794520547944, 2.183333333333333, 5.5],
                    [1980.0945205479452, 1.15, 4.5]
                ],
                "nativeRange": [28869.5, 29203.5],
                "nativeStart": "1900-1-1",
                "nativeDelta": 29.5,
                "rawTimes": [28869.5, 28899.0, 28928.5, 28959.0, 28989.5, 29020.0, 29050.5, 29081.5, 29112.0, 29142.5, 29173.0, 29203.5],
                "stdDelta": 29.5,
                "units": "days since 1900-1-1",
                "nativeUnits": "days",
                "stdTimeRange": [722400.5, 722734.5]
            },
            "name": "pr_GPCP-SG_L3_v2.2_197901-197912",
            "_id": {
                "$oid": "523b2a9bb1f9a42ee88189c3"
            }
        }]
    },
    "error": null
}

[benbu]

This bug still exists, there are two things going on here.

1. The first timestep of the animation produces no results. This is due to a bad time value being passed to the workflow. When no data returns, the legend removes itself. Maybe the time information stored in the database is bad, or there is a rounding error when converting the time to milliseconds (or w/e representation we seem to be using), or something else, I'm not sure. @cjh1 or @demarle are probably best suited for this bug.
2. On the second frame frame of the animation, data is returned from the workflow and rendered properly, but the legend does not come back. The logic for adding/removing the legend may be off. @aashish24 is probably best suited for this.

[benbu]

This bug is now occuring even on local datasets on branch next, but not master.

[benbu]

This appears to be fixed on next.

[aashish24]

Thanks! closing it for now