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

Bad rendering of aeqd projection #1462

Open
sankhesh opened this Issue Jul 21, 2015 · 34 comments

Comments

Projects
None yet
6 participants
@sankhesh
Contributor

sankhesh commented Jul 21, 2015

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

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.

@sankhesh sankhesh added VCS Bug labels Jul 21, 2015

@sankhesh sankhesh added this to the 2.3 milestone Jul 21, 2015

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Jul 21, 2015

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

This comment has been minimized.

Member

doutriaux1 commented Jul 21, 2015

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

This comment has been minimized.

Member

durack1 commented Aug 4, 2015

@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])

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Aug 4, 2015

@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

This comment has been minimized.

Member

doutriaux1 commented Aug 4, 2015

@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

This comment has been minimized.

Contributor

aashish24 commented Aug 4, 2015

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

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Aug 4, 2015

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

This comment has been minimized.

Contributor

aashish24 commented Sep 14, 2015

@doutriaux1 I don't seem to find test_vcs_basic_boxfill_aeqd_proj

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Sep 14, 2015

@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.
aeqd_-180_90

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

This comment has been minimized.

Contributor

aashish24 commented Sep 14, 2015

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

This comment has been minimized.

Contributor

aashish24 commented Sep 14, 2015

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

@aashish24 aashish24 added the Critical label Sep 14, 2015

@aashish24 aashish24 modified the milestones: 3.0, 2.4 Sep 14, 2015

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Sep 14, 2015

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

@aashish24 aashish24 removed the Critical label Sep 14, 2015

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Sep 14, 2015

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

@doutriaux1 doutriaux1 modified the milestones: 2.4, 3.0 Sep 14, 2015

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Sep 14, 2015

@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

This comment has been minimized.

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Sep 14, 2015

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

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Sep 15, 2015

@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

This comment has been minimized.

Contributor

aashish24 commented Sep 15, 2015

image

and UV-CDAT with center at 90,0
s

@jbeezley

This comment has been minimized.

Contributor

jbeezley commented Sep 15, 2015

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

This comment has been minimized.

Contributor

aashish24 commented Sep 15, 2015

@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

This comment has been minimized.

Contributor

jbeezley commented Sep 15, 2015

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

@jbeezley

This comment has been minimized.

Contributor

jbeezley commented Sep 15, 2015

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

This comment has been minimized.

Contributor

aashish24 commented Sep 15, 2015

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

s2

@jbeezley

This comment has been minimized.

Contributor

jbeezley commented Sep 15, 2015

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

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Sep 15, 2015

@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

This comment has been minimized.

Contributor

aashish24 commented Sep 15, 2015

@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

This comment has been minimized.

Contributor

aashish24 commented Sep 15, 2015

@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

This comment has been minimized.

Contributor

jbeezley commented Sep 15, 2015

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

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Sep 15, 2015

@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

This comment has been minimized.

Contributor

aashish24 commented Sep 17, 2015

@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

This comment has been minimized.

Contributor

aashish24 commented Sep 17, 2015

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

@aashish24 aashish24 modified the milestones: 3.0, 2.4 Sep 17, 2015

@durack1

This comment has been minimized.

Member

durack1 commented Sep 17, 2015

@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

This comment has been minimized.

Contributor

aashish24 commented Sep 18, 2015

@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 aashish24 changed the title from Bad wrapping with projections to Bad rendering of aeqd projection Sep 18, 2015

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Sep 18, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment