Lets Tutorial

Since the launch of the Google Tasks API many Google Apps domain administrators have asked us how to use the API with 2-legged OAuth 1.0 (2LO) for authorization. The process for using 2LO with the Tasks API is slightly different compared to using it for the Google Calendar API or the Google Contacts APIs, which makes it a little tricky if you are already accustomed to working with those.

1. Any use of the Tasks API needs to reference a project in the APIs Console, as the Console is used to manage API quotas and other application settings (such as IP filters).
2. The Tasks API needs to be explicitly enabled for your domain OAuth key and secret.

Note: 2-legged OAuth via the method described in this post and referenced documentation is available for Google Apps for Business and Google Apps for Education administrators, but is not available for administrators of the Free edition.

Referencing an APIs Console Project

The Tasks API needs to know which APIs Console project is sending requests to the API (so quota can be deducted, filters can be checked, etc.). To supply this information, you need to specify the API Key of your project within each request to the Tasks API-- even when using 2LO. This is done by specifying the API Key in a key URL query parameter.

    e.g.: https://www.googleapis.com/tasks/v1/users/username/lists?key=<API_KEY>

The Java client library can do this for you automatically if you specify it after initializing the Tasks service:

// Initializing the Tasks API service
Tasks service = new Tasks("2-LO Tasks Test", httpTransport, jsonFactory);
service.accessKey = API_KEY;

Enabling the Tasks API for your domain OAuth key and secret

Also, before your API requests will be successful, you will need to change a few things in your OAuth Consumer Key and Secret configuration. In the Manage OAuth domain key page available in the Google Apps Control Panel (under advanced tools), you will need to make sure that the option Enable this consumer key is checked and the option saying Allow access to all APIs is unchecked. This may sound counterintuitive, but this option will give you access to a specific set of APIs and is necessary to access the Tasks API.

Setting up the domain OAuth consumer key and secret
Then you will need to specify which APIs you want your domain OAuth key and secret to have access to. You will be able to do this in the Manage third party OAuth Client access page where you will need to list manually all the scopes that your domain key will have access to. For example for your token to have access to the Google Calendar API and the Google Tasks API use:
    e.g.: https://www.google.com/calendar/feeds/, https://www.googleapis.com/auth/tasks

You should then be all set to use 2LO with your Google Apps domain key and secret.

For a more detailed and step-by-step explanation with code samples on how to use 2LO if you are a Google Apps domain admin, I invite you to have a look at the newly published article: Using 2-Legged OAuth with Google Tasks API for Google Apps domain administrators.

Nicolas Garnier profile | twitter | events Nicolas joined Google’s Developer Relations in 2008. Since then hes worked on commerce oriented products such as Google Checkout and Google Base. Currently, he is working on Google Apps with a focus on the Google Calendar API, the Google Contacts API, and the Tasks API. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

Want to weigh in on this topic? Discuss on Buzz

The passive microwave data from the Advanced Microwave Scanning Radiometer (AMSR), available at https://gcom-w1.jaxa.jp/auth.html, is delivered in orbital swaths. The raster band contain the image data in various frequency range, and the geolocation information for 89GHz is stored in one containing latitude values for each pixel, and another channel containing longitude values for each pixel. This data needs processing before having a regular geocoded raster.

The following is not an exhaustive description, but extended notes on how to read AMSR-2 files, which possibly may be of   help to others trying to solve a similar task.

For some, the final commented script at our github page may be enough help, the text below tries to explain the most important steps in this script:

The various frequency bands of AMSR-2 have different resolution (see the product specs and the user manual ), we choose the L1R dataset, where the data is already processed to match the geolocation stored in the lat/long band for 89GHz.

Information on the hdf image can be retrieved with gdalinfo:

gdalinfo C:UsersmaxDocumentsGW1AM2_201301311114_050A_L1SGBTBR_1110110.h5

The metadata printed out contains the names of the subchannels, as seen here:
and information about a specific channel can be retrieved by using gdalinfo on exactly this subchannel-name from the metadata:

gdalinfo HDF5:"C:UsersmaxDocumentsGW1AM2_201301311114_050A_L1SGBTBR_1110110.h5"://Brightness_Temperature_(89.0GHz-A,V)

Opening one of the bands in QGIS, the data looks like this (all images in this post are © JAXA EORC ):

HDFfile = gdal.Open( rC:UsersmaxDocumentsGW1AM2_201301311114_050A_L1SGBTBR_1110110.h5 )

HDF_bands = HDFfile.GetSubDatasets()

#HDF Subdatasets are opened just as files are opened:
HDF_SubDataset = gdal.Open(HDF_bands[channel][0])
HDF_SubDataset_array = HDF_SubDataset.ReadAsArray()

HDF_Lat89A = gdal.Open(HDF_bands[46][0])
HDF_Lat89A_array = HDF_Lat89A.ReadAsArray()
 
HDF_Lon89A = gdal.Open(HDF_bands[48][0])
HDF_Lon89A_array = HDF_Lon89A.ReadAsArray()

In the next step, a create a comma-separated file containing longitude, latitude, brightness values for each raster point. This comma separated file is then the input for gdal_grid. I loop through each pixel and write the three values (  longitude, latitude, brightness ) into a csv-file.

So for the 89GHz channel, I write both 89A and 89B to a csv-file:

 
#Add header line to textfile
textfile = open( AMSRcsv, w)
textfile.write(lon,lat,brightness
)

## Loop through each pixel and write lon/lat/brightness to csv file
for i in range(rows):
    for j in range(cols):
        wgs84=pyproj.Proj("+init=EPSG:4326")
        EPSG3411=pyproj.Proj("+init=EPSG:3411")
     
        lonA = HDF_Lon89A_array[i,j]
        latA = HDF_Lat89A_array[i,j]

        # lon/lat written to file already projected to EPSG:3411
        (lonA_3411, latA_3411) = pyproj.transform(wgs84, EPSG3411, lonA, latA)
        brightnessA = HDF_Br89AH_array[i,j]* 0.01 #APPLYING SCALING FACTOR!

        lonB = HDF_Lon89B_array[i,j]
        latB = HDF_Lat89B_array[i,j]

        # lon/lat written to file already projected to EPSG:3411
        (lonB_3411, latB_3411) = pyproj.transform(wgs84, EPSG3411, lonB, latB)
        brightnessB = HDF_Br89BH_array[i,j]* 0.01 #APPLYING SCALING FACTOR!

        if 35 < latA < 90:
            textfile.write(str(lonA_3411) + , + str(latA_3411) + , + str(brightnessA) + 
)

        if 35 < latB < 90:
            textfile.write(str(lonB_3411) + , + str(latB_3411) + , + str(brightnessB) + 
)
       
textfile.close()

For the lower resolution channels, I use the odd numbers of the 89A long and lat channel:

 
#Add header line to textfile
textfile = open( AMSRcsv, w)
textfile.write(lon,lat,brightness
)

## Loop through each pixel and write lon/lat/brightness to csv file
for i in range(rows):
    for j in range(cols):
        wgs84=pyproj.Proj("+init=EPSG:4326")
        EPSG3411=pyproj.Proj("+init=EPSG:3411")

        #For low resolution the odd columns of Lon/Lat89 array to be taken!
        lonA = HDF_Lon89A_array[(i) ,(j*2+1)]
        latA = HDF_Lat89A_array[(i) ,(j*2+1)]

        # lon/lat written to file already projected to EPSG:3411
        (lonA_3411, latA_3411) = pyproj.transform(wgs84, EPSG3411, lonA, latA)
        brightnessA = HDF_SubDataset_array[i,j]* 0.01 #APPLYING SCALING FACTOR!

        if 35 < latA < 90:
            textfile.write(str(lonA_3411) + , + str(latA_3411) + , + str(brightnessA) + 
)

textfile.close()

Now I can almost run the gdal_grid, but as described at http://www.gdal.org/gdal_grid.html I need to create a xml file describing my comma-separated csv file.

 
<OGRVRTDataSource>
 <OGRVRTLayer name="GW1AM2_201301010834_032D_L1SGRTBR_1110110_channel89H">
  <SrcDataSource>G:AMSRGW1AM2_201301010834_032D_L1SGRTBR_1110110_channel89H.csv</SrcDataSource>
  <GeometryType>wkbPoint</GeometryType>
  <GeometryField encoding="PointFromColumns" x="lon" y="lat" z="brightness" />
 </OGRVRTLayer>
</OGRVRTDataSource>

This xml file above can be created in a python script in the following manner, some more info here:

root = ET.Element("OGRVRTDataSource")

OGRVRTLayer  = ET.SubElement(root, "OGRVRTLayer")
OGRVRTLayer.set("name", AMSRcsv_shortname)

SrcDataSource = ET.SubElement(OGRVRTLayer, "SrcDataSource")
SrcDataSource.text = AMSRcsv

GeometryType = ET.SubElement(OGRVRTLayer, "GeometryType")
GeometryType.text = "wkbPoint"

GeometryField = ET.SubElement(OGRVRTLayer,"GeometryField")
GeometryField.set("encoding", "PointFromColumns")

GeometryField.set("x", "lon")
GeometryField.set("y", "lat")
GeometryField.set("z", "brightness")

tree = ET.ElementTree(root)
tree.write(AMSRcsv_vrt)

Now we finally can run gdal_grid, either command line:

gdal_grid -a_srs EPSG:3411 -a average:radius1=4000:radius2=4000:min_points=1 -txe -3850000 3750000 -tye -5350000 5850000 -outsize 760 1120 -l GW1AM2_201301010834_032D_L1SGRTBR_1110110_channel89H GW1AM2_201301010834_032D_L1SGRTBR_1110110_channel89H.vrt GW1AM2_201301010834_032D_L1SGRTBR_1110110_channel89H.tif

or called from a Python script:

AMSRcsv_shortname =  GW1AM2_201301010834_032D_L1SGRTBR_1110110_channel89H
AMSRcvs_vrt = GW1AM2_201301010834_032D_L1SGRTBR_1110110_channel89H.vrt
AMSR_tif = GW1AM2_201301010834_032D_L1SGRTBR_1110110_channel89H.tif  

radius1 = 4000  
radius2 = 4000  
os.system(gdal_grid -a_srs EPSG:3411 -a average:radius1= + str(radius1) + :radius2= + str(radius2) + :min_points=1 -txe -3850000 3750000 -tye -5350000 5850000 -outsize 760 1120 -l  + AMSRcsv_shortname +    + AMSRcsv_vrt +   + AMSR_tif)

The radius indicates in which distance around a given output raster point the algorithm searches for points falling into the NSIDC raster -- if too small, it will result in empty pixels, if too large there will be too much smoothing since many pixels are averaged into one.

The result is, finally, the part of the swath falling into the NSIDC-raster:


In a final step, I take all of such swaths for one day and average them into a full image of that given day, see the Average Daily function in the script for details (images  © JAXA EORC ).


One issue using gdal_grid is its very low performance regarding speed (see this comment ), one 89GHz band takes 10 minutes and a lower resolution band 2 minutes calculation time. This is then about 25 minutes for all channels of one hdf file, and since every day has about 20 files, this means 8 hours for one averaged daily raster. gdal_grid may therefore not always be feasible until the speed issue is improved.

If youre interested in creating Android games using Flash CS5, then check out Lynda.coms Flash Professional CS5: Creating a Simple Game for Android Devices video training course. This course on creating Android games will show you how to translate your existing Flash skills so that you can use them to design a game in Flash and publish it as an AIR for Android app. By the end of the course, you will have learned the following game concepts: collision detection, random enemy creation and movement, shooting capabilities, creating multiple levels, and displaying high scores.


This course also goes beyond game functionality and shows you how to incorporate the use of mobile device capabilities such as the accelerometer and gestures to control graphics, and the hardware keys to activate menus. Youll also learn how to optimize your game so that it plays well on mobile devices. Once youve designed and created your own Android game using the skills youve learned from this course, youll probably want to distribute it through the Android Market; this course will teach you that as well.

This training course consists of a total of 3 hours and 35 minutes worth of video divided into different chapters. Youll be viewing clearly presented video recordings of the author showing you how to create the Android game. No need to go through long pages of text, and best of all, youll see exactly whats happening on the authors screen so that you can easily follow along.

Here are a couple of sample videos from the course that will give you a better idea of the kind of game that you will be creating:

Introduction - Flash Professional CS5: Creating a Simple Game for Android Devices

Adding code snippets - Flash CS5: Creating a Simple Game for Android Devices

This video talks about Flash CS5s handy feature known as code snippets. Code snippets are pre-made customizable code that you can easily add to your project.

Adding elements of randomness and chance to your game - Flash Professional CS5: Creating a Simple Game for Android Devices

This video will show you how to create an element of chance when generating the number of enemies that come up in your game. Youll also learn how to randomize the movement of these enemy characters.

Using the accelerometer to enable the user to move the game character by tilting the device - Flash Professional CS5: Creating a Simple Game for Android Devices

This video will show you how to use the AS3 Accelerometer class in order to take advantage of an Android devices accelerometer sensor, which detects if the device is being tilted by the user, so that it can be used to make the character move.


If you liked the sample videos, then go ahead and sign up for a Lynda.com membership to view the entire course. For $25, you get 1-month unlimited access to not just this training course, but all of Lynda.coms 900+ training courses. No long-term commitment required. You can cancel your membership at any time. And as a special promotion for visitors of this site, you can get a Free 10 day pass to lynda.com. Go ahead and see for yourself what a great learning resource this website is.


Heres a more detailed outline of the course:

Title: Flash Professional CS5: Creating a Simple Game for Android Devices
Author: Paul Trani
Duration: 3hrs 35mins
Date of Release: 15 February 2011

Chapter 1: Introduction to Mobile
Understanding the user
Flash content on Android devices

Chapter 2: Mobile Game Setup
Reviewing the game
Creating a file in Device Central
Reviewing the game structure
Adding code snippets

Chapter 3: Basic Game Movement
Animating the intro screen
Moving the player
Adding enemies
Adding movement
Adding chance and randomness

Chapter 4: Advanced Interactivity
Adding lasers
Detecting collisions
Adding explosions
Removing assets from the stage
Adding audio

Chapter 5: Scoring
Adding scoring and levels
Subtracting lives and ending the game
Creating a results screen
Displaying the score
Saving and loading game results

Chapter 6: Mobile-Specific Functionality
Detecting movement with the Accelerometer
Using the swipe gesture
Using hardware keys

Chapter 7: Optimizing for Mobile Devices
Handling exits and idle mode
Handling activation and deactivation
Optimizing graphics
Optimizing ActionScript

Chapter 8: Publishing
Creating the application files
Creating the app (Mac)
Creating the app (PC)
Publishing to an Android device (Mac)
Publishing to an Android device (PC)

Chapter 9: Uploading to the Android Market
Uploading to the Android market
Downloading from the Android market



So if you want to start learning about Android game development so you can start creating your own Android games, then sign up for Lynda.coms Flash Professional CS5: Creating a Simple Game for Android Devices training course.