This is a bit of a coming out party. So, noisemakers and party hats all around!
Last month I put up a post about the Situational Awareness Map, highlighting some changes I had made, and some future plans. Well I'm happy to announce that the map is now out of beta development and is available for general use. A lot of the changes are evolutionary, not revolutionary. But the changes and improvements are significant enough that a quick overview is warranted.
Perhaps the biggest change is that the map is now focused on the entire southeastern US, not just Georgia. I've talked with key users of this map for some time and the thought is that a regional focus makes more sense; weather systems and radio signals don't respect political boundaries, and we are often called on to support our fellow ARES members in adjacent states. But how do we define 'southeastern US'? Well, the most logical way is to follow FEMA, and use FEMA Region 4 as the definition. This makes a lot of sense since organizations like SHARES, DHS, CISA, NOAA, the Army Corps of Engineers and other federal agencies structure their disaster response frameworks in relation to FEMA regions. So FEMA Region 4 it is!
Other key improvements come in how the map (data) layers are structured in the map. Data structure is tightly focused around individual states. This give each state the ability to focus/display only the data pertinent to their states. There is a lot of regional/national data in the map, but that's only for map layers that by design must span the region. The best example is NOAA weather radar. This is a national-level data feed and it is impossible to segregate it out by state.
Another serious issue that is starting to push to the forefront is map performance. At this time there are over 45 separate data layers in the map, everything from severe thunderstorm warning polygons to PSAP 911 service areas. Every data layer, even if it's turned off, imposes a performance penalty in the map. Let's use the HIFLD fire/EMS station dataset as an example. This is a national-level dataset with tens of thousands of point (station locations). Before the map can display just fire stations in state of Florida it must first pull across the entire dataset, apply a dynamic filter against the data to select just fire stations that fall inside of Florida, apply a complex symbology rule against those points and then dynamically display them in the map so the fire station symbols remain the same size regardless of the zoom level the user selects. That's a lot of work to ask a web browser to handle. Multiply this one example by 45 or so data layers and you start to understand why map performance is an issue that must be carefully managed. This map is starting to push the performance limits of what Chrome, Firefox and Edge can reasonably handle. For that reason I've imposed some rules that users need to be aware of:
- With the exception of the Severe Thunderstorm Warning and Tornado Warning polygons (provided by NOAA) all other data in the map is turned off by default. When the map opens, it opens to a blank screen that shows just the state and county outlines. It's up to the individual user to tailor the map to his/her needs by turning on the data layers they want. Therefore it's very important that you review the available map layers and practice turning layers on/off
- Requests to add new data layers will require some serious justification from the requester. You will have to provide a compelling operational need for the data layer you are requesting. Remember, every data layer imposes a performance penalty. During real-world events like hurricane disaster response I'll add whatever data is needed without too many questions, but for non-operational use I'll have to be very selective about what gets added
- Data layers that don't get used will get dropped. I can track individual data layer requests, and if I see a particular data layer just isn't getting used, especially if it's a national or regional layer, it'll get deleted from the map
W8BYH out
No comments:
Post a Comment