[
https://issues.apache.org/jira/browse/CLIMATE-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16262797#comment-16262797
]
Michael Anderson edited comment on CLIMATE-934 at 11/22/17 4:11 PM:
--------------------------------------------------------------------
More or less what is happening is the first date in the series is 01-01-01.
When figuring out the xticks / xtick labels for the time series, matplotlib is
subtracting some value from that date to calculate the view min, but Epoch
minus something is negative which results in trying to convert a negative
number to a date and the error is thrown.
If I update the example to shift the dates to the middle of the month it works
without error.
I could also change the utilscalc_climatology_monthly to return 01 - month -
mid point of month day which would be neater. I could add an optional
parameter to use the first, mid or last day of the month to avoid breaking
anyone who expects it to be the first of the month.
Something like this in plotter.py for time series will also work:
ax.set_xlim(xmin=datetime.datetime(01, 01, 01)) as it stops it from looking
before the epoch. The resulting graph is not as nice as it butts right up
against the y axis.
Feedback appreciated on the preferred approach.
was (Author: michael.arthur.ander...@gmail.com):
More or less what is happening is the first date in the series is 01-01-01.
When figuring out the xticks / xtick labels for the time series, matplotlib is
subtracting some value from that date to calculate the view min, but Epoch
minus something is negative which results in trying to convert a negative
number to a date and the error is thrown.
If I update the example to shift the dates to the middle of the month it works
without error.
I could also change the utilscalc_climatology_monthly to return 01 - month -
mid point of month day which would be neater. I could add an optional
parameter to use the first, mid or last day of the month to avoid breaking
anyone who expects it to be the first of the month.
I could also dig into the plotter.py and see if there is a switch to tell it to
apply the first xtick at 0 on the x rather than trying to calculate the offset.
Feedback appreciated on the preferred approach.
> time_series_with_regions.py Fails With Type Error
> -------------------------------------------------
>
> Key: CLIMATE-934
> URL: https://issues.apache.org/jira/browse/CLIMATE-934
> Project: Apache Open Climate Workbench
> Issue Type: Bug
> Components: examples
> Affects Versions: 1.1.0
> Reporter: Michael Anderson
> Assignee: Michael Anderson
>
> time_series_with_regions.py Fails With:
> Traceback (most recent call last):
> File "time_series_with_regions.py", line 122, in <module>
> Bounds(-10.0, 0.0, 29.0, 36.5),
> File "/Users/michaelanderson/Downloads/climate/ocw/dataset.py", line 351,
> in __init__
> if boundary_type[:6].upper() == 'CORDEX':
> TypeError: 'float' object has no attribute '__getitem__'
> The example is constructing the Bounds object like so:
> Bounds(-10.0, 0.0, 29.0, 36.5),
> However the Bounds constructor looks like so:
> def __init__(self, boundary_type='rectangular',
> us_states=None, countries=None,
> user_mask_file=None, mask_variable_name=None,
> longitude_name=None, latitude_name=None,
> lat_min=-90, lat_max=90, lon_min=-180, lon_max=180,
> start=None, end=None):
> So when the Bounds constructor gets here:
> if boundary_type[:6].upper() == 'CORDEX':
> It is trying to treat an int like an array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
