Skip to main content
  • Guide

Connecting Windographer to Your Database

If you store wind resource data in SQL Server, MySQL, or PostgreSQL, the enterprise edition of Windographer can connect directly to your database.

Close up of a wind turbine

Databases are powerful. They provide a  central storage location for enormous quantities of data, allowing access by multiple users simultaneously, and offering regular backups and tight control of data integrity. More and more wind power developers and analysts are turning to databases to store their wind resource assessment data. 

If you store wind resource data in SQL Server, MySQL, or PostgreSQL, the enterprise edition of Windographer can connect directly to your database. It can import a dataset from your database, let you analyze and modify that dataset, and then export the changes back to the database, with no need for windog files. You don’t need a custom version to do this; Windographer is flexible enough to talk to any database that supports stored procedures.

Windographer can even import from the database multiple datasets at once. The Import From Database window, shown below, lets you select all the datasets you want to import. It also enables you to enter a search term to narrow down the list in case your database contains hundreds of datasets. When you click Import, Windographer reads the datasets from the database, allowing you to work with that data exactly as if you had imported it from a data file.

Windographer Import From Database window

The database can store all the data that windog files store, including:

  • Dataset properties – Name, longitude, latitude, and elevation
  • Data column properties – Name, type, units, and measurement height
  • Data columns
  • Flags that apply to each data column
  • Calibration history for each data column
  • Dataset history

Windographer talks to your database by calling stored procedures, which are functions written within the database. It does not directly execute SQL statements on your database because that would require Windographer to know the names of your tables and your fields, and how the tables relate to each other. Instead, it simply calls a set of stored procedures, which perform the querying and format the results into recordsets (simple table structures) that Windographer can read. 

That means you, or someone on your team, must do some work to make this happen. You have to write a few stored procedures that execute the SQL queries appropriate to your table names and data structure. This is standard for database administrators and database programmers, and the Windographer database specifications provide the necessary guidance. 

As an example, say your database stores some dataset properties (like name and period of record) in a table called Datasets, and other properties (like location and time zone) in a table called Projects:

Datasets database table

ID Dataset Start End  TimeStep Description ProjectID
2 Bluebird_M1371 2018-04-28 2018-05-03  600   82
3 Bluebird_M3832 2018-05-06 2018-05-11 600   82
4 Bluebird_M4930 2018-05-17 2018-05-22 600   82
6 Linden 2013-11-27 2014-03-30 600   173
1 Torre24 2021-07-29 2021-08-04 600 San Vincente 61

Projects database table

ID Project Landowner Region TimeZone
82 Bluebird McIntyre Ranch Southeast UTC
173 Oyen Farmer Bill Central UTC
61 Rosa Betty Beltrán Oaxaca UTC-6

When Windographer calls the stored procedure to retrieve the list of datasets, your stored procedure will have to execute the appropriate SQL SELECT statement to query the necessary fields from those tables and combine the results into a single recordset of the structure required by the Windographer database specifications, like this:

Recordset returned to Windographer

dataset_id dataset_name dataset_timestep dataset_timezone dataset_start dataset_end dataset_description
2 Bluebird_M1371 10 0 2018-04-28 2018-05-03  
3 Bluebird_M3832 10 0 2018-05-06 2018-05-11  
4 Bluebird_M4930 10 0 2018-05-17 2018-05-22  
6 Linden 10 0 2013-11-27 2014-03-30  
1 Torre24 10 -240 2021-07-29 2021-08-04 San Vincente

That recordset presents the data in the form that Windographer expects and omits extraneous information (like landowner and region) that Windographer doesn’t use. The stored procedure has translated your data into a form that Windographer can understand. Other stored procedures do similar work to allow Windographer to read the data column properties, the time series data itself, the flag status of each data point, and so on, and to write that information back to your database in case the user makes modifications.

Windographer database interface specification

The current database specifications can be found here.

Learn more about Windographer 5 and get a complimentary software trial.

Download a software trial


Learn more about what Windographer can do for you.

Learn more

Get connected with our sales team

Thanks for your interest in our products and services. Let's collect some information so we can connect you with the right person.

Please wait…