Temperature in metric units rounding to whole number at airport locations (KLAX,KLAS,etc.)

[ajoros]

Temperature for airport locations (KLAX, KLAS, etc.) seem to be rounding to whole numbers when using metric units.

When I view an example online via MesoWest website the rounding issue doesn't seem to be present. http://mesowest.utah.edu/cgi-bin/droman/meso_base_dyn.cgi?stn=KLAS&unit=1&timetype=LOCAL

In [15]:
from MesoPy import Meso
from pprint import pprint as pp

mytoken = 'XXXXXXXXXXXXXXXXXXXXXXX'
m = Meso(token=mytoken)

m.timeseries(start='201602100000',end='201602110000',stid='klas',vars='air_temp')
Out[15]:
{u'STATION': [{u'ELEVATION': u'2180',
   u'ID': u'239',
   u'LATITUDE': u'36.07188',
   u'LONGITUDE': u'-115.16340',
   u'MNET_ID': u'1',
   u'NAME': u'Las Vegas, McCarran International Airport',
   u'OBSERVATIONS': {u'air_temp_set_1': [22.0,
     20.0,
     17.0,
     16.0,
     16.0,
     14.0,
     12.0,
     12.0,
     11.0,
     11.0,
     10.0,
     10.0,
     9.0,
     9.0,
     9.0,
     12.0,
     13.0,
     16.0,
     17.0,
     18.0,
     20.0,
     21.0,
     22.0,
     22.0],
    u'date_time': [u'2016-02-10T00:56:00Z',
     u'2016-02-10T01:56:00Z',
     u'2016-02-10T02:56:00Z',
     u'2016-02-10T03:56:00Z',
     u'2016-02-10T04:56:00Z',
     u'2016-02-10T05:56:00Z',
     u'2016-02-10T06:56:00Z',
     u'2016-02-10T07:56:00Z',
     u'2016-02-10T08:56:00Z',
     u'2016-02-10T09:56:00Z',
     u'2016-02-10T10:56:00Z',
     u'2016-02-10T11:56:00Z',
     u'2016-02-10T12:56:00Z',
     u'2016-02-10T13:56:00Z',
     u'2016-02-10T14:56:00Z',
     u'2016-02-10T15:56:00Z',
     u'2016-02-10T16:56:00Z',
     u'2016-02-10T17:56:00Z',
     u'2016-02-10T18:56:00Z',
     u'2016-02-10T19:56:00Z',
     u'2016-02-10T20:56:00Z',
     u'2016-02-10T21:56:00Z',
     u'2016-02-10T22:56:00Z',
     u'2016-02-10T23:56:00Z']},
   u'PERIOD_OF_RECORD': {u'end': u'2016-02-16T23:56:00Z',
    u'start': u'1997-01-01T00:00:00Z'},
   u'SENSOR_VARIABLES': {u'air_temp': {u'air_temp_set_1': {u'end': u'2016-02-16T23:56:00Z',
      u'start': u'2016-01-04T20:53:00Z'}},
    u'date_time': {u'date_time': {}}},
   u'STATE': u'NV',
   u'STATUS': u'ACTIVE',
   u'STID': u'KLAS',
   u'TIMEZONE': u'America/Los_Angeles'}],
 u'SUMMARY': {u'DATA_PARSING_TIME': u'0.525951385498 ms',
  u'DATA_QUERY_TIME': u'3.95202636719 ms',
  u'FUNCTION_USED': u'time_data_parser',
  u'METADATA_RESPONSE_TIME': u'48.1729507446 ms',
  u'NUMBER_OF_OBJECTS': 1,
  u'RESPONSE_CODE': 1,
  u'RESPONSE_MESSAGE': u'OK',
  u'TOTAL_DATA_TIME': u'4.478931427 ms',
  u'TOTAL_TIME': u'95.3438282013 ms'},
 u'UNITS': {u'air_temp': u'Celsius'}}

[ghost]

@ajoros. thanks for pointing this out. Closing this issue here as it originates in the API. We are tracking it...will try to get it released with the API v2.5 (no estimated release date yet).

[ajoros]

Thanks Josh, do you have any temporary work around for this? I was thinking using SciPy's F2C() function on the Fahrenheit temperature data and just convert on the fly to Celcius. Not sure if this would reduce any accuracy of the data returned by the Mesowest API.

Andrew Joros Assistant Research Scientist Applied Innovation Center Division of Earth and Ecosystem Sciences Desert Research Institute, 2215 Raggio Parkway Reno, NV 89512 Office: 775.674.7112

On Wed, Feb 17, 2016 at 1:10 PM, Joshua Clark notifications@github.com wrote:

@ajoros https://github.com/ajoros. thanks for pointing this out. Closing this issue here as it originates in the API. We are tracking it...will try to get it released with the API v2.5 (no estimated release date yet).

— Reply to this email directly or view it on GitHub https://github.com/mesowx/MesoPy/issues/19#issuecomment-185404801.

[ghost]

@ajoros The MesoPy request you have made is already in Celsius. By default, our API outputs metric. If you'd like, this can be changed by using the units parameters. Ex. units=english would yield temp in Fahrenheit, wind speed in mph, etc.

[ajoros]

Josh,

Yea i figured that out last night doing some testing on my own. I'll just have to wait until you guys fix the "rounding to nearest whole number" issue is fixed. For now I guess I can just use the MESOWEST API until MesoPy is patched.

Thanks man,

AJ

[ghost]

@ajoros It's an API issue, no problems with MesoPy (for now...)

[ajoros]

Ahhhh your right... It looks like this issue with rounding to whole number is occurring after a specific date for various airport sites.

[ajoros]

Joshua, is there any update on if the "bad" rounded data was correct and fixed at all? I know this was an issue at the Mesowest API end of things.