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