by nshipes on May 16, 2012
In addition to its quick and easy implementation, another exciting component of our Aeris iOS Weather framework is our interactive weather map feature. This component is a completely functional map with Aeris weather data and imagery overlaid on top of it which you hvae complete control over.
Our demo application that comes with the framework distribution has a basic example of how you could integrate the interactive weather map into your own custom iPhone and iPad applications. We have even provided a simple options view for users to control which weather overlays are currently displayed on the map. When using this built-in view for your map options, only those overlays your Aeris API account level has access to will be displayed.
Changing the Map Options
You may wish to use the built-in map options view in your map as is, but adjust the options that are displayed. To achieve this, simply set the sections property on your AFWeatherMapOptionsViewController instance with the options you wish to use instead. Your custom value should be an NSArray of NSDictionary objects for each section in your options table. The default value for the sections property is:
self.sections = [[NSArray alloc] initWithObjects:
[NSDictionary dictionaryWithObjectsAndKeys:@"Overlays", @"section", overlays, @"rows", nil],
[NSDictionary dictionaryWithObjectsAndKeys:@"Point Data", @"section", pointdata, @"rows", nil],
[NSDictionary dictionaryWithObjectsAndKeys:@"Map Type", @"section", mapTypes, @"rows", nil],
nil];
Then the value you provide for the rows key in each NSDictionary instance should be an array of NSDictionary instances providing the information for each row, which should include keys for code and name. For example, the mapTypes variable above, which changes the type of Google base map displayed, would be defined as:
NSArray *mapTypes = [NSArray arrayWithObjects:
[NSDictionary dictionaryWithObjectsAndKeys:@"standard", @"code", @"Standard", @"name", nil],
[NSDictionary dictionaryWithObjectsAndKeys:@"satellite", @"code", @"Satellite", @"name", nil],
[NSDictionary dictionaryWithObjectsAndKeys:@"hybrid", @"code", @"Hybrid", @"name", nil],
nil];
For weather overlays, the codes for each row correspond to an AFTileOverlayType or AFPointDataType and are listed on the documentation for our interactive map. These codes must match exactly in order for the options to work. However, you can set the name value to anything of your liking.
You may find that sticking with the standard iOS views is likely too basic for your own application. Using some of the available methods on the weather map instance you can create more custom implementations depending on your stylistic and functional needs. Before getting started, make sure to review the public properties and methods available in AFWeatherMap instances.
Toggling Map Overlays
There are two ways for turning weather overlays on and off on your map: using toggleOverlayForType: and have the internal overlay manager determine when to show and hide the overlay, or combining showOverlayForType: and hideOverlayForType: to control when overlays should appear or be removed. Note that these methods are for tile overlays only, but the same types of methods are available for point data overlays (togglePointDataOverlayForType:, showPointDataOverlayForType:, hidePointDataOverlayForType:). The only option you need to pass these methods is the overlay type from AFOverlayType (or AFPointDataType) you want to apply the action to.
For instance, you have a custom toolbar containing buttons for each overlay you want to enable on your map, one of which is a button to toggle the radar tile overlay. Your selector for the button’s UIControlEventTouchUpInside event would use the above methods on your AFWeatherMap instance to control the radar overlay’s visibility.
- (void)toggleRadarOverlay {
// ask the framework's internal overlay manager if this overlay is currently active on the map
if ([self.weatherMap hasOverlayForType:AFTileOverlayTypeRadar] == YES) {
[self.radarOverlayButton setSelected:NO];
[self.weatherMap hideOverlayForType:AFTileOverlayTypeRadar];
}
else {
[self.radarOverlayButton setSelected:YES];
[self.weatherMap showOverlayForType:AFTileOverlayTypeRadar];
}
}
You could also use toggleOverlayForType:
- (void)toggleRadarOverlay {
// ask the framework's internal overlay manager if this overlay is currently active on the map
if ([self.weatherMap hasOverlayForType:AFTileOverlayTypeRadar] == YES) {
[self.radarOverlayButton setSelected:NO];
[self.weatherMap hideOverlayForType:AFTileOverlayTypeRadar];
}
else {
[self.radarOverlayButton setSelected:YES];
[self.weatherMap showOverlayForType:AFTileOverlayTypeRadar];
}
}
Our next tutorial topic will cover how to use custom annotations and annotation views in your own map.
...
Read more...
by nshipes on May 01, 2012
We’re excited to announce that yesterday we officially released version 1.1 of the Aeris iOS weather framework with several new features and improvements, including improved map overlay animation, new object loaders and endpoints, new map overlays and customization options for the interactive map. Over the course of the next week or two, we will cover some of the advanced features of the iOS framework in greater depth to help you get the most out of using our toolkit.
New Object Loaders, New Overlays
To align with some of the great new endpoints recently added in our core Aeris API, the following API endpoints now have corresponding object loaders in iOS for you to easily integrate into your applications: countries, sunmoon, moonphases, normals, records, tides, and earthquakes. Refer to the Object Loaders documentation for additional information about the new object loaders and the API endpoints they correspond to.
In addition to providing you quick access to the new API endpoints within the iOS framework, we have also added new interactive map point data overlays for climate records and earthquakes. We’ve also included two new tile overlays to the map: current sea surface temperatures and current chlorophyll. All of these new overlays will automatically appear within your map options menu with the update (as long as your account level has access to them).
This 1.1 update also now displays map options based on your current account level (based on your provided client id/key combination), so if you don’t have access to a certain tile or point data overlay it will no longer appear in your map options view.
Map Customization
With version 1.1, you now have more control over the look and feel of your interactive weather map. You can now provide custom graphics to use for the various point data annotations, set the opacity of any tile overlay and control some of the animation features. You can read more about the types of customization currently supported on our main customization section within the iOS framework docs.
Be sure to review the complete version history for details on the additions, improvements and changes in version 1.1, and refer to each framework’s code documentation (for Aeris, AerisUI and AerisMap) for the public classes available to your applications.
...
Read more...
by lhuffman on Apr 11, 2012
We released version 1.2 of our Aeris Weather API. This release includes new endpoints for US climate normals as US tide predictions as well as other enhancements. Review the version history for the complete list of changes.
US Climate Normals
The new normals endpoint provides access to the 30-year climate normals for maximum and minimum temperatures, precipitation and snowfall. Data is available in daily, monthly and annual summaries.
To query your local normals for today, your query would look similar to:
/normals/minneapolis,mn
To obtain the normals for the next week:
/normals/minneapolis,mn?to=+1week
Using the complex search functionality built into the Aeris API, you can also perform advanced search queries on the climate information. For example, to search for the top 10 maximum temperature normals in Minnesota for today:
/normals/search?query=state:mn&sort=maxt:-1&limit=10
For complete usage information and more examples review the normals and normals/stations documentation.
US Tide predictions
The tides endpoint provides access to tide predictions for select US locations through the next two years.
To query today’s tide predictions closest to Miami, FL, the query would be:
/tides/miami,fl
To obtain the next week of tide predictions close to Miami, FL:
/tides/miami,fl?to=+1week
To obtain the information for the immediate next high or low tide near Miami,FL:
/tides/miami,fl?to=+1day&plimit=1
To find the top 10 highest tides in Florida today:
/tides/search?query=state:fl&filter=high&limit=10&sort=height:-1,dt
For complete usage information and more examples review the tides and tides/stations documentation.
New Period-Specific Options
With the new normals and tides endpoints, we have introduced a series of additional parameters that are specific to the periods contained within each object returned: plimit, psort and pskip. These vary from the standard limit, sort and skip parameters as they apply to the items contained within the “periods” property of each object instead of the entire objects returned.
For example, if you wanted the next two tide predictions for the 5 stations closest to Miami, you would combine the limit and plimit parameters:
/tides/closest?p=miami,fl&limit=5&plimit=2
In this use case, limit applies to the number of stations returned, and plimit applies to the number of periods returned for each station. The same rules would apply for sort/psort and skip/pskip.
Note that plimit, psort and pskip are only supported for those endpoints that contain a “periods” property and have them listed as supported options in their respective documentation. We are excited about this new functionality and will look at utilizing and expanding it as we continue to add more functionality to the Aeris API.
Here Comes Tropical Season
With the tropical season just around the corner, we are busily working to to add many new tropical features to the 1.3 release of the Aeris API in the upcoming weeks. Check back often and follow us on twitter for the latest status updates.
...
Read more...
by lhuffman on Mar 27, 2012
Today we released an update to our Javascript SDK that fixes a few minor bugs, adds new data collections to reflect the new API endpoints released in version 1.1, and a new Daily Records widget. For the complete list of changes view the version history.
New Data Collections
The new data collections are:
-
Earthquakes - Provide access to worldwide earthquakes
-
Fires - Access to US fires
-
Records - Access to US daily records.
-
Sunmoon - Access to worldwide sun and moon information.
-
MoonPhases - Access to moon phase calendar information.
These correspond to the equivalent Aeris API endpoints of the same name. Review the Collections documentation for more information.
Daily Records Pre-built Widget
A new daily records widget has been added to our pre-built widget library and provides an easy way to display nearby daily records for an area. The record types include precipitation, snowfall, high temperatures, low temperatures and more.
Here is an example on how to add the new widget to your site, which is based on the “Getting Started” example from the Aeris JavaScript SDK documentation:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>Sample Aeris Widget</title>
<style type="text/css">
#widget-records{width:380px;height:460px;}
</style>
<link rel="stylesheet" type="text/css" media="all" href="http://js.aerisapi.com/css/widget.css" />
<script type="text/javascript">
window.Aeris = window.Aeris || {
onLoad: function() {
// Initialize the SDK with your options
Aeris.init({
client_id: 'CLIENT_ID',
client_secret: 'CLIENT_SECRET',
widgets: true
});
},
onReady: function() {
// show the Records widget in the "widget-records" div
var currentsTop = new Aeris.widgets.Records($('#widget-records'), {
params: {
p: '55415',
from: '-7 days',
to: 'now',
sort: 'detail:-1'
}
});
}
};
// Load the SDK asynchronously
(function(w, d) {
var loader = function() {
Aeris.secure = (d.location.protocol === 'https:');
var b = '//' + ((Aeris.secure === true) ? 'js-secure' : 'js') + '.aerisapi.com/';
var v = Aeris.version;
var script = d.createElement('script'), tag = d.getElementsByTagName('script')[0];
script.type = 'text/javascript';
script.async = true;
script.src = b + ((v && v !== '') ? v + '/' : '') + 'aeris.js';
tag.parentNode.insertBefore(script, tag);
}
w.addEventListener ? w.addEventListener('load', loader, false) : w.attachEvent('onload', loader);
})(window, document);
</script>
</head>
<body>
<div id="widget-records"></div>
</body>
</html>
...
Read more...
by nshipes on Mar 13, 2012
We have released version 1.1 of our Aeris Weather API with some exciting new features and enhancements. This launch is also aligned with the release of the initial public version of our Aeris JavaScript SDK released last week, which allows you to quickly add weather content to your web sites and applications using either the customizable built-in widgets or quickly creating your own.
Batch Requests
With this release, our batch request feature is officially released and is no longer considered beta. Our batch request feature allows you to fetch data from multiple endpoints all within a single request (the current maximum is 5 endpoints per batch request), which greatly reduces the number of hits against your account’s allotment. For more information on using batch requests, review our introductory blog post and our official documentation.
New Endpoints
A number of new endpoints are also available with the 1.1 release, which provide even more weather data for your applications. For weather data, we now offer data for sun and moon information, moon phases, earthquakes, and records. Refer to each endpoint’s documentation for the types of data returned and how to properly request it
Usage Stats
You can view usage stats for your account, including daily hit summaries and and hourly breakdown of which endpoint/action combinations you are using the most based on the number of hits. When viewing the daily summaries using your client ID, the total number of hits for each day across all of your registered applications will be shown in addition to the number of hits for each registered client_secret for your account.
Although your current account level allows for a defined number of hits per day, we do provide for occasional situations in which you go over your this daily maximum without affecting or disabling your service. Once you go over your maximum allowed hits for the day, you will begin to see a warn_maxhits_daily warning with every response letting you know you have gone over, but this will not affect the normal response data. However, once you are 25% over the maximum allowed by your account, your access will be disabled and every request thereafter will result in an error. This restriction will be reset daily, so your access will be re-enabled at midnight the following day if you begin receiving overage errors. Refer to our API response documentation for more information regarding the errors and warnings provided.
You can view your API usage stats and trends by logging into your account and selecting “Usage Stats”. The following are screenshots of the new API statistics page from within your account.
Overall usage trends compared to yesterday and last hour:
Usage trends for the the past 7 and 14 days, month, and 3 months (hourly options also available):
Chart representing the endpoints accessed during the past 24 hours. If the above graph is showing hourly trends instead of daily, this graph will match the period selected for the graph:
Endpoint Schemas
To assist with your development, we have created a new schema action for each endpoint. The purpose of this action is to provide you with a complete property set for the specific endpoint along with each property’s description, data type and whether or not the property is required. If a property is not required, it may not always be returned in the response and is determined by the type of request and filters, if any, specified.
Be sure to review the full documentation for the new schema action and its usage.
Geolocating With ":auto"
We now support geolocating a location automatically by assigning the p parameter to :auto. This feature will find the coordinate based on the IP address of the request and return data for the location closest to that coordinate.
The following request would fetch the observations for the user’s location:
/observations/closest?p=:auto
Use the :auto value for your place when you are unable to determine the latitude and longitude using the built-in W3C Geolocation API included in modern browsers or alternative API for mobile platforms, such as CoreLocation in iOS or LocationManager on Android.
These are just a few of the changes, for a complete list of the changes review the full version history for the complete list of fixes, modifications and additions introduced in version 1.1. Make sure to follow us on Twitter and keep up with our blog as we continue to expand our Aeris suite of products and services.
...
Read more...
by nshipes on Mar 08, 2012
We released the initial version of our Aeris JavaScript SDK, which is the first toolkit publicly available as part of our Aeris Web product line. Last month we previewed the SDK and highlighted many of the major features included with it. Also be sure to check out our documentation and pre-built widgets for the SDK from our Developer Center.
The following is a run-down of the primary features currently included with the initial version of the Aeris Weather JavaScript SDK.
Widgets
One of the best features of the Aeris JavaScript SDK is its support for quickly creating weather widgets. As we previewed last month, the SDK already comes with a library of pre-built widgets for you to instantly includes on your web site or within your web applications. These widgets are extremely flexible, allowing you to customize the styles simply by overriding the default CSS styles, or allowing you to define a new HTML template altogether. In our preview post and current documentation, we describe how our widgets have utilized Handlebars JS as its templating engine to offer a very fast and flexible platform for widget generation.
Customizing the Pre-Built Widgets
On our own HAMweather site we have included some of these pre-built widgets from the SDK, such as the current conditions widget (Aeris.widgets.CurrentsCompact) in our site’s main navigation bar and the nearby weather conditions (Aeris.widgets.NearbyWeather) displayed on our home page. The first thing you’ll notice is these don’t look the same as the default pre-built widgets. We’ve simply modified the default CSS styles for our own implementation, and for the current conditions in the navigation, we’ve provided a completely new HTML template.
To demonstrate how easy it is to customize these widgets with a different template, below is an example of how we are setting up the widget in our site’s navigation bar:
var currentsTop = new Aeris.widgets.CurrentsCompact($('#header ul.top-elements > li.wx'), {
cls: 'hw-widget',
tpl: '<div class="aeris-widget-currents-compact-icon">' +
'<a href="{{links.wxlocal}}?pands={{lower places.0.place.name}},{{#if places.0.place.state}}' +
'{{lower places.0.place.state}}{{else}}{{lower places.0.place.country}}{{/if}}">' +
'<img src="{{paths.wxicons}}{{observations.0.ob.icon}}" />' +
'</a></div>' +
'<div class="aeris-widget-currents-compact-temp">' +
'<a href="{{links.wxlocal}}?pands={{lower places.0.place.name}},{{#if places.0.place.state}}{{lower places.0.place.state}}' +
'{{else}}{{lower places.0.place.country}}{{/if}}">{{observations.0.ob.tempF}}°<span class="aeris-widget-unit">F</span></a>' +
'</div>' +
'{{#advisories}}<div class="aeris-widget-currents-compact-alert"></div>{{/advisories}}',
opts: {
resize: {
auto: false
}
}
});
In our example, we needed to differentiate this widget instance from all other instances that may appear, such as on our sample widgets page, in order to properly target it with our custom CSS styles. Therefore, we set our widget’s cls property to “hw-widget” and then each style we needed to override for this instance is prefixed by .hw-widget:
.hw-widget .aeris-widget-currents-compact-loader {background-color:transparent;background-image:url("http://js.aerisapi.com/css/assets/loader_ffffff_4f4f4f.gif");border:0;}
.hw-widget .aeris-widget-currents-compact-icon {margin-top:5px;margin-right:5px;}
.hw-widget .aeris-widget-currents-compact-icon img {width:30px;height:30px;}
.hw-widget .aeris-widget-currents-compact-icon a img {border:0;}
.hw-widget .aeris-widget-currents-compact-temp {font-size:18px;color:#fff;margin-top:10px;}
.hw-widget .aeris-widget-currents-compact a {color:#ddd;border:0;}
.hw-widget .aeris-widget-currents-compact a:hover {color:#fff;text-decoration:underline;}
We also needed to define a new template as there were certain elements we didn’t need from the default widget template. So we included a new HTML template in the widget’s tpl property, which also contains the variables pertaining to the actual API data we wanted to display. For instance, to display the current temperature in degrees Fahrenheit, the API returns:
{
"success": true,
"error": null,
"response": {
"id": "KMSP",
"loc": {
"long": -93.233333333333,
"lat": 44.883333333333
},
"place": {
"name": "minneapolis",
"state": "mn",
"country": "us"
},
"profile": {
"tz": "America/Chicago"
},
"obTimestamp": 1331217480,
"obDateTime": "2012-03-08T08:38:00-06:00",
"ob": {
"timestamp": 1331217480,
"dateTimeISO": "2012-03-08T08:38:00-06:00",
"tempC": -4,
"tempF": 25,
"dewpointC": -6,
"dewpointF": 21,
...
}
}
To display this in our HTML template, we would use the variable format expected for Handlebars JS and explained in the SDK documentation:
{{observations.0.ob.tempF}}
Since our widget is using a BatchCollection to load the data, the response data returned from the API is stored in the collection as an array for the endpoint used. Thus, we would need to access it by prefixing our variable key with the endpoint we want data for, observations, and the item number which we want to access, observations.0. The item number will typically be “0” unless you are using a BatchCollection to
load the same data for multiple locations, such as current observations for five locations. Then you would access each according to their zero-based array index:
{{observations.0....}}
{{observations.1...}}
{{observations.2...}}
You will also noticed we have used a block expression for #advisories and an #if block helper in our template, which are all features supported by Handlebars JS. Be sure to review the complete documentation for Handlebars JS to take advantage of its flexibility in your own Aeris JavaScript templates.
We will soon be adding a tutorials section to our Aeris JavaScript SDK documentation for additional examples of creating your own custom widgets using the SDK.
Collections & Models
The JavaScript SDK makes it extremely easy to use your Aeris API subscription within your own custom web applications and sites even without using the widgets. We’ve included a set of collection objects that perform all of the necessary data requests and parsing from the API in order to provide you with an easy method for accessing this weather data. Each API endpoint has its own collection within the SDK, so you don’t have to worry about API URLs, paths or query strings. Simply create your collection instance and tell it what type of data you want to fetch, including any of the supported API options for each endpoint.
To make accessing the returned API data even easier, we’ve assigned model objects for each collection as well. This type of abstraction allows for more efficient usage and better backwards compatibility, so if anything ever changes with the core Aeris API, our JavaScript SDK can automatically account for such changes internally. This greatly reduces the potential of your own application having errors due to such changes.
...
Read more...
by nshipes on Feb 08, 2012
Over the past few weeks, we’ve been actively working on the first component to Aeris Web -- the JavaScript SDK. We are continuing to test and wrap up all items required for our version 1.0 slated for release within a couple of weeks, but we wanted to provide a preview of how easy it will be to incorporate your Aeris API subscription into your custom web applications.
For instance, if you wanted to fetch the latest weather observations for Seattle, WA, you would just need to use the following snippet once you have initialized the Aeris JS SDK with your access information:
var obs = new Aeris.collections.Observations();
obs.bind('load', function(collection){
var model = collection.at(0);
alert('Currently in Seattle it is ' + model.get('ob.tempF') + ' degrees.');
});
obs.fetch('seattle,wa');
The same properties from the core data API are also used in the JavaScript SDK, so switching between the two formats is straightforward.
Built-In Widgets
We will also be including a set of basic built-in JavaScript widgets that you can include in your application that are fully customizable using CSS and custom templates. The following is an example of using our built-in Advisories widget that loads advisories for Birmingham, AL and renders it to a <div> whose id is “widget-advisories”:
var advisories = new Aeris.widgets.Advisories($('#widget-advisories'), {
params: {
p: 'birmingham,al'
}
});
All of our HTML templates are based on Handlebars JS, so it is very easy and quick to customize any of the built-in widgets or creating your own by extending our core objects.
Below are screenshots of some of the built-in widgets that will come with the Aeris JavaScript SDK.
Our included widgets also support additional features, like displaying data based on the user's geolocation or allowing them to view the data for a particular location they can search for. Additionally, widgets can be configured to auto-refresh its data based on a specific time interval, so you can ensure your data is always up to date no matter how long the page is open or application running.
We will be posting additional updates as we get closer to the official release of version 1.0 of the JavaScript SDK.
...
Read more...
by nshipes on Feb 03, 2012
This week we have pushed out updates to the Aeris Weather API and the iOS framework. We have also been busy wrapping up development for the initial release of the JavaScript toolkit coming soon.
The Aeris Weather API 1.0.6 update is a maintenance release that fixes several bugs and adds a few improvements. Most notably, updates to the storm cells endpoint and a new sortable date-time mapping for the storm reports, storm cells and fires endpoints. Additionally, a new “skip” parameter (currently in beta) was added which allows skipping over a specific number of results, which is useful when pagination is required. Review the version history for a complete list of changes.
Additions to the Storm Cells Endpoint
The storm cells now include a place object that provides the closest city, state and country to the storm cell. Also, a new ob.location property has been added which provides the distance and bearing to the closest city, such as “3 miles SSW of Mobile”. This better aligns the storm cells endpoint with our standard output for other similar endpoints.
Additionally, new query mappings were added for the name and state of the closest city to the storm cell, which can be used to request all storm cells within a state:
For example, the following query will return up to 100 storm cells in the state of Alabama:
/stormcells/search?query=state:al&limit=100
The following will return up to 100 storm cells in the state of Alabama with a rotation signature:
/stormcells/search?query=state:al&filter=rotating&limit=100
New sort mapping for Storm Reports
We have added two new sort mappings for storm reports: “dt” and “details”. The new “dt” mapping allows sorting results based on the report date and time.
For example, the following query will return up to 50 storm reports in the state of Minnesota, sorted newest to oldest, over the past 7 days:
/stormreports/search?query=state:mn&sort=dt:-1&from=-7days&limit=50
Note: The “dt” mapping was also added to the stormcells and fires endpoints.
The new “details” mapping allows sorting results based on the measured value in the report, when available.
For example, the following would return the top 10 snow reports in Minnesota for the past week sorted by the amount of snow reported in descending order:
/stormreports/search?query=state:mn&sort=detail:-1&filter=snow&from=-7days&limit=10
Skip Parameter
Although this feature is still in beta, we are also introducing the new “skip” parameter. This parameter can be used to skip a specified number of results, which when combined with the “limit” parameter can be useful in paging implementations.
For example, you may want to return 10 of the closest cities to Minneapolis sorted by descending distance but skip the first 10 results:
/places/closest?p=minneapolis,mn&skip=10&limit=10
Aeris iOS Framework Updates
Our 1.0.3 release of the Aeris iOS framework is a maintenance release that fixes several bugs and brings the model properties up to date with the property changes recently made in the core API.
The biggest change resulted from a bug in which the date and times displayed in the sample application were not using the proper time zone of the actual location the data was for, but instead always falling back the time zone of the iOS device. Therefore, we have added a new `timeZone` property that stores an NSTimeZone instance for the time zone of data’s location. This can then be passed to custom date formatters and calendars to get the correct day and time from the stored `timestamp` property (Note that all dates in iOS are stored in GMT). Refer to the developer documentation for the Aeris.framework for the full set of properties supported for each object.
Although new features have not been added in this update, support for batch processing and several new features are in the works will be coming very soon to the iOS framework. Refer to the full version history for the full list of changes in version 1.0.3.
...
Read more...
by lhuffman on Jan 27, 2012
We released version 1.0.5 of the Aeris Weather API which provides support for Canadian postal codes and several bug fixes. Review the version history for a complete list of changes.
Canadian Postal Codes
With this release, Canadian postal codes have been added to our supported place formats. When using postal codes, the space that occurs within the middle is optional, making "M3C 4H9" and "M3C4H9" equivalent.
An example of finding the place information for a postal code:
/places/M3C4H9
/places?p=M3C4H9
/places?p=M3C%204H9
An example of finding the closest observation for a postal code:
/observations/M3C4H9
Warnings
We have introduced the concept of request warnings with this update. Request warnings will be issued in special cases, such as when a parameter is being used improperly or your request includes deprecated functionality or properties. In such cases, the API will still provide a successful response with data, but the error object will include a warning message.
...
Read more...
by lhuffman on Jan 11, 2012
Today we released version 1.0.3 of the Aeris Weather API. This release provides support for auto-complete style queries with the new “starts with” functionality as well as several other minor items. Additionally, with this release we added batch requests as a beta feature! Batch requests allow you to query multiple endpoints with a single request to the servers. Review the version history for a complete list of changes.
“Starts With” Query / Auto-Complete
A common feature seen in many weather applications is the auto-complete style functionality that queries the server as a user is typing in a location name. Now with the new “starts with” query modifier, this can be accomplished easily. All that is needed is to precede the search string in the query with a caret (^) symbol.
An example of a query searching for words starting with “minn”:
/places/search?query=name:^minn&limit=10
The following uses the same above query but limits it to US locations only:
/places/search?query=name:^minn,country:us&limit=10
Batch Requests (Beta in v1.0.3 of the Aeris Weather API)
We have received many praises and requests for the Aeris Weather API, the most common request being the ability to query multiple endpoints all within a single query. Our new batch request feature takes care of this for you without having to learn a new endpoint or request format. Please note that as of 1.0.3 we consider this a beta feature and a max of 5 endpoints can be performed per batch request.
See the batch request documentation for full usage. The following are the primary features:
The batch endpoint uses a requests parameter set to a string of comma-separated standard endpoint requests. Each endpoint request must include either an :action or :id and its own parameters (optional). If the main batch request uses an :id, then this ID will be automatically passed to each endpoint query.
Additionally, any other parameters passed to the batch request are considered global and passed to each individual endpoint requests found in the requests parameter. Note, however, that the parameters included within an individual endpoint request will override those same options found in the global parameters of the batch request. For example:
/batch?limit=10&requests=/observations/closest,/stormreports?limit=5,/fires/closest
In this batch request, the global option “limit=10” is used by the observations and the fires endpoints, but the stormreports endpoint overrides this with it’s own “limit=5”
Use Case 1 - Fetch multiple data types for the same location:
The is the simplest and most common use of a batch request:
/batch/:id?requests=/:endpoint1,/:endpoint2,/:endpoint3
For example, to fetch the latest observation, daily forecast and active advisories for Minneapolis, MN:
/batch/minneapolis,mn?requests=/observations,/forecasts,/advisories
Parameters can be passed to each individual endpoint as well. For example, to obtain the latest observation, the forecast in daily intervals, the forecast in hourly intervals and all active advisories, the batch request would be:
/batch/minneapolis,mn?requests=/observations,/forecasts,/forecast?filter=6hr,/advisories?filter=all
Use Case 2 - Fetch data for multiple locations:
To fetch the latest observations for Atlanta, Minneapolis and Seattle:
/batch?requests=/observations/atlanta,ga,/observations/minneapolis,mn,/observations/seattle,wa
Use Case 3 - Fetch weather extremes:
The following batch request is combined with the power of the query and sort parameters to return the warmest and coldest locations in the US based on their latest observations:
/batch?limit=1&query=country:us,temp:-999&requests=/observations/search?sort=temp:-1,/observations/search?sort=temp
Here the “query=country:us,temp:-999” queries only observations in the US and only includes observations that have a valid temperature (observations that didn’t report a temperature for a particular hour will have -999 as the temperature value, so we would want to eliminate those that didn’t report).
Often during the winter months the warmest location in the US may be in Puerto Rico. So, adjust the query to eliminate locations in Puerto Rico to query only the 50 states:
/batch?limit=1&query=country:us,state:!pr,,temp:-999&requests=/observations/search?sort=-1,/observations/search?sort=temp
...
Read more...