other versions
- wheezy 2.5-3
DRAWMAP(1) | General Commands Manual | DRAWMAP(1) |
NAME¶
drawmap - draw customized maps, using raw USGS data filesSYNOPSIS¶
drawmap [-l latitude1,longitude1,latitude2,longitude2] [-L]VERSION¶
This is the manual page for version 2.5 of drawmap.DESCRIPTION¶
The U.S. Geological Survey, and other sources, support sites on the Internet with many gigabytes of raw geographic data, mostly for the USA. Drawmap draws maps, using a subset of the available data. The relevant subset includes:- 250K Digital Elevation Model (DEM) files
- Each file covers a block, one-degree square, with a 1201 by 1201 grid of elevations (in meters). The extra sample in each direction is due to overlap of the DEM files at their edges. (Files for Alaska use smaller grids, with only 401 or 601 samples in the east-west direction.) For Hawaii and the "lower 48," the one-degree square is covered by elevation samples spaced 3 arc-seconds apart; and you will often hear these files called 3-arc-second files. In terms of distance along the ground, the sample spacing varies with latitude. It is generally less than 100 meters. (The "250K" means that the data were digitized from a map at the scale of 1:250,000.) Files of this type are currently available for free download from the USGS.
- 24K Digital Elevation Model (DEM) files (in the 'classic' format or the SDTS format)
- These files usually result from digitizing a "quad" map sheet. (Each 1-degree block of latitude and longitude, covered by a 250K DEM file, is further subdivided into an 8-by-8 grid to produce smaller blocks called quads.) The number of samples in each direction varies, from quad to quad, but there is roughly one sample per second of arc. These files differ from the 250K DEM files in that the samples are spaced a fixed number of meters apart rather than a fixed number of arc-seconds. Because each quad represents an area that is 7.5 minutes of latitude by 7.5 minutes of longitude, you will also hear these files called 7.5-minute DEMs. The USGS provides 24K DEM data for free download, in the Spatial Data Transfer System (SDTS) format. Some files in the older format are available from other sources, and may be available for purchase from the USGS.
- 100K Digital Line Graph (DLG) files (in the 'optional' format or the SDTS format)
- These files come in collections, each of which covers a quarter of the one-degree square covered by a 250K DEM file. The files contain information that allows segmented linear and polygonal features to be drawn on maps, including boundary lines, hydrographic features (streams, lakes, and so on), transportation features (roads, rail lines, pipelines, and so on), public land survey data, and hypsographic lines (the familiar contour lines of a topographic map). The different general classes of data come in separate files. Files of this type are currently available for free download from the USGS, in either the 'optional' format or the SDTS format.
- 24K Digital Line Graph (DLG) files (in the 'optional' format or the SDTS format)
- Like the 24K DEM files, each of these files covers a single quad. Except for their inherently greater detail, these files are essentially the same as the 100K DLG files. As with the 24K DEM files, these files are freely available in SDTS format, but are harder to come by in the 'optional' format.
- GTOPO30 files
- GTOPO30 files are similar to 250K DEM files, but with samples spaced 30 arc-seconds apart, and with a quite different format. (For the purposes of this manual page, you can consider GTOPO30 files as just another variety of DEM files.) While these files have relatively low resolution, they have the virtue of providing full coverage for the entire planet. Furthermore, they are currently available for free download.
- Geographic Names Information System (GNIS) files
- These files are basically lists of place names, with the addition of latitude/longitude and other information. They are available for free download.
Map Projection Used by Drawmap¶
The only type of map projection currently supported is not technically a projection at all, but simply a grid of latitudes and longitudes. (The word "projection" is a mathematical term describing the "stretching" of the earth's roughly-spherical surface onto a flat map.) Over limited areas, this latitude/longitude grid approximates a family of projections called cylindrical projections. By default, the grid is square, in the sense that 1000 pixels in the latitude direction represent the same number of degrees as 1000 pixels in the longitude direction. You can make the grid non-square by playing with the "-x" and "-y" options. There are several reasons for using this approach. First, the 250K DEM data contain sample points that are evenly spaced in degrees of latitude and longitude, making a simple grid the natural choice. (Drawmap was originally written solely with 250K DEM data in mind.) Second, this is an intuitive projection for small-area maps. Over small areas, it approximates the Transverse Mercator projection, a cylindrical projection that is often used for topographic maps. Third, the USGS DLG data and 24K DEM data are specified in Universal Transverse Mercator (UTM) coordinates, which are based on a rectangular grid of x-y distances. Over small areas, degrees of arc make a reasonable substitute for x-y distances, as long as the horizontal and vertical directions are appropriately scaled. And, finally, the latitude/longitude grid is also acceptable for large-scale maps. Since users of drawmap can produce maps covering any amount of territory, the latitude/longitude grid is a lowest-common-denominator that can handle any request.Introduction to UTM¶
In order to find your way around the data, it is useful to know something about the UTM system, which is an international military standard that divides the world into 60 zones (like panels on a beach ball), each of which is 6 degrees of longitude in width, and runs from 80 S to 84 N. A UTM projection, of a given zone, has a central meridian bisecting the map from top to bottom, which serves as a reference from which the locations of other features are derived. Zone 1 runs from 180W to 174W, with its central meridian at 177W. Successive zones run to the east, with zone 2 beginning at 174W. In the UTM system, the location of a feature is specified by its distance to the north of the equator, in meters, and its distance eastward from the central meridian, in meters plus 500,000. In the southern hemisphere, 10,000,000 is added to the distance north from the equator. (The purpose of the 500,000 and 10,000,000 offsets is to avoid having any negative distances.) Drawmap internally converts UTM distances into latitude/longitude coordinates before plotting features on a map. Included with drawmap are two programs, utm2ll and ll2utm, that you can use to convert back and forth between UTM coordinates and latitude/longitude coordinates. You don't really need these to use drawmap, but they are useful in their own right. (Be sure to read the associated manual pages to get information on conversion accuracy.) The result of the cylindrical projection is to map each one-degree by one-degree latitude/longitude patch (on the curved surface of the Earth) into a rectangular area (on the map projection). In the process, of course, the projection distorts shapes and areas as it stretches the beach-ball panels into flat rectangles; and these deviations get larger as the distances from the central meridian and equator increase. Distortion may also occur due to the way the latitude lines are projected. In the classical Mercator projection, for example, the latitude lines are spaced farther and farther apart as they near the poles (reaching infinity at the poles themselves). This gives the map some useful directional properties, but grossly distorts shapes and areas near the poles. (You can approximate this kind of stretching with drawmap by using the "-x" and "-y" options to vary the number of pixels per longitudinal or latitudinal degree; but remember that, within a drawmap map, latitude and longitude always vary linearly.) It is a fact of life that mapping a sphere onto a flat piece of paper is going to produce distorted results. Various types of map projections are chosen for the ways they preserve one or more valuable features of a globe-shaped map (features like shape, area, distance, and direction). In the Transverse Mercator projection, the distortions are reasonable for points that are within several degrees of the central meridian, and for maps that aren't too near the poles. In fact, a cylindrical projection has the property that it is "conformal" in the mathematical sense, meaning that it preserves angles (and hence shapes and areas) within small areas of the resulting map. The classical Mercator projection is also conformal in the cartographic sense, meaning that it preserves angles everywhere on the map. (In other words, if the great-circle route from Newark to Peoria is X degrees east-of-north on the globe, then a straight line from Newark to Peoria on a classical Mercator map is also at an angle of X degrees east-of-north.) Of course, over large areas, the classical Mercator projection can grossly distort shapes and areas. Since, with drawmap, you can define your own image boundaries, the output map may span any portion of one or more UTM zones, and zero or more central meridians may appear at arbitrary positions within the map boundaries. Over small areas, stretching latitude/longitude angles into a square grid (which is what drawmap does) produces roughly the same map image as a square grid of UTM coordinates would. Try to keep the map area smaller than a UTM zone, and center the map on a central meridian, if you want to use the map as a UTM surrogate. UTM coordinates are usually used for areas much smaller than a UTM zone, such as a 7.5-minute USGS quad. For such small areas, the geometrical difference between latitude/longitude angles and surface distances is small.Introduction to the Different File Types¶
At the time this manual page was updated (August, 2001), various DEM, DLG, and GNIS files were available for free download by following appropriate links from http://mapping.usgs.gov/. For some files, convenient graphical interfaces were available to let you locate desired files by clicking on a map. Some DEM, DLG, and GNIS files, and the GTOPO30 files too, were available via FTP from edcftp.cr.usgs.gov, in the pub/data directory. (In the case of GNIS files, there was simply a pointer to another download site.) Access to the various files changes over time, so you may have to do some searching to find what you want. Ordinary DEM and DLG files (that is, non-SDTS and non-GTOPO30 DEM and DLG files) are in (gzip-compressed) ASCII text format, and are human readable (when uncompressed) except that they generally don't contain linefeeds to structure them into easily-editable lines of text. (Some newer DLG files do have linefeeds; and I have come across some DEM files with linefeeds also.) The web site provides information on how to add linefeeds and view the file contents, but drawmap is able to read and use the files in their native state (in gzip format, with a ".gz" suffix on the file name). Drawmap can also process the files in uncompressed form. It is okay to have linefeeds in ordinary DLG files, as long as no line is longer than 80 bytes (including the linefeed); and it is okay to have linefeeds in ordinary DEM files, as long as no line is longer than 1024 bytes (including the linefeed). The drawmap distribution contains the block_dlg and block_dem programs to add appropriate linefeeds to DLG and DEM files but, beyond that, you are on your own if you want to muck around inside the files. In general, you can add or remove records to or from a DLG or GNIS file, as long as you don't violate the record structure. For example, I have added linefeeds to a DLG file (using the block_dlg program), deleted a record, added a record, and then used drawmap to process the file. If you want to do this sort of thing, then you may also want to get copies of the various guides and standards for the different kinds of files. These documents are available through the web sites. Using SDTS files is a bit more complicated. SDTS data generally come in the form of tar archives, compressed with gzip. Each such archive should be unpacked into a separate directory. This is true even if there are several archives in a single directory on the download site. (Transportation archives, for example, normally come in triples --- one each for roads, railroads, and other transportation features. These triple archives should be unpacked into three different directories to avoid files from one archive overwriting files from another.) When you provide SDTS files as input to drawmap, you don't have to include all of the unpacked files on the command line. For DEM files, each archive should contain one or more files with names like ????CEL@.DDF, where the '?' symbol stands for any single character, and the '@' symbol stands for any single digit. Use one or more of these file names (each preceded by "-d") just as you would an old-style DEM file name, and drawmap will figure out the names of the other files in the archive. For DLG files, each archive should contain one or more files with names like ????LE@@.DDF. Use one or more of these file names just as you would an optional-format DLG file name. There is also a Master Data Dictionary available for each kind of DLG file. At present, drawmap makes no use of these. Once you have unpacked the archives, you can compress the individual files with gzip if you wish. If you do compress them, compress every file that has a ".DDF" extension. You can also change the file names to all lower case, but don't mix and match upper and lower case files. Other than changing upper to lower case, DO NOT change the file names. Drawmap uses the file names to deduce what to do. The GTOPO30 files also come in archives, and must be unpacked before use. (You don't need to unpack each archive into a separate directory, but it isn't a bad idea.) Once they are unpacked, you can compress the individual files if you wish, as long as you compress both the ".HDR" file and the ".DEM" file, which are the only files that drawmap uses. (The same guidelines apply as for SDTS files: try to be consistent with upper/lower case, compression, and the like.) There is one GTOPO30 archive that contains a Polar Stereographic projection of Antarctica. Drawmap can't handle that one. On the FTP site, there is also a gtopo30hydro directory. The files in this directory are derived from GTOPO30 data, but use a Lambert Azimuthal Equal Area projection. Drawmap does not currently handle these either. To use GTOPO30 files, simply invoke the "-d" option, and provide as a parameter the file whose name ends in ".HDR" (or ".HDR.gz" if you compressed the individual files). Use caution with GTOPO30 data. Each data set spans a large area, and the memory needed to read it all in can be enormous. You can limit the amount of memory required by using the "-l" option to restrict the range of the image to a subset of the available GTOPO30 data. Be careful with downloads. Some download software will uncompress gzip files during a download but still store the files with a ".gz" suffix. Other download software will leave the data compressed, but remove the ".gz" suffix. Drawmap will become confused when this happens. It relies on the suffix to determine the file type.Drawmap Tidbits¶
If you provide all three types of data (DEM, DLG, and GNIS) as input, then drawmap will first produce a shaded relief map (or, when "-c" or "-C" is specified, a contour map), and then overlay it with data from the DLG files (with the data from each DLG file, in succession, being overlaid on all previous data), and then overlay everything with place names from the GNIS file. If you omit the DEM data, then the shaded relief (or contouring) is replaced by a simple white background. Drawmap will take whatever information you provide and assemble a map containing just that information. If you provide information that falls outside of your specified map boundaries, it is simply ignored. If you supply any DEM data, and if you don't specify a contour map (via the "-c" or "-C" option), and if there is room, a color key will be placed at the bottom of the map to help you interpret the shaded relief. If you specify the "-c" or "-C" option, then a message about the contour interval will appear at the bottom of the map, if there is room. Also, if there is room, a title will be placed at the top, containing the lowest and highest values of longitude and latitude for this map, and containing the latitude, longitude, and elevation of the points on the map of lowest and highest elevation. (Actually, of course, there may be multiple points on the map that attain the lowest or highest elevation, but drawmap shows only the first ones that it finds. Furthermore, for low-resolution output images, that have small x and y pixel dimensions relative to the granularity of the available DEM data, drawmap may be a little sloppy about the exact latitude and longitude, and about the exact maximum and minimum elevations.) If only one DEM file is supplied, the location name from the DEM file header will be included in the title. (Sometimes, it is hard to figure out exactly what the correct name is, so don't be surprised if the title looks a bit strange.) Latitude and longitude tick marks will be placed around the map boundaries, with one tick every tenth of a degree. Tick marks at full degrees and half degrees will be larger and (if there is room) will have text next to them that specifies the latitude/longitude. Tick marks can be turned off with the "-t" option. North is always at the top of the map, and east is always at the right.OPTIONS¶
- -l latitude_low,longitude_low,latitude_high,longitude_high
- You usually must provide latitude and longitude coordinates that define two diagonal corners of the image. They must be separated by a comma or other non-space character (as in: -l 34.3,-109,35.9,-109.713), and they must be in decimal degrees. Note that east longitude is positive and west longitude is negative. Similarly, north latitude is positive and south latitude is negative. If you only provide one "-d dem_file" option, then you can omit the "-l", and the corners of the single DEM file will be used to define the map boundaries. This is useful when you are simply trying to figure out what area a given DEM file covers.
- -L
- Print out the program license information and exit.
- -o output_file.sun
- You may provide an output file name. It can be any name that you choose. By convention, SUN rasterfile images have a ".sun" file name extension, but you can omit it if you wish. If you provide no name, then "drawmap.sun" is used. (If you use the "-h" option, and provide no name, then "drawmap.pgm" is used.)
- -d dem_file
- You can provide as many DEM files as you want. (There is a
hard-coded limit of 1000 files in the source code, but it is easily
changed.) Since each file covers a limited area, it can take quite a few
to cover the image if you specify a large latitude/longitude range for the
image boundaries.
- -c contour_interval_in_meters
- This option has no effect unless you provide one or more DEM files. The DEM files are normally processed into multicolored shaded relief. If you include the "-c" option, then the shaded relief is replaced by a set of contour lines (orange lines on a white background) that represent elevations separated by the given contour interval (in meters). Note that it is also possible to generate contour lines by using data in hypsographic DLG files, making the "-c" option seem somewhat redundant. However, at the present time, the area covered by the available DEM files is a superset of the area covered by hypsographic DLG files. Furthermore, the "-c" option allows finer control over the spacing of contour lines than is available with hypsographic DLG data. On the other hand, the DLG data is likely to be more precise about the locations of contours.
- -C contour_interval_in_meters
- This option is exactly the same as the "-c" option, except that it doesn't use a white background. Instead, it fills in the areas between the orange contour lines using a rotating set of solid colors. These distinct colors make it easier to follow elevation contours as they swirl around the map. (The colors come from the same set used to generate shaded relief, except that white is excluded because it tends to stand out too much from the other colors.)
- -g gnis_file
- Only one GNIS file is allowed. This is not really a
restriction since you can edit these files with an ordinary text editor,
making them contain whatever place names you want to include. In fact, it
is normally necessary to winnow out much of the available GNIS data;
otherwise the map would be plastered nearly solid with place names.
- -a attribute_file
- There are three high-level types of objects in a DLG file:
Nodes (points where lines join), Areas, and Lines. These objects often
have attribute codes associated with them. Each attribute code consists of
a major code and a minor code. The major code denotes a particular general
type of feature, such as 50 for hydrographic features. The minor code
denotes a subtype, such as 412 for a stream, or 421 for a lake or pond.
- -x x_size and -y y_size
- The horizontal and vertical dimensions of the map, in
picture elements (pixels), can be specified via the x and y options. You
can supply either or both of them. If you don't provide them, they will be
selected so that 250K DEM data can be displayed at one half of full
resolution.
- -w
- The DLG files describe bodies of water within land areas. However, they don't generally provide polygonal areas to define sea-level water in coastal areas. When you use the "-w" option, drawmap will attempt to make ocean areas bright blue, just like the inland waterways. This feature is provided as an option, rather than as the default, because it sometimes produces odd results. For example, some DEM data in the Sacramento, CA, area give elevations below sea level. With the "-w" option, the map ends up with anomalous-looking sub-sea areas surrounded by water. (This representation may, in fact, be correct. The areas may be polders, pumped out for farming purposes. I don't know. But they look odd.)
- -n color_table_number
- Drawmap provides a choice of four color schemes for
shaded relief. The default is color table 2, which provides a
natural-looking color scheme. Using the "-n" option, you can
instead choose color table 1, a very-neutral non-obtrusive scheme; color
table 3, a natural-looking but garish scheme reminiscent of maps in school
textbooks; or color table 4, a very garish scheme designed to provide good
perception of variations in elevation. From 1 to 4, the tables are ranked
in order of increasing obtrusiveness.
- -r relief_factor
- Normally, when drawing shaded relief, drawmap
manipulates the colors in the color table so as to provide maximum
sharpness in the relief. In other words, the shading varies from full
brightness all the way to black.
- -m relief_magnification
- Some regions of the world are relatively flat, with only
minor relief. In such regions, it may be desirable to make the relief
stand out more sharply. The "-m" option allows you to supply a
magnification factor that enhances elevation differences. The factor must
be greater than or equal to 1.0, and the default value is 1.0. (The
"-m" option has no effect when you are requesting contours with
the "-c" or "-C" option.)
- -z
- When the given DEM data span a small range of elevations,
shaded relief uses only a small portion of the color table. In fact, if
the range of elevations is small enough, the entire map may end up using
only a single color, with whatever light/dark shading is called for by the
limited roughness of the terrain. This results in a pretty boring map.
- -i
- When you provide this option, drawmap doesn't produce a
map. Instead it prints out some useful information about all of the DEM
and DLG files that you specify on the command line.
- -h
- When you provide this option, drawmap doesn't
produce a map. Instead it takes the DEM information and produces a
height-field file, in Portable Graymap (PGM) format. The file is readable
ASCII, beginning with the line "P2", which identifies the file
as a PGM file. The next line contains the x and y dimensions, and the
maximum elevation in the file, separated by white space. Then the file
includes all of the elevation samples, one per line, beginning with the
top west-to-east row, and followed by all of the other rows in sequence.
Finally, there are some commentary lines containing information about the
data, including the latitude/longitude of the southeast and northwest
corners, and the minimum and maximum elevations.
- -t
- Normally, drawmap will put tick marks and latitude/longitude numbers around the borders of the map. However, for maps that span large regions of the earth, these tick marks and numbers can overlap and interfere with one another. Drawmap makes a limited attempt (with emphasis on the word "limited") to reduce the density of the markings as the map area increases. Rather than try to adapt to any situation, though, I chose to provide the "-t" option, which totally shuts off production of tick marks and latitude/longitude legends. It is for use in situations where the border markings become cumbersome.
- dlg_file
- Any argument that doesn't match any of the above options is assumed to be a DLG file. You can add as many as you like. Note that files are processed in the order given, and each file is overlaid by the ones that come after it. Thus, you generally want to put "transportation" files after "hydrography" files, so that roads will be shown as crossing over streams instead of the other way around.
EXAMPLES¶
To generate a simple shaded relief map for a portion of the southern California coast, with the size of the map set to a reduced resolution of 300x300 pixels (full resolution would be 1200x1200): drawmap -d santa_ana-w.gz -l 33,-117,34,-118 -x 300 -y 300 To extract the upper right quadrant of the above map, and display it at full resolution: drawmap -d santa_ana-w.gz -l 33.5,-117,34,-117.5 -x 600-y 600 To add in some place names from a GNIS file (that you have prepared in advance, using llsearch): drawmap -g gnis_santa_ana_west -d santa_ana-w.gz
-l 33.5,-117,34,-117.5 -x 600 -y 600 To add in some DLG files for hydrography: drawmap -g gnis_santa_ana_west -d santa_ana-w.gz
-l 33.5,-117,34,-117.5 -x 600 -y 600
santa_ana-e_CA/hydrography/522274.HY.opt.gz
santa_ana-e_CA/hydrography/522275.HY.opt.gz
santa_ana-e_CA/hydrography/522276.HY.opt.gz
santa_ana-e_CA/hydrography/522279.HY.opt.gz To draw a map of western Europe, using GTOPO30 data, first download the w020n90.tar.gz and w020n40.tar.gz archives, and unpack them by typing: gunzip -c w020n90.tar.gz | tar xf - gunzip -c w020n40.tar.gz | tar xf - Then draw a map by typing: drawmap -t -x900 -y1200 -w -l30,20,70,-10 -d W020N90.HDR
-d W020N40.HDR
LIMITS¶
As distributed, drawmap is limited to 1000 DEM files, one GNIS file, and one attribute file. The DEM limit is easily changed in the code. As explained above, the GNIS limitation is not really a limitation, since you can concatenate as many GNIS records as you want into a single file. I'm not sure how to implement multiple attribute files, or even what they would be used for. The number of DLG files is only limited by your system's limits on command-line length. Another limitation arises from the fact that drawmap must be able to read all of the input data into memory. If you want to produce large maps, then you must have large memory. When dealing with 24K DEM data, there will often be visible seams between the data from different files. There are several reasons for this. First, there can be marked differences in data quality between files. Lower quality data can have a lot of anomalous "fuzz", which forms discontinuities with adjacent data of higher quality. Even if one ignores other sources of discontinuity between data blocks, the visual difference between the two quality levels can be quite obvious. Second, the calculations used to map raw data into the image may produce discontinuities, because numeric rounding may pull a data point one way, at the edge of one block of data, and may push an adjacent data point the other way, at the edge of the adjacent block of data. Third, it goes without saying that there may be residual bugs in the code that handles the DEM files. Finally, there may be flaws in the data itself. For example, some 24K SDTS DEM files, produced before January 2001, are known to have small positional errors. (The non-SDTS DEM files don't suffer from this problem.) Similar seams may appear between blocks of GTOPO30 data, but aren't usually as obtrusive. There is another issue involving 24K DEM data. Each 24K quad represents a latitude/longitude square, with one eighth of a degree on each side. However, the native coordinate system for 24K DEM quads is a UTM grid. In UTM coordinates, the latitude/longitude square becomes an approximate quadrilateral, which often has no two sides of the same length. The four sides of the quad will usually be tilted at slight angles to the UTM axes. It is this odd-shaped quad that is stored in a 24K DEM file, as a set of elevation samples that are evenly-spaced in UTM coordinates. (The spacing is normally 10 meters or 30 meters.) Different columns of sample points may contain different numbers of samples, depending on where the columns intersect the slanting sides of the quad. An evenly-spaced collection of UTM points does not map onto an evenly-spaced set of latitude/longitude points. In order to map the UTM data onto a latitude/longitude grid, drawmap must warp the points into new relative positions, turning the unevenly-shaped UTM quadrilateral into a latitude/longitude square. (You might picture this by imagining an odd-shaped quad, which is cut out of a rubber sheet and covered with a uniform grid of dots, and which is then stretched into a perfect square.) During this warping process, rounding quantization can produce some diagonal artifacts in the map image. (We could sidestep this issue by making drawmap produce maps using an optional UTM grid, rather than always using a latitude/longitude grid. However, drawmap is not presently so endowed.) Rounding quantization may also sometimes produce anomalous vertical and horizontal linear features on the map, in the form of small discontinuities in the changing elevation. This can happen for data of any level of detail; and is a result of trying, for example, to stretch a 100-by-100 grid of data points to cover a 101-by-101 grid of image pixels. The data don't quite fit, and something, somewhere, has to give. Whether artifacts are horizontal, vertical, or diagonal, their incidence can sometimes be reduced by adjusting the values of the "x" and "y" image dimensions. However, while this is usually straightforward for 250K DEM or GTOPO30 data, it can be a challenge for 24K DEM data. This is because, while drawmap can tell you the height and width, in UTM samples, for the raw 24K DEM data, it doesn't know how to figure out an optimal width and height after the data are warped onto a latitude/longitude grid. Furthermore, when you provide more than one 24K DEM file, there is no truly optimal width and height for the image, because the quadrangle covered by each file has a slightly different shape from the quadrangles adjoining it. What works well for one quad may not be the best for another. I don't have a general rule of thumb for adjusting the width and height. I usually just try a few minor tweaks, to the "x" and "y" values, and pick the one I like the best. Faced with various possible image artifacts, drawmap tries to smooth things out, but faces a tradeoff between making the image look good (and blurring some of the good data), or leaving the good data unaltered (resulting in some esthetic imperfections). Drawmap tends to err on the side of leaving good data untouched at the expense of leaving some artifacts in isolated spots on the image. It tries hardest to preserve the pristine data when the map image dimensions are approximately the same as the resolution of the raw data. This is because, in such cases, there is approximately a one-to-one mapping between the raw data and pixels in the image. It seems useful to preserve this correspondence, and not to blur it with smoothing algorithms. When you specify image dimensions that differ considerably from the resolution of the data, drawmap takes more liberties in its attempt to produce pleasing results. If the map resolution is greater than the resolution of the data, then drawmap must replicate data points in order to fill up the map. It does some smoothing on the finished image to reduce the resulting "checkerboard" effect. If the data have considerably greater resolution than the map image, then drawmap has more data than it needs, so it averages adjacent data points to determine each elevation in the map. Thus, one alternative for reducing image artifacts is to produce a map at, say, half resolution. If, for example, a 24K DEM file has a 300-by-400 sample grid, then you might try drawing a map with "x" set to 150 and "y" set to 200. The averaging operation will then smooth the data, which will usually reduce image artifacts. If you are using the "-c" or "-C" option, and the given DEM files do not fully cover the image, there may be anomalous contour lines along the borders of the valid data. (This happens when you fail to completely tile the image with DEM files.) This problem is a result of the way the contours are produced. It may get fixed some day, but isn't a high priority since it is usually hard to mistake these anomalies for valid data. The code that reads SDTS files is not a complete implementation of all of the relevant standards involved in SDTS. In particular, SDTS relies on the ISO 8211 standard, and it would not be at all difficult to construct a valid ISO 8211 file that drawmap would be unable to read. The code is intended to be smart enough to read SDTS files from the USGS, and hopefully from other sources, but it is not necessarily smart enough to read any file you might throw at it. If you find a USGS SDTS file that drawmap can't read, I would be interested in hearing about it. (I can't promise to fix the problem, because the range of possibilities is large, and I don't want to end up trying to support every dialect that happens to pop up.) Most of the SDTS DEM files I have examined store elevations as binary two's-complement integer numbers. Some files, however, store them as binary floating-point numbers, in IEEE 754 format. When it encounters such a file, drawmap simply assumes that your computer uses IEEE 754 floating point as its native floating point format. If this assumption is not true, then the file won't be correctly parsed. There may be some DLG attribute codes that are not properly handled. While I have downloaded and processed thousands of DLG files, in the various supported formats, I can't be sure that this subset of the available files spans the full range of possibilities. Also, it is not always clear, in the relevant specifications documents, exactly how attributes should be encoded, in either the old-style DLG files or the newer SDTS DLG files. I know of at least a few ambiguities that I am not sure how to handle. These are documented in the source code. Furthermore, there are numerous special cases, some of which appear to involve relatively small subsets of the USA. I put a lot of effort into trying to properly process the attributes, but it is difficult to test every possible situation, and my patience for dealing with finicky details is not infinite.SEE ALSO¶
llsearch(1), utm2ll(1), ll2utm(1), block_dlg(1), block_dem(1), sdts2dem(1), sdts2dlg(1), pgm(1)August 1, 2001 |