See flowchart below...
All you have to do to ammend your forecast is use the forecast submission again! The code will overwrite your old forecast(s) as long as the new one is still before the time that it was due (usually 1730Z). You can ammend your forecast as many times as your heart desires.
This is a complicated problem. First, I will lay out the easy stuff, then I will lay out some more difficult scenarios.
If, when you filled out your forecast, you entered a town/city in the form. That can be used to correct the issue by contacting the webmaster/admin.
If you didn't fill out the city/town of your target location... there is nothing that can be done to remedy the issue. This is why adding that information, though optional, is extremely important!
This is commonly caused by "fat fingering" the longitude or latitude in some way. The webmasters sometimes catch these errors and correct them. This is especially important because reentering verification for a forecast is a time consuming process. However, the bulk of this responsibility is on the forecaster to quality control for themselves (or their friends/colleagues).
Okay, so here is the complicated scenario...
Let's say there is a 10% risk in central Nebraska near a triple point, with a heavily capped dryline extending south to Texas (2%). Let's say a forecaster enters an incorrect latitude for their forecast and ends up with a forecast point in Oklahoma (all by themselves). Morning convection destroys the environment in NE... but one cell manages to break the cap in OK and goes bonkers and produces several tornadoes. This is what we would like to call "failing upward." So how would we handle this...
Forecast city is labelled Hastings, NE ~ Welp, sorry but you're getting moved back to Nebraska to fail with the rest of us.
Forecast city is left blank ~ congrats, you beat the system. By the grace of a higher power, you win and there is nothing we can do to take it away from you.
These contingencies keep people from essentially using a "fat fingered" forecast to have 2 forecast points. There is really no other feasible way to handle this until Google Maps let's us embed their api into forms for free.
We isolate SPC storm reports that mention landspouts or gustnadoes in their remarks and remove them from the scoring. However, if a landspout is deemed to be a threat by the NWS via tornado warning (< 15 miles), the tornado report will we used in scoring.
Most cases are easy to assess. The trick is, look at the two *highest* tornado risk areas and the majority of that shape to determine the forecast region. For example, if there is a 15% hatched risk such as in March 28th 2020, you can see that the risk stretches from the Great Lakes to Texas. By isolating the 10% and 15% tornado risk areas (where most people would cluster their forecasts), we can see that the forecast region would be in the Midwest.
Powered by Python! Eventually, we will post our codes to GitHub. The codes are... clunky, to say the least. Crowd sourced improvements may serve us well in the future!
You can travel to this link: Unsubscribe and fill out the form. It will likely take a few days to be removed from the email listserv, so you have some time to change your mind if you wish!
We take the average latitude and longitudes of everyone who forecasted (once they have been reprojected) and score it as if consensus is a real person.
Welp, you screwed up! Just kidding, send me an email and I can send you a fresh link!
There is a link to a form where you can report potential misconduct at the bottom of the homepage or you can use this link! Report Misconduct
Contact Kyle or ask one of the Discord moderators. We can probably set this up for you as long as there is sufficient interest!