Pablo's Mission Planning Website

Home Links Tips Downloads MPSSF Tips

Greetings Mission Planners,

A problem has been found during testing of PFPS 3.3.1.  FalconView's Chart Update (Tools - Data Adminstration - Chart Currency - Chart Update) only updates NAVPLAN (JOG-GNC), TLM(1:50K and 1:100K), Day LFC/TFC Charts and CIB Imagery.  Chart Update will not replace outdated  Night LFC or City Graphic Charts.  When you get a new monthly LFC/TFC CD or a new City Graphics CD you'll need to manually delete old chart coverages then copy the new data from the CD.  Annoying?  You bet!   As I mentioned a few weeks ago, the Chart Update Tool won't update Miscellaneous Map files (1:200K, Military Installation Maps etc.) either.

Despite the slowdown in news over the holidays there are still some interesting facts available.  The USGS has procured extremely high resolution imagery over major cities and made it available on the internet - that is they've made most of the information available.  As this story in the Philadelphia Inquirer shows, some of the imagery has been fuzzed to hide some features.  You can download the data and with varying amounts of work you can view it in FalconView.

The image above is being displayed in FalconView 3.3.1 which adds additional scale "bins" for high resolution GeoTiffs - in this case the image is being treated as a 0.3 Meter GeoTiff while the highest resolution bin in FalconView 3.2 and 3.3 is 1 Meter.  Looks like they fuzzed the sides as well as the roof.

This image shows the limitations of FalconView's 256 color map display.  You'll note some artifacts on the roofs of the buildings and in the grassy areas that aren't present in the original image.  

NOTE:  After this email I'll be replacing all the "@nima.mil" addresses with "@nga.mil".  FYI I have 43 subscribers from NGA including LtCol Gus Luzzi.  Hope your still out there somewhere sir...

Mission Planning Tip: Excel2FV Map Path Scrubbing

FalconView's Map Data Manager handles most things very well, but there are a few situations that can reduce it to common cluelessness.  Scrubbing your map paths with Excel2FV will help avoid these common pitfalls:

Pitfall 1 - Read-Only Files:  When you use FalconView to load and move map files they'll never get marked as "read-only", but somehow read-only files seem to end up in some map data paths.  How does it happen?  When people get smart on map data they'll figure out what files go in which folder and sometimes will manually copy (using Windows Explorer) map files from a CD.  In Windows 2000 (and earlier OS Versions) this copied files from the CD to the hard disk marked as "read-only."   FalconView will give cryptic errors when you try to delete read-only files or when a Chart Currency Update tries to replace an outdated (but read-only) RPF frame file.  When you scrub a map path you'll reset any read-only file to a normal read/write file.  There is no reason why you'd want to mark map files as read-only.  If you're concerned about users deleting map data put it on the network on a 'read-only' path.

Pitfall 2 - Multiple RPF files:  FalconView 3.2 and 3.3 have a disturbing habit of copying multiple RPF (CIB and CADRG) frame files covering the same area into the same path.  Even worse, when there are multiple RPF file versions FalconView will always show the oldest (i.e. the outdated) data.  When you scrub a map path you can delete the outdated frame files and configure FalconView to regenerate coverage for that path the next time its started. 

The Map Path Scrubber is built into the latest version of Excel2FV.  You can download the newest version from http://home.earthlink.net/~goose08/.  Open the Excel2FV Word Document (ensure Macro Security is set to Medium and that you've installed PFPS Update) and click on the bottom button:

You'll see the buttons from the previous "repair" section along with a new button to scrub a map data path:

Pressing the Map Path Scrubber button will bring up the Scrubber Menu:

You can select any read/write map data path on your system and choose to remove "read only" attributes and duplicate files.  Alternately you can choose to only do one or the other (although I can't think of a new reason why).  As a path is processed you'll see a dialog documenting how many files have been checked and how many file problems have been fixed:

Before any duplicate files are deleted you'll get the chance to agree or cancel the deletion.  As you remember, each RPF (CIB and CADRG) frame file name has a digital version encoded in the filename.  For CADRG the filename's (as defined by MIL-PRF 89038 and Amendment 2) are "fffffvvp.ccz" where "fffff" encodes a geographical location, "vv" encodes a digital version, "p" encodes the file's producer, "cc" encodes the chart type and "z" encodes the RPF zone.  CIB filenames (as defined by MIL-PRF-89041, Amendment 1 and Revision A) are encoded as "ffffffvp.ccz".  The differences from CADRG are one additional character to define location and one less character to define digital edition (the extra character allows CIB to define higher resolution products like 1 Meter or even 0.5 Meter CIB while the maximum resolution for CADRG is 1:8K).

Keep in mind that none of this would be possible without the forethought that went into creating the standards for RPF, CIB and CADRG in the mid 1990s.  The CADRG and CIB standards were designed from the outset for automated updates and currency tracking (as implemented in programs like FalconView).  No other Military or Civilian raster (GeoTIFF, NITF, MrSID, GeoJPG2000, dppdb, Imagine) or vector (VPF, Shape, Digital Line Graph, ArcExport) standard provides these features.  Why not?  These features are absolutely key for Military Operations but are of little concern to most other users.  RPF products require a lot of work during production, but the alternative is a lot of work by every data consumer.  The Military "geospatial" customer doesn't know what "geospatial" means - they use words like "target", "infil", "employment" and "huah".  We depend on the experts to encode information in standards based products.   The data must be there, be current, be seamless and be "invisible" (i.e. "don't know how it got here, don't know how its stored, don't know how its managed, don't know what the filenames are etc).  When people have to stop doing their job to think about Geospatial Data we've failed. 

Paul