90 Meter Elevation Data
To generate an international forecast for Seasonality, I take in a GeoPoint and find the 4 closest surrounding data points from the GFS Forecast model. The GFS data is 0.5 degree resolution, so if I had a location at point 50.2° latitude, 30.8° longitude, I would use the following data points when generating the forecast: (50°, 30.5°), (50°, 31°), (50.5°, 30.5°), and (50.5°, 31°). The problem is that these surrounding points could be fairly distant from the weather location being queried, so depending on the terrain a forecast can vary widely. However, the forecast could be made more accurate if the elevations of each GeoPoint is taken into account.
So where does the 90 meter data come from? Well, the SRTM mission a few years back captured this level of detail for the area from -60° to 60° latitude, which includes almost all the land masses. Outside that range, a lower resolution dataset is used to fill in the gaps. A data point every 90 meters doesn’t sound like much; afterall that’s elevation points about a football field away from each other. I imagine in some terain where you have a lot of quick elevation changes, such as canyons or cliffs, this wouldn’t be enough. However, do not underestimate the amount of data here. The compressed download is around 1.2 gigabytes, and it expands to a ~7 gigabyte data file. The entire dataset is 86400×43200 data points, or 3,732,480,000 GeoPoints. Multiply that by 2 bytes per data point and you have a 7 gigabyte file.
Fortunately, this file is easy to parse. There is no header, just the raw data. The map projection is a simple equirectangular projection, giving equal distance across latitude and longitude. The location starts at (90°, -180°) and continues across an entire 86400 point row before moving South to the next row. The final GeoPoint is (-90°, 180°). Each data point is a signed “short” integer (2 bytes long). Perl’s unpack function works wonders here to get a short value from the binary data.This data is going to be perfect for taking elevation into account while forecasting. It’s resolution is over 14000x (!) more detailed than my 0.5 degree GFS dataset, giving 120 GeoPoints between each GFS GeoPoint in each dimension. This should be plenty of data to work with. Maybe I’ll talk about how I use elevation to make more accurate forecasts in a future article.
Here’s something I’ve been thinking of lately: the effect of elevation on time of sunrise and sunset. Obviously, someone in a valley is going to have a shorter amount of time between the two vs. someone on the top of a ridge.
It’s funny because I was recently thinking of the same topic. The thought went something like: “Wow, it would be cool if Seasonality could look at the elevation profile of the area around each location and take that into account when calculating sunrise and sunset.”
Then came the gear turning, trying to figure out how to actually accomplish this. It would probably be reasonable to find the compass direction where the sun would rise and set, but then you would have to look at the terrain in that direction to find where the tallest peak would be. You’d have to take into account the curvature of the earth and the distance of the peak from the location’s origin. Then you’d have to use that data to offset the horizon and adjust for it.
It sounded like a ton of work for an adjustment of at most a few minutes, except in very mountainous terrain which is relatively rare. With all the other features I’d like to add, I abondoned the idea. But it would definitely be cool. 🙂