polar plot for sub zones seems to not work

[doutriaux1]

use clt data

datawc_x1 = -60
datawc_y1 =  -50
datawc_x2 =  30
datawc_y2 =  -30

[doutriaux1]

@aashish24 care to take a look while you do the wrapping thing?

[aashish24]

@doutriaux1 I will work on this as soon as I fix the animation issue.

[doutriaux1]

@aashish24 @danlipsa I believe this is fixed no?

[doutriaux1]

ok I tested this is "sort of work" the issue is that data are drawn past the range required. Moving to 2.6

[doutriaux1]

It should be a arc ring, not everything should be plotted.

[doutriaux1]

Actually the old vcs wasn't much better about it:

[danlipsa]

@doutriaux1 @aashish24 In the latest master I disabled gm.datawc for geographic projections including polar. In the current code datawc is used as a zoom-in feature where the dataset stays the same and only the parallel projection changes. This cannot work for data transformed through a geographic projection because 1. datawc is specified in lon/lat 2. the subset of data is not rectangular for the geographic projected data
If we want to make this work for data transformed through geographic projections we need to change the data created in genGrid.

[doutriaux1]

@danlipsa hum... I need to think about this, i think it's important it works again for all projections. Especially for the one above. The other projection are probably less importatn, robinson/molleweide really require the whole dataset, although I cans ee poeple trying to plot data going -180/180 and other data going 0/360 with the same gm and starting wondering why they look different. Lambert should always be plotted with a sub-region so I don't think it's as critical there.

[danlipsa]

@doutriaux1 @aashish24 A small correction. For datasets that go through a geographic projection datawc works for wrapping (translation of the origin: 0:360 to -180:180) and for flipping but not for zooming into the data.

In the past, zooming was using an array of points in the desired interval that was transformed through the geographic projection, then the bounding box of the transformed points was used for parallel projection. This does not work in all cases, as you could end up with a concave shape in the Cartesian space (an arc of a circle). Getting the bounding box for that will not produce the correct results.

[danlipsa]

If you use
x.plot(a(latitude=(-60,-50), longitude=(30, -30)), b, bg=1)
it seems to produce the correct result

[danlipsa]

@doutriaux1 @aashish24 If we want to fix this, we have to do the datawc processing before we create the VTK dataset.

[alliepiper]

@danlipsa Following our discussion today, here are some links to the bits I was referring to:

#1450 contains some specific discussion of the issues with trying to execute python-implemented VTK filters in vcs.
#1343 discusses the reference leaks that caused the segfaults in #1450.
Commit 457c5fd shows the implementation of the doWrap filter. This was not used since leaked vcs objects held a reference to it, and the python interpreter had shut down by the time it was destroyed (triggering a segfault).
Commit fab23e8 shows how the doWrap filter would be used, and refactors the animation updates to reuse the existing pipelines. It is part of the unmerged update_input_vector UV-CDAT branch.