SECTMAP1.TXT   Ver 0.91  17 MAY 01

            TECHNICAL MUMBO-JUMBO FOR SECTOR DEVELOPERS


   Installation and general help is in SECTMAP.TXT.

   Very little in this file changed from the previous version.


   --------------------------------------------------------------
   |                                                            |
   |                    EXCUSES, EXCUSES                        |
   |                                                            |
   --------------------------------------------------------------

   I haven't quite figured out how ATCC plots items on its map.
   My equations are obviously different.  SectMap uses the Lambert
   projection.  I'm not sure what projection ATCC uses.

   To test it, I set up a grid of fixes several degrees apart.
   Fixes at the same latitude show up along a straight line.  Lines
   of latitude are parallel.  Fixes at the same longitude are also
   on a straight line, but the tops of adjacent lines "lean in" (at
   least in the northern hemisphere).  This is sort of Mercator for
   latitude and Lambert for longitude.

   The bearing between two distant points at the same latitude
   is reported as 90 or 270 degrees plus the (constant) sector
   variation.  This must be the way ATCC handles lat/long
   computations internally, but it is not the way airplanes fly.

   On a 500 mile segment between two points at the same latitude in
   the continental U.S., great circle effects would cause the
   mid-point of the segment to be about eight miles from the
   constant-latitude path. The initial true course would be about
   four degrees toward the pole, and the magnetic variation would
   differ by four to seven degrees at the end points.

   ATCC also uses the same magnetic variation for the entire sector.
   For large sectors, or sectors far from the equator, the variation
   may change significantly from one side of the sector to the other.
   If you use charted radials, but ATCC applies the variation from a
   point several hundred miles away, the computed positions are
   likely to be wrong.

   Even for small sectors, the navaids in the sector generally
   have different station declinations.  This also means that
   charted radials may produce incorrect positions.

   These observations are only to explain how SectMap and ATCC are
   different, and why fixes and airways may not show up exactly
   where you expect them.  It should not detract from your enjoyment
   of the simulation, since the airplanes go where they are supposed
   to go.

   A lot of SectMap was taken from existing programs, including the
   lat/long computation routines.  I expect to use this program
   for other tasks in the future, so I prefer to keep a consistent
   set of equations.

   However, since the initial goal of SectMap is to display ATCC
   sectors, it would be more useful if it could come closer to ATCC's
   display.  I'll work on that.


   --------------------------------------------------------------
   |                                                            |
   |                      PRESTO-CHANGO                         |
   |                                                            |
   --------------------------------------------------------------

   I have tried to have SectMap read the files in such a way that
   you can edit the various files, save the results, and switch back
   to SectMap to see the results immediately.

   One problem with this shows up when you have set the center and
   range to work on a particular area.  You would not want the
   display to jump back to the original center and range.

   Therefore, SectMap does not read the range or position information
   from SECT_XX or C_INFO files, or process any center or range
   commands in the TXT file, except when the file is first opened.
   If you modify any of this data, you will have to do another
   File|Open to see the changes.

   It does re-read the FIXES, SEPS, MAP_XX, AIRPORTS, FREQS, and
   other items in the SECT_XX, C_INFO, and TXT files each time it
   repaints the display.

   You may need to do a REDRAW (button or F5) when you switch back
   to SectMap, since Windows only repaints the part of the display
   that was covered by other tasks.

   You must SAVE any files changed in your editor before SectMap
   will see the changes.  If you use a fancy word processor, be sure
   to save the files in text format.

   With Notepad, you do not have to close a file to allow SectMap
   to read it.  That may not be true of all editors.


   --------------------------------------------------------------
   |                                                            |
   |                  GARBAGE IN, GARBAGE OUT                   |
   |                                                            |
   --------------------------------------------------------------

   Most of the testing of this program was with stable sector files.
   The error reporting will be improved in the next version.  (But
   this already is the next version.  Oh, well.)

   For now, you will get minimal error information in a popup window,
   or a message in red in the upper left corner of the display.  If
   that happens, further processing of the files stops.  Try using
   ATCCCC.EXE to check for errors.  At some point, the two programs
   may merge.

   The file information in the lower right corner may be displayed
   in the wrong font if normal processing stops.  I was going to fix
   that, but for now it's more noticeable than the error message.


   --------------------------------------------------------------
   |                                                            |
   |                      RUNWAY DISPLAY                        |
   |                                                            |
   --------------------------------------------------------------

   One thing that SectMap can help clean up is runway definitions.
   At ranges less than 25 miles, the runway is shown in gray, and
   a blue line connects the ends of the runway with the taxi-to
   and taxi-from points.

   Center the display (right click) on the airport of interest,
   and set the range to about 2 miles.  You will be able to see
   the runway and taxiway definitions.  You can then position the
   mouse cursor to where you want the runway or taxiway to be,
   and read the lat/long from the status line.

   If you are trying to define a new runway, the best way is to use
   an airport taxi chart or equivalent.  If you do not have one
   available, you can center the map on the airport coordinates and
   eyeball the position of one end of the runway.  Center the map
   on this point, and use the bearing and distance read out in the
   status line to determine the lat/long of other end of the runway
   (10,000 feet is about 1.6 NM).  The original files have taxiway
   lengths of around 500 feet, or 0.08 NM.  Whether this is
   important is anybody's guess.

   Tests have indicated the following:

      Initial position - "ramp coordinates".  Primary target only.

      Taxi to "Taxi To" coordinates at 30-40 kts.

      Start takeoff roll at start coordinates of runway, moving
      toward end coordinates of runway.  Untracked target with
      limited datablock.

      About 400 AGL - usually tracked target, can get full datablock
      and route line.  No strip.

      If the "initial heading" value is non-zero, start turn to that
      heading, else remain on runway heading.  "Tower overload" can
      produce a "ghost target" that continues on a heading at
      5000 AGL forever - remains untracked, no datablock, no strip.

      About 2500 AGL, normal targets turn the shortest way toward the
      first fix in the route, even if they have not completed the turn
      to the initial heading.  Strip available.  May catch an "RVxxx"
      on the strip if your timing is good.  Handoff to next sector
      begins, regardless of handoff distance value.

   For testing in ATCC, I centered the display on the airport of
   interest, set the range to 5 miles, turned on the primary button,
   and set the number per hour to 20 for the route(s) of interest.

   Since aircraft appear to stay on the initial heading for only a
   short time, it seems to be easier to control the flight path with
   fixes in the route.  The heading will allow you to force a left
   turn or a right turn if the first fix is 180 degrees from the
   runway heading.  If the first fix is straight out, a 90 degree
   turn will produce a 2-3 mile offset that might be useful.

   The tower assigns an initial altitude of 5000 AGL, and hangs
   on to the airplane until it is at least 2500 AGL.  Then it gives
   a freq change to the first sep.  This makes it impossible (so far)
   to have an airplane level off below at least 3000 AGL.


   --------------------------------------------------------------
   |                                                            |
   |                        ROUTE DATA                          |
   |                                                            |
   --------------------------------------------------------------

   The goal is to have most data items in a route displayed
   graphically.

   There are still a lot of unknowns about how route items are used
   by ATCC, and which are really important.  But, this should make
   it easier to work with handoff points, and other items.

   I haven't tried printing maps with individual routes yet.  The
   constant number of pixels used for some symbols may be too small
   to see on the printed page.

   First is a list of what the menu items do.  Then there is an
   example that explains the symbols used.


      Routes | Select..., Deselect, Prev, Next

         Data for an individual route may be displayed by entering
         the route number in the Routes|Select dialog box.  The
         dialog box may be directly accessed with Ctrl+S.  Think
         "S" for select, not "R" for route.  Ctrl+R will get you
         the "Range" dialog box.

         If you want to remove the route display, use Route|Deselect,
         or set the route number to 0.

         The RTE+ and RTE- buttons, or Routes|Prev and Routes|Next,
         or Ctrl+P and Ctrl+N, may be use to cycle through all route
         numbers in the current center (not just this sector).  Some
         centers are defined with gaps in the route numbers.

         The current route number is zero when you first open a sector,
         and after Route|Deselect.


      Routes | List

         On the left side of the display, the total number of
         aircraft per hour for routes listed in SECT_XX is shown.
         "Work" represents aircraft that will be handed off to the
         current sector.  "Watch" represents adjacent sector traffic.

         The number of aircraft per hour actually generated may be
         limited by the "busy factor" value in SECT_XX.  The work
         value for typical sectors is 70-80.

         Just below that is the number of departures per hour per
         airport.  Tracking on a per runway basis is not attempted
         (can depend on "runway preference" value in AIRPORTS.XXX).
         "Ghost targets" seem to be generated when the rate is more
         than 30-40 per hour per runway.

         Route numbers for aircraft that will be handed off to the
         current sector are shown in magenta on the right side of
         the display.  "Adjacent sector" route numbers are shown in
         cyan (blue-green).  To show up in magenta, the route number
         must be listed in the current SECT_XX, and at least one of
         the seps listed in the route must be for the current sector.


   Open ZLA sector 38 to follow along with this example.

   To eliminate non-related clutter, I've been using the following
   setup to view routes (totally optional):

      Properties | Data tab     - turn ON Sep Info, turn OFF Runways.

      Properties | Txt File tab - select ALL OFF.

      Properties | Routes tab   - List ON.
                                  Turn OFF all other items.
                                  Then OK.


   Here's the data for ZLA route 26 (in ver 1.1):

      26 !PSP..YUCCA..PMD..AVE
      0 0 0 0
      1 PSP 100
      2 SFO 80 SJC 20
      2 ASA 70 ROA 30
      7
      56  0 0 7            sep 56 PSPL   = sect 44
      27  0 0 5                27 YUCCA         19
      57  0 0 5                57 SOGGI         19
      46  0 0 15               46 S3852         38
      4   0 0  5                4 LAMPE         27
      5   0 0  5                5 S27S1         27
      7   0 0 10                7 AVE           26
      1

   Select route 26 with the Routes|Select... dialog box.

   A summary of the route is shown in the upper left.  Line 1
   gives the route number, initial altitude (if not 0), miles
   in trail value (if not 0), and number of aircraft per hour.

   Line 2 shows the origin and destination airports, and line 3
   shows the route text.

   The route line is shown in magenta (runway operations ignored).

   The beginning of the route can be identified by the green text:
   [26]O-44

   The [26] is the route number.  The O-44 indicates that sector 44
   has the initial handoff (sector associated with sep 56).

   For all airborne aircraft, and for departure aircraft with a
   non-zero initial heading (line two, third item), a dotted green
   line shows the initial flight path.  More in "Runway Display"
   section above.  There is no initial heading for this route.

   For airborne aircraft, you probably want to adjust the heading
   so the green line is near the magenta line.

   The first handoff point (7 miles from sep 56) is identified by
   the magenta plus sign, and the text:  56H-19.

   The 56 is the sep number that the handoff distance is measured
   from, and 19 is the sector number associated with the sep on the
   following line (sep 27).  The location of seps used in the route
   are shown as cyan dots.

   The next handoff point is shown as:  27*

   The 27 is the sep number, and the "*" means a "handoff" within
   the same sector.  The next sep in the route is 57, and both
   seps 27 and 57 are in sector 19.

   The next handoff (and the first problem) is:  57H-38

   Sep line 3 says this handoff is 5 miles past SOGGI.  However the
   closest point on the route to SOGGI is about 20 miles away.  The
   logic and the mathematics gets complicated really fast when you
   try to cover all the bases on this one (turn points, zigzag
   routes, etc.).

   So, what I did when the sep is farther sideways from the route
   than the handoff distance, is use the point on the route abeam
   the sep location (if one exists).  This one may not look "abeam"
   unless you turn off the solid and dashed lines.

   Another logical way to handle this is to make the handoff point
   X-miles past the abeam point.  I don't think it is worth the
   effort to find out what ATCC does.  If you want to avoid the
   uncertainty, put your seps closer to your flight paths.

   The orange color is used for this and other "problem" points, to
   call attention to them.  It doesn't mean that the route won't
   work.  It does mean that I'm not sure how ATCC handles that
   situation.

   See FDOCS.TXT from Xavius for suggestions on where to put seps
   and handoff points.  If you put seps right on the route (not off
   to the side), and follow their guidelines for handoff distances
   (halfway for in-sector seps, dist to boundary for out-of-sector
   seps), everything should show up in magenta.  This may not be
   practical with the 150 fix limit, and is overly conservative.

   The other handoff points on this route are similar to those above.

   Since there are multiple destination airports, the route line stops
   at AVE.  In the next version, I may draw dotted lines to defined
   destination airports.

   For another example, select RTE- to get to route 25, and set the
   range to about 50 miles, so you can see the first two points.

   The first handoff point on this route has an associated
   altitude:  21H-18(140)

   If there is an initial altitude restriction, it will be shown
   with the first point (green).  An "at or below", such as -31
   will be shown as (310-).  Altitudes in the route description
   are in thousands.  SectMap uses the "datablock" format - hundreds.

   There are some altitude actions over 100 in the Xavius sectors.
   They will show up as a 4 digit number until somebody figures out
   exactly what they mean.  In one test with departures, the altitude
   was limited to 1000 feet below the bottom altitude of the next
   sep.  No effect was observed on overflights.

   Route 15 shows another problem.  The handoff distance from the
   first sep (LANGE) is 99.  Several other routes have 99 as the
   handoff distance on the first sep line.  That may mean something
   special.  It definitely does not mean 99 miles -- that would be
   somewhere around DAG.

   The 99 is processed as 0.1 miles.  In this case, with both
   sep 8 and sep 49 at the same location, you get 2 orange points.

   There are a few handoff points set at 100 in ZNY.  None of
   the 100's are on the first sep line.  I treat those as 100 miles.

   There is something I don't understand yet about how ATCC does
   the initial handoff on a departure.  No matter how far from the
   departure airport I define the first handoff point, the handoff
   starts when the airplane is a few thousand feet off the ground.
   I am beginning to think that ATCC is ignoring me.

   If you have a zigzag route, there may be accidental abeam points
   that will generate a handoff symbol in SectMap too early.  Changing
   the handoff distances will get rid of the orange points in SectMap,
   but probably does not affect the operation of ATCC.

   If successive points are close together (less than 1/8 of the map
   range), the text alignment is changed from left to right, or top
   to bottom, to attempt to show both items.

   Lastly - if there is an altitude on the last sep line, that
   altitude is shown at the last point on the route (not at the
   last sep).


   --------------------------------------------------------------
   |                                                            |
   |                AUXILIARY DATA FILE FORMAT                  |
   |                                                            |
   --------------------------------------------------------------

   SectMap looks for a file named SMZZZXX.TXT in the same
   folder as the sector file SECT_XX.ZZZ.  For SECT_75.ZAU, it
   would look for SMZAU75.TXT.

   This optional file allows you to add information to a sector file
   for documentation purposes.  If you use a fancy word processor,
   be sure to save the files in text format.

   Check the TXT files included with this distribution for examples.


            ------------------- GENERAL -------------------

   Lines beginning with '#' are comments, and are ignored.

   Blank lines are ignored.

   Commands are not case-sensitive.  FontSize, fontsize and FONTSIZE
   all do the same thing.  Text in the various Text... commands is
   case-sensitive.


            ------------- COMMAND ELEMENTS ----------------

   The items in angle brackets will be used in the commands described
   in the next section.

   A <position> may be specified in several ways:

      (1)  A latitude and longitude separated by '/', without
           spaces.  A decimal point, and zero or more digits after
           the decimal point, are optional.  The values to the left
           of the decimal point are degrees (0-90 or 0-180), and
           minutes (0-59).  The value to the right of the decimal
           point is a fraction of a minute (not seconds).

      (2)  A fix defined in the associated FIXES.ZZZ.

      (3)  A bearing and distance from a defined fix.  The bearing
           is magnetic, and both the bearing and distance must have
           3 digits.  The variation that SectMap uses may be
           different from the station declination used at any
           particular navaid.

      (4)  A bearing and distance from a defined fix, but with
           a 'T' at the end will compute a true bearing.

      The positions computed in (3) and (4) use a great circle path
      from the fix, not a rhumb line (constant heading).

      Here are some legal <position>s:

         N3600/W12454
         N3600.1/W12454.4
         S8959.99/E17959.99

      and, if CIVET is defined for the current sector:

         CIVET
         CIVET090030
         CIVET090030T

   <from position> and <to position> are <position>s used with
   Text.... items described below.

   A <distance> is specified in nautical miles.

   <line type> may be one of:

      SOLID
      DOT
      DASH
      DASHDOT
      DASHDOTDOT

   <justification> may be one of:

      LEFT
      CENTER
      RIGHT

   <box type> may be one of:

      BOX
      CIRCLE

   If used in a command, <text> is always the last item on a line.

   <sector number> is from FREQS.ZZZ.


            ----------------- COMMANDS -----------------

      NoDraw
      Draw

   The 'NoDraw' command suppresses drawing of elements until a 'Draw'
   command is encountered.  You may use this pair of commands to
   prevent displaying some items on the map, but retain them in the
   TXT file for later use.  You can get the same effect with '#'
   on each line.

   If drawing is currently enabled, additional 'Draw' commands
   are ignored.

      Center  <position>

   Sets the center of the map to the given position.  If no 'Center'
   command is given,  SectMap uses information in C_INFO.ZZZ and
   SECT_XX.ZZZ - but this does not work quite right for all sectors.

      Range  <distance>

   Sets the map range to the given value.  If no 'Range' command is
   given, SectMap sets the range to the value in SECT_XX.ZZZ.

   The Center and Range commands are only processed when the file
   is first read after a File|Open.  This seems to work better for
   editing the files, and switching back and forth between the editor
   and SectMap.

   If you change the Center or Range entries in the TXT file, you
   will need to do another File|Open to see the effects.

      FontSize  <number>

   Sets the font size in points, which will remain in effect until
   the next FontSize command.  The initial font size is 8 point.

      Color <number> <number> <number>

   Sets the display color for lines and text to the requested value.
   The series of <number>s represent an RGB color (red-green-blue).
   <number> may range from 0 to 255.  This color will remain in
   effect until the next Color command.

   Sample colors:  255 0 0 = red, 0 255 0 = green, 0 0 0 = black.

   If you are not familiar with RGB colors, you may use the Paint
   program (Start|Programs|Accessories|Paint) to experiment.  Go to
   Options, Edit Colors..., and Define Custom Colors.  Set the values
   in the boxes, or move the sliders to see what happens.  Use
   'Cancel' to quit without changing any saved colors (recommended).

   Some (most?) printers will not do a good job of displaying
   single-pixel-wide lines in other than basic red, green, blue,
   and combinations.  Light colors (high numbers) may look better
   on the screen, and dark colors (low numbers) may look better on
   the printer.  I have had the best results using colors containing
   0, 32, 64, 96, 128, 160, 192, 224 and 255.

   Black & white printers generally use shades of gray to represent
   colors.  This is likely to produce different results on different
   printers.  On my B&W printer, rotated text in some colors is
   much darker than horizontal text of the same color.  I don't know
   if this a programming problem, a Windows problem, or a printer
   problem.

      Text      <justification> <position>      <text>
      TextBox   <justification> <position>      <text>
      TextR     <from position> <to position>   <distance>  <text>
      TextBoxR  <from position> <to position>   <distance>  <text>

   These commands display text, boxed text, rotated text, or
   boxed rotated text.

   Text and TextBox will be printed horizontally.

   TextR can be used for documenting traffic flows, for example.

   TextBoxR is designed for airway labels.

   The <text> field is all of the remaining characters on the line,
   including spaces.

   Rotated text is placed along a great circle defined by the
   <from position> and the <to position>, and rotated to be parallel
   to the great circle.  The text is rotated so it can be read
   without standing on your head, regardless of which position is
   listed first.  The bottom of the text, or of the box, is slightly
   above the great circle.

   For TextR or TextBoxR, the text will be placed <distance> nautical
   miles from the <from position>, in the direction of the
   <to position>.

   If the distance is zero, the label is conveniently placed halfway
   between the two positions.  A negative distance works too.  In
   that case, the label will be "prior to" the <from position>,
   instead of between the two positions.

   The label will be centered on the computed position.  There is no
   command to left or right justify rotated text.

   If you want an airway label at the mid-point of a segment, the
   two positions are simply the end points of the segment, and the
   <distance> is zero.  SectMap does the rest.

      TextStack  <justification>  <position> <text>
      Stack      <text>

   These commands can be used to place a block of text at a given
   position.  Use TextStack for the top item in the stack,
   and use Stack for the remaining items.

   Blocks of text placed with these commands will retain the same
   spacing, even when the map range changes.

   Text lines are separated by 1/2 the height of the current font.
   With some of the more unusual fonts, this does not work.  I do
   not yet know why.

      Freq   <box type>  <sector number>  <position>

   This command finds the matching <sector number> in FREQS.ZZZ,
   and displays the associated frequency centered on the given
   <position>, surrounded by the <box type>, using the current
   FontSize and Color.

      Line  <line type>  <from position>  <to position>

   One use for this command might be to show low sector boundaries
   for a high altitude sector.  The user can turn off these lines
   with a switch on the Data menu.  (The GROUP command that will be
   in the next version will provide a better way of doing this.)


   --------------------------------------------------------------
   |                                                            |
   |                          LATER                             |
   |                                                            |
   --------------------------------------------------------------

   The Draw/NoDraw commands were the first idea for displaying
   part-time data.  The problem with that is the user would have
   to edit the TXT file to turn things on and off.

   A better idea is to have a command to "group" a set of commands,
   and then select the entire group on or off from the menu.

   It will look something like this:

     GROUP Traffic Flow
     ... commands to document traffic flow
     ENDGROUP

     GROUP Boundaries 1
     ... commands to draw a set of boundaries
     ENDGROUP

   The description part of the GROUP command will be dynamically
   added to that menu when the sector is opened, and be selectable
   on/off.


   --------------------------------------------------------------
   |                                                            |
   |              NOT READY FOR PRIME TIME BUTTONS              |
   |                                                            |
   --------------------------------------------------------------

   The computation buttons on the tool bar were already developed
   for another program.  Initially I thought they would be useful
   in placing map items.  However, as I have learned more about how
   ATCC plots things, I no longer think that.

   Since the program code is already in place, I kept the buttons.
   They provide "correct" answers -- it's just that the answers
   are not very helpful right now.

   Here's the scoop on what they do.  If you can use them for
   something - wonderful.

   (These buttons now mostly work with the "real" data.  The program
   check for items in a sector file first (if open), and then looks
   at SMDATA.BIN.)

   The button functions are also available on the Display menu,
   as well as via function keys F6 to F9.

   The text window on the left is the input window.  The input
   cursor will stay in that window, unless you click within the
   right window (which is for output).  If the input cursor winds up
   in the right window, what you type will show up there, but nothing
   useful will happen.

   With the new route boxes, the cursor may end up in several
   places.  For the near future, just plan on clicking in the input
   box when necessary.

   In the left window, you may use any of the <position> formats
   defined above in the Command Elements section.

   You may also left-click anywhere on the map to add that lat/long
   to the current contents of the left window.  More clicks will add
   more lat/longs to the window.  If you want to view the additional
   text, use the cursor movement keys.

   The input/output window sizes were chosen so they would fit in a
   standard VGA display.  I hope to learn how to adjust the sizes to
   use the current available width.

   The first button (eraser end of pencil) will clear both windows.

   The second button (question mark) will look up/compute the
   lat/long of the fix in the left window.  A magenta line (great
   circle) will be drawn from the map center to the fix.

   The third button (ruler) will compute the true bearing, magnetic
   bearing, and distance from the first fix to the second fix.  Less
   than two valid fixes will generate an error message.  A magenta
   line will be drawn from the first fix to the second fix.

   The fourth button (intersecting lines) requires four valid fixes
   in the input window.  The output is the lat/long of the
   intersection of a line from the first fix to the second, with a
   line from the third fix to the fourth.  Magenta lines will be
   drawn between the two pairs of fixes.

   Distances and true bearings are based on an ellipsoidal model
   of the Earth's surface (Fortran programs available at
   ftp://ftp.ngs.noaa.gov/pub/pcsoft).  There are some
   inconsistencies in segment lengths that are slightly less than 1/2
   way around the Earth, but that shouldn't be a problem in this
   application.  The ellipsoidal and spherical models are usually
   within several miles of each other.  The ellipsoidal model gives
   answers closer to charted values where there are differences.
   The problem may be with my conversion of the code to C++.

   Magnetic bearings use variation as computed by World Magnetic
   Model 2000 (Fortran program available at http://geomag.usgs.gov).
   Bearings may not agree with charted radials - that requires
   knowing the station declination for each navaid.