The Laser-Scan STRUCTURE package is a structured IFF creation and processing package. The package operates on Digital Equipment VAX and Alpha AXP series computers running the VMS operating systems. See later sections for details of hardware and software prerequisites. It is recommended that the reader becomes familiar with the "LAMPS Environment Guide" which outlines in some detail the hardware and software environment required by the LAMPS package as a whole (of which STRUCTURE is but a part). LAMPS is the *Laser-Scan *Automated *Map *Production *System.
The acronym IFF stands for *Internal *Feature *Format. IFF is the Laser-Scan vector file format generated by LASERAID and other Laser-Scan mapping systems and used as the data structure throughout the Laser-Scan LAMPS system. IFF files are binary and cannot be manipulated directly using a text editor. The STRUCTURE package offers the user to a variety of geometry idealisation options and also provides the option for generation of IFF link node data structure. The link/node structured IFF data data can be used for many network processing operations, such as polygon generation, route planning, map colouring and data-base compilation.
Although all data input to the STRUCTURE package utilities must be in IFF format, conversion software is available to transfer a variety of commonly used customer formats to and from IFF format. See the CONVERT package SPS for details of supported customer format conversions.
The STRUCTURE package consists of independent modules which together form a powerful data structuring system within an automated mapping environment. All the modules have common command syntax which is decoded using the Command Line Interpreter as used by the VMS utilities. STRUCTURE modules all generate VMS format messages and set VMS DCL symbol $STATUS on image exit. In command files, the success of a preceding STRUCTURE module may be tested using $STATUS before proceeding. All STRUCTURE modules are comprehensively documented in the STRUCTURE Reference Manual and the documentation includes an explanation of messages output by the modules together with suggested user action.
STRUCTURE modules run under OpenVMS VAX Version 5.5-2, or OpenVMS AXP V6.1 (or later version, assuming continued upward compatibility by DEC). STRUCTURE modules may be run concurrently with other interactive and batch processes.
The prerequisite Laser-Scan MAPPING package provides IFF and FRT file interface libraries.
The Laser-Scan LITES2 interactive digitising and editing software is recommended for digitising vector input data.
It is recommended that the reader becomes familiar with the LAMPS Environment Guide which outlines in greater detail the hardware and software environment required by the LAMPS package as a whole (of which STRUCTURE is but a part).
The minimum hardware and software requirements for any future version of this product may be different from the minimum hardware requirements for the current version.
STRUCTURE is a fully supported Laser-Scan standard software product.
The facilities offered by STRUCTURE are described by module.
ILINK (IFF data tidying and structuring)
ILINK is an IFF geometry tidying and link-node structuring utility offering the following features:
The structured data generated by ILINK permits network processing operations, such as polygon generation, route planning, map colouring and structured data-base compilation.
Six geometry idealisation options are available:
OPTION 1 (LPJOIN) - Feature-end to feature joining. This process is useful when feature ends fall just short of, or project just over other features, or where features are required to move onto point features which are close to them. For example, railway lines being moved so as to pass exactly through railway stations.
OPTION 2 (PPJOIN) - Feature-end to feature-end joining. For example, where a digitised network such as a road map needs to have feature ends within some small tolerance brought together to arrive at a unique point
OPTION 3 (LLJOIN) - Feature alignment. For example, where a polygon map has been digitised as a series of closed polygons and these are required to be aligned.
OPTION 4 (MERGE) - Feature merging. For example, where a polygon map has been aligned as a series of closed polygons and these are required to be merged so that duplicate boundary sections become single shared-features.
OPTION 5 (BREAK) - Breaking features where they cross. For example, where a wire-frame perspective projection is required to be broken into separate line features between every point where lines cross, so that hidden line sections can subsequently be edited out manually.
OPTION 6 (FREE_ENDS) - Reporting free ends. All free ends (1-arm nodes) are found and reported, either to a LITES2 command file or as point features in a separate final IFF layer.
In addition to the geometry idealisation options ILINK also provides IFF link/node structuring.
OPTION 7 (STRUCTURE) - This option is useful when the link-node structure resulting from the ends with ends joining operation described above, is required for subsequent processing. For example, the compilation of a structured data base or route planning.
OPTION 8 (SORTARMS) - Junction Structure 'arm' sorting. The arms in the IFF JB (Junction Block) node_to_link pointer entries are sorted (in situ) into order of increasing orientation angle (measured anti-clockwise from the positive x axis).
Because each of the above options is independent, they can be used individually, or can be applied successively to transform an image in a series of iterative steps.
This makes ILINK very flexible; for example, the following sequence of ILINK command lines:
$ ILINK infile file1/PPJOIN/JNTOL=4<CR>
$ ILINK file1 file2/LPJOIN/JNTOL=4<CR>
$ ILINK file2 file3/LLJOIN/JNTOL=1.5<CR>
$ ILINK file3 file4/MERGE<CR>
$ ILINK file4 file5/BREAK<CR>
$ ILINK file5 outfile/STRUCTURE<CR>
will result in joining ends with ends; followed by joining ends to lines; followed by feature alignment; followed by merging; followed by breaking lines where they touch or cross; and finally producing a link/node structured IFF output.
Specific features may be selected for processing on the basis of IFF layer and/or feature code. All other features will be transferred from input to output IFF files unchanged.
The positions of any unattached link ends and zero length links may optionally be recorded in a LITES2 guidance file. This facilitates semi-automatic editing of the IFF data using the LITES2 graphical editor.
RELHT (IFF feature relative height coding)
RELHT assigns relative heights to the ends of all links in a junction structured IFF file. RELHT requires for input the junction structured IFF file and an ASCII file containing a user defined table of feature code height priorities. The junction structured file may be produced by either ILINK or LASERAID.
The relative height coding for the ends of each link are placed in type 10 and type 11 AC (Ancillary Code) entries for the start and end of each link respectively.
The junction structure is not preserved in the output file.
The relative height coding may be used to determine which feature "lies on top of" another for reprographic and GIS applications. For example, the relative height infomation may be used to ensure that motorway features are plotted as a continuous feature, while a river feature would be broken where it intersects with the motorway.
The junction positions of any doubtful link ends may optionally be recorded in a LITES2 guidance file. This facilitates semi-automatic editing of the IFF data using the LITES2 graphical editor.
RELHT offers the option of an ASCII output file to contain a list of the coordinate position and the number of arms for all the junctions in the input IFF file.
ICASE (generation of road casings and area fills)
ICASE is suited to the production of large scale schematic road casings and area fills as often seen in road atlases.
Given a junction structured IFF file containing road centrelines, a table of feature codes, priorities and road widths, the program will create an output IFF file containing road casings and area fills for the selected features.
It is important to realise that the input road centreline data must be geometrically clean to prevent spurious results occurring.
Note that for small scales work, it is often easier to generate road casings 'on the fly' during display and plotting, using the prioritised multiple representation capabilities of FRTLIB now used in LITES2 and FPP.