The Microsoft OGDI DataLab is an initiative led by Microsoft.
OGDI DataLab uses the Microsoft Windows Azure™ platform to publish and use a wide variety of public data from government agencies. Microsoft’s Windows Azure platform is a group of cloud technologies, each providing a specific set of services to application developers. The Windows Azure platform can be used both by applications running in the cloud and by on-premises applications.1
This chapter assumes familiarity with the Microsoft Azure Platform, tables, column types, connection parameters, KML geometries, and cloud computing in general.
Microsoft OGDI DataLab Product and System Requirements
|
Format |
Platform |
Operating System |
||||
|---|---|---|---|---|---|---|
|
Reader/Writer |
FME Desktop License |
FME Server |
FME Cloud |
Windows 64-bit |
Linux |
Mac |
|
Reader |
Available in FME Professional Edition and higher |
Yes |
Yes |
Yes |
Yes |
Yes |
|
Writer |
Available in FME Professional Edition and higher |
Yes |
Yes |
Yes |
Yes |
Yes |
Connecting to Azure Tables
Connecting to Azure Tables requires that you provide a Storage Service name or URL, and a Primary Access Key that grants access to that service. The Primary Access Key is usually provided when creating an Azure account for that service. Note that you should store this access key because it is not easily human-readable and you must provide it for new connections using the reader and writer.
It is strongly recommended that you use FME defaults for this format.
Background
The Windows Azure Table service is a cloud storage service that is part of the Windows Azure platform on which OGDI DataLab is built.
The Windows Azure Table service is designed to store simple tabular data in the cloud. In many aspects, it behaves like a database. Windows Azure tables are scalable, and they can store terabytes of data.
The key limitation of Windows Azure tables is that they are not relational; however, they are not limited to a specific set of fields. Two different entity sets within a table may have completely different fields, so schema is a fluid concept. At the row level, every entry has a partition key and a row key. These two keys together form the identity of the entry. The partition key can also load-balance the table across multiple servers.
The related Azure Table service reader and writer and the underlying Azure Table architecture do not include any native geometry support. OGDI DataLab builds on Azure Tables and adds its own geometry (stored in KML snippets) and metadata support.
Note: Currently, the OGDI DataLab reader and writer connect with the Microsoft Windows Azure architecture and retrieve data from the Table storage type. Reading and writing from or to Blob or Queue storage types is not supported.
Since it is not a relational database, the OGDI DataLab reader and writer do not support a SQL interface. Instead, you should use the Windows Azure SQL Database.
How does Windows Azure SQL Database differ from SQL Server?
The OGDI DataLab reader and writer communicate with Azure servers directly through the REST API.
Reader Overview
The OGDI Reader produces an FME feature for each row in a table in the provided source.
Writer Overview
You can choose keys (as long as every Partitionkey-RowKey is unique), or you can let FME create keys.
If you let FME create the keys, FME will give a unique partition key per translation. This Partition key will be the same for all the features on the same translation to optimize batch transfer to the server. The row key will be a random UUID for each feature.
Additional Information
Additional information on the Microsoft Windows Azure Platform is available at http://www.microsoft.com/windowsazure/.
For more information on the Azure Table storage service, see the Summary of Table Service Functionality.