Pablo's Mission Planning Website |
Greetings Mission Planners, Well if you didn't make it out to the Mission Planning Users Conference in Las Vegas then you missed a great time. Over 2,000 attendees from all four Services, other government agencies and Allied Nations made for a great mix. The food was a lot better this time too. If you attended and didn't fill out the Feedback Survey in Las Vegas you can do it on line here. I expect many of the presentations from the general session and side meetings to be available on line within a few weeks. The March AMC Valid Dropzone Database contains some serious errors. More details are available on the Mission Planning System Support Facilities Website here. If you download your DAFIF directly from NGA then you may have missed the arrival of DAFIF Edition 8. DAFIF has moved to a DVD containing Edition 7 data , Edition 8 data and the MIDAFIF (Map Info DAFIF) and AVDAFIF (ArcView DAFIF) that used to come on a third CD. You still get 3 discs (Edition 6 CD, Edition 7 CD and Edition 7/8 DVD) so the case looks the same. More on this shortly. Recently FalconView has had problems opening some Shapefiles. The problem is caused by ArcView 9.x's new default to save Shapefiles in 3D - which FalconView 3.x can't read (4.0 does fine). Fortunately there's an ArcGIS Extension called ET GeoWizards that lets you save a 3D Shapefile in the older 2D format. These converted files open in FalconView w/o a problem. This is a "free feature" available in ET Geo Wizards demo version without registering or paying. Normally I don't get much into Near Real Time Threat info in the newsletter, but I can't resist passing on these tips I got from my friend Will. Even if you don't use the Birddog Tools (BDT), some of the info will come in handy for keeping your FalconView happy and healthy:
I've posted a new version of Excel2FV on http://www.mission-planning.com. In addition to several bug fixes I've added:
The image below shows three Air Traffic Control (ATC) tracks translated from an Excel Spreadsheet into a FalconView Drawing File: Mission Planning Tip: Vertical Obstructions Part IV, VO Wrapup Last time we talked about the Vertical Obstruction Database and NGA's new Vector Vertical Obstruction Database (VVOD) format. Since then NGA's new VOD website has "gone live" on the SIPRNET and JWICS. You can download VVOD, but until someone pays to get FalconView modified to display the data it won't do any good. Probably the most misunderstood fact about CHUM is how old the data is when it gets to your PC. For example the obstruction cutoff for the March 2005 CHUM was 30 December 2004 - 59 days before the CHUM became effective. That means that if you're flying with the March CHUM information on the 31st of March there'll be 90 days of obstructions that aren't on your chart. It's perfectly legal, but it ain't optimum. If you're proactive and updated with April ECHUM as soon as it was available then you'll still had about 75 days of unplotted obstructions when you performed the update. Why is the obstruction data so old? Well believe it or not, CHUM is more than just towers. A significant portion of the Vertical Obstruction analyst's time is taken up with CHUM items like the one below: You might not pay much attention, but that red airfield isn't from DAFIF - it's from the CHUM Manual. Clicking on it displays it's CHUM information: If you turn off the CHUM you can see the DAFIF airfield below: Of course DAFIF has a lot more information behind it than the CHUM airfield does: So why is NGA wasting so much time duplicating information that's already in DAFIF? Simply put, NGA's CHUM process is still oriented towards updating paper charts. In that world there was no such thing as DAFIF. The only way things got on the chart is when someone went through the CHUM book and makes the listed changes. NGA has asked for "relief" from double tracking these airports in DAFIF and in CHUM, but the Services have yet to agree. Removing DAFIF airports from the CHUM process will:
Hopefully the Services and NGA will agree to remove these airfields from the CHUM process today, and eventually remove them from the charts. It's no secret that the Airfield, Airspace and Navaid info on our charts is laughably out of date. Anyone who's depending on this stuff to navigate by or avoid a violation is setting themselves up for a Flight Evaluation Board (FEB). As one example, here's R4001B near Baltimore: The nice extension to the south is in DAFIF but not on the printed chart. Plenty more examples like that where trusting the chart will lead to a violation or worse. We don't want NGA to try to keep this stuff current (it's darn near impossible), we just want it off the chart. Since we've got DAFIF we don't want duplicate info (since it will inevitably get out of date) on the chart at all. NGA has also proposed extending the CHUM cycle to 56 days, double the DAFIF cycle. This would bring the DAFIF and CHUM cycles "in sync" (a long term goal for people who have to update multiple computers), reduce the number and expense of the CSD set and allow NGA's Vertical Obstruction Office to spend more time finding VOs instead of putting out CHUM Editions. As long as NGA figures out a way to keep VO data in the field less than 90 days old (the maximum age today) this should be all right. Currently NGA has 60 days with new VO data before it becomes "effective" and must be plotted on your chart. If NGA can figure out a way to cut this down to 32 days (a 28 day reduction, matching the extension from a 30 day to 56 day cycle) then the age of the oldest VO on your chart would remain the same. As a bonus the number of yearly CHUM updates would be cut nearly in half. Will any of this happen? Search me. Agreeing to reduce what NGA's required to put on a chart, reduce what NGA's required to put in the CHUM and extend the CHUM cycle is difficult for anyone to do, but it's very necessary. If we continue to require NGA to support a process designed for a paper chart world we'll never be able to move forward to the products we really need, i.e. charts that reflect the "facts on the ground" today. Paul |