hybrid sigma coordinate whould work with float values

[Andreas Hilboll]

I have a nc file with a atmosphere_hybrid_sigma_pressure_coordinate,

double lev(lev) ;
    lev:standard_name = "atmosphere_hybrid_sigma_pressure_coordinate" ;
    lev:long_name = "hybrid level at layer midpoints (A/P0+B)" ;
    lev:positive = "down" ;
    lev:formula_terms = "ap: hyam b: hybm ps: PS p0: P0" ;

lev = 0.116718480138169, 0.152770787071305, 0.188823094004441,
    0.227128670120898, 0.274447322970639, 0.336186898593634, 
    0.411446089316556, 0.492113126079447, 0.568724278312361, 
    0.638575622995312, 0.702117813964964, 0.759350851221318, 
    0.810274734764372, 0.854889464594128, 0.893195040710585, 
    0.925191463113743, 0.950878731803602, 0.970256846780163, 
    0.983776461880089, 0.99459215396003 ;

when trying to display this with MSS, the MSS GUI only shows me one single model level. I think I traced this down to https://bitbucket.org/wxmetvis/mss/src/3e9bebfb363906d43cc77f23dfe8f804ad394e81/mslib/mswms/mss_2D_sections.py?at=develop&fileviewer=file-view-default#mss_2D_sections.py-186, where the vert_data values are being cast to int, leading to the list [0] being returned from get_elevations.

Is this expected behaviour? I mean, does the rest of the code rely on the elevations being cast to integer? Of course I can preprocess the nc file before feeding it into MSS, so this is not a dealbreaker, but it would be nice to know if this is really necessary.

[Joern Ungermann]

I stumbled upon this some time ago, but worked around it (levels were km originally and were changed to be in m). Removing this limitation would be nice, but I also do not know what relies on this. This patch:

diff --git a/mslib/mswms/mss_2D_sections.py b/mslib/mswms/mss_2D_sections.py
index 816b466..95a1248 100644
--- a/mslib/mswms/mss_2D_sections.py
+++ b/mslib/mswms/mss_2D_sections.py
@@ -183,7 +183,7 @@ class Abstract2DSectionStyle(with_metaclass(ABCMeta, object)):

             # Get a list of the available levels.
             if self.driver.vert_data is not None:
-                return [u"{:d}".format(lvl) for lvl in sorted({int(_x) for _x in self.driver.vert_data})]
+                return [u"{:}".format(lvl) for lvl in sorted({float(_x) for _x in self.driver.vert_data})]
             else:
                 return []
         else:
diff --git a/mslib/mswms/wms.py b/mslib/mswms/wms.py
index e83e92c..0704f56 100644
--- a/mslib/mswms/wms.py
+++ b/mslib/mswms/wms.py
@@ -387,7 +387,7 @@ class WMSServer(object):

             # Vertical level, if applicable.
             level = query.get('ELEVATION')
-            level = int(level) if level else None
+            level = float(level) if level else None
             layer_datatypes = self.hsec_layer_registry[dataset][layer].required_datatypes()
             if (("ml" in layer_datatypes) or ("pl" in layer_datatypes)) \
                     and not level:

seems to allow non-integer levels. That might look very ugly for those hybrid levels, though...

I am hesitant though to enable this in the stable branch for 1.5.2 release... I'll dig into the OWS specification if there are some limitations posed on the "level" field.

[Andreas Hilboll]

Great, thanks a lot!

I agree about not including this in stable for the next release without being confident about there being no implications ;)

We're currently working around this issue by changing the lev variable to values 1..20, as EMeRGe is starting now and we don't want to risk our running system. After EMeRGe-EU, we'll be able to try it out.

BTW, for EMeRGe-EU, we're using MSS 1.4.1; the first forecasting meeting should have been this morning. The ball is rolling :-)

[Joern Ungermann]

I would change the status from bug to feature request. And assign it to me, I will prepare the test and add some demodata for it.

[Joern Ungermann]

Fixed by c7da9526