Continents are off

[doutriaux1]

When plotting data with a user we noticed the continents seem to be a bit to much up north.
1.5.1 is ok. Png to follow soon

[doutriaux1]

our version (BAD)

1.5.1 version (good)

[doutriaux1]

actually the continents look good, it's almost as if the data is shifted rather than continents

[doutriaux1]

@dlonie I think it is because we set the data on "cellData" rather than "pointData" I'm using ployDataMApper and DatasetMAppers, do they do anything with the grid if data is on cells? It is odd.

Please use the same script/data (bad.nc) I sent earlier and switch between isofill or boxfill for gms, you will see the data shift dramatically when switching. Moving isoline/fills from cellData to pointData seems to have fixed this.

Any idea?

Bellow the good (isofill) and bad/shifted (boxfill) data
good:

and bad:

[doutriaux1]

and good version of boxfill, generated with 1.5.1 (excpet for colors)

[doutriaux1]

@dlonie any ideas?

[alliepiper]

I suspect it has something to do with the transforms that are used to
resize / translate the data (the fitToViewport stuff, IIRC). I'd start
looking there.

It seems to me that it'd be more robust to not rescale/stretch/etc the data
with a transform, but rather leave the data in the same coordinate system
and adjust the viewport/camera to get the desired view -- It's fewer things
to keep track of and less error prone. Is there a reason for using the
transforms that I'm missing?

On Fri, Mar 6, 2015 at 9:39 AM, Charles Doutriaux [email protected]
wrote:

@dlonie https://github.com/dlonie any ideas?

—
Reply to this email directly or view it on GitHub
#1106 (comment).

[doutriaux1]

@aashish24 you designed this at the very beginning of the VTK rewrite, can you take a look please?
@dlonie the problem though is we do want to stretch/squeeze the data to fit the viewport, is that doable w//o a transform?

[alliepiper]

@doutriaux1 Yes, the vtkCamera class provides complete control over the modelview and projection matrices, which allow anisotropic stretching/scaling. The vtkPerspectiveTransform class can be used to help define the matrices, in particular vtkPerspectiveTransform::Ortho method looks like what we'd want.

[alliepiper]

BTW, I'm not suggesting that as a fix for 2.2. If we make the camera/viewport-instead-of-actor-transforms change, it would be as part of the post-2.2 work.

[doutriaux1]

@williams13 I think @dlonie is right. It's part of making everything "the-right-vtk-way" It's slightly off on boxfill plots for noew but isoline/isofill are correct. I'd say let ship 2.2 like that and fix it for 2.3/3.0. Thoughts?

[williams13]

I just don’t want users to compare the output with other packages and say UV-CDAT gives wrong output. This will be very bad!

From: Charles Doutriaux <[email protected]mailto:[email protected]>
Reply-To: UV-CDAT/uvcdat <[email protected]mailto:[email protected]>
Date: Friday, March 6, 2015 at 12:26 PM
To: UV-CDAT/uvcdat <[email protected]mailto:[email protected]>
Cc: Dean Williams <[email protected]mailto:[email protected]>
Subject: Re: [uvcdat] Continents are off (#1106)

@williams13https://github.com/williams13 I think @dloniehttps://github.com/dlonie is right. It's part of making everything "the-right-vtk-way" It's slightly off on boxfill plots for noew but isoline/isofill are correct. I'd say let ship 2.2 like that and fix it for 2.3/3.0. Thoughts?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1106#issuecomment-77629379.

[aashish24]

@doutriaux1 this is still broken right?

[doutriaux1]

Oh! I have the data now, I need to double check.

[aashish24]

@doutriaux1 did you check?

[aashish24]

@sankhesh do you think @danlipsa can look into this? Can you help?

[sankhesh]

Yes. This should have been fixed already. @doutriaux1 was going to check.

@danlipsa may be able to verify.

[doutriaux1]

doh! I'm on it.

[aashish24]

thanks @doutriaux1

[danlipsa]

@doutriaux1 Are you going to look into this? I got a bad.nc from David Lonie but I don't have the script to use with it. Thanks.

[alliepiper]

This might be unrelated, but I had this script stored with the bad.nc file:

import cdms2,vcs,cdutil

f=cdms2.open("bad.nc")
ice = f("variable_6")
x=vcs.init()

gm = x.createisofill()
gm.label = "y"
#gm = x.createboxfill()
#gm.boxfill_type="custom"

tmpl = x.createtemplate()
#tmpl.blank()
tmpl.data.priority=1
tmpl.data.x1=.05
tmpl.data.x2=.95
tmpl.data.y1=.05
tmpl.data.y2=.90
tmpl.title.priority=1
tmpl.box2.priority=1
tmpl.box2.x1=.23
tmpl.box2.x2=.815
tmpl.box2.y1=.11
tmpl.box2.y2=.895
tmpl.title.x=.5
tmpl.title.y=.95

tmpl.legend.priority=1
tmpl.legend.x1=tmpl.box2.x1-.05
tmpl.legend.x2=tmpl.box2.x2+.05
tmpl.legend.y1=.03
tmpl.legend.y2=.055
tmpl.max.priority=1

#tmpl.crdate.priority=1
#tmpl.crdate.x=.8
#tmpl.crdate.y=.95
txt = x.createtext()
txt.height = 20
#txt.color=242
txt.valign="half"
txt.halign = "center"

tmpl.title.textorientation=txt.To_name
tmpl.title.texttable=txt.Tt_name

ice.long_name = "September sea ice fraction: 4xCO2 climate, no ocean albedo alteration "
levs = vcs.mkscale(ice.min(),ice.max())

cols=vcs.getcolors(levs)
cols[0]=240

gm.levels= levs
gm.fillareacolors = cols
#gm.projection="polar"
gm.datawc_y2=30
gm.datawc_y1=90

x.plot(ice,gm,tmpl,bg=1)
fnm = "bad.png"
x.png(fnm)

[danlipsa]

Thanks I will take a look.

[danlipsa]

@doutriaux1 @sankhesh @aashish24 I run the script that Charles gave me and the bad.nc that Dave Lonie gave me and got an image identical with the good image that Charles sent on March 5th -- see attached. Charles, can you check and close the issue - Thanks.

[sankhesh]

@danlipsa Could you also post an image of the boxfill plot?

[danlipsa]

I commented out createisofill() and uncommented createboxfill() and boxfill_type. Here is the image:

[doutriaux1]

@danlipsa it still seems that we have a lot of seance inside greenland and greenland should be empty. If you look at my "good" (purple) png I posted on this thread, Greenland is mostly w/o any sea-ice in it.

[danlipsa]

I see. So isofill is correct but boxfill is not?

[doutriaux1]

yes, exactly. I believe it is because one is using celldata and the other point data filters.

[danlipsa]

Sounds good. I will take a look.

[aashish24]

@danlipsa any update?

[danlipsa]

@aashish24 no result yet.

[danlipsa]

@doutriaux1 Can I have the bad.nc you have? I am not sure but the data I have seems slightly different. Notice the maximum occurs in level 4 for my image (magenta color) and in level 3 for your good image (deep red color). Thanks.

[danlipsa]

@doutriaux1 As we have discussed in the meeting, the missing row at 90 degrees seem to be the problem. All rows are shifted up by one, which explains why we have ice over Greenland and also answers why the maximum occurs in different rows for the two images.