I'm in two minds about posting this as it's a rather niche product. But here goes anyway:
http://www.degreedays.net/api/
Degree days are a specialist form of temperature data that comes in three main flavours: heating degree days (HDD), cooling degree days (CDD), and growing degree days (GDD). Respectively they correlate with heating energy consumption (e.g. the energy required to heat a building), cooling energy consumption, and plant growth. People use the data to monitor energy consumption for ongoing efficiency and to normalize it for the weather so that they can more accurately track their progress towards energy/carbon reduction targets.
The degreedays.net system turns raw temperature data into degree days. The raw temperature data comes from Weather Underground, to whom I am eternally grateful for letting the project go ahead (and for their awesomely huge database of weather data). The aim is to take something complicated and messy (raw temperature data is frequently irregular, patchy, and erroneous in parts) and turn it into continuous sets of degree-day data that are error-checked and easy to work with.
The main site - http://www.degreedays.net/ - was launched in 2008, and now has between 500 and 1000 people downloading data from it each day. Most of the regular users are energy-saving pros of various sorts, like consultants that advise businesses on how to save energy, and energy managers at large organizations. (Typically the bigger the energy spend of the organization, the more to be gained from this sort of analysis.)
What's new is the API at http://www.degreedays.net/api/ For that we've had to beef up the data-calculation infrastructure, switching from a VPS to an Amazon EC2 cluster running on Elastic Beanstalk, with temperature data stored in SimpleDB.
Right now you can only use the API with the client libraries for Java (or other JVM languages) and .NET. There's an XML API underneath but it still needs to be documented. Also, whilst the Java and .NET client libraries are really easy to work with, the XML API underneath is not so straightforward... The typical use case is to use the API to generate large quantities of custom-specified data, fast, and that just didn't seem to fit with a simple REST approach. Instead we have an XML-RPC API that breaks more "best practices" than you could shake a stick at. Though it does work well.
Java and .NET seems to suit most of the companies that we've spoken to about this so far, but we do need to support other options. I'm contemplating trying my hand at a Python client library as well as documenting the underlying XML API.
I spent many months agonizing over the design of the API, particularly that of the Java and .NET client libraries. I'm ashamed to say that I am a hopeless perfectionist, and about as slow a developer as they come. We've got companies integrating this API into installable software (energy-tracking and energy-reporting packages for businesses), so long-term compatibility is a top priority. I'm hopeful that the time spent on the technical design will pay off if it means we can keep the API usable and approachable whilst retaining backwards compatibility.
Feedback and questions are most welcome if you should have any.
I'm guessing it's unlikely that many readers are working on the sorts of energy/HVAC/utilities software that this API would be useful to, so apologies if you think this post off topic. But if you are working in a similar space and would like to get in contact, I'd love to hear from you. Send an email through the site with my name in it and it'll get to me.
http://www.degreedays.net/api/
Degree days are a specialist form of temperature data that comes in three main flavours: heating degree days (HDD), cooling degree days (CDD), and growing degree days (GDD). Respectively they correlate with heating energy consumption (e.g. the energy required to heat a building), cooling energy consumption, and plant growth. People use the data to monitor energy consumption for ongoing efficiency and to normalize it for the weather so that they can more accurately track their progress towards energy/carbon reduction targets.
The degreedays.net system turns raw temperature data into degree days. The raw temperature data comes from Weather Underground, to whom I am eternally grateful for letting the project go ahead (and for their awesomely huge database of weather data). The aim is to take something complicated and messy (raw temperature data is frequently irregular, patchy, and erroneous in parts) and turn it into continuous sets of degree-day data that are error-checked and easy to work with.
The main site - http://www.degreedays.net/ - was launched in 2008, and now has between 500 and 1000 people downloading data from it each day. Most of the regular users are energy-saving pros of various sorts, like consultants that advise businesses on how to save energy, and energy managers at large organizations. (Typically the bigger the energy spend of the organization, the more to be gained from this sort of analysis.)
What's new is the API at http://www.degreedays.net/api/ For that we've had to beef up the data-calculation infrastructure, switching from a VPS to an Amazon EC2 cluster running on Elastic Beanstalk, with temperature data stored in SimpleDB.
Right now you can only use the API with the client libraries for Java (or other JVM languages) and .NET. There's an XML API underneath but it still needs to be documented. Also, whilst the Java and .NET client libraries are really easy to work with, the XML API underneath is not so straightforward... The typical use case is to use the API to generate large quantities of custom-specified data, fast, and that just didn't seem to fit with a simple REST approach. Instead we have an XML-RPC API that breaks more "best practices" than you could shake a stick at. Though it does work well.
Java and .NET seems to suit most of the companies that we've spoken to about this so far, but we do need to support other options. I'm contemplating trying my hand at a Python client library as well as documenting the underlying XML API.
I spent many months agonizing over the design of the API, particularly that of the Java and .NET client libraries. I'm ashamed to say that I am a hopeless perfectionist, and about as slow a developer as they come. We've got companies integrating this API into installable software (energy-tracking and energy-reporting packages for businesses), so long-term compatibility is a top priority. I'm hopeful that the time spent on the technical design will pay off if it means we can keep the API usable and approachable whilst retaining backwards compatibility.
Feedback and questions are most welcome if you should have any.
I'm guessing it's unlikely that many readers are working on the sorts of energy/HVAC/utilities software that this API would be useful to, so apologies if you think this post off topic. But if you are working in a similar space and would like to get in contact, I'd love to hear from you. Send an email through the site with my name in it and it'll get to me.