unblock_dlg(1) [debian man page]
UNBLOCK_DLG(1) General Commands Manual UNBLOCK_DLG(1) NAME
unblock_dlg - Insert linefeeds into an optional-format Digital Line Graph (DLG) file SYNOPSIS
unblock_dlg [-L] DESCRIPTION
The drawmap program processes USGS optional-format Digital Line Graph (DLG) files (along with other types of files) to produce customized maps. Drawmap is able to read these files in their native format. However, since the files usually don't contain any linefeeds, they are difficult for a human to read. Unblock_dlg filters a DLG file and inserts linefeeds for human readability. It takes input from the stan- dard input and writes to the standard output. The input data must be in uncompressed form, not in gzip-compressed form. Also, unblock_dlg does not work with SDTS DLG files. Unblock_dlg normally takes no options, but, if you use the "-L" option, the program will print out some license information and exit. Some DLG files already have embedded linefeeds. Unblock_dlg makes a feeble attempt to detect these files and abort. If the detection fails, the results are likely to be garbled, so it is wise to check the format of each file first. The drawmap program, with the "-i" option, will attempt to tell you whether a file contains linefeeds or not. The intended use of unblock_dlg is simply to let you conveniently examine the files to see what is in them. However, if you are in the mood for adventure, or if you need to repair a defective file, you can use unblock_dlg to make the file easy to edit, then you can edit the file as desired. Drawmap can still process the files after linefeeds are inserted, but will become confused if any line (including the linefeed) is more than 80 characters long. Drawmap may also become confused if you make any significant changes to the format of the file. You can use this capability to remove selected items from DLG files, when those items cause problems. You may even be able to repair faulty data. However, you need to be familiar with the content and structure of DLG files in order to do this effectively. You also need to remember that drawmap depends on DLG files having a predictable structure, and it won't properly parse files that violate this pre- dictability. Do this sort of thing only if you know what you are doing, or if you have a lot of free time on your hands. It should be noted that you can obtain a similar effect by using the command recommended by the USGS: dd if=inputfilename of=outputfilename ibs=8000 cbs=80 conv=unblock I prefer the unblock_dlg command because it simply replaces the last byte of each record with a linefeed. This lets me easily tell how long the original records were. The effect of unblock_dlg or dd can be undone by typing: dd if=inputfilename of=outputfilename ibs=8000 cbs=80 conv=block You may come across files that have a linefeed in the 81st byte. Drawmap doesn't like these, both because it can't tell (within the space of the first 80-byte record) whether the file contains linefeeds or not, and because the records exceed the maximum record length of 80 bytes. You may be able to repair such files by blocking them with the above dd command. SEE ALSO
unblock_dem(1), drawmap(1) Jul 24, 2001 UNBLOCK_DLG(1)
Check Out this Related Man Page
SDTS2DEM(1) General Commands Manual SDTS2DEM(1) NAME
sdts2dem - Convert a 24K USGS SDTS DEM to a DEM in the `classic' format. SYNOPSIS
sdts2dem [-L] | [sdts_dem_file.ddf [output_file_name]] DESCRIPTION
The U.S. Geological Survey (USGS) provides sites on the Internet with a lot of Digital Elevation Model (DEM) data. Depending on the reso- lution of the data, it may be available in one of at least three different formats: `classic' DEM format, a newer version of the `classic' format, or Spatial Data Transfer System (SDTS) format. The 24K DEM data (which are also called 7.5-minute DEM data) are only available for free-download in the SDTS format. The drawmap program can read the files in SDTS format; but the SDTS data come in the form of archives, each of which contains numerous files. It may sometimes be more efficient, and perhaps simpler, to store the data in the `classic' format. Sdts2dem is a program that converts each SDTS archive into a single classic-format DEM file. So far, sdts2dem only works with 24K DEM data, mainly because I haven't got any other data available to test against. If you invoke the program with the "-L" argument, it will print some license information and exit. In normal use, the first argument is an SDTS file name. Each SDTS DEM archive should contain one or more files with names of the form ????CEL@.DDF, where the '?' symbol stands for any single character, and the '@' symbol stands for any single digit. If you provide a single such file as an argument, sdts2dem will produce a clas- sic-format DEM file, based on the given SDTS file and the other files in the SDTS archive. (When you unpack the SDTS archives, you can change all of the resulting file names to all lower case and/or compress all of the files with the gzip program. If you are going to change to lower case, change all of the files. If you are going to compress the files, compress all of them.) The USGS takes each 1-degree-square block of latitude and longitude, and divides it into an eight-by-eight grid of 7.5-minute-square `quads'. The rows of this grid are labeled 'a' to 'h' from bottom to top, and the columns are labeled `1' through `8' from right to left. Each quad is then referred to by a name of the form `AABBBCD', where `AA' is the latitude of the southeast corner of the 1-degree block, `BBB' is the longitude of the southeast corner, and `C' and `D' represent the corresponding row and column labels. If you don't specify an output file name, the output file produced by sdts2dem will have the form `AABBBCD.dem'. If you specify an output file name, then your name will be used instead. LIMITATIONS
The converted files are in the newer version of the `classic' format. This newer format is theoretically backwards compatible with the older format, but has a bunch of new fields added to the file header (in space that the older format specified as blank). Most of these new fields will also be blank in the converted files, because their values are embedded in long human-readable text strings in the SDTS files, and I didn't consider it worth the effort to write a bunch of finicky code to dig them out. Three of the new fields are included, though: the horizontal datum, the vertical datum, and the vertical datum shift. These fields are useful in converting back and forth between coordinate systems, and in converting elevations to newer measurement scales. Sdts2dem will try to populate all of the fields specified in the original `classic' format. However, you may note some differences in the first 140 bytes of the header. One such difference is that the latitude and longitude of the southeast corner usually appeared in bytes 131 through 139 of the original `classic' format, in a truncated form. (The bytes in the DEM specification are numbered starting from 1.) In the new `classic' format, these two values are in bytes 110 through 135, in all of their un-truncated glory. As another example, sdts2dem doesn't even try to recover the free-format text field because it usually duplicates information present elsewhere, and because it isn't clear that we would end up with anything useful after automated conversion to SDTS and automated conversion back to `classic' DEM. Some floating-point numbers will have a different format from their original USGS versions. The USGS files normally put the first signifi- cant digit after the decimal point, while sdts2dem puts it in front of the decimal point. The actual numeric values are the same, but the format differs. SEE ALSO
drawmap(1), sdts2dlg.1n Jul 24, 2001 SDTS2DEM(1)