|
|
|
|
|
|
by drusenko
544 days ago
|
|
|
I was initially very excited because this data is not nearly as it should be, especially historical forecasts. However, your pricing model seems to seriously limit the potential uses. I would imagine that most people who have a serious interest in weather forecasting and would be target users of this service don’t think in terms of number of points but rather in lat/lon bounds, resolution, and number of hours & days for the predictions. I imagine they would also like to download a GRIB and not a CSV. Your pricing for any large enough area to be useful presumably gets somewhat prohibitive, eg covering the North Pacific (useful for West Coast modeling) at 0.25 deg resolution might be ~300k data points per hour if I am doing my math right? |
|
|
I tried to tie the pricing with the amount of processing that the API needs to do, which is closely related to the number of grib2 files that the API needs to download and process in order to create the response. And it doesn't change as much wether I extract 1 point or 1000 points. But I thought I had to draw the line somewhere or nobody would ever pay for anything because the freetier is enough.
But I might make it same price for maybe chunks of 5000 or more points.
From the line of business I come from the main usage is actually to extract scattered coordinates (think weather where specific assets are, like hotels or solar panels or wind farms) and not whole boundaries at full resolution but it makes a lot of sense that for other types of usage that is not the case.
It is definitely in the roadmap to be able to select based on lat/lon bounds and even shapes. Also to return data not as timeseries but the gridded data itself, either as grib2 or netCDF or parquet or a plain matrix of floats or png or even mp4 video.