GENERALIZE2

 

generalizes the arcs in a line coverage.  GENERALIZE2 is similar to ARC GENERALIZE (BENDSIMPLIFY option), except that in the process of generalizing arcs it also moves them to resolve spatial conflict with other arcs, a la OVERPOSTing.

__________________________________________________________________________

 

GENERALIZE2 <in_cover> <out_cover> <arc_move_item> <node_move_item> <buffer_distance> <cell_size> {block_cover} {block_buffer} {weed_tolerance} {JOIN | NOJOIN} {sequence_item | ANGLE | DENSITY} {split_tolerance} {spline_tolerance}

 

ARGUMENTS

 

<in_cover> - the input arc coverage.

 

This coverage is not altered by GENERALIZE2.  Manipulations to the input arcs are done so in a copy of the <in_cover>.

 

<out_cover> - the name for the output arc coverage.

 

The name must not be the name of an existing file or directory.

 

<arc_move_item> - the item in the <in_cover> AAT that indicates which arcs can be moved, in the event of spatial conflict.

 

An <arc_move_item> value of zero indicates that the arc can be moved.

 

Any value other than zero indicates that the arc can not be moved.

 

<node_move_item> - the item in the <in_cover> NAT that indicates which nodes can be moved.

 

A <node_move_item> value of zero indicates that the node can be moved.

 

Any value other than zero indicates that the arc can not be moved.

 

<buffer_distance> - the minimum desirable distance (in map units) between arcs in the <out_cover>.  Arcs that are within this tolerance will be separated.

 

<cell_size> - the cell size for the grids created to generalize the arcs and resolve spatial conflict.

 

WARNING - GENERALIZE2 is slow, so a small <cell_size> may result in a long processing time.

 

{block_cover} - the input arc coverage whose lines will also be used to alter the location of the arcs in the <out_cover>.  <out_cover> arcs will be separated by {block_buffer} from the {block_cover} arcs.  By default no coverage is used.

 

For example, the {block_cover} might be a stream coverage, and the <in_cover> a road coverage whose arcs are not to pass within the {block_buffer} of any streams (except at stream crossings.)

 

{block_buffer} - the distance to buffer lines in the {block_cover}.

 

<in_cover> arcs ideally will not pass within the {block_buffer} of the arcs in the {block_cover}.

 

{weed_tolerance} - the weed tolerance used by ARC GENERALIZE (BENDSIMPLIFY option) to generalize the <out_cover> arcs.  Defaults to <buffer_distance>.

 

If you don't wish ARC GENERALIZE to be run, specify a {weed_tolerance} of zero.

 

{JOIN | NOJOIN} - specifies whether or not to join the <in_cover> AAT attributes to the <out_cover> AAT.  Defaults to JOIN.

 

{sequence_item | ANGLE | DENSITY } - how to sequence the arcs in the input coverage.

 

sequence_item - the number item in the <in_cover> AAT that is used to sequence the input arcs.

 

By default the <in_cover># is used as the {sequence_item}.  In other words, the sequence of the arcs is unchanged.

 

Item values must be sequential starting with 1.

 

ANGLE - the input arcs are sequenced using the ARCROUTE2 AML.

 

The FLOW option of ARCROUTE2 is used to group arcs that deviates least from the current direction of travel.

 

DENSITY - the input arcs are sequenced in descending order based on line density of <in_cover> and {block_cover}.

 

The reason for sequencing the arcs is that the arcs processed first by GENERALIZE2 are less likely to be moved than are arcs processed subsequently.  So arcs that aren't to be moved as much should be processed first.

 

{split_tolerance} - the weed tolerance used when determining where to break the input arcs prior to generalization.

 

It defaults to the <buffer_distance>.

 

A copy of the input arcs are weeded with the ARC GENERALIZE command (POINTREMOVE option) using the {split_tolerance} as the weed tolerance.  The input arcs are then split at these vertices.  These vertices lie at signifcant bends in the arcs.

 

The reason for breaking the input arcs is because some arcs double back on themselves.  GENERALIZE2 doesn't check an arc for spatial conflict with itself when it is processing it.  Therefore, by splitting the arcs at significant bends GENERALIZE2 will, in effect, check arcs for internal spatial conflict.

 

After the arcs are generalizied they are rejoined using the UNSPLIT command.

 

{spline_tolerance} - the initial GRAIN size used during generalization of the output arcs.

 

It defaults to {weed_tolerance}.

 

The output arcs are splined three times.  First with a GRAIN size equal to the {spline_tolerance}, the second time with a GRAIN size equal to 2/3 the {spline_tolerance}, and the third time with a GRAIN size equal to 1/3 the {spline_tolerance}.

 

If the {spline_tolerance} is set equal to 0, then no splining will take place.

 

 

NOTES

 

GENERALIZE2 runs from the GRID module of ARC/INFO, ver. 8.1.

 

The ANGLE option is slow.

 

If a lot of arcs (ca. 5,000+) are being processed memory limits may be exceeded.  If this happens a segmentation fault will be reported.  If this happens, you can split up the input coverage, and process each part separately.

 

The <out_cover> is not built.

 

 

DISCUSSION

 

PROCESS - GENERALIZE2 works by 1) splitting each arc at significant bends, 2) sequencing the arcs based on importance, 3) gridding each arc, 4) moving the arc's nodes if need be, 5) reconstructing the arc by tracing a path over a cost surface, 6) vectorizing this path, and then 7) generalizing the new arc.

 

1) SPLIT - All of the input arcs are split at significant bends.  What constitutes a significant bend is determined using the {split_tolerance} in conjunction with the ARC GENERALIZE command.  This is done by running ARC GENERALIZE (POINTREMOVE option) on a copy of the input arcs using the {split_tolerance} as the weed tolerance.  The vertices remaining are used to split the original input arcs.

 

2) SEQUENCE - All of the input arcs are sequenced in order of importance.  Arcs that shouldn't be moved as much should come first.  There are three different methods for sequencing the arcs: {sequence_item | ANGLE | DENSITY}.

 

3) GRID - First each input arc is gridded using the specified <cell_size>.  In so doing this generalizes the form of the arc.  Specifying a smaller <cell_size> will retain more definition, but will lengthen the processing time.

 

4) MOVE NODES - If either node at the ends of each arc is within the <buffer_distance> of all previous arcs (including those in the {block_cover}), then the node is moved outside of the buffer.  (Each node in the cover can only be moved once.)

 

5) RECONSTRUCT - The path of each arc is reconstructed by finding the least-cost path between the nodes at either end of the arc.  The cost surface for this analysis is created by summing A) a buffer of the arc with B) a buffer of all previous arcs (including those in the {block_cover}.)  In both cases the buffer radius used is <buffer_distance>.  Both buffers are assigned cost weights.  The "A" buffer weights start at 0 in the center and increase to 7 at the perimeter.  The "B" buffer weights start at 15 in the center and decreases to 1 at the perimeter.  (The weights are increased by a foactor of 1.5 where two or more previous arcs are within the <buffer_distance>.)  In addition to the cost surface, a horizontal factor grid is used to make it easier to cross the "B" buffer on a diagonal than it is to move through it in a perpendicular or parallel direction.

 

6) VECTORIZE - The least-cost path is then vectorized to create a new arc.

 

7) GENERALIZE - And the new arc is then generalized using ARC GENERALIZE and ARCEDIT SPLINE.

 

 

EXAMPLES

 

Grid: &run generalize2

Usage: GENERALIZE2 <in_cover> <out_cover> <arc_move_item> <node_move_item> <buffer_distance> <cell_size> {block_cover} {block_buffer} {weed_tolerance} {JOIN | NOJOIN} {sequence_item | ANGLE | DENSITY} {split_tolerance} {spline_tolerance}

 

Grid: &run generalize2 road_cov road2_cov move move 500 60 ~

Grid: stream_cov 300 300 join angle 500 500