![]() |
|
|
Главная --> Промиздат --> Map principle ![]() Figure 6.2. The node snapping function in GIS projection units of the LOCATION. In general reasonable values for snapping thresholds depend on the map scale, such as: 1:5000 - 1:10000: Snap distance 1-2 m on ground 1:10000 - 1:25000: Snap distance 2-5 m on ground 1:25000 - 1:50000: Snap distance 5-10 m on ground You should enter values around 0.002 for Enter new Dig threshold to fulfill the above recommendations. The threshold according to ground distances is calculated immediately. The module v.digit provides different colors for distinguishing various vector types and the label status. The color of snapped nodes will change, with open nodes being green by default, and snapped nodes turning to magenta. Digitizing elevation contour lines. To make the digitizing of contour lines more efficient, GRASS offers a semi-automatic labeling of digitized contours. First, digitize the contour lines without attributes. Then switch to the Label menu by pressing L. Now hit i for contour interval and enter the appropriate value for interval of lines, default is the increment of 5 per line. The map units are usually meters, hence this represents 5 m contour intervals. The application of the values to a set of lines is done by digitizing a new temporal line across the contour lines for selection. This is done by mouse after pressing c for Contour labels . Now select the lowest and the highest contour line. Both points are connected by a line crossing the contours in between. If one or both of these contour lines are not labeled yet, GRASS will ask for the elevation of this unlabeled line: Enter elevation for this line . The labeling of the contours in-between will only be done if the defined elevation interval matches the values of the lowest and highest line. Common digitizing problems and solutions. A common digitizing problem is that area boundaries are not closed or lines intended to be connected ( polylines ) are broken. Lines too short and not reaching another traverse line are called undershoot , lines too long which cross another line without having a node at the intersection are called overshoot (see Figure 6.3). To fix these problems, you should use the snapping function. Note that snapping is also implemented in additional vector modules such as v.support. During the editing process within v.digit, the graphics screen can become cluttered for various reasons. Press the key ! to correctly replot the graphics. You can find further information about digitizing in the CERL-Tutorial: v.digit which is available on the GRASS Web site (section Documentation ). Post-Digitizing issues. As a general rule, you should always run v.support after using v.digit to build the topological information for the vector map. If needed, you can add/modify the category labels for vectors. You have to start v.support in interactive mode and select the option Edit the category file . See Section 6.2.2 for details. Maps containing intersecting vectors without nodes at the line intersections are called spaghetti maps which are topologically incorrect. To resolve this problem, the module v.spag can be used (see Figure 6.4 illustrating the functionality) which inserts nodes at the line intersections. To avoid unintended ![]() Figure 6.3. Overshoots and undershoots in vector maps ![]() Figure 6.4. Correction of spaghetti digitizing modifications of your digitized data, running it on a map copy (generate with g.copy vect=oldmap, newmap) is recommended. Additional modules for cleaning the vector data are v.clean and v.prune. Both have to be used carefully. Again, we recommend working on a copy of the original vector map to avoid complications. The module v.clean removes dead lines from a vector map. Dead lines are vectors that have been marked deleted in v.digit. The module v.prune can be used to remove excessive nodes from a map. Use it with care as you can simplify complex areas/polygons to squares or triangles if you remove too many nodes. 6.2. METADATA AND ATTRIBUTES MANAGEMENT Internally, GRASS 5.3 handles only one attribute per vector. However, by linking GRASS to an external database management system (DBMS), multiple attribute per vector object can be managed. The management of multiple attributes for vector data in conjunction with an external database management system will change substantially for GRASS 5.7 that is under development and is not covered in this book; please check the Web site for the most current updates. To find information about a related module that is already available, run (preferably in HTML mode): g.manual database
|