Workstation 오류:segment table full 원인
3840 단어 table
Error: Segment Table Full (CRESEG); Segment Table Full (PUTSEG)
Article ID:
12214
Software:
PC ARC/INFO/DAK 3.5.2
Platforms:
N/A
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.
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.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Vuetify에서 행 그룹화이 기사에서는 유사한 값으로 테이블의 행을 그룹화하는 방법에 대한 경험을 공유하고자 합니다. 물론 기본 그룹화 예제를 찾을 수 있지만 제 사용 사례에는 약간의 고급 기능이 필요했습니다. 제품 데이터가 있다고 가정합니...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.