Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Continents are off #1106

Closed
doutriaux1 opened this issue Mar 3, 2015 · 32 comments
Closed

Continents are off #1106

doutriaux1 opened this issue Mar 3, 2015 · 32 comments
Assignees
Milestone

Comments

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Mar 3, 2015

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
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 3, 2015

our version (BAD)
bad

1.5.1 version (good)
good

@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 3, 2015

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

@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 6, 2015

@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:
ok
and bad:
bad

@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 6, 2015

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

@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 6, 2015

@dlonie any ideas?

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 6, 2015

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 notifications@github.com
wrote:

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


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

@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 6, 2015

@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?

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 6, 2015

@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.

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 6, 2015

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
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 6, 2015

@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
Copy link
Contributor

@williams13 williams13 commented Mar 7, 2015

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 <notifications@github.commailto:notifications@github.com>
Reply-To: UV-CDAT/uvcdat <reply@reply.github.commailto:reply@reply.github.com>
Date: Friday, March 6, 2015 at 12:26 PM
To: UV-CDAT/uvcdat <uvcdat@noreply.github.commailto:uvcdat@noreply.github.com>
Cc: Dean Williams <williams13@llnl.govmailto:williams13@llnl.gov>
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.

@doutriaux1 doutriaux1 added this to the 2.3 milestone Mar 9, 2015
@doutriaux1 doutriaux1 removed this from the 2.2 milestone Mar 9, 2015
@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Oct 15, 2015

@doutriaux1 this is still broken right?

@aashish24 aashish24 added this to the 3.0 milestone Oct 15, 2015
@aashish24 aashish24 removed this from the 2.4 milestone Oct 15, 2015
@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Oct 16, 2015

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

@doutriaux1 doutriaux1 added this to the 2.4 milestone Oct 16, 2015
@doutriaux1 doutriaux1 removed this from the 3.0 milestone Oct 16, 2015
@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Nov 13, 2015

@doutriaux1 did you check?

@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Nov 13, 2015

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

@sankhesh
Copy link
Contributor

@sankhesh sankhesh commented Nov 13, 2015

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

@danlipsa may be able to verify.

@aashish24 aashish24 assigned danlipsa and unassigned sankhesh Nov 13, 2015
@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Nov 13, 2015

doh! I'm on it.

@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Nov 13, 2015

thanks @doutriaux1

@danlipsa
Copy link
Contributor

@danlipsa danlipsa commented Nov 16, 2015

@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.

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Nov 16, 2015

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
Copy link
Contributor

@danlipsa danlipsa commented Nov 16, 2015

Thanks I will take a look.

@danlipsa
Copy link
Contributor

@danlipsa danlipsa commented Nov 16, 2015

@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.

bad

@sankhesh
Copy link
Contributor

@sankhesh sankhesh commented Nov 16, 2015

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

@danlipsa
Copy link
Contributor

@danlipsa danlipsa commented Nov 16, 2015

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

@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Nov 16, 2015

@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
Copy link
Contributor

@danlipsa danlipsa commented Nov 16, 2015

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

@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Nov 16, 2015

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

@danlipsa
Copy link
Contributor

@danlipsa danlipsa commented Nov 16, 2015

Sounds good. I will take a look.

@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Nov 18, 2015

@danlipsa any update?

@danlipsa
Copy link
Contributor

@danlipsa danlipsa commented Nov 18, 2015

@aashish24 no result yet.

@danlipsa
Copy link
Contributor

@danlipsa danlipsa commented Nov 18, 2015

@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
Copy link
Contributor

@danlipsa danlipsa commented Nov 18, 2015

@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.

danlipsa added a commit that referenced this issue Nov 24, 2015
… bounds

We did not handle correctly a nc file which specifies bounds and
has decreasing latitude or longitude.
danlipsa added a commit that referenced this issue Nov 24, 2015
… bounds

We did not handle correctly a nc file which specifies bounds and
has decreasing latitude or longitude.
doutriaux1 added a commit that referenced this issue Dec 2, 2015
BUG #1106: wrong dataset created from nc file with decreasing lat and…
danlipsa added a commit that referenced this issue Dec 2, 2015
danlipsa added a commit that referenced this issue Dec 2, 2015
doutriaux1 added a commit that referenced this issue Dec 10, 2015
Add test for issue #1106: Continents are off.
@danlipsa danlipsa closed this Dec 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants