Duplicate longitude wrap #1736
Duplicate longitude wrap #1736
Conversation
| @@ -609,6 +609,8 @@ def project(pts, projection, wc, geo=None): | |||
| pname = projDict.get(projection._type, projection.type) | |||
| projName = pname | |||
| pd.SetName(projName) | |||
| pd.SetOptionalParameter("over", "true") | |||
| pd.SetCentralMeridian(float(xm + xM) / 2.0) | |||
There was a problem hiding this comment.
@danlipsa what about case where user specified the central meridian?
There was a problem hiding this comment.
I just seen your post about this. I'll look at it and use that value instead.
There was a problem hiding this comment.
@danlipsa what about case where user specified the central meridian?
@doutriaux1 that what was the question @danlipsa asked in the issue. How does someone specify that in vcs?
There was a problem hiding this comment.
@aashish24 I replied to @danlipsa he's on it. Thx.
|
thanks @doutriaux1 @danlipsa when you make a pull request which has new baselines, could you please reference to the data pull request as well? |
|
@doutriaux1 once this and the clipped data (and two of yours merged in) we should finalize the release.. what you think? |
|
@sankhesh was VERY close from getting XCode 7 in, I would like to have this in as well! |
danlipsa
force-pushed
the
duplicate-longitude-wrap
branch
4 times, most recently
from
f68d2f9
to
1412d21
Compare
|
@danlipsa some tests arw failing. Are you lookinf intonit? |
|
@aashish24 @sankhesh @doutriaux1 This is strange. For some machines all test pass, for some there are 85 tests failing. I don't see what is different about the machines that fail. Any ideas? |
|
weird I was going to say "MESA" but no. Very odd. But most machines fail though. |
|
I'm compiling on my Mac to see if I can reproduce those issues. Hopefully I can. |
|
@doutriaux1 @aashish24 At least on https://open.cdash.org/viewTest.php?onlyfailed&buildid=4151636 |
|
@aashish24 @doutriaux1 Thanks @sankhesh for building uvdat on your mac laptop and duplicating the problem. It seems that proj4 behaves differently on that build. Removing +over option fixes the problem for the -3 projection. I am building uvcdat on my mac laptop to debug the proj4 behavior. |
|
@aashish24 @sankhesh @doutriaux1 I have a hard time building uvcdat on my mac. One problem is that cdtime and cdms2 tried to link against libpng15 which did not exist on my system. I fixed this by changing the link command to link to libpng. Now I get: ImportError: dlopen(/Users/danlipsa/uvcdat/build/install/Externals/lib/python2.7/site-packages/vtk/vtkCommonCorePython.so, 2): Library not loaded: libvtkCommonCorePython27D-6.3.1.dylib However that library is in: |
|
OK, I can reproduce the proj4 problem on my laptop. The build problem I was seeing (libvtkCommonCorePython27D) is still there but that appears only when you run the test through runtest. If you run it directly through python it works fine. |
@danlipsa you have to install xquartz (https://github.com/UV-CDAT/uvcdat/wiki/Install-on-Mac-OS-X) and then make sure you build from scratch (and remove any workardounds that you may have). |
|
Thanks @aashish24 I used xwindows installed with mac port. I will try with xquarts. |
We pass two additional options to proj4 +over to not wrap longitude values +lon_0 to set the central meridian This fixes the wrapping issues we were seeing.
danlipsa
force-pushed
the
duplicate-longitude-wrap
branch
from
1412d21
to
0552f7a
Compare
|
@danlipsa the mangling will be a problem since I won't have time tomorrow to look into it. the code to transition to newer proj4 is there. We would also need to build proj4 as well. |
|
@doutriaux1 Are the buildbots ok? They been running for more than 24 hours. |
|
I think sometihng got stuck, I'm updating the bots system to timeout. |
No description provided.