Performance using countyID vs zoneID

[mre33]

I notice that the API alerts/active responds much faster when a zone is used instead of a county. I also notice that very few of the zone responses contain the flood alerts that are all around the Mississippi River at the moment. Even when the zone and county are basically the same geographic area, the county will show the alert while the zone(s) covering that county show nothing.

(1.) Are there any plans to improve the response time for alerts when a county ID is used?
(2.) Is there some difference in what type of alerts are returned depending on whether the call was a zone or county? If so, it that documented somewhere?

[StephenClouse]

The response times shouldn't be considerably different for either. Could you provide some URLs of the requests you are making so we can investigate further?

As far as the zone vs. county issue, the API is strictly adhering to what the original product declared. Some products are issued for public zones and some for counties. We do not currently have any mapping or equivalency between public zones and counties. So taking, for example, this flood warning:

MOC183-189-042128-
/O.CON.KLSX.FL.W.0106.000000T0000Z-000000T0000Z/
/SCLM7.2.ER.190501T1648Z.190606T0600Z.000000T0000Z.NO/
429 PM CDT Mon Jun 3 2019

The Flood Warning continues for
the Missouri River at St. Charles

This will show in the API for counties MOC183 and MOC189 as declared in the product's UGC header, but not for any public zone, even if those zones happen to be the same geographic area, since they were not explicitly declared in the source product.

We are looking at ways we could improve this, since it is a bit of a poor user experience. But we also want to be wary of "massaging" the data into something that isn't necessarily reflective of the original source data.

Our current recommendation, if you are pulling data for specific known geographic areas, is to pull alerts for both the county and the public zone. For specific lat/lon points, you can find the IDs of both via a /points query.

[mre33]

I will give you a couple of urls that I am using but the slow return of counties appears everywhere I have tried it. At the moment none of these zones or the county has an active alert.

https://api.weather.gov/alerts/active?zone=ALC003
On first response after the cache has expired the url above can take as long as 14 seconds to respond.

https://api.weather.gov/alerts/active?zone=ALZ262,ALZ264,ALZ266
This rarely takes more than 4 seconds even though it is checking all three zones in the same county as above.

I also have a friend in S. Carolina that discovered the same thing with SCC051. I have tested a few others and notice the same thing. County calls take much longer to respond than zone calls. Of course after the first access for the next 30 seconds the API will respond immediately.

Just my speculation is that maybe the alerts database is very large for counties at the moment because they contain virtually all of the flood warnings while the zones do not. Still seems a bit odd...

As far as calling both zones and counties, well, most of what I am doing is running web sites that call the API on demand and wait for the results. When it is taking 14 seconds to get a response that is not pleasant for a user. I suppose one could run a cron/cache in the background for some of what I am doing but that would slam your servers pretty heavy if all users adopted that method.

[StephenClouse]

Looking into this, we have found a performance regression that only occurs when a county zone is in the query. Short version, it ends up forcing a non-indexed query of the database, so that explains the big performance hit.

We're still looking into the best way to solve this.

[mre33]

Sounds good. I hope this issue can be solved and the performance improved for county queries. In my experience they seem to provide the most complete results for my purposes.

[StephenClouse]

We did rectify this issue for our next software update in July.