projections still broken #1640
Comments
|
@danlipsa it would be great if you can look into this next... thanks, |
|
Actually never mind. @doutriaux1 this bug with these kind of projection will require some additional bug. Like I mentioned proj4 is doing the right thing. Either we have to know the projection and chop-off data before sending it for rendering or apply some stencil techniques before we tackle this one. I don't know if we have enough time to fix this for 2.4 but can look into it immediately. I think we should plan y for 2.4.1 release as well. |
|
Note that vcs_test_basic_boxfill_-3_proj_NH seems to be also aeqd and that works fine. I'll have to look at the differences. |
danlipsa
added a commit
that referenced
this issue
Dec 16, 2015
A side note is that the -3 = polar (non gctp) projection is the same as aeqd projection though it has a different _type (-3 versus 204)
danlipsa
added a commit
that referenced
this issue
Dec 16, 2015
A side note is that the -3 = polar (non gctp) projection is the same as aeqd projection though it has a different _type (-3 versus 204)
|
After proj4.9.2 upgrade aeqd plots look better. We'll replace this PR with |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@aashish24 looking at baselines:
https://github.com/UV-CDAT/uvcdat-testdata/blob/master/baselines/vcs/test_vcs_basic_boxfill_aeqd_proj.png
You can see that the purple blob over africa gets cut at the 0 longitude.
The text was updated successfully, but these errors were encountered: