Bad rendering of aeqd projection

[sankhesh]

The following image is one of the baselines in the vcs testing suite (for test_vcs_basic_boxfill_aeqd_proj)

There is a visible seam in the center of the image. The blob over Sahara in Africa is just half shown purple.

[alliepiper]

The new refactoring branch fixes a number of similar issues. See the meshfill-related baselines in CDAT/uvcdat-testdata#58. The main issue there was that doWrap uses the scale factor set by fitToViewport, but was called before fitToViewport, so it was wrapping using the unscaled bounds.

Not sure if this is the same issue, but it sounds similar. My fix in that branch is tied up with the new vtk python filters that segfault when they are leaked, so we'll need to address the leaks before that can be tried. But it might help for tracking this down.

Again, it would be a good idea (in my opinion) to have a user/scientist/vcs guru go through the baselines and the tests to identify which ones have issues. Seems like we're finding invalid "reference" images fairly regularly, and it would go a long way towards improving the quality of UVCDAT to ensure that our reference images are actually correct. Just my 2c.

[doutriaux1]

northern europe continents are all messed up as well. I think this issue has been present since before the refactoring though. I guess we can double check with the baseline history.

[durack1]

@dlonie are there plans to add some projection examples (Mollweide, Robinson) into the test suite? These are where some of the more obvious errors have appeared in 2.2.0 - I'd also note that in the above image it appears that the left side is truncated (it should be rounded like the right hand side, not square in the tropical latitudes [20S - 20N])

[alliepiper]

@durack1 I'm not working on VCS any longer, only on VTK, so I have no plans to add further tests for VCS. Please talk with @sankhesh or @doutriaux1 about VCS specific issues.

[doutriaux1]

@sankhesh is that in your area of expertise? @aashish24 should we find someone at Kitware who is an expert at these? Lots of work is needed with projections it might be worth it.

[aashish24]

@doutriaux1 is this a projection issue or a wrapping issue?

[doutriaux1]

The latest I've seen are wrapping issues, drawing the boxes/isofills accros the globe when going 5->355, instead of splitting it into 2 boxes. One way to "know" how to treat cells like this is to look if the vertices go clockwise vs counterclockwise.

[aashish24]

@doutriaux1 I don't seem to find test_vcs_basic_boxfill_aeqd_proj

[aashish24]

@doutriaux1 good news and bad news. I think I know what's going on. Look at this image created using aeqd projection but between -180 and 90 longitudinal axis.

And looks close to correct. I think the problem is that in aeqd projection lon values from 90 - 180 will get wrapped behind the 0 - 90 values and since that happens later, plotting code will draw that vs the previous colors and that's how you are seeing australia which is really behind Africa.

Bad news: Well it could be that PROJ4 is doing the right thing here or may be not. May be we need to upgrade to new PROJ4 and see if this fixes the issue. At VTK level, I have to think about how to resolve this since there is no z value to use for resolution. We may have to fix this in 3.0

[aashish24]

Here is the command line I used to generate the plot above:

python test_vcs_basic_gms.py --gm_type=boxfill --projection=aeqd --lon1=-180 --lon2=90 --lat1=-90 --lat2=90

[aashish24]

Also, for testing I commented out the code in fitToViewport call.

[aashish24]

@doutriaux1 I moved it to 3.0 for now. I don't have quick solution to this project.Looking at the newer proj4 I think the proj4 library is doing it right its just that this is how this projection works. Let me know what you think.

[doutriaux1]

@aashish24 yes that is the whole issue, proj4 wants data from -180 to 180. So it's not a 3.0 issue, WE need to make sure data going to proj4 are between -180 and 180 and we need to tweak the proj parameters (center_meridian etc..) to make sure it is centered properly and show the portion that the user want.

[aashish24]

@doutriaux1 its not a proj4 or -180-180 issue. If you chose the center to be 0,0, the project math wraps the entire world into a orthographic projection, however, the other side is wrapped as orthographic as well which in our case gets drawn on top of the initial rendering. I have to verity the math in of aeqd but I don't think there is an easy fix since we don't know which data will wrap how as for aeqd you can give any seed point.

[aashish24]

Ref: http://www.remotesensing.org/geotiff/proj_list/azimuthal_equidistant.html

[doutriaux1]

that's my point we need to make sure we chose the correct center for our users.

[aashish24]

@doutriaux1 the most useful images I see from aeqd is for lat=90/-90 (think United Nations logo, https://en.wikipedia.org/wiki/Azimuthal_equidistant_projection). Do you want me to make such change? If we want to support some other centers, either we would need to apply some transparency or come up with some other technique.

[aashish24]

and UV-CDAT with center at 90,0

[jbeezley]

That is upside-down is it not? I thought the purple spot was supposed to be Australia. In fact, as I look at it more, it looks like the position of the colors on the map here are identical to the image you posted earlier relative to the land outlines.

[aashish24]

@jbeezley what you mean upside down? this is aeqd projection centered at 90, 0 (latitude, longitude). I posted this picture to verify the conversion (w comparison to UN logo). I was mentioning to @doutriaux1 earlier that most usefulness of aeqd is when the center is at 90, 0. For other values, we would need to do some extra work.

[jbeezley]

I mean it looks like it is centered at -90, 0.

[jbeezley]

That big purple spot is over Africa in that image. Maybe that is correct, but you seemed to say it was Australia in the comment I linked.

[aashish24]

Nope.. its 90, 0. You would not see US like this if it is -90,0. Below is -90, 0

[jbeezley]

I know the land outlines are correct, I was referring to the colors.

[aashish24]

@doutriaux1 please let me know if 90, 0 seems to be a reasonable defaults. For all other values between 90, -90, we need to think of a way to render them.

[aashish24]

@jbeezley colors are correct (as they show up on mercator or robinson). I cannot verify the value of the data but this is CLT and I believe these colors makes sense to me (in all of the pictures above except the wrong one at the top).

[aashish24]

@jbeezley if you are referring to legend then ignore that for now. I removed some code for testing and that has resulted in wrong legend titles (I removed some code in order to find the issue with the problem described earlier).

[jbeezley]

Okay, I just misunderstood your earlier comment. Ignore me.

[aashish24]

@jbeezley if you are referring to legend then ignore that for now. I removed some code for testing and that has resulted in wrong legend titles (I removed some code in order to find the issue with the problem described earlier).

Cool. Wrong legend title because the "longitude" shows up on top of it. Its just that it is too close to the legend.

[aashish24]

@doutriaux1 my initial attempt on fixing it via current VTK features failed. I will see what else we can do in 2.4 but like I said its the math (unless someone proves me wrong) and rendering issue.

[aashish24]

@doutriaux1 the only way I think this could be possible now is a custom mapper which will require some time and testing. What you think? I would prefer we take care of this issue in 3.0 as now we know that it is a projection specific issue and not related to wrapping as such. I haven't seen any request from scientists to take care of this issue. Instead, I would like us to focus on vector plots and matrix view plot. Let me know what you think until then I am moving it to 3.0 (feel free to put it back to 2.4)

[durack1]

@aashish24 I (a scientist) would like to request projections to work.. I know there are many more in the building here at LLNL and elsewhere that would also advocate strongly to get back functionality that's been broken for a while..

[aashish24]

@durack1 projections are working this is a specific case where aeqd is not rendering correctly. the main culprit is that the other part of the world gets wrapped as well but since that is rendered last in this case, it draws on top of the already drawn pixels.

[aashish24]

@durack1 this particular issue is found by @sankhesh recently (not long ago).

[doutriaux1]

moved to vcs.