BUG #1849: Re-enable datawc for linear projection.

[danlipsa]

For datasets using a geographic projection, datawc
is only used to specify wrapping (translation of the origin,
for instance from 0:360 to -180:180) and flipping.

[danlipsa]

CDAT/uvcdat-testdata#112

[aashish24]

@danlipsa why so many baselines changed? It seems to me that we are back to half cell on most of them?

[doutriaux1]

good idea!

[doutriaux1]

@danlipsa looks good, let's add a quick test to make sure we don' break this again.

[danlipsa]

@aashish24 @doutriaux1 It is true that we are back to half cell - this is what vcs.utils.getworldcoordinate tells us to do - to zoom into the dataset.

We can try to get rid of vcs.utils.getworldcoordinate and only follow datawc. getworldcoordinates sets zooming based on the datawc or if that is not set it sets it based on the data (without bounds).

Note there is still no cutting or misalignment so we did not loose that.

[doutriaux1]

@aashish24 where do you see a half cell? worldcoordinate uses your axes values, we can try to tweak it to use the axes bounds rather than the just the axes. I'm opened to that.

[danlipsa]

@doutriaux1 Look for instance at https://github.com/UV-CDAT/uvcdat-testdata/pull/112/files. Instead of showing the whole dataset we zoom in and cut the cells on the margine in half.
Take a look at infinity.png for instance.

[doutriaux1]

Ok I found a few ones finally. Thanks. Let's try to have getworldcoordinate return the bounds. Historically it use to be just the axes and originally I wanted to preserve this, to help users feel more confident with the VTK transition. At this point I don't think we need to do this anymore. Let's have getworldcoordinate return the real world coordinates of the data, i..e with axes bounds.

[danlipsa]

@doutriaux1 @aashish24 The problem with modifying getworldcoordinates is that coordinates depend on the type of plot we have: boxfill uses bounds, isofill, isoline and vector do not.
Question: Why do we create both cell data and point data datasets? This does not seem to be specified in the nc file.
Regardless, it is possible for different variables to have different bounds coming from an nc file in which case there is nothing we can do.

I already started passing backend.dataset_bounds using **kargs mechanism. I would use that instead and maybe get rid of getworldcoordinates alltogether as some point. Maybe we do this in two steps. 1. Try to show the full dataset if datawc is not set. I will use dataset_bounds for this 2. get rid of getworldcoordinates all together as a separate issue.

[doutriaux1]

@danlipsa the worldcoordinates for all graphic method should come from bounds, in the case of meshfill there are no axes so use data.getMashfill().min/max()
boxfill/meshfill uses celldata because we draw cells/polygones defined by the data itself, isolines and isofill only need point data since we interpolate. Does that make sense?

[danlipsa]

@doutriaux1 I was thinking that always using cell data would make the code more consistent and simplify it. If we need point data in certain plots we can easily convert cell data to point data. So, we always create the data that is specified in the file, regardless of what a specific plot needs. Note that vtkCellDataToPointData works by averaging cells used by every point, which will give you the same bounds as for the cell data which is a nice thing to have when doing several plots in the same image.

[doutriaux1]

@danlipsa that's fine with me. I thought isofill was requiring point data (filter) if it doesn't then it's ok with me. Although point data is nice for unstructured grid since we don't always have the whole cell information. Anyhow let's do this in a separate PR.

[danlipsa]

@doutriaux1 Definitely a separate PR.

[danlipsa]

@aashish24 @doutriaux1 Note there are missing triangles when zooming into mesh data:

Probably has to do with wrapping of meshfill data, but I don't know why it happens. I will look into it.

[danlipsa]

@doutriaux1 besides that problem it should be ready to merge. I think it is worth trying to see if it fixes PCMDI/pcmdi_metrics#296. @aashish24 We decided to leave the half cells in as this was the original behavior of uvcdat and we'll be faster in fixing the issue at hand. We can enable showing the whole dataset as a separate PR.

[doutriaux1]

@danlipsa yes! It does fix this issue:

[danlipsa]

@doutriaux1 Great!

[danlipsa]

@doutriaux1 Interesting plot by the way.

[danlipsa]

@doutriaux1 What does the plot mean? For each cell, it shows 4 things? What are those? I am curious. :-)

[doutriaux1]

Each cell is basically a score skill for a model/variable. The cell itself is broken into N (4 in this case) references. That is to make sure your score does not depend on the set set of observation you used.

[durack1]

@danlipsa, @gleckler1 will be delighted that you think the gleckler plot is "interesting".. He's going to be making many more of them in the coming months..

[danlipsa]

@durack1 Indeed, I think the plot looks good - it draw me in even without knowing what it means.