build filename node
build filename arc
build filename poly
Quad units were then assembled in L-R order using the edgematch macro in Arcedit. Once quads were edgematched, they were rebuilt as above, with some requiring the clean command, and then mapjoined, typically using ther upper left-most quad as template, into horizontal "bars". These bars were then edgematched, built or cleaned, and mapjoined in top to bottom order. The final step to assebling the count coverage was to dissolve (with the #all poly option) the quad boundaries to unify cross-quad polygons. Coverages were then visually checked aginst thew original quad sections to insure topological soundness
NOTES:
Several factors present difficulty in compiling a basin-wide SSURGO
coverage. The county soil surveys were not compiled with the goal
of cross-county compilation in mind. For each mapunit (read soil
type) within a coverage there is assigned a muid (mapunit-identifier?).
Soil-type polygons are assigned this muid, a six didget number oftem with
a seventh-character alpha modifier (relating to slope (?)). These
ìcodesî are unique to counties, thus preventing the neat creation
of a single-key basin-wide soils coverage. In addition to this descision
in the creation of the soils coverages, some of the coverages we have used
are in preliminary status:
| Benton | preliminary |
| Clackamas | preliminary |
| Columbia | preliminary |
| Douglas | certified |
| Lane | preliminary |
| Lincoln | certified |
| Linn | certified |
| Marion | preliminary |
| Multinomah | certified |
| Polk | preliminary |
| Tillamook | unavailable |
| Washington | preliminary |
| Yamhill | prliminary |
note-this table represents the ISEís best understanding of the county status as of 8/25; it has not been verified by NRCS
Which means that there are topological and data-base errors within those counties. In some cases, the topological differences between counties were severe and created other problems upon adjustment to one another. In some cases the county coverages were digitized with an alternatly named field as the key (instead of muid). The ìkeyî field had various names across the preeliminary county, and corrosponded to the field musym (another ìkeyî field which can be used to associate to muid through a common lookup table. These naming crosswalks were supplied by Scheri Schneider:
Date: Thu, 06 Aug 1998 06:39:31 -0500
From: Sheri Schneider <sschneider@or.nrcs.usda.gov>
To: daver@darkwing.uoregon.edu
Subject: soils stuf
Dave
The musym is in the following item for each of the surveys listed below.
You
just need to change the name of the item to musym. (Use the modify
command in
tables. You might need to change the type and width depending on what
the are
set to.
Benton PUBSYM
Marion SOILABB
Polk SOILTYPE
Yamhill ATTRIBUTTE
With the counties all variously put together, the ultimate goal pathway
was to: edgematch, mapjoin, and dissolve these into a single coverage,
to then be ìupdatedî onto the STATSGO coverage. This
could not be achieved due to the preliminary nature of some of the coverages:
in order to perform the mapjoin operation, coverages have to have identical
sets of items. The set of seven (Wash, Clac, Doug, Linc, Linn, Mult,
Lane) for which we have comlete data were configured so that they have
the same fields: the four default (non-user-defined) and muid (which is
unique to counties and so cannot in itself be the item for a dissolve between
counties), hydrogroup (HYDGRP), k-factor (KFFACT-which is the one without
rock fragments included and is the one used in the USLE/RUSLE equation),
RKDPHR (the range of depth to bedrock, which is calculated from the ROCKDEPL
and ROCKDEPH-- respectively the upper and lowr depth to bedrock), WTDPHR
(the range in seasonal depth to water table, calculated from WTDEPL and
WATDEPH--respectively the upper and lower seasonal depth to water table),
and CTY_MUID, which is a for-the-momewnt blank field for concatenating
a ìuniversalî key to the county SSURGO data comprised of the
county-id and the unique county MUID.
In order to get these features together in the county coverage
.pat table, the .pat table had to be joined with the layer table for kffact,
and the comp table for the other attributes. If the county had musym
instead of muid, the mapunit lookup table provided the musym-muid association.
This was done with the joinitem command in arc. The command pullitem
was then used to create a new .pat table with only the desired set of attributes.
Because not all of the .pat tables were identical in item-column ranges,
the commands additem and dropitem in arc, combined with the move
and alter commands in info, were used to add a new item with the desired
perameters, the data moved into the new column, and the old column dropped,
and the added item renamed to the original name.
See an example
of some of the processes in attribution of county coverages.
The interim map that is currently under construction will be composed in the following manner: clac-wash-mult all adjoin and have data and lane-doug-linn all adjoin and have data, and linc is orphaned on the western edge. These two clumps and one orphan all now agree in items, and are edgematched. Due to the preliminary nature of the data, the edgematching is not perfect--sometimes largish distances are invloved (c. 100 m +/-) and sometimes without the same number of arcs intersecting the county boundary from both sides--meaning that some polygons will terminate at the county boundary. These will then be mapjoined and intersected with (updated onto) the modified statsgo (modified to have matching items), and then dissolved on the desired item.
Two issues that ahve arrisaen so far is the order in whick the data is clipped--pre v. post mapjoin (post is the proper way). Clipping before joining creates sliveers along the basin boundary as the coverage is adjusted t an adjacent coverage. Another singular problem was encountered when mapjoining wash and clac--mapjoiin failed but the use of append and clean (which comprise mapjoin) worked (?).
9/7
Two issues are not detailed above. One is that even with the ATTRIBUTE field of Yamhill ALTERed to MUSYM, the fields did not join because the contained different sets of items. It turns out that the attribute field had a 1-100 numeric equivalent to the three-letter musym field. Sheri Shcneider provided this crosswalk; it worked with one complicating factor of the type of the crosswalk fields of the two tables were of different types, C and I. Conversion of one field to the oter type in INFO did not solve the problem as the numbers retained improper justification, or were appended by a "0" (such that 45 became 450). Conversion of this field to an I in the arcview environment was, however, sucessful. The second issue is that two additional field were added to the original; list: compname, and muname.
The topological descrepancies between county coverages (as described above is enough that sliver polygons renmain even after edgematching. In addition, the degree of the adjustment is severe enough that topological anomolies occur along the perimeter of the adjustmetn bounding box. As well, there is enough discrepancy between the Linn and Marion border that the degree of adjustment could cause severe distortion of the county coverage as it was recieved. Several courses of action, with hope, will remedy these for an interim reliminary draft map: sliver polygons left after edgematching along cultural borders will me merged into the visually apparent matching non-sliver polygons (eliminate, which merges polygons along thier longest shared boreder was exploted as an option, but rejected, as the process requires selection of the polygons to be thus merged based on some attribute, and no sufficiently discriminating attribute could be identified). Sliver polygons of large size along the Linn-Marion boder (quantified?) will be left as zero or no data polygons, because of, the magnitude of topological adjustment that would occur from thier bieng matched along a border. [I feel it is better with this degree of error, to leave the artifact rather than distort the rest of the coverage, or merge the resultant small-world polygon into one of the existing ones.]
Even with the whole coverage available for adjusting, the severity of the adjustment is too great to be accepted. What I am trying right now is this: it turns out that the edit feature can be an arc as well as a node (it can apparently be a poly or other features as well), so I am linking the county coverage boundaries as arks. Ideally the disagreement between the two would be averaged across both, which seems as if it should be possible given the ability to switch edit and snap coverages in the edgematch macro, but only the coverage currently marked as the edit coverage it adjusted, even if lnks have been added both ways.
Had to adjust the coverages to each other twice and then was still left with 28 slivers that had an average with of something like .33 m. merged these by hand and am moving on.
Joining arcs to arcs is an acceptable way of edgematching to coverages with a contiguous single-polygon border, such as a riverine border. The methodology that arc uses to calculate the placement of identity links along a border of any significant links is impractable, as it slows with the accumulation of links (recalculating the entire list for the addition of the next?). The links ae added between verticies within the set tolerances. The workaround to this is to use the limit area links are added button in the edgematch macro to choose smaller portions of the coverages to link. Thus manually limited, arc calculates the links within the set bounded area, and, as sequential areas are linked, adds added links to a "master list". Another aid in the edgematching process is the use of the save/get links option wihtin the macro. This allows links to be written to an existing coverage, or to create a coverage of just the links. Repeated saving of links to the same coverage appends all links to the coverage, leading to delay when the links are retrieved (ie. always save to a new file). in this manner, an adjust can be tried on a coverage and the links adjusted if the result is not desirable, or if the session needs to be interrupted.
In some cases, such as beween Linn and Marion, and Linn and Benton,
the digitized coverages overlapped (*but did not agree). In both of the
named cases, Linn was used to erase portions of the other counties to aid
in edgematching. Marion was edgematched to all adjoining coverages (the
reciever of all the wrinkles). This caused some violence to the covrage,
even with the erased boundaries and constraints placed on the area of adjustment.
Because alteration of the edgematch/adjustment process did not produce
a sound result, the coverage was opened in arcedit, and polygons either
copied into the working coverage from the pre-adjusted coverage, or the
linework traced from the original (in both cases after deleting the bad
linework). The result of breaking the plygons and recreating them required
the reinstatement of sound topology through clean (as build bailed). The
result of the clean opperation was to lose the polygonal attributes. It
was found through experimentation in a similar situation with Benton county
that if topology could be restored without deleting arcs, that attributes
were retained. This was accomplished by moving or deleting verticies.
Commands used (in arcedit) for the above included:
put
v move
v delete
move (w/ ef as node)
Attributed labels were moved from mari2 to mari4 through a combination of the put command in arcedit, the arc commands additem and joinitem, and the info command move.
In arcedit the edit coverage was set to mari2 wiht the editfeature as label; all lables were selected using the select all command. Labels were then put into mari4 using the "put" command, and choosing to append. Only the user-id's were moved into mari4 as a result of this action. A field entitled "joinitem" the same attribute field parameters was then added to both of the coverages in arc. In info, then, the user-id's of both coverages were moved into thier respective "joinitem" fields using the "move" command. The .pat files were then joined by using the joinitem command in arc. Topology had to be restored, and was done without harm to the data using the clean command in arc, though build might have sufficed. The only areas of concern are those that were particularly damaged during the adjustment of the coverage. The only error observed during a visual inspection of the labels was one polygon that contained two labelpoints: both labels retained the same attributes, but one referred to no polygon.
With all the coverages now matching in topology and in attribution, they were joined with the mapjoin command in arc, and then clipped to the wrb using clip (some of the individual county coverages having been previously clipped. The resultant coverage will then be updated onto wrbstatsgo.
10/21
Despite editing/adjustment of the coverage's topology using the edgematch
macro and the command erase, there were still inconsistencies (gaps) between
the county boundaries. The eliminate command in arc was used to dispose
of the "new" polyons to the best degree possible. The eliminate command
works (in one application of it) through the use of logical arguments to
select polys that will be eliminated. To select spurious polygons, the
following arguments were used:
Arc: eliminate wrbssurgoc wrbssurgoce keepedge poly
Eliminating polygons in wrbssurgoc to create wrbssurgoce
Enter a logical expression. (Enter a blank line when finished)
>: res wrbssurgoc-id = 0 and kffact = 9.99 and area < 10000
>:
Do you wish to re-enter expression (Y/N)? n
Do you wish to enter another expression (Y/N)? n
573 features out of 113859 selected.
Number of Polygons (Input,Output) = 113859 113286
Number of Arcs (Input,Output) = 340048 339456
Creating wrbssurgoce.PAT...
Creating wrbssurgoce.NAT...
Arc:
where the wrbssurgo-id of zero applied to polys created in the mapjoin operation (as well as others; a kffact of 9.99 is equivalent to "no data"; and the area delimiter did not include the largest of the spurious polys (as some were quite large--see examples of topological descrepencies). There were 800 polys that were selected with the first two criteria, and of these, 573 were selected by the third criterion.
In response to our own needs, the attributes of clirr, clnirr, sclirr, and sclnirr (relating to soil class) were added to the .pat table of wrbssurgo and wrbstatsgo for soils suitability reasons. In doing this, we initially attempted to join all the comp tabular tables together using the merge command in info, but the preliminary coverage tables differed in the parameters of the fields, and could not be joined. it is possible, though, to join to one county's tabular data at a time using muid (which is unique between counties) as the relate item. With this and some of the earlier described info command sequences, it is possible to populate the full coverage with desired attributes . See "How to attribute the interim soils data with desired fields" for this example.