Radioactive Fallout Model - Google Earth

by Buddy McCloskey     04/29/2010     Contact

We extended the results and theories beginning from the previous studies as follows:

World Trade Center Dust Bowl Analysis
Demolition Dust Model
Lidar-NED's City Building Extractions
Radioactive Fallout Model (Radfo) - Part I
Radioactive Fallout Model (Radfo) - Part II Winds

This web page is called RadfoGeo. We can use this name to represent 3 meanings.

1) RadfoGeo = Radfo-Google Earth Overlays
2) RadfoGeo = Radfo Geo-Graphics . Since many preprocessor programs and subroutines here were borrowed from that web site program.
3) RadfoGeo = Pronounced as Rad FoGEee Outlook with the GE representing Google Earth. You can think of this as a sort of fog, or fine dust particles that settle, even though the correct meteorology classification of fog is their droplets do not settle. However, here we have a definite ending or back boundary of this bad foggy layer.

1. Advantages for Adapting to Google Earth:

       A. Zoom Features:

To best display the Radfo plumes and Time Plots, Google Earth has these capabilities. We could zoom in and out - but in fixed increments or setting when viewing NYC06030307 from our last topic. Here, we have a smooth transition and changing features for an almost unlimited zoom ranges. Also, with the fixed framed, we lose track where we are unless we have a fixed reference point underneath the display. We do have a + at ground zero but away from ground zero is more important for traffic control. Actually, it appears that the towns are the base map, then the Radfo plume is a ground overlay, then the highways are the last overlay so always visible on top. When zooming in, more highways are displayed as well as the town features. If the Radfo plume, it's legend or other plot displays block the town features, you can use the fader bar or click the feature off and on to see the underlying features. Use the zoom bar or the +,- keys for slower zooming.

       B. Scaling Features:

If we move to the scale on the Radfo map frame, we lose the location and must return back. With Google Earth, the scale is always at the bottom of the screen so the location is not lost. When a scale is needed, you can use the hand pull mouse cursor and pull that portion of the map over the scale to see distances. You can rotate the entire map in order to align the features to overlap the semi-transparent scale. An example of this would be to see how far/fast the time plot advances within say a 3-4 color time interval to determine if the traffic speed is able to maintain a minimum speed to stay abreast of the advancing Radfo plume.

       C. Legend Access:

Just as in Google Earth's fixed to the screen scale, we have that option also. We may have the legend for the Radfo plume fixed to the screen also. We placed the color coded accumulated rads value (legend) in the upper left portion of the screen. It is placed there as not to interfere with their scale, data contributors and logos. Also, the NW corner is the rarest sumatted wind vector for most of the US. This way, you don't have to leave the local area display to go to the corner of the framed map to view the legend color and navigate back. Besides, the complete legend can be clicked on and off or faded down once your value is found. The way this was set up, you can expand the legend folder and click off any legend values. For instance, look at the display legend for 8000 Rads.

       D. Direction Access:

With the hand pull mouse cursor, you can move the map in any direction instead of using a scroll bar. To move the map NW-SE, you would have to use bottom & top scroll bars but here, just drag towards your desired direction. I'm sure you have all used this feature before in navigation map programs. However, you can use the mouse cursor to set the pic in motion. Sort of a fly by as they call it. The faster you pull the pic and release the click while in motion, the faster the fly by is in the direction the map is pulled. It is sort of a smooth continuous panning.

       E. Rotation & Zoom Bar Access:

This feature will be shown below in the NE corner of Google Earth screen capture *.jpg pics. You can rotate the map with the ground overlay by moving the North (N) point around the perimeter of a circle. With the fixed pic frame, you would have to know how much angle ahead of time where here, you continually adjust your rotation angle. The zoom bar is directly below this and both almost fade to invisible when not in use but return with the mouse over. It is barely seen here in this background pic to the right of the earth.

       F. Health Effects:

Another quick reference can be clicked on and off fixed to the screen display similar to the Rads Legend and Travel Time displays. These are screen capture pic files of the health effects from total accumulated Rads/Rems and seen in color coded Health Effects 1 and Health Effects 2 .

This shows the seriousness of the fallout radiation. Notice, the terms are in Rems (Roentgens Equivalent Man) instead of Rads. However, the terms are nearly equivalent so we don't have to distinguish between them. The colors of the text description and header values, are somewhat close to the Legend values color increments for the Rads display in the Radfo plume. It is used here as a quick reference.

2. GRID to PCX's Folder: GRIDPCXF.c

       A. Multi-PCX Files:

This program is a modification of PANGRID.c explained in 7.B.(2) of the last topic Radioactive Fallout Model (Radfo) - Part II Winds. Here we don't use a 1/2 overlap screen but the whole screen and screen capture every one if other than black. We also insert a subroutine to convert to the required units in a *.kml file for Google Earth, where kml stands for a universal geographic Keyhole Markup Language, similar to HTML. For the coordinate conversions, we need to borrow some of my subroutine programs from the original web site (Geo-Graphics) I used for merging Topo Maps.

With a grid of 4000 x 5000, (400 mi x 500 mi), it is too large a picture file to load using Google Earth. It would slow their whole display system down, even if it loaded. So, the grid must be chopped up into smaller pics. With much experimenting, the smaller the pics, the more accurate the mosaic due to a flat rectangular surface placed on a curved earth. The most obvious blocky effects are with long longitudes. An early example of this is seen in this first screen capture of Google Earth as Philly Rads . We are using the 1 mega blast over NYC but moved it's impact over Philly as if the blast occurred there, but in reality, less buildings, as seen in Philly Sky Line , so a lesser plume. This will also show some more land features as the bulk is over the ocean but passes through New Jersey and skims Long Island.

       B. Coordinate Conversions:

We also need the Lat/Long of center city Philly (City Hall) ground zero to convert to the UTM system to find the 4 corners of each pic, then convert these corners back to Lat/Long again, then average the 4 corners to represent the geographical center of each picture. However, the top corners have slightly different Lats as does the bottom corners. Also, the same with the different Longs on the west & east corners. To solve these problems, see the detailed explanation in the top fig and explanation under it in Pixel to UTM for Lat/Long .

       C. KML Files:

As we convert coordinates for each pic, we must also create a KML folder file, which includes corresponding kml files for each pic. To see how 2 files are joined, we used a generic file we called Combo.kml . Here we extract the lines with the tags and insert our new info between the tags, name NYC14 as an example, when needed. Notice, that the sub file GroundOverlay represents the call to the pic file within the 1 Folder's beginning & ending tags. We have 345 such GroundOverlay pic files in Philly Rads .

       D. Radfo Plume Displays:

The 345 files appear as grids lines as seen in Philly5 . Each pic size is 5 miles horizontal by 10 mi vertical. At this scale, you would think there would be no room for boundaries between these pics. However, it appears that the reverse is true when you zoom up in Philly2 , as those grid lines disappear. Notice the blockiness appears smoothed in Philly5 as compared to our first attempt in Philly1 due to the shorter but more longitude increments. The fader bar is applied to see some underlying surface features in the zoomed up Philly6 . For the plume display with the legend, we see Philly7 . The text size of these legend values appear larger than necessary but want no misreads here. They can be faded more or certain ones turned off.

3. Plot Particle Travel Times Coordinates: PPTTCKML.c

We updated the Time Plots in 10.C. near the bottom of the previous topic. In timev4an.gif , the letters weren't allowed to go out far enough, (MSN program error) and they appeared as gaps (holes within the alpha-numerics). In timev4px.gif , it first appeared nice but the colored broom was too thin just using pixels and with isolated single pixels, you could barely determine their color. Also, they didn't appear pronounced as a ground overlay in Google Earth. Our idea now is to use the concept of this last display and let each colored pixel represent the center of the cap cylinder circle then color plot the interior of the entire circle. However, another MSN Program error did not process the filled colored circles correctly when they overlapped as seen in timepo.gif . Also, this time, we have a 1280 x 1024 pixel pic. So for here, let's just try for one larger pic and it won't appear blocky. We will keep the 345 pics scale method to correspond to the main Radfo plume display.

       A. Complex Coordinate Conversions:

In this case, we still use the same method of conversion but now we are working with pixel displays, not a grid of pure distances. As before, we have a detailed explanation in the 2nd fig, under the dashed - - - line and explanation under that in Pixel to UTM for Lat/Long . In the explanation, it was seen that a correction factor (latc=dlat-Lat) was needed for a larger pic due to a flat larger rectangular surface placed on a curved earth. Also, under this shows a routine to store an array of pixels to color fill the plotted landed cylinders circles.

Above in 2.B. Coordinate Conversions:, we have a grid point (pixel) for every .1 mi so dpdx=dpdy = 1pix/.1mi = 10 pix/mi. The grid was 4000 x 5000 and so the distances were converted to Lat/Longs and Google Earth scales this by the aspect ratio, so is made to show equal distance in N-S and E-W on mostly all computer monitors. However in this case, we have to condense the 4000 x 5000 (400 mi x 500 mi) down to 1280 x 1024 screen capture. So we now have dpdx= 1280/400 = 3.200 pix/mi and dpdy = 1024/500 = 2.048 pix/mi instead of the 10 pix/mi. We correct this so we have a nice screen display as seen in timept.gif . However, that's forcing dpdx=dpdy which isn't the case. In Google Earth, the circles appeared stretched vertically. So for them to appear round in Google Earth which scales by Lat/Long, they must appear flattened on the PC monitor. For the kml file, generic.kml was used to depict a single ground overlay map, non folder. The final screen capture for Google Earth is seen by tpe.gif and seen in Google Earth by Time Plot Early .

       B. Extracting More Info:

            (1) Time Plot Early:

In the topic before, this represents the advance of the earliest fallout pattern with the Time Plot legend in the NW corner of the pic. However, this Time Plot legend was screen captured separately to be positioned anywhere on the display independently as seen in Time Plot Legend . The grid receptor example is seen in ppttcp.grd . The pixel grid file is initialized by the character | which is #124. Since travel time rounded off to 0 is possible, we used such a large value instead. All those boxes shown are really different symbols representing the rounded off time in hours. If they appear as boxes, it's because your default editor counts them as unprintable characters. We loop n from n=0->14 hrs. However, this would mean that the later travel time circle plots would be plotted last. Here, in the Time Plot Early, we set the reverse order by hr=14-n so the earlier time plots are plotted last that overwrites the later time plots circles if there is overlap. First, we do this in the pixel grid in case a later time value occupies the same pixel location.

As explained above, if you take the distance between the time colored boundaries and overlay it on the scale, then that distance ending on the scale from 0 is the mean vector in mph the plume is traveling at that location. After alligning the Time plots & Rads plots, you can flip the Time Plots on & off by the cursor in the check box and switch to the Radfo plume to compare the two plots at the same location. However, you will notice in the Time Plots, the heavily colored overlapping circles appear to almost create a plume also. This is what is really done in the Radfo plume but much more calculations to obtain a Rads value (chi). The heavy overlap roughly indicates that many dust cylinders have landed there so expect higher concentrations. Conversely, notice the circle plots to the north are almost detached and fewer, because of the large wind shear, which is a non-persistent wind, where it didn't even show up in the Radfo plume minimum values. Here we have x & y, 2 dimensions, the z value time plot dimension for 3D, but now the appearance of these time plots overlap, or lack of, gives a pretty good estimate of concentration also, so we almost have a 4D plot.

            (2) Time Plot Late:

You may ask, if we flee the radiation, don't we want to know the first arrival time. That is correct so what purpose is this plot? Since this shows the last cylinder landed, there will be no more ambient radioactive dust in the air since all dust has landed. Now we would still receive radiation from the ground layer but none to inhale unless windy conditions at the surface entrains the dust again. On the surface, the radiation from a particle goes off in any direction making a sphere of radiation. However, many spheres but in greater distances from the body. When inhaled, the sphere of radiation will continually bombard the lungs, nose or throat since the particle is surrounded by tissue. This plot then gives a safer time when to renter a region, if it were necessary to just get in and get out again quickly. The accumulated radiation is still in effect but no more increase in the radiation emission rate. This should be used in conjunction with the Radfo plume plot for accumulated 12 hr dose radiation. This new plot can be seen in Time Plot Late . This is the definite ending or back boundary of this bad foggy layer. Here, the ppttcp.grd is wiped clean by being initialized with '|' again but now we loop hr=n from n=0->14. This would mean that the later travel time overrides the earliest pixel grid location. When plotting, the latest plots are plotted last that overwrites the earlier time plots circles if there is overlap.

Both Early & Late time plots are run in this same program and took less than 9 minutes compared to the 75 minutes required for the for the Radfo plume RADFOGF.c and another 10 min for the Google Earth files by 2. GRID to PCX's Folder: GRIDPCXF.c and another 10 min uploading them by FTP.

4. Interacting with Google Earth:

Any agency or user of this Radfo program should make better use of Google Earth by downloading the program itself instead of the Google Earth screen captures which are also done and uploaded. I download the latest (6.0.0) as it is much larger with more features. These downloads are free at Downloads . You may also want to refer to Users Guide and the Tutorials and the Documentation .

For those who have downloaded any of these versions of Google Earth, you can bring up all the features by clicking on any one of these features we discussed above. Our 3 mandatory GE legends that should be downloaded first were just explained above and are linked in our last topic 10. below.

5. More Google Earth Screen Capture Plots:

To show the variety of daily patterns, we chose another unusual wind profile from Aug '09 as another complex pattern to show a strong reversal of winds as seen in 09081600.pit. This also tests the validity of the program when under strong wind shears. Here we use New York City again but place the plume over NYC with ground zero @ the Empire State Building. This unusual plot is seen in NYC1 . Notice, we don't have any radiation east of 50 mi or west of 30 mi from ground zero but a strange display of concentric maxes. The early and late time plots are shown in Time Plot Early and Time Plot Late . Notice that the reverse flow returns radioactive dust particles over the same area again but much later. Notice too, that although it appears the radiation particles landed further out, which they did, there wasn't enough to make the minimum value of the 12-hour dose plume ( NYC1 ).

        A. Screen Capture Plots Alternative:

For those that don't want to play with Google Earth each time, we have an alternate solution. Since your internet speed may be slow, and the mosaic image may approach over 900 individual pics, just a simple composite pic may suffice. However, a few more details may be required so we may make a few zoom in pics available also. The other advantage is that the pics could be by E-Mail as an attachment which is much faster and ready to use. However, this takes some human interface with the model runs and Google Earth at the distribution centers. In order to have this for all the cities, a staff or volunteers would have to employed for expanded services meaning some kind of monthly fee at first, then possibly less cost per city as more subscribers. The e-mail of pics to cell phones is an excellent application rather than on line Google Earth. The choice will be in the last topic link.

            (1) Gallery Upload:

As with the uploads of the Google Earth *.kml, *.htm and pics files, we save the screen captures in directory 'new.dir' and upload them to web's 1,2, etc. Each city has it's own *.htm file that includes 2 pics of the city with the dated *.jpg screen captures in ascending order between them then line by line below the pics. We just append the STA.htm list of pics and the pics themselves in /STA. The program created for this is CITIES.c with more explanation given in Cities.dia and WebGEf.dia . The results are all seen by clicking on the last topic 10. B. Gallery below.

6. Flow Diagrams:

To see all the programs involved in the correct order and linked files that produced these final results, see Radfo.fld. However, with the updates, we now have a flow diagram for the new setup for use of the RUC data in RadfoRUC.fld.

7. Trajectory Upgrade - A 4D application:

       A. Horizontal Wind Variation:

Even though we used winds from 00Z & 12Z at a given station and date for PIT & Dulles International (IAD) earlier, we had to enter one at a time. We wanted to finally progress to a new web site and method called the Rapid Update Cycle that forecasts hours in advance for a 40 km grid system. This will require a complete upgrade of program PTTC.c .

The RawinSonde Balloon is really a trajectory from the station from which it is released even though it represents all the winds aloft from that ground station. The accession rate is assumed as 5 mps = 16.4 '/sec. For winds up to 100,000', this would take 101.6 min = 1.69 hrs. So for a mean wind speed of say 25 mph at a constant direction, the balloon and it's package traverses 42.3 mi horizontally when it reaches 100,000' vertically. For many winter transition seasons and winter itself, we may have a 50 mph mean with the balloon now 84.7 mi away. For 100 mph, it's 169.3 mi away from launch. Usually > 100 mph mean would not be uncommon.

Therefore, a large particle with a fall velocity of 5 mps should follow the same path? No, The particle is rising faster than the balloon rate in the stem updraft (by a factor of 80 times initially) and in the cloud growth. It was determined that the cloud growth takes nearly 9 min from earlier graphs. Therefore, the particle starts it's descent at a different location than the balloon would be at this same height. Now let's assume the particle descends at the same rate the balloon ascends. The particle is in the region of higher winds so the location of this particle after a few minutes is much further out than the balloon impact from lower level winds and more subject to it's local region's winds. When the balloon's rise matches the height of the particles fall, they are far apart and so each will take on different wind in the 2 different locations due to horizontal wind variation. An example of this is also a check of wind direction flows as we have Chicago Trajectory , a plot from the descent of the 50 mb chosen standard particle size trajectory indicated by the yellow push pins.

       B. Time Variation:

            (1) Normal Moving Systems:

Above, we assumed that there was no variation in time - the 4th dimension. To complicate this further, weather systems move, but not as fast as the winds. An old rough guess was 50% of the winds at 500 mb (18,000'). Look at a picture of an upper air strong trough in the Central US .

            (2) Slowly Moving or Stationary Systems:

A deepening trough can become a closed low and a ridge, a closed high pressure aloft. Here, we examine a strong closed low at multi-levels or called a "stacked low" that may really move slowly. These are clearly seen in the following ascending order for 12Z 13 March 2010 up to 25,000'.

925 mb Low
850 mb Low
700 mb Low
500 mb Low
400 mb Low

However, blocking weather patterns don't move but we still need their horizontal wind variation for trajectory purposes. Either stationary or progressing, it doesn't matter because the RUC model predicts the wind for any x,y,z,t - the 4th dimension.

            (3) Steady State vs. Trajectory Ramifications:

To show the critical difference between the two, let's assume we have the older steady state same wind direction and speed with height and apply this to a deep upper air lows With some simple graphics, we extend what would happen if we assume steady state vectors instead of the real trajectories. Lets look at 850 mb SS . We draw a line segment parallel to the wind direction and it's length somewhat proportional to it's wind speed. First, note the yellow line from NE NJ-PA to Lake Superior. If we assumed steady state, there wouldn't be much error. With light winds, the green line in Tennessee wouldn't cause much error either. However, the purple straight trajectory from Eastern NC to off the Jersey coast intersects Jersey winds at nearly right angle with the wind speed at least doubled.

The next case is the 500 mb SS . Here, the yellow line from Eastern IL to Nebraska-Kansas border, is again nearly off by 90 degrees with less wind speed. Finally, in 400 mb SS , the blue line from Western AL to mid NC encounters winds over 90 degrees change in direction. In these cases of life vs. death radiation patterns, we must completely reject the steady state estimates under these meteorological conditions. There is no substitute for the more realistic trajectory methods. In all the cases shown, with stationary systems, the wind direction trajectory would nearly follow the iso-height lines of these constant pressure levels around the pressure centers instead of their depicted colored straight line segments.

        C. New Sounding Data:

Direct from NOAA is their web site RUC Soundings. These soundings are taken throughout the US at 00z & 12z for these Raob Stations . The predicted soundings are those listed in ACARS Airports and plotted as seen in US METAR Stations. They use the nearest 40 km grid point to represent those airports. We see an example of this new format in 281009ne.ruc . Notice the date is the US Gov & military classification day mo yr, not the civilian mo/day/yr. I added ne to identify a list of NE Airports which can be a string of the 3 letter station identifiers. Also, the time in Z of the predicted soundings we requested.

The 1st line (Op40) gives the nearest grid point to the airport - that is 4.5 nautical miles along a bearing 161 degrees from the PIT airport. The 2nd line (Op40) adds the Z time in front of the date. The 3rd line ?. The 4th line (1) is ID, Lat, Lon, msl. The rest of the lines is the sounding itself. The whole format is given by GSD.txt . Here, missing data is indicated by 99999 instead of a blank. The blanks appear nicer but requires stiffer data extraction code techniques.

            (1) Present Status:

An urgent request was made to the NOAA'S GSD @ NCAR's in Boulder,CO to obtain a block of all the Metar's soundings at once. As explained in STAPTTCT.c<--->PTTCT.c = trSTApt.c above, the semi-automatic cut & paste can lead to possible errors. Thus, speed and accuracy is very relevant for real time operation of RADFO. The block of 12 hourly predicted RUC sounding for each of the US Metar's Stations could be compressed to within a 15 mb file. To obtain a sample of this one block would then be compressed then uncompressed when needed with this program. The whole 3+ yr effort would all be wasted if this best available data is not obtained. Also, the continuity for completion also must be expedient.

Instead of the required block of data, an automated data extraction method was suggested by NOAA'S GSD @ NCAR. This is further explained back in PERL . With some new points to learn, this was Key #1 to make this program completely automated and could now be inserted into a Radfo Batch File .

8. Keys # 2 & 3 for Complete Automation:

       A. Picture Conversion (Key # 2):

To eliminate any Window's graphic's picture format conversion, we must use a command line to be put into the main RADFO batch file as a batch file itself. We noticed a flaw in Google Earth ? The Time Plots early and late in *.gif format fail to show the bottom half of the plot. It shows the Travel Time hours legend at the top left corner, but if there is no colored cylinder pixel data until near mid pic near ground zero, it continues all black with no plot of hours even though it's there. Converting *.pcx -> *.png solved this problem for some reason. Also, we made the Travel Time hours legend a separate pic so the real ground zero of any time plot could be moved nearer the now stationary time legend for larger and easier reference location. Next, the nearly 400 picture mosaic to make up the Rads Plume in Google Earth must be converted from *.pcx -> *.gif. Also included in this batch file is to delete all the *.pcx files after they served their purpose.

The internet search engines came through again. About 5 such programs now advertised their command line conversions capabilities. The most expensive was about $60, down to a free version. You know we would try the free program, but after wrestling with a few of their commands and finding out they changed the color palette and colors in the pics, it was dropped. Finally, the cheapest ($20), was the one that worked. However, they added colors to their color palette but did not use them so the original *.pcx colors were preserved. This program is Total Image Converter . With some more wrestling with newer line commands to learn from their [Help] > [Command Line Parameters] tabs and being conservative with relative vs. absolute paths, automated conversions for the Travel Time Early & Late hours as well as the Rads converted by these new commands in another batch file, it was successful. Part of the command automatically deletes the original file your converting. A generic batch file is modified by the programs that search for characters to replace the date-time and station (STA), which is then run after, not within the program, but could have been.

       B. Upload Routines (Key # 3):

Since PPTTCKML.c can be run before the 1-hr RADFORUG.c program, these Travel Time plots can be posted first. Also, we need to upload the Rad's 400 *.gif files as well as their respective *.kml files. Again, we go back to Strawberry Perl and did a search but their online chat help was great and free. We copied and saved their chat session as they gave the help and example where to upload a text message (*.kml) and pic (binary) file. Also, we could use a 1 liner to upload all the global files using the wild card '*'. Again, a generic Perl batch file is made by the program searching for characters to replace the date-time and station (STA), as well as creating and changing directories on the web site but run after, not inside the program but could have been.

An extension of this upload is the download. We use this in the final topic 10. seen below. Both PPTTCKML.c pic plots can be run before the 1-hr RADFORUG.c program, so we download RTradfo.htm and add the latest pic & kml files as a link there as it also searches for the time to insert these links, with the latest on top. These programs are dlRTRhtm.bat & upRTRhtm.bat , then as UPradKML.bat in Radfo Batch File . Since the upRTRhtm.bat uploaded the updated RTradfo.htm 1 hr earlier, this later RTradfo.htm is still waiting for the link info to the Rads Plume by RADFORUG.c and uploaded after executing the program with the Rads *.gif & * kml update.

9. Adapting for Network: 10/20/10

To consider this an application by real time, it would be advised to have a few satellite bases rather than have all the activities at one site. This main site application could operate by grant funds to continual running the programs for the major cities, but it may be better to distribute the work load and have each area's base examine it's own regional plots. This would also help the main base if there are computer difficulties or power outages. Also, security or sabotage at one main base could be alleviated.

       A. Modify PPTTCKML.c & RADFORUG.c:

Although it's seems timely to upload the Time Plots first, it may be better to examine the results before uploading automatically. This can be done while RADFORUG.c is running. So we overwrite our hard drive copy of RTradfo.htm , instead of downloading it from the web site. Finally, we upload both program results together. Thus, we combine upTPkml?.pl & upRDkml?.pl into a new perl program upTPRAD?.pl for uploading the pics by the batch file upTPRAD.bat and the complete list (*.kml) of the new pics in the Real Time Radfo.htm by upRTRhtm.bat .

A better pic of this is seen in the flow diagram WebGEf.dia . Here, we see that the batch files *.bat do not change but run the perl upload files *.pl for the pic & *.kml files to their appropriate directories for ? webservers/websites ?=0,1,2,.. etc. These web servers are read from WebSite.aup . Here, we list the server, userid, password and C: or website. So the name WebSite.aup , represents the website and suffix 3 letters are authorized(a), userid(u) and password(p). As seen, the server, userid and password are indicated by dummy names here for security purposes. These header line titles of WebSite.aup are read as 1st line l=0 indicating the files to be loaded first on the local hard or flash drive. The 2nd & 3rd lines are the websites l=1,2. To add another web site (l=3), we add a new line info and modify the 2 programs to use these added websites from the list by writing each line of the *?.pl in website sequence.

            (1) Fussy Servers UC/lc:

As we reference here and in the programs, we use Upper Case & lower case to help identify program and file names. However, in the DOS *.exe files, even though we name them that way, they print the file names as they please. The key on this PC was that however the last name was written, they take on these last UC/lc if the letters match. If this is a new file name, it takes on the UC - all capital letters. For the local PC's hard drive, Google Earth will open it regardless if UC/lc as long as the letters match. However, each particular web server may not. To solve this problem, we make all the *.kml file names with capitals. Also, for the Total Image Converter program, the pics are converted to all lc so all the referenced pics in the *.kml files should be lower cased.

Now the complete list of program files to date are run in Radfo Batch File # 7 and seen with brief explanations in the remarks (rem) sections.

10. Real Time Radfo:
    A. Using Google Earth:
    B. Google Earth's Screen Capture Gallery: