Regression |
Exception | Condition |
---|---|
LocationException | The request failed because of problems relating to the specified Location. |
ServiceException | The request failed because of a problem with the API service (sorry!). |
RateLimitException | You hit the RateLimit for your account's plan, and need to wait a little while before it's reset. |
InvalidRequestException | The request that is sent to the API servers is invalid (e.g. it is authenticated with invalid API access keys or regression is not available on the current API account plan). |
TransportException | A problem sending the request to the API servers, or a problem getting the API's response back. |
DegreeDaysApiException | The superclass of all the exceptions listed above. |
ArgumentNullException | request is null. |
The API's processing will typically require it to generate degree days to match the InputData you provide in your request, so it can use those degree days in the regressions it tests. To do this it will use the Location specified in your request.
If you specify a StationIdLocation then the API will use data from that station. But, if you specify a GeographicLocation, the API will choose which station(s) to use automatically. The choice will depend on the dates of your InputData as well as the location you specify. Some stations have more data than others, and the quality of a station's data can vary over time. The API will choose the station(s) that can best match the data you provide in your request.
If you specify an inactive weather station (more on these here), or a GeographicLocation for which no active station can be found with enough data to run regressions against your InputData, you will get a LocationException instead of a RegressionResponse.
Regressions not covering all of your input data:
If the location you specify in your request does not have sufficient weather data for the API to run regressions against your full input data, it may still be able to run regressions against part of it. You can check the SampleSize and the SampleSpan of any Regression in the response (comparing with the number of Periods and the FullRange of your InputData) to see if this has happened.
It is unlikely to happen unless you are trying to run regressions against very old energy data, or very recent energy data e.g. that includes a day that finished in the last hour or two. If you want to be sure to prevent it from happening, you could make a LocationInfoRequest first, specifying data with a DayRangePeriod that matches your InputData, with a minimum DayRange that also specifies that same DayRange. If you get a successful response back you will have a weather station ID that you know you can use in your regression request. But you will have used only 1 request unit to find that out (versus however many it might take to run a load of regressions that might only cover part of your data).