Skip to content
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

FIX: single dimension problem #393

Merged
merged 4 commits into from Nov 5, 2019

Conversation

@kmuehlbauer
Copy link
Member

kmuehlbauer commented Oct 2, 2019

  1. fix single dimension problem (nrays=ndims)
  2. assign root after reading sweeps (moved from @egouden)

done in #395
3. VolumeTimeSeries class + test (VolTS, with @egouden)

Test data for 1.& 3. possibly provided by BOM Australia, waiting for feedback

@kmuehlbauer

This comment has been minimized.

Copy link
Member Author

kmuehlbauer commented Oct 2, 2019

@egouden You might have a look into this. I had to copy your assign_root part due to the other changes a simple merging wasn't actually feasable. Tomorrow is a day off here, hope to get your things in on friday.

@egouden

This comment has been minimized.

Copy link
Collaborator

egouden commented Oct 2, 2019

OMG
I have been playing with this as well... see my updated PR.
Does your VolTS works from the DWD files?

@kmuehlbauer

This comment has been minimized.

Copy link
Member Author

kmuehlbauer commented Oct 2, 2019

@egouden It works with the Australian data, hope to add something on Friday. Same for the DWD data. My intention is, to keep the ODIMH5 as single volume container and the VolTS as timeseries.

Of course we need to coordinate better, hope we can establish some routine next week.

@egouden

This comment has been minimized.

Copy link
Collaborator

egouden commented Oct 2, 2019

Yes we can discuss this on Tuesday ;-)
Now I am taking some holidays...

@kmuehlbauer

This comment has been minimized.

Copy link
Member Author

kmuehlbauer commented Oct 2, 2019

Does your VolTS works from the DWD files?

Yes, it works well with the DWD data. I've checked with an updated version of the DWD notebook. Now the real adventure can start.

@codecov

This comment has been minimized.

Copy link

codecov bot commented Oct 4, 2019

Codecov Report

Merging #393 into master will decrease coverage by 0.04%.
The diff coverage is 67.67%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #393      +/-   ##
==========================================
- Coverage   90.05%   90.01%   -0.05%     
==========================================
  Files          35       35              
  Lines        5981     6007      +26     
==========================================
+ Hits         5386     5407      +21     
- Misses        595      600       +5
Flag Coverage Δ
#wradlibtests 90.01% <67.67%> (-0.05%) ⬇️
Impacted Files Coverage Δ
wradlib/georef/xarray.py 100% <100%> (ø) ⬆️
wradlib/io/xarray.py 92.96% <66.31%> (-0.45%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d1ee02a...4fdac94. Read the comment docs.

@kmuehlbauer kmuehlbauer force-pushed the kmuehlbauer:wip-xarray-dimensions branch from a6c441a to d885b5c Oct 7, 2019
@egouden

This comment has been minimized.

Copy link
Collaborator

egouden commented Oct 7, 2019

Apparently it does not work with sweep by sweep input files.
Are their requirements on the input files?
What if my scanning strategy is like this:
3, 1.6, 1
4, 1.6, 1
2, 1.6, 1
3, 1.6, 1
4, 1.6, 1
2, 1.6, 1
.......

@kmuehlbauer

This comment has been minimized.

Copy link
Member Author

kmuehlbauer commented Oct 7, 2019

What if my scanning strategy is like this:

Volume swp 1 swp 2 swp 3
0 3 1.6 1
1 4 1.6 1
2 2 1.6 1
3 3 1.6 1
4 4 1.6 1
5 2 1.6 1
.. .. .. ..

Right, this doesn't work. The requirement on the input files:

  • OdimH5: files have different elevation angles (for PPI) and belong to same volume (eg. DWD data)
  • OdimTS: files contain same structure of sweeps.

We just can't combine different elevation angles (with possibly different number of bins and gate length) into one consistent xarray dataset.

kmuehlbauer and others added 3 commits Oct 9, 2019
@kmuehlbauer

This comment has been minimized.

Copy link
Member Author

kmuehlbauer commented Oct 29, 2019

taken over by #395

@kmuehlbauer kmuehlbauer reopened this Nov 3, 2019
@kmuehlbauer kmuehlbauer force-pushed the kmuehlbauer:wip-xarray-dimensions branch from d885b5c to 0c5713c Nov 3, 2019
@kmuehlbauer kmuehlbauer changed the title FIX+ENH: xarray FIX: single dimension problem Nov 3, 2019
@kmuehlbauer kmuehlbauer modified the milestones: 1.5.1, 1.6 Nov 3, 2019
@kmuehlbauer kmuehlbauer merged commit 06dd85d into wradlib:master Nov 5, 2019
2 of 4 checks passed
2 of 4 checks passed
codecov/patch 67.67% of diff hit (target 90.05%)
Details
codecov/project 90.01% (-0.05%) compared to d1ee02a
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@kmuehlbauer kmuehlbauer deleted the kmuehlbauer:wip-xarray-dimensions branch Mar 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.