English

Error: Segment Table Full (CRESEG); Segment Table Full (PUTSEG)

Solution or Workaround

Summary

While running CLEAN, the following message occurs:

   Segment Table Full (CRESEG) 

Sometimes the (PUTSEG) routine is listed.

Cause

The coverage probably has a very dense arrangement of arcs and segments. The error occurs in the OVRSEG program which is part of CLEAN and MAPJOIN.

The Segment table is a table that is temporarily kept in memory while it processing (OVRSEG) arcs. When OVRSEG is done, the information in the table is discarded. As it proceeds through the file from north to south, it has a scan line or band that stretches east/west along the file.

       ------------------------
* * *
* * A *
| * * * cover
| * * B * D *
V =========*====*========= scan line or band
* * * *
* * *
* * C *
* * *
------------------------

To do correct processing, it must keep track of all the segments that pass through the band. In the example, A is above the band, so it has been processed; it was in the segment table, but is not anymore. C is below the band and has not been processed yet; it is not in the segment table, but will be soon. B and D cross the band, so they are being processed and they are currently in the segment table.

The error will occur in the intersection stage and happens when there are too many band-related segments. This happens when the number of entries in the active segment table is at maximum. It could happen, for instance, when generating a buffer with a fuzzy tolerance that is relatively large compared to the buffer distance. Among other factors, the band width is proportional to the fuzzy tolerance value, so reducing the fuzzy tolerance value may help.

If you have more than 8000 arcs running through the scan line at the same time, then the segment table will fill and you will get this error message.

The longer the arc, and the longer its segments, the longer it stays in the segment table when the arc runs in a north/south direction. For example, an arc that runs completely from north to south, will always be in the segment table. One that runs mostly east/west will only reside in the table a short time.

Solution

Make sure you are using at least version 3.5.2. The segment table was increased in version 3.5 to be the same as workstation ArcInfo. If you are using 3.5 or earlier, you need to upgrade.

If you are using 3.5.2, then the coverage must have a lot of arcs. SPLIT the coverage into smaller parts and run CLEAN again.

Alternately, change the fuzzy tolerance for the coverage and run CLEAN again. If the fuzzy tolerance is below the single precision limit, you in effect have no fuzzy at all, and you should increase it. If the fuzzy is already too high, then decreasing may help.

Splitting the coverage north/south, so you have an east and west piece, will help as it will cutting the number of north/south lines in half. Splitting it the east/west direction will not help at all. Splitting does not help with MAPJOIN.

You can use PROJECT. Make the input and output projections the same and use the densifyarc option in project. You can also increase the number of arcs by doing a spline (with a lower grain tolerance)
in ARCEDIT.

Note:
For Older versions of PC ARC/INFO: If greater than 581K of conventional memory is available, OVRSEGB will be used instead of OVRSEG. OVRSEGB has higher limits.