"Too Much" Lead Time?

[Mike Smith]

Lanny,

So you are still beating that dead horse?

Tom Wolfe never rode a Mercury capsule but it didn't stop him from writing a highly acclaimed, award-winning book ( The Right Stuff) about the Mercury program and what it was like to ride in a capsule.

Erik Larson wasn't even alive when the 1900 Galveston Hurricane occurred but it didn't stop him from writing a gripping account of the storm in Isaac's Storm.

I interviewed more than 25 people for the book and traveled to four cities during the writing process. I was in Greensburg multiple times while writing the book. The people of Greensburg and city officials seem to have no problem with my account of the storm.

And, yes, I visited New Orleans and did interviews there.

As to not PM'ing this, since you made your unhappiness with me public, why would I answer your accusation in private?

Mike

 

[Lanny Dean]

...As to not PM'ing this, since you made your unhappiness with me public, why would I answer your accusation in private?Mike

Because this back and forth is taking away from the discussion and thread at hand and because I felt it was the right thing to do. I was simply trying to help keep "our" noise away from this thread if possible as I was actually enjoying the topic.

CAN WE GET BACK TO THE TOPIC AT HAND???

 

[Dave Rennie]

Just as weather radios have advanced through the use of S.A.M.E. capabilities, I think warning technology could advance further through the use of GPS-enabled cell phones, especially in the smart phone arena. As more of the general population moves to smart phone use, their capabilities could be exploited to provide individualized warning capability through a joint effort between the NWS and cell phone providers (or app developers).

For example, if the NWS issuance of a tornado warning included: (1) Current tornado location via LAT/LON; (2) Direction of travel; and (3) Speed of travel; then a smart phone app receiving this information could determine, based upon the phone's current GPS location, whether a warning was required and, if so, what kind of textual warning statement to provide, such as: "TORNADO WARNING....Tornado located 12 miles southwest of your location at 1:30 pm, moving northeast at 50 miles per hour, expected to arrive at your location in 15 minutes - 1:45pm....TAKE COVER NOW!"

Such a system could enhance public safety while providing more specific information, upon which the public could base their responses. Just a suggestion.

 

[Tim Stoecklein]

I think that statement could be taken several ways. I personally took "moment by moment" to be through the eyes of a meteorologist (data interpretation, etc). I haven't read the book and could be wrong... but that's my first interpretation.

This was my interpretation BEFORE reading the book, and AFTER. Someone stated earlier, "...and I hope more people will post!" about the original topic.......I'd like to, but I'm having a hard time stepping into the arena without getting a shower from the pissing contest underway.

Any chance we can get back to the original topic?

 

[rdale]

For example, if the NWS issuance of a tornado warning included: (1) Current tornado location via LAT/LON; (2) Direction of travel; and (3) Speed of travel; then a smart phone app receiving this information could determine, based upon the phone's current GPS location, whether a warning was required and, if so, what kind of textual warning statement to provide, such as: "TORNADO WARNING....Tornado located 12 miles southwest of your location at 1:30 pm, moving northeast at 50 miles per hour, expected to arrive at your location in 15 minutes - 1:45pm....TAKE COVER NOW!"

Great idea, and some apps do at least a rudimentary process similar to that. But -- the clincher -- something like that costs money. You'd have to put a LOT of time and effort into developing 1) the program to do it and 2) the app to run without interfering with other phone features and battery life 3) the outgoing communications to send warning info to phones and 4) tracking the phone so you aren't alerting the same phone 8 times as the driver zigs and zags around town. Which goes back to point #1 - it's very very time and resource intensive.

Who is going to pay for that? You can't recover it with a $0.99 app because Joe Public isn't going to pay. He already gets the generic warning alert from AW or TWC's apps for free and is fine with that.

The cell phone company isn't going to pay. You can't do it by selling advertising as this would conceivably never be seen by the individual unless there is a warning.

Find a flaw in my notes and I'll start the development process now. I have much of that running web-based with First2Warn, so the background is there. I just can't find a model to get this in smart phones.

(Well, PM me if you have a great idea, I don't want Mike stealing it )

 

[Skip Talbot]

Great idea, and some apps do at least a rudimentary process similar to that. But -- the clincher -- something like that costs money. You'd have to put a LOT of time and effort into developing 1) the program to do it and 2) the app to run without interfering with other phone features and battery life

The code involved isn't too complex. You just need to parse the warning text and do some math between your current Lat Long and the tornadoe's current Lat and Long. Better than a textual warning, would be a realtime update of your proximity to the tornado and eta. I don't have any real experience programming mobile platforms, but conceptually I don't see why these would be such big hurdles to overcome in a smart phone app (maybe it doesn't have to run continuously).

I have most of the pieces in place right now to do that on my laptop for the custom radar software I'm developing, with the ultimate goal being to automatically control my camera systems.I think it could easily port over to a phone with the right tools.

 

[Dave Rennie]

No ideas here...just thinking outside of the box. However, it wouldn't surprise me to see such a system as I described someday, with all of your concerns addressed and dealt with. Given the rate of technological advances in our lifetimes, it seems inevitable.

 

[Mike Johnston]

Lanny, my use of the phrase "tornado forecast" was meant in the context of the warning itself as a forecast. Since the lead time is a function of the warning, hence the connection.

It just seems to me that longer lead times should be a natural progression from improving the accuracy of the warnings. Of course, the nominal lead times could be extended just by extrapolation of the warning in space and time but that would necessarily increase the false alarm rate. While I'm not sure about the "cry wolf" effect, I do believe complacency can be an issue and too many false alarms only exacerbate this problem.

In the instant St. Louis case, Mr. Farley's post above provides some relevant insight. Sounds like differing local policies on when to "sound the alarm" had an impact. I'm not sure if the NWS provides any formal or informal guidance to local authorities on this issue? Perhaps someone here in the EM business could chime in and enlighten us on this.

 

[Lanny Dean]

Lanny, my use of the phrase "tornado forecast" was meant in the context of the warning itself as a forecast. Since the lead time is a function of the warning, hence the connection.

It just seems to me that longer lead times should be a natural progression from improving the accuracy of the warnings. Of course, the nominal lead times could be extended just by extrapolation of the warning in space and time but that would necessarily increase the false alarm rate. While I'm not sure about the "cry wolf" effect, I do believe complacency can be an issue and too many false alarms only exacerbate this problem.

In the instant St. Louis case, Mr. Farley's post above provides some relevant insight. Sounds like differing local policies on when to "sound the alarm" had an impact. I'm not sure if the NWS provides any formal or informal guidance to local authorities on this issue? Perhaps someone here in the EM business could chime in and enlighten us on this.

I agree 100%. I am sorry I didn't really understand your original post. And as far as differing local policies I couldn't agree more. Makes a guy wonder if someone thought to themselves "ohhhhh...we sounded the alarm to quick"! Either way and whatever the reasons it certainly caused confusion it appears.

 

[rdale]

The code involved isn't too complex. You just need to parse the warning text and do some math between your current Lat Long and the tornadoe's current Lat and Long.

I have the code to do that already. That's not the concern...

but conceptually I don't see why these would be such big hurdles to overcome in a smart phone app (maybe it doesn't have to run continuously).

If it doesn't run continuously, how would it know when a warning is issued for the area you are in? If it's going to be checking a server, you either rely on the open, free ones (not an option for life saving data) or host your own (incredibly expensive if 100 million smartphones are going to be pinging it.) If broadcast all warnings, it's going to be processing a ton of data on big weather days which will kill the battery plus you have the problem with moving (i.e. if I'm in Lansing when the warning is for Jackson, my phone is going to ignore it, yet if I drive to Jackson while the warning is in effect is the process continually saving all active warnings to see if I'm in the area? Even bigger battery drain.) If you are going to only look for warnings in your locality, how does the host server know where the phone is unless it's running 100 million processes to determine which warnings are valid?

Again, I'd love to develop this further and I'll give anyone a cut since the tools are already on my system. I just see too many variables right now that I can't find an answer to.

I think it could easily port over to a phone with the right tools.

If you can figure out a way to port it to 100 million phones, I'll just ask for 50% of that $1 per user annual fee

 

[Greg Stumpf]

Of course, the nominal lead times could be extended just by extrapolation of the warning in space and time but that would necessarily increase the false alarm rate.

Hence the reason (we believe) for adding probabilistic information to warnings. Provide extended lead time warnings but with lower probability. In a perfectly reliable system, the probability of verification should equal the probability of a hit. Or the probability of the event not happening equal the false alarm rate. So extended lead time warnings should be expected to verify fewer times.

So, why issue warnings with longer lead times and lower probabilities? For those folks that need longer lead times that decide for themselves to take action even at a lower probability because their cost-loss ratio is lower, in other words they'd rather be safe than sorry. An example is given in one of my earlier posts.

The usual disclaimers: 1) Probability numbers don't even need to be communicated in the warnings to make this work. They can be expressed in different ways (e.g., threat levels). Or they can be used to provide the custom warning threshold for that specific user. The warning system that they use (perhaps provided by a private vendor) would alert them at lower probability thresholds, and thus they would get their alerts earlier. 2) With a longer lead time warning, time of arrival and departure information for that specific location is required.

 

[Skip Talbot]

If it doesn't run continuously, how would it know when a warning is issued for the area you are in?

It could check once a minute (or a shorter or longer duration depending on which works best)?

If it's going to be checking a server, you either rely on the open, free ones (not an option for life saving data) or host your own (incredibly expensive if 100 million smartphones are going to be pinging it.)

Sure, disclaimer that its not for life saving information. I doubt 100 million phones are going to be using the app, and if they are, let them. Put all of the load on the NWS servers. Let them deal with the traffic. If they can't handle the traffic, than they need to upgrade their hardware or bandwidth. That's the whole point of their website anyway isn't it? Providing information to everyone? They are already sending out radar to millions of people, which uses considerably more bandwidth than a few text warnings.

If broadcast all warnings, it's going to be processing a ton of data on big weather days which will kill the battery

Fifty tornado warnings is what, a few kilobytes? You don't have to check and parse all the warnings every second. The battery should last a lot longer than using apps like Angry Birds.

plus you have the problem with moving (i.e. if I'm in Lansing when the warning is for Jackson, my phone is going to ignore it, yet if I drive to Jackson while the warning is in effect is the process continually saving all active warnings to see if I'm in the area? Even bigger battery drain.)

Sure, it'll save the warnings, and when it checks it again it will see you are now closer to a particular tornado. Your location to any particular warning wouldn't put more strain on the software since its making that check every time anyway. You could probably make the software a little smarter by filtering out warnings with simpler criteria than computing your distance from the tornado for each one, or by varying the frequency of checks based on your location, speed, or warning count. I still think the simple text parse and check for proximity is not a big deal though.

If you are going to only look for warnings in your locality, how does the host server know where the phone is unless it's running 100 million processes to determine which warnings are valid?

Send 'em all! NWS doesn't need to check every client's location, just send the whole warning sheet out. They'll need a bandwidth upgrade when we get to 100 million users, but so what? We'll just pay some taxes.

If you can figure out a way to port it to 100 million phones, I'll just ask for 50% of that $1 per user annual fee

Heck, I'd just release it for free. Seems like an app I could tinker with over a couple weekends and just throw out there if I had a smart phone to play with.

 

[Dave Rennie]

I don't think such a system would need to update on the users' phones continuously, only if conditions changed, ie. the tornado changed direction or speed, or dissipated. Otherwise, the original warning... it's going to be here at 1:45pm ...would stand.

Of course, if you had someone who used the initial warning to hop in their car and speed >toward< the tornado, then they're on their own! To provide updated warnings for such users ("Airborne condition imminent!") would be a waste of resources.

 

[rdale]

I don't think such a system would need to update on the users' phones continuously, only if conditions changed, ie. the tornado changed direction or speed, or dissipated. Otherwise, the original warning... it's going to be here at 1:45pm ...would stand.

Right, but if the warning is for the county next to me and it's disseminated, my phone will see that it's not my county and drop it. If my travels take me into that county, if the app shuts down as Skip noted then it would "forget" that warning and I wouldn't get the notification.

 

[Mike Johnston]

Hence the reason (we believe) for adding probabilistic information to warnings. Provide extended lead time warnings but with lower probability. In a perfectly reliable system, the probability of verification should equal the probability of a hit. Or the probability of the event not happening equal the false alarm rate. So extended lead time warnings should be expected to verify fewer times.

So, why issue warnings with longer lead times and lower probabilities? For those folks that need longer lead times that decide for themselves to take action even at a lower probability because their cost-loss ratio is lower, in other words they'd rather be safe than sorry. An example is given in one of my earlier posts.

The usual disclaimers: 1) Probability numbers don't even need to be communicated in the warnings to make this work. They can be expressed in different ways (e.g., threat levels). Or they can be used to provide the custom warning threshold for that specific user. The warning system that they use (perhaps provided by a private vendor) would alert them at lower probability thresholds, and thus they would get their alerts earlier. 2) With a longer lead time warning, time of arrival and departure information for that specific location is required.

Greg, how do you envision such a concept operating in practice? Are the various warning areas and probabilities dilineated by a computer algorithm or with human analysis? What about refreshment - at fixed intervals or at variable intervals based on actual development of the storm, etc.? How about overlap of 2 or more storm tracks - simply an additive probability? I can think of 1001 questions on this topic; it just seems the concept would need to be thoroughly vetted to demonstrate superiority over the current warning system.