-
Notifications
You must be signed in to change notification settings - Fork 57
Minimum Safe Distance Symbol Issues #240
Comments
@joebayles This is a CBRN symbol. The doctrinal reference / requirement source for this symbol is FM 3-11.3 / MCRP 3-37.2A / NTTP 3-11.25 / AFTTP(I) 3-2.56 "MULTISERVICE TACTICS, TECHNIQUES, AND PROCEDURES FOR CHEMICAL, BIOLOGICAL, RADIOLOGICAL, AND NUCLEAR CONTAMINATION AVOIDANCE". This symbol is described on page I-3 "Figure I-1. STRIKWARN Plot Showing MSD 1 and MSD 2, Single-Burst"; I included this figure and the NATO one in the CP that removed the doctrinally incorrect third ring. Note this symbol is specifically for a Single Burst. The symbol for Multiple Bursts, is on page I-4 of the same document , "Figure I-2. STRIKWARN Plot Showing Multiple Bursts". The multiple burst symbol is not supported in MIL-STD-2525. WRT issue # "2. There is no mention of how the radii are identified or communicated, except "As defined by operator". This for automated systems, this symbol is rendered upon the receipt of a Strike Warning (StrikWarn) message; USMTF, VMF, ADat-P3, ABCS xml schema instance, etc. The purpose of this message is "To transmit information needed for friendly forces to take safety precautions against the blast effects of friendly conventional and nuclear bursts". The message provides the data required to render the symbol - center point and two distances, one for each radii. If contamination is detected after the burst then a separate action would generate one or more contaminated areas. Fire Support C2 systems when planning fires often use a collateral damage assessment tool (most are classified) which uses a variety of inputs, to include point of impact, trajectory, munitions specific effects data, elevation data, and vegetation and man made features. Of the outputs I have seen, none have been circular. Agree a CP is needed to clarify draw rules; I'll draft one. Since we are past the CP cut off date for new CPs to be included in 2525D Ch1, I'll do this as a modification to the approved CP. Your thoughts? |
Thanks for the clarification @ottenw. Re: STRIKWARN, understood. In this instance, I think we're good as long as the draw rules are up-to-date. Now, I understand the STRIKWARN will carry two numbers (in hundreds of meters), which is the radii of each MSD. @abouffard, @csmoore, @Dbarnes1 , we need to ensure that we build those two attributes into our schema to receive the message properly. Re: MSDs/REDs, understood. I am operating off of a pencil-and-paper, maneuver-planning understanding of Fire Support. Would we still want to standardize that symbology? Seems useful to me. Let's make sure to divest this part of the conversation from this issue and keep it focused on STRIKWARN MSDs. I'll copy your comment here: #241 |
@joebayles - what two attributes? if you mean radius1, radius2 - these are already defined by the points |
@joebayles @abouffard - please see attached draft / proposed change one to the CP. Your thoughts? |
@ottenw 👍 |
My question was answered. Closing this issue. |
After discussing the issues rendering Minimum Safe Distance Zone (25272100), I believe a CP should be drafted to bring clarity to this symbol. Understand that the design and intent behind this symbol is to render two concentric circles around a fixed point denoting minimum safe distance of a CBRN nature. These safe distances should not be confused with Fires control measures (i.e. for indirect fire and air to ground engagements). The implication from the Orientation guidance is that it is more like CBRN safety zones, like this guidance from the EPA: http://www2.epa.gov/emergency-response/safety-zones.
The implication (especially with the removal of the 3rd ring in #190), is that the inside of circle 1 is the Hot Zone, the inside of circle 2 is the Warm Zone, and anything outside of circle 2 is the Cold Zone.
Given all of the above, I believe the following issues need to be addressed:
I suggest that a CBRN-type command (MSCoE CDID?) be asked for clarification and:
@ottenw, please weigh in.
#190
Esri/military-features-data#166
The text was updated successfully, but these errors were encountered: