pirate-weather / pirateweather Goto Github PK

Hello! 👋 I'm just familiarizing myself with your project and I noticed in your docs:

Dark Sky provides both temperatureHigh and temperatureMax values, and since I am not sure what the difference between them is, the same value is currently used for both.

Indeed, this is confusing! The best (only?) explanation I've seen is here: https://status.darksky.net/2017/08/29/daily-updates.html -- I'll quote it here in case they take down their blog:

A longstanding complaint with the Dark Sky API is that we report daily temperatures differently than other services: we report the minimum and maximum temperature during a given date, while other services report the daytime high and overnight low. (Put another way, our service reports temperature extrema between midnight and midnight, while other services report extrema from dawn to dawn.) These two were typically the same for daily high temperatures, but typically off by one day for the daily low temperatures (which usually occur around dawn). To address this complaint, we have added two new fields to daily data points: temperatureHigh and temperatureLow, which match the calculation methods used by other weather services. (temperatureMin and temperatureMax are still supported, but are now considered deprecated.)

Interestingly, the official Dark Sky iOS app seems to use the (allegedly deprecated) min/max instead of the new high/low.

Their documentation also aims to explain the differences between the data points (a bit too succinctly for my taste) but it makes sense once you have the context from their blog post. I'll quote it here as well:

temperatureHigh: The daytime high temperature.
temperatureLow: The overnight low temperature.
temperatureMax: The maximum temperature during a given date.
temperatureMin: The minimum temperature during a given date.

To add some additional color, note that the AerisWeather API has a /forecast endpoint with "filters" which I found interesting in comparison: https://www.aerisweather.com/support/docs/api/reference/endpoints/forecasts/#filters -- so, I believe the including the mdnt2mdnt filter and then taking the minTemp/maxTemp would approximate the behavior of Dark Sky's min/max, for example.

As an aside, for a bit of background, this a point of contention with the more sophisticated users of my iOS weather app (https://helloweather.com) because the sources are inconsistent about when/what the overnight low temp is, and I really haven't found a great solution where all of the data sources we support are fully consistent. Instead, I tend to default to making our iOS app "look like" the data source's native iOS app. (Thus me noticing that Dark Sky's official app continues to use min/max even though they say it should be considered deprecated.)

Anyway, I'm not sure how this might impact your model (perhaps you'll choose to only support one or the other) but I figured I'd drop you a note since this confused me as well. Feel free to close this issue in any case, I wasn't quite sure where to post this info!

Hi, when you sign up for an api key it says subscription ends in 30 days. Does the Subscription auto renew or do you have to signup again every 30 days?

It would be nice if the summary field could be split into two summary fields with one being for daytime conditions and the other one for nighttime conditions. One of my main complaints about the summaries from DarkSky is that since they kept the summaries breif it would often miss out on large portions of the day depending on the forecast. Some examples

Foggy in the morning.
Possible light rain in the morning.
Rain and windy overnight.

Those summaries don't provide much information outside of those timeframes so you'd have to look at the hourly forecast anyway to get more information and having it split into day and night helps to solve that problem.

As for the existing summary/icon fields they could either be used to show a summary of the day like they are now or it could show the day information during the day and then swap to the night information at night. The first option is something weather.com does with their API so maybe that would be better?

Hello,

I wanted to report a couple discrepancies on what is being reported in Pirateweather versus AccuWeather.

Pirateweather is showing current wind speed at 78.62 mph (SSW). It is a bit windy today, but actual wind speed according to AccuWeather is only 7 mph (SSW) with Max Wind Gusts of 20 mph.

Pirateweather is also showing humidity at 76% and AccuWeather is only showing humidity at 68%

Temperature and Air Pressure look to be pretty accurate compared to AccuWeather

Just thought I'd share this with you.

Thanks,
Mike

As someone who signed up with the old portal I am wondering if I will need to migrate over to Apiable at some point. I know you've mentioned old keys will still work but I don't know if the old portal will be closed at some point in the future or will it work indefinitely.

I know I could signup for a new key on Apiable but then I'd get less calls per month and no dev access on the free Apiable plan. The lower number of calls doesn't bother me much but I'd like to keep my dev access but it isn't a huge loss if it isn't possible to keep dev access.

EDIT: What I have now is similar to the Keep this project going tier on the pricing page in terms of calls per month (30k vs 25k). I only just realized that you can over hover the names in order to see the number of calls per month you get and might be easier to replace a section with the number of calls you get since the hover isn't really intuitive.

I lost my API key and logged in. I clicked regenerate API key and all it did was delete the key. No new one was generated. I tried different browsers and different internet connections. The problem persists.

I then created a brand new account. I signed up for another subscription with a different email. Sadly the part of the page where the API key would be is completely missing. Here is what I see:

I wonder if https://pirate-weather.apiable.io/subscription/[redacted] is somehow not generating keys.

Thanks for releasing this! It's awesome!
Interestingly, I am running into an issue when querying data on June 30, 2022.

POST https://timemachine.pirateweather.net/forecast/[key]/28.92942579,-82.33328679,1656561600?&units=ca&exclude=currently,minutely,daily,alerts
>>
"Data for this date is not yet available, please try an earlier or later date"

POST https://api.pirateweather.net/forecast/[key]/28.92942579,-82.33328679,1656561600?&units=ca&exclude=currently,minutely,daily,alerts
>>
"Requested time too early, please use https://timemachine.pirateweather.net"

A few questions:

1. What is the rule of thumb for which api or timemachine should be used for a certain time span? Forecasts are in api and historical in timemachine?
2. Is there a better way of getting historical data for multiple years? I've been querying iteratively each unix date, but was wondering if there's a more efficient way as it takes hours for each lat/lon and takes up a lot of requests.

I was checking the API this morning and I saw a few parameters in the hourly section showing -0.0 as the value. The only ones I've noticed were precipIntensityError and uvIndex but it could be possible that there are others that can do the same thing. It might be worth going through and adding a check for any parameter that doesn't make sense to have a negative number to just set it back to 0.

Here is the block showing the issue with precipIntensityError:

        "time": 1659222000.0,
        "icon": "clear-day",
        "summary": "Clear",
        "precipIntensity": 0.0,
        "precipProbability": 0.0,
        "precipIntensityError": -0.0,
        "precipAccumulation": 0.0,
        "precipType": "none",
        "temperature": 24.73,
        "apparentTemperature": 27.61,
        "dewPoint": 13.16,
        "humidity": 0.48,
        "pressure": 1007.5,
        "windSpeed": 10.67,
        "windGust": 20.92,
        "windBearing": 294.94,
        "cloudCover": 0.0,
        "uvIndex": 1.52,
        "visibility": 16.09,
        "ozone": 323.5

Here's the one for uvIndex:

        "time": 1659322800.0,
        "icon": "cloudy",
        "summary": "Cloudy",
        "precipIntensity": 0.0,
        "precipProbability": 0.0,
        "precipIntensityError": 0.0,
        "precipAccumulation": 0.0,
        "precipType": "none",
        "temperature": 22.29,
        "apparentTemperature": 24.9,
        "dewPoint": 12.66,
        "humidity": 0.5,
        "pressure": 1005.0,
        "windSpeed": 13.58,
        "windGust": 27.9,
        "windBearing": 206.57,
        "cloudCover": 1.0,
        "uvIndex": -0.0,
        "visibility": 16.09,
        "ozone": 312.72

Did the threshold to show the precipitation icon on the currently block change? When I look at the API currently I see a precipIntensity of 0.36 so it should be showing snow as it's over the 0.25 threshold to show the snow icon. When I look in the hourly section it works like normal. My guess is that when you added the fallback to hourly data something messed up with the icon calculation in the HRRR domain?

Data from the API is below:

  "currently": {
    "time": 1677960000,
    "summary": "Cloudy",
    "icon": "cloudy",
    "nearestStormDistance": 0,
    "nearestStormBearing": 0,
    "precipIntensity": 0.36,
    "precipProbability": 0.25,
    "precipIntensityError": 0.0974,
    "precipType": "snow",
    "temperature": -0.03,
    "apparentTemperature": -1.95,
    "dewPoint": -1.09,
    "humidity": 0.93,
    "pressure": 998.9,
    "windSpeed": 5.736,
    "windGust": 12.15,
    "windBearing": 25.56,
    "cloudCover": 1.0,
    "uvIndex": 1.82,
    "visibility": 3.5,
    "ozone": 346.37
  },
...
    "hourly": {
    "summary": "Cloudy",
    "icon": "cloudy",
    "data": [
      {
        "time": 1677960000,
        "icon": "snow",
        "summary": "Snow",
        "precipIntensity": 0.2857,
        "precipProbability": 0.47,
        "precipIntensityError": 0.1053,
        "precipAccumulation": 0.2857,
        "precipType": "snow",
        "temperature": -0.02,
        "apparentTemperature": -1.95,
        "dewPoint": -1.09,
        "humidity": 0.93,
        "pressure": 998.9,
        "windSpeed": 5.74,
        "windGust": 12.15,
        "windBearing": 25.56,
        "cloudCover": 1.0,
        "uvIndex": 1.82,
        "visibility": 3.5,
        "ozone": 346.37
      },

Many thanks for the project and open sourcing your processing scripts.
I tried to dabble a bit myself before finding this project and only got as far as extracting and looking at the data in the grib files.
I was able to run the docker with your included scripts to download the data from s3 onto my machine.

Building

cd pirateweather/wgrib2/
docker build -t wgrib2 -f Dockerfile .
docker image list

Running

docker run --net=host \
    -v "D:\\WEATHER\\:/mnt" \
    -e bucket="noaa-hrrr-bdp-pds" \
    -e download_path="/mnt/data/efs1z" \
    -e temp_path="/mnt/data/tmp" \
    -e time="2022-12-30T15:45:00Z" \
    wgrib2 \
    /mnt/pirateweather/scripts/hrrrh_combined-fargate.py

I have a couple questions.

1. The timestamp input seems to determine the times that are downloaded, how do you normally specify this? The current time?
2. Do I need to run all scripts? or since I am in the US, can I just run the HRRR which I believe has most data (you note on the docs it doesn't seem to have UV, but that is ok for me currently).
3. If I need to run the other scripts, can this be done concurrently, or just sequentially?
4. The example run command puts files inside a efs1z folder. Is this a specific folder name? or does it have some meaning here? Should the other scripts be in a different folder?
5. I want to run the download on a cron job, could you explain how I should interpret this trigger table? Should I run HRRR every hour to get data, or just every 3 hours could suffice?

The one code I am trying to find is what maps the lat, lon to query these files. The docs say that this is a lambda function that does this and is relatively detailed on the process. Is this code public? If so could you point me in the right direction? Many thanks!

In the old portal, I can see my current API calls usage. I can't find the same number in the new APIable system.
Does that exist and I'm overlooking it?

This is not really an 'issue', just a heads-up and THANKS for providing a DarkSky-formatted API for weather enthusiasts worldwide.

I've done some mods to my existing DS-forecast.php script set (using the DarkSky API while it still is being offered to legacy users) to now use the pirateweather.net API instead and offer a multilingual forecast with icons for personal weather websites.

https://github.com/ktrue/PW-forecast
and
https://saratoga-weather.org/scripts-PWforecast.php

Best regards,
Ken

First of all thanks for providing an alternative weather API. Unfortunately, after spending $25 with the intention of evaluating this in my apps for a month, I had to switch away to another service (using WeatherKit) after just a few days. The following are all reasons why I had to discontinue using your API, and I hope this may illustrate items that you might want to address in case other developers have needs similar to mine.

1. Inaccurate high temperatures in the evening (I believe after 7 PM). The forecasts show a seemingly random (IE not the high for the current day or the next day) high temperature during the evening time for the current (zero index) day. This temperature appears to represent the highest temperature for the rest of the daily forecast range, as it is greater than the high for the current or next day. For example, today's high was only 62. Tomorrow's high is 68, the next day is 69. However the first entry in the daily->data array shows a high of 72.57. This appears to be the high temperature 3 days from now, and is grossly incorrect for the current day forecast.

2. API latency. The API response time I see, minimum, is over 1000 ms. This is far too slow for an API of this kind, and is probably the result of the on-demand AWS lamdba functions having to process into a massive dataset for each request. Sure this is convenient on your end, for scalability, ease of implementation and only paying AWS for the minimum processing you need, but it is at a performance cost for all end users. If you really want to provide nationwide coverage, then pre-generating static json in 3km grids would result in vastly faster response times, and if your service grows in use, will actually require less processing on average as well. Regardless, this latency is directly passed down to my app users (although I cache county-wide data in 15 minute intervals to save on API calls, so at least some of the requests are cache hits), and it is far too slow.

3. Cost. I already pay $100 a year for the Apple Developer Program, so basically I get 500k REST weather requests a month free. However even if I didn't, it would still only cost $8.33 a month for 500k requests purely to access weather from Apple. Pirate Weather costs $25 a month for 300k requests, which is 3 times as much for less requests. Further it isn't clear what happens when I exceed 300k requests, or how one goes about paying for a plan to get more than 300k requests per month.

4. There is no way (that I could find) to track my API request usage. Sure, I can try and count this on my end, but whatever the service itself is counting is what really matters, as that is the limit that, when exceeded, could immediately cause my app's weather to cease functioning for the remainder of the billing period.

5. The Minutely, Hourly and Daily "summary" is no longer a summary as it was in DarkSky, but is just a precipitation condition code, like "Clear" or "Rain". The "Clear" value is apparently used to represent any condition that is not precipitating. Thus overcast, foggy, cloudy, etc all has a summary of "Clear" which is highly inaccurate. Regardless, the summary fields were, for my use, the highest value piece of information in the entire forecast dataset (with the possible exception of the low and high temp). This is not generated by your API, so this cannot serve as a drop-in DarkSky replacement for me, which is how the service is advertised.

6. The code used by the API is not open source, as the true core of the implementation, which is whatever is generating the JSON output, has not been released. I believe this is the code that is in error or deficient as discussed above, and the lack thereof also prevents me from rolling my own internal processing of NWS data to pre-calculate the data I need instead of doing so only on demand. So I am unable to fix, enhance or increase the performance of this service. It just seems to advertise as an open source service when it isn't.

Since today, the API appears to give the forecast of the wrong location.

My command :

curl 'https://dev.pirateweather.net/forecast/<api-key-readacted>/49.4299653,7.7532999?units=si'

The return begins like :

{"latitude": 41.198161, "longitude": -73.3492245, "timezone": "America/New_York",

The returned location is the same, no matter what I query.

Instead of adding to issue #30 in the HA repository I'd create a separate topic about this.

It's been about 2 weeks since the 1.1.7 update on the dev API and it seems like the update hasn't been pushed live yet. I checked this morning and the main API is still on 1.1.6. Documentation will need to be updated here as well so just a reminder to do that at some point as well.

Loving the work @alexander0042 - great service. I had one oddity lately: cloudCover in currently seems to flip from 0 to 1 randomly, and any number in between. This is for SE England, a country which spends most of its time under cloud. At the time, it was cloudy, probably near 80% coverage, but the API said 0. An hour later it flipped to 1. It's now 0.93, which seems accurate, but there's little confidence given the number seems to change so often. Is that a bug or an error from whoever you're scraping?

Lastly, how often does this figure update in currently?

From the website pirateweather.net, the by-line reads:

A Free, Open, and Documented Forecast API

As of this writing, this project is, as far as I can tell, "closed source" (at least here in the US) since there is no indication about what license is that the project falls under. I don't see a LICENSE file for the project nor do I see license file headers in the source files. If I've missed these, my apologies.

"Open Source" has a generally accepted meaning of being able to use the digital artifacts for commercial purposes. The OSI and Wikipedia's entry on open-source licensing both articulate that commercial re-use is a (generally accepted) requirement of an "open source" license.

Was the intent to make this project libre/free/open source?

If so, could you indicate the license, either by providing a LICENSE file with the appropriate license or by putting a license preamble in each of the source files (preferably both).

If not, it might be good to clarify what the restrictions are to avoid confusion.

I noticed this yesterday on the dev API endpoint but it wasn't an issue until now on the production API. It looks like HRRR data isn't being integrated into the API and it's using the global GFS/GEFS API.

It must be an issue on PirateWeather's end as I see the 16z run of the model on AWS so there should be HRRR data integrated from a previous run being used still.

Hi, I'm running Pw within a WordPress site. Pw files have been uploaded and edited using a WordPress plugin "Advanced file manager" which is a bit like a Cpanel utility. I've run into 2 issues.

• I've changed the list of towns but it doesn't show on the website; it still shows the default list
• the above message ("Sorry.. the Pirateweather forecast is not available.") has now been showing. Is this a cache related issue (as maybe the first issue is?)

Hello there,

I've noticed that the PirateWeather API doesn't filter hourly data properly when a Unix timestamp is passed for a specific day. For instance, when I try to get hourly data for a specific day using the following endpoint:

https://api.pirateweather.net/forecast/{API_KEY}/28.906433,28.232497,1680008100?lang=en&units=si

It returns 48 hours of data, instead of the expected 24 hours for that specific day. In contrast, the same request made to the DarkSky API works as expected, returning 24 hours of data.

https://api.darksky.net/forecast/{API_KEY}/28.906433,28.232497,1680008100?lang=en&units=si

Thank you.

Hey, awesome project!

I loved Dark Sky because of their "summary" field. The summaries were usually pretty descriptive, something like "Rain (with a chance of 2-4 in. of snow) starting in the afternoon." Looking at the next seven days forecast, the summaries are more like something I can get from other APIs. The one for the next few days in my area just says "Clear", "Cloudy", or "Rain". Is there a plan to make this summary more descriptive?

Please ignore if the summary fields are identical and I've just not seen any descriptive ones yet!

I had posted this in this issue yesterday night but I figured I'd separate it out into a new thread to keep that discussion cleaner.

There's a bug with the new high/low setup for the current day after 6pm where it's using the highest forecasted temperature for the week rather than for the current day. Apparent temperature seems to be doing the same thing.

        "time": 1674622800,
        "icon": "snow",
        "summary": "Snow",
        "sunriseTime": 1674649875,
        "sunsetTime": 1674683974,
        "moonPhase": 0.14013338096939384,
        "precipIntensity": 0.927,
        "precipIntensityMax": 1.1494,
        "precipIntensityMaxTime": 1674702000,
        "precipProbability": 1.0,
        "precipAccumulation": 4.6349,
        "precipType": "snow",
        "temperatureHigh": 0.29,
        "temperatureHighTime": 1674900000,
        "temperatureLow": -9.96,
        "temperatureLowTime": 1674694800,
        "apparentTemperatureHigh": -17.87,
        "apparentTemperatureHighTime": 1674900000,
        "apparentTemperatureLow": -18.92,
        "apparentTemperatureLowTime": 1674694800,
        "dewPoint": -11.37,
        "humidity": 0.87,
        "pressure": 1000.84,
        "windSpeed": 25.74,
        "windGust": 57.69,
        "windGustTime": 1674702000,
        "windBearing": 77.96,
        "cloudCover": 1.0,
        "uvIndex": 0.06,
        "uvIndexTime": 1674691200,
        "visibility": 0.68,
        "temperatureMin": -9.96,
        "temperatureMinTime": 1674694800,
        "temperatureMax": -9.21,
        "temperatureMaxTime": 1674702000,
        "apparentTemperatureMin": -18.92,
        "apparentTemperatureMinTime": 1674694800,
        "apparentTemperatureMax": -17.87,
        "apparentTemperatureMaxTime": 1674687600

If I convert 1674900000 into date/time format I get this: Saturday, January 28, 2023 5:00:00 AM GMT-05:00 which isn't even remotely close to the current day so it shouldn't be used here. Before 6pm today it was showing -9 as the high temperature which is much more reasonable.

Using the current temperature would be the easiest solution but I know other sites after a certain time no longer give a value for the high temperature. I'm not sure if it's possible to compare to the previous value and take the highest value or maybe have a min/max since 7am and use that for the high temperature instead? Just throwing out ideas to see what might work.

Hi, I'm seeing different results in home assistant compared to Merry Sky despite using the same GPS coordinate. It's currently snowing in my area, but the home assistant integration shows it's cloudy/fog:

Merrysky with the same GPS coordinate correctly shows snow (https://merrysky.net/forecast/43.84239530,-79.4681130/ca):

When i hit login, it redirects me to auth.apiable.com, then back to https://pirate-weather.apiable.io/ but with an iss query param contain a URI that returns an error if i decodeUriComponent and go to it manually

I tried clearing the storage for pirate-weather.apiable.io and auth.apiable.io, but still nothing is different

Would it be possible to return a field with the elevation for the point that is forecasted? Thanks!

Minor issue here which did cause me issues in my iOS app. DarkSky API reported current wind direction (windDegrees) in whole integers. However your PirateWeather API is reporting windDegrees as a float with tenth of a degree precision. Tenth of a degree is surely far more precise than the actual accuracy of the data. I'm working around this server-side in my data processing to round it to an integer before my iOS app consumes it. This kind of issue can be common in very type-strict languages like Swift.

Just pointing this out if you are interested in the highest level compatibility with DarkSky.

I have done some research into converting precipitation to snow height for my app, and I'd like to share the formulas I arrived at - they might provide a bit better results than just multiplying by 10:

It's in swift, but the conversion should be easy - will this help?

public func kelvinFromCelsius(_ celsius: CGFloat) -> CGFloat {
	return celsius + 273.15
}

/// - Returns: kg/m3
public func estimateSnowDensity(temperatureC: CGFloat, windSpeedMps: CGFloat) -> CGFloat {
	/// interpolation at  https://docs.google.com/spreadsheets/d/1nrCN37VpoeDgAQHr70HcLDyyt-_dQdsRJMerpKMW0ho/edit?usp=sharing
	/// Ratio ranges:
	/// 3-30x: https://www.eoas.ubc.ca/courses/atsc113/snow/met_concepts/07-met_concepts/07b-newly-fallen-snow-density/
	/// 3-20x: https://www.researchgate.net/figure/Common-densities-of-snow_tbl1_258653078
	/// 4-20x: https://www.researchgate.net/figure/Fresh-snow-density-as-a-function-of-air-temperature-and-wind-for-the-3-options-included_fig2_316868161

	/// Equations: from ESOLIP, https://www.tandfonline.com/eprint/Qf3k4JEPg3xXRmzp7gQQ/full (https://www.tandfonline.com/doi/pdf/10.1080/02626667.2015.1081203?needAccess=true)
	/// Originally from https://sci-hub.hkvisa.net/10.1029/1999jc900011 (Jordan, R.E., Andreas, E.L., and Makshtas, A.P., 1999. Heat budget of snow-covered sea ice at North Pole 4. Journal of Geophysical Research)
	/// Problem: These seem to be considering wind speed and it's factor on compacting the snow? Is that okay to use? According to ESOLIP paper probably yes.
	var kelvins = kelvinFromCelsius(temperatureC)
	
	/// above 2.5? bring it down, it shouldn't happen, but if it does, let's just assume it's 2.5 deg
	kelvins = min(kelvins, 275.65)
	
	let windSpeedExp17 = pow(windSpeedMps, 1.7)
	
	var snowDensityKgM3: CGFloat = 1000
	if kelvins <= 260.15 {
		snowDensityKgM3 = 500 * (
			1 - 0.904 * exp(-0.008 * windSpeedExp17)
		)
	} else if kelvins <= 275.65 {
		snowDensityKgM3 = 500 * (
			1 - 0.951 * exp(
				-1.4 * pow(278.15 - kelvins, -1.15) - 0.008 * windSpeedExp17
			)
		)
	} else {
		/// above 2.5 degrees -> fallback, return precip mm (-> ratio = 1)
		/// should not happen - see above
		snowDensityKgM3 = 1000
	}
	
	/// ensure we don't divide by zero - ensure minimum
	snowDensityKgM3 = max(snowDensityKgM3, 50)
	
	return snowDensityKgM3
}

public func estimateSnowHeight(precipitationMm: CGFloat, temperatureC: CGFloat, windSpeedMps: CGFloat) -> CGFloat {
	let snowDensityKgM3 = estimateSnowDensity(temperatureC: temperatureC, windSpeedMps: windSpeedMps)
	return precipitationMm * 1000 / snowDensityKgM3
	
	/// This one is too much, with its 10-100x range
	/*
	 /// formula from https://www.omnicalculator.com/other/rain-to-snow#how-many-inches-of-snow-is-equal-to-one-inch-of-rain
	 let ratioBase: CGFloat = 10.3 + (-1.21 * temperatureC) + (0.0389 * temperatureC * temperatureC)
	 let ratio: CGFloat = clamp(value: ratioBase, from: 10, to: 100)
	 let snowMm: CGFloat = precipitationMm * ratio
	 return snowMm
	  */
}

On https://pirateweather.net/en/latest/, it says

a $2 monthly donation lets me raise your API limit from 10,000 calls/ month to 25,000 calls per month.

On https://github.com/sponsors/alexander0042/, it says:

$1 a month

This helps support this project, and will let me raise your API limit from 20,000 calls per month to 50,000 calls per month!

In the JSON for the API, the "nearest-station" value seems to be always set to zero. Is this just because the value is not being currently calculated, so defaults to zero? If so, is it possible to set the value with respect to the station providing the "currently" value set?

I know this has already been explained on the daily block but I was wondering when there's a mix of precipitation how it is determined which precipitationType is used for the hourly, minutely and currently blocks. I know DarkSky doesn't have any support for multiple precipitationTypes so I'm assuming that it chooses whichever one there's more of. So like if there's more rain than snow it chooses snow.

I know that some sites use the icon of the most prominent precipitation type and have the text say Rain and Snow or Rain/Freezing Rain as examples. So maybe something to consider when doing the text summaries.

I had posted this comment in the Weather Details thread but thought creating a new issue would be better. Are general API issues going in here or do you have a specific repo for it?

I just noticed that Fog seems to be overriding the rain icon as seen when you query here https://dev.pirateweather.net/forecast/[API]/44.6476,-63.5728?units=ca.

"time": 1648245600,
"icon": "fog",
"summary": "Fog",
"precipIntensity": 0.3549,

Shouldn't that be showing the rain/snow/sleet icon instead of fog? The hierarchy should be:

Rain/Snow/Sleet
Fog
Wind
Clear/Partly Cloudy/Cloudy

Also the icon is still broken on the front-end viewer:

Hello, I see in the documentation you mention using a nearest grid cell calculation to find the appropriate forecast based on the lat/lng params passed in on the request. Would it possible to include that in the response? For context, I am looking to use the API to handle requests from potentially any location and would like to add a caching layer between my app and Pirate Weather so that we don't make unnecessary of requests for what's effectively the same location multiple times within a given timeframe. So ideally I'd like to do something similar on my end and cache results for particular areas. ZIP codes are an option but vary in size pretty wildly and of course are only in the US. I could also do some kind of grid calculations on my side and use that but if there is an already available data point, that would be much easier!

Suggest adding a link to the hosted version of docs in the repo readme file instead of linking to the tutorial.

Background

I'm wondering what are the differences between this and the OpenWeather API? I use the API 2.5, which was mostly compatible with Dark Sky and limits the calls. They also have a newer API 3.0, which requires you to enter payment information even for the free plan. They will charge you if you go over your call limit, rather than returning a "limit reached" response. They also don't tell you how many requests you have left before hitting your limit.

Questions

1. Dark Sky returned a header in the response that tells users how many requests they have left. Does this API do that?
2. Do you require payment info for the free plan and charge for going over, or do you limit the requests?
3. Is there a per-minute rate limit to prevent a massive amount of rapid calls?
4. Do you plan to change the API or plans offered in a future version similar to what OpenWeather did, or do you plan to keep it the same as a stand-in for Dark Sky?
5. Do you plan to create and have a weather website available, like darksky.net used to be?
6. Fun question, do you support or plan to support emoji weather maps, like Dark Sky had?

Hey, I have been playing around with the API and i found something i think might be a bug :

When calling :

curl --location 'https://timemachine.pirateweather.net/forecast/API_TOKEN/50.0,14.43,1609452000?units=si'

I get the following daily data :

"daily": {
        "data": [
            {
                "time": 1609369200,
                "icon": "clear-day",
                "summary": "Clear",
                "sunriseTime": 1609444732,
                "sunsetTime": 1609474091,
                "moonPhase": 0.55,
                "precipAccumulation": 0.01,
                "precipType": "none",
                "temperatureHigh": 4.23,
                "temperatureHighTime": 1609419600,
                "temperatureLow": -1.96,
                "temperatureLowTime": 1609448400,
                "apparentTemperatureHigh": 2.77,
                "apparentTemperatureHighTime": 1609419600,
                "apparentTemperatureLow": -4.85,
                "apparentTemperatureLowTime": -4,
                "dewPoint": -2.43,
                "pressure": 968.97,
                "windSpeed": 1.97,
                "windBearing": 169.89,
                "cloudCover": 0.14,
                "temperatureMin": -1.96,
                "temperatureMinTime": 1609448400,
                "temperatureMax": 4.23,
                "temperatureMaxTime": 1609419600,
                "apparentTemperatureMin": -4.85,
                "apparentTemperatureMinTime": -4,
                "apparentTemperatureMax": 2.77,
                "apparentTemperatureMaxTime": 1609419600
            }
        ]
    }

The apparentTemperatureMinTime , apparentTemperatureLowTime are incorrect right? or am i misunderstanding that they should be UNIX timestamps?

@alexander0042 I'm getting a ERR_CONNECTION_REFUSED error when I try to query the API using both the dev and api urls. At first I thought it was the VPN so I tried disabling that and it didn't change anything.

I tried on a different device to see if it is just an issue on my computer but my phone is giving me the same error on WiFi and data. What's weird is that it doesn't seem to want to work in my browser but my Rainmeter card is working without issues. I also tried a different browser and it still doesn't work.

Is the API down or is it a weird issue on my end that's causing the issue?

EDIT: It works if I use Firefox but using a Chromium based browser doesn't seem to work. (Edge and Opera GX)

I've been sitting through a few days of stormy weather and the "nearest storm" function has remained at zero. Have you seen this before or maybe I have this setup incorrectly.

Looking at both the Daily and Hourly editions of the API, there are several precipitation sensor entities that are added. However, there is no clear cut one that shows the forecasted daily precipitation like how Dark Sky showed. Each precipitation sensor reports totally different data which I assume is based on some rolling time line, whether it be an hour, a 24 hr period, etc. I just want to know which entity I need to use to show the day's forecasted precip amount. Everything I try doesn't merry up with local forecasts or even MerrySky.

I'd assume " Daily Max Precip Intensity 0d" entity is the one; however, it's report data isn't lining up.

I know this is probably pretty picky and is something that has been bugging me for a while but some of the fields in the API either don't have any rounding or round to three decimal places instead of two.

I know that the precip fields outside of the daily block don't have any rounding applied to them and neither do the moonPhase on the daily block. windSpeed in the current block and I know that humidity and cloudCover on daily all around to three decimial points instead of rounding to three like the other fields do. Not sure about Time Machine but there is this comment from last December which points out the issue with the fields on Time Machine.

This obviously doesn't need to be very high priority but maybe something to work on in the background for a 1.2 release?

Hello,

Apologies if I missed this in the documentation. I noticed hourly time has a decimal while others do not. First, is this intended? If so, will the fractional part ever contain a non-zero value? Thank you.

{
      "time": 1674619200.0,
      "icon": "cloudy",
      "summary": "Cloudy",
      "precipIntensity": 0.0,
      "precipProbability": 0.0,
      "precipIntensityError": 0.0,
      "precipAccumulation": 0.0,
      "precipType": "none",
      "temperature": 32.52,
      "apparentTemperature": 27.42,
      "dewPoint": 29.37,
      "humidity": 0.81,
      "pressure": 1025.9,
      "windSpeed": 5.26,
      "windGust": 12.57,
      "windBearing": 259.29,
      "cloudCover": 1.0,
      "uvIndex": 0.0,
      "visibility": 10.0,
      "ozone": 311.93
}

I'm having trouble getting data from the timemachine API, and I'm not sure what I'm doing wrong.

Here's my API request: https://timemachine.pirateweather.net/forecast/<API_Key>/40,-88,-86400 to get the weather results for the past day.
And here's the response: "Data for this date is not yet available, please try an earlier or later date"

I've also tried various unix timestamps from the past week and few months, but I continue to get the same result.

Right now, I'm just trying this out in my web browser, but I would like to eventually use this with R in RStudio. There I'm getting a 500 error code and the same message.

Am I misunderstanding what the timemachine API is for or what timeframes should be available?

Any help or suggestions would be appreciated!

This issue is a continuation of the discussion from this issue Pirate-Weather/pirate-weather-ha#78 and since the discussion about adding other precipitation types.

I know that DarkSky is pretty limited when it comes to precipitation types (as well as icons) and I am aware that you want to keep things compatible with DarkSky and using flags/API options instead of breaking things. I know that WeatherKit has added in more icons/precipitation types to their API so maybe it's worth breaking things in this case?

Maybe the following could be added as precipTypes:

• freezingrain or ice
• hail
• mixed
• unknown or precipitation

I thought about adding in thunderstorm but since it isn't a form of precipitation I decided to exclude it. I was thinking about thunderstorms today and it would be a nice addition to the API. I know there are ways to forecast using Lifted Index/CAPE/precipRate/wind speed/etc. and using the Blitzortung (#6) to show in the currently section.

I would show the icon only if precipType is rain and it would always come after the precipType so if we use today as an example it would show Freezing Rain and Thunderstorms.

EDIT: I might be misunderstanding the Categorical Ice/Rain/Snow/Sleet that HRRR offers. During precipitation only one of those four values will be 1 and the rest 0? If that's the case then maybe we can not bother adding in mixed as a precipType

This isn't anything related to the API but with the recent updates the readmes for https://github.com/alexander0042/pirateweather and https://github.com/alexander0042/pirate-weather-ha are outdated and need updating.

• HA and this repo are still linking to weather.pirateweather which has been replaced with MerrySky
• This repo has links to the main website and the documentation website which are now the same url.

Shouldn't the terms of service be moved from the portal site to the main website? Otherwise they're hidden and cannot be found easily. Also maybe https://github.com/alexander0042/weather-vue and https://github.com/alexander0042/alexander0042.github.io can be archived since they're not in use anymore? Might be woth looking into creating an organization for the PW repos though I think it would break the links?

As a sidenote maybe Discussions could be enabled here? There's an option in GitHub to enable them and they're kinda like forums.

This is something I noticed last night and I'm seeing it again tonight. I'm assuming that this is an HRRR issue and not a pirateweather issue and if so then feel free to close.

Anyway I've noticed that the hourly temps seem to fluctuate overnight for seemingly no reason. Here's what pirateweather is showing for my location currently:

Here's Environment Canada's hourly forecast for comparison:

Not shown in the screenshot was HRRR forecasting a temp of -7 at 8pm. No idea why it's saying that 11pm is going to be the coolest part of the night when usually around 6am is the coldest part of the night.

Hi, I would like to show the forecast age in the UI (and ideally also delay the next request until the next model update), but I don't know how to interpret flags.sourceTimes. Could they be in a format that can be parsed unambiguously? Eg. ISO 8601, or unix timestamp (which is already used in forecast data)?

"sourceTimes": {
  "gfs": "2023-03-29 06:00:00",
  "gefs": "2023-03-29 00:00:00"
}

Low priority, but figured out I might ask :). Thanks, Tomas

I signed up via the Apiable service today and received an API key for Pirate Weather. However, when I make an API request (https://api.pirateweather.net/forecast/TOKEN_HERE/40.73,-73.93/ is what I've been testing) I get a forbidden response back, with the note that I should ensure that I'm properly subscribed to the endpoint, which I am. I regenerated and tried a different API key and waited several hours between attempts, but get nothing but forbidden responses.

I originally added this as a comment as part of a separate issue but I'm not sure if you saw it or not so I figured I'd just open it as a separate issue. I haven't found a global source of radar or the one that I found was four hours behind which isn't useful at all for the API.

The closest thing I could find to a global API is this from RainViewer might still be useful as it combines all available radar sources into one source. This from EUMETSTAT while not global might still be useful to cover areas outside of North America which aren't covered by RainViewer though it is lagging behind by about 30m.

From looking at both of the sites they don't seem to offer the data in formats that would be particularly easy for you to use/integrate. I know there's a way to convert GeoTiff files into a format that would be easier for you to use but I don't know how well the conversion works.

Get this from the API:

"latitude" : 38.729,
"longitude" : -9.153,
"offset" : -1,
"timezone" : "Etc/GMT+1"

The timezone is sort of correct (but would be better as Europe/Lisbon) but the offset is wrong. It should be +1.

It would be great if I could submit my local weather data to you from my Ambient Weather stations. Below is a screenshot of the my weather stations' custom server input screen.