We’ve been working on this one for a while, but now it’s ready for prime time. The Web Coverage Service (WCS) is one way to access data directly from our weather data platform and functions as a real-time weather data API for teams that need fast, structured access to forecasts and model output.

WCS is an OGC standard for accessing gridded datasets. It’s structured in a way that encourages the use of weather data. Lots of support for big data lists, along with ways to acknowledge that data may be missing sometimes.

We do like to complain about WMTS and WMS, in particular, which are also OGC standards, but WCS has improved in many ways. It still has some Web 1.0 assumptions baked in, but it’s much better, and we can work around most of them.

What Data Sets are Available

Like many OGC standards, you can ask the server for a full list of what’s available. WCS has better ways of doing this, which can reduce bloat. We’re using the metocean extension, which is very compact and looks like this.

That’s a concise way of saying we have NDFD data for this set of time steps. It doesn’t list the variables we support, but there’s another call for that.

We also support the older way of doing it, listing each model run individually.

This is a bit wordier (XML!), but it does have the advantage of indicating which model runs have all data (complete is True) and which are still coming in (complete is False).

Supporting both results is 15MB of XML for one of our customers!

Why? It’s radar data. It’s always radar with these standards. You design something nice and logical for an hourly forecast, and someone starts throwing data at you every 2 minutes. Oh well.

Our service can calculate that XML and return it in under 5 seconds. With caching, that’s even faster and good enough for now.

We’ll see if we can improve this in the future, but it doesn’t matter all that much because most people don’t use Capabilities very often. They review it once, identify the patterns, and then apply some of our shortcuts, which we’ll discuss below.

What’s in a Data Set

DescribeCoverage is the call you can use to examine a model run more closely. If we pass the CoverageId “ndfd-conus-non_latest-complete” as above, we’ll receive about 54 KB of XML. You can actually do something with that in a limited amount of time!

Unfortunately, the XML return is one of the least comprehensible in the spec, and a screenshot will not tell you much. It uses internal XML references, which is always a bad sign in our opinion.

Though it works, and if you want metadata on a given weather model, it’s there, and it’s not too horrible to parse once you get the hang of the metocean extension.

Or you can do what most people do and skip this step entirely, because you can hardwire your queries and ignore all this metadata.

Latest vs Incomplete in a Real-Time Weather Data API

With many of these OGC standards, the Capabilities function is well-intentioned but slower than you’d like. So users and providers develop shortcuts. Ours is the “latest” family of queries.

Each of these “latest” data sets does what it sounds like: “latest” and “latest-complete” query the latest complete model run. You want the full dataset? You’ll get it.

The “latest-incomplete” queries will use data coming from a new model run. If the GFS 6z is still coming in, you’ll get that. Of course, not all forecast hours may be available yet, but you’ll get the latest data.

This is one of the areas where WCS begins to behave less like a legacy standard and more like a real-time weather data API. You’re not waiting for full file transfers. You’re querying what exists right now.

We should add a “latest-merge” that merges “latest-complete” and “latest-incomplete,” since that’s likely what our users are actually doing.

But what can you do with these CoverageIDs?

Just Get Me The Data

That’s a lot of talking when you really want data! So let’s go get some data. Here are the parameters passed in to a GetCoverage call to get us some NDFD wind speed data.

All of that is baked into a big URL and sent to our WCS Service. The result returns in about 500ms with a large list of wind speeds for each forecast time at 10m. Here’s an entry in that list.

It’s JSON! Not surprising since we asked for JSON, but much friendlier to parse. There are other options, like NetCDF.

What’s often as interesting with WCS is what you don’t include. We didn’t include a forecast time in the query, so we got all the forecast times back from the latest model run. Pretty useful!

If we include a forecast time range, we’ll just get those back. Always best to only ask for what you need. That might look like this.

With that query, you get the 30m forecast return.

This is where WCS fully acts as a real-time weather data API. You’re not downloading full model grids unless you want to. You’re querying exactly what you need, at a specific point, for a specific time range, in a format your application can use immediately.

Future Work on WCS

There are lots of features we didn’t cover in detail. You can get grids out of this, though, if you’re pulling whole model runs, let’s talk about using Labrador for that instead. This is meant for speed.

What our WCS implementation is good for right now is fast data query. We even restructured the model runs so you can query the entire set at once. That was a lot of work, but it’s now very fast.  

Speed is the point.

If you’re building dashboards that require the latest data, internal logic that needs real-time forecasts, alerting systems, or decision engines that cannot wait for bulky file downloads, this is the tool. WCS delivers the structure of an OGC standard with the responsiveness of a real-time weather data API.

It plugs directly into applications. It supports the way developers actually build systems. And it gives you immediate access to the forecast data driving your operational decisions.

If your workflows depend on fast, reliable forecast queries, Web Coverage Service is the real-time weather data API built to handle it.