Aislo/docs/raw/plans/2026-09-01_plan_implementation_verification_context_hold.md

2026-09-01 구현 완료·최종 검증 대기 배경 원문

상시 계획서 축약 전의 배경·설계·검증 조건을 보존한다. 완료 아카이브가 아니며 최종 검증 전까지 보류 상태다.

노선 원천 일원화 + 도엽 서피스 온디맨드 (2026-09-01 신규)

배경: 용화 자동 체인이 끝까지 돌았는데 종단 계획선이 직선으로 나왔다. 저장본:

basis: "station_alignment"          ← 1차 배관 정착이 아니라 2차 폴백
PVI 3개:  0.0m(879.14) → 830.5m(839.71) → 1070.4m(826.62)

원인은 관 측점이 노선과 다른 기준에서 나온 것이다. pipe_points.json 관 22개 측점이 92.6 … 2044.9 m로 트림 전 원본(2,136 m) 기준인데 확정 노선은 1,070.4 m다. 22개 중 10개가 노선 끝 너머라 계획선 산출에서 관이 통째로 버려졌다.

왜 갈렸나: 트림·조밀화를 Service_Chain._planned_route_points_in_project_crs() 한 곳에만 넣었는데, 계획노선을 읽는 곳이 다섯 군데다.

읽는 곳	용도
B03_FileInput_Service_Chain.py:53	체인 BP·EP·CP (트림 적용됨)
common_util_drainage_context.py:116	배수유역·관·세부유역 (트림 없음)
B04_PreProcess_Router_Inflow.py:82	유입 분석 (트림 없음)
B04_PreProcess_Engine_SheetSurface.py:457,493	도엽 서피스 절취 범위 (트림 없음)
B04_PreProcess_Engine_Extent.py:20	지도·GIS 범위 (트림 없음)

같은 자리를 b03 커밋 892c33c7도 건드렸다(shapefile 판독 누락 3곳). 노선 원천이 흩어져 있어 생기는 같은 종류의 문제다 — 한 곳에서 나오게 모아야 한다.

① 도엽 서피스도 기본 하나만 자동 생성

SHEET_SURFACE_METHODS 6종을 매번 다 만든다 — WF1 891초 중 655초가 여기다. LAS 필터와 같은 규칙으로 바꾼다: 자동은 SHEET_SURFACE_DEFAULT_METHOD(laplace) 하나, 나머지는 B04에서 관리자가 버튼을 누를 때 그 방식만. build_sheet_surface_from_route()가 이미 methods 인자를 받으므로 엔진 변경은 최소다.

② 배수유역도 트림된 노선만 분석

트림된 구간 밖은 지표 데이터가 없어 유역·관 배치가 성립하지 않는다. 노선 원천을 공용 함수 한 곳으로 모으고 위 다섯 곳이 모두 그것을 쓰게 한다.

③ 트림된 지점이 종점

②가 되면 자동으로 따라온다 — 배수유역이 트림 노선을 쓰면 마지막 정점이 종점이고, routes_match()가 성립해 B05 계획고·경로 정점이 그대로 물린다.

구현 체크리스트:

• 자체검증 — 용화 재실행으로 관 측점이 트림 노선 안에 들어오고 basis가 배관 정착으로 바뀌는지 확인

보류: Engine_Extent(지도·GIS 범위)는 트림 전 노선이 맞다 — 배경 지도는 계획 전 구간을 덮어야 사용자가 측량 범위 밖을 볼 수 있다. 트림 적용 대상이 아니다.

---

B04 노선 3D 표시 + 서피스 밖 노선 자동 트림 (2026-09-01 신규)

배경: 실무 자료 용화.las가 계획노선 2,136 m 중 1,400 m(66%)만 덮는다. 좌표 문제가 아니라 측량 범위 자체다 — 근거는 아래 「입력 자료 실측」. 이 상태로는 자동 설계 체인이 서피스 밖 정점에서 끊긴다.

① B04 3D 뷰어에 계획노선 평면 표시

노선을 3D 데이터 최고 표고(bounds.z[1]) 평면에 수평선으로 그린다. 지표면에 드리운 곡선이 아니다(사용자 확정) — 노선과 측량 범위가 평면상 어디서 어긋나는지 한눈에 보이게 하는 것이 목적이다.

뷰어 좌표 규약(ModelContext.scene_vertices, TerrainViewer:584와 동일):

scene.x = model.x - cx      scene.y = model.z - cz      scene.z = -(model.y - cy)
cx,cy,cz = 모델 bounds 중심

따라서 노선은 scene.y = bounds.z[1] - cz 고정, x·z만 노선 좌표를 따른다. 점 목록은 이미 있는 fetchPlannedRoute()(/planned-route, 프로젝트 좌표계)를 쓴다. 색은 2D 지도와 같은 --map-route — 같은 선을 두 화면에서 다른 색으로 그리지 않는다.

② 서피스 밖 노선 자동 트림

서피스를 만든 뒤 노선에 지표 데이터가 없으면, 서피스가 덮는 구간만 남기고 자른다. 서피스 가장자리는 불규칙하므로 잘라낸 쪽 끝에서 30 m를 더 트림한다(사용자 확정).

• 판정은 DtmGridSampler.sample_xy()가 돌려주는 valid — 확정 DTM의 valid_mask가 곧 불규칙 실제 외곽이다. bounds 사각형이 아니다.
• 30 m 트림은 잘린 쪽 끝에만 적용한다. 노선 본래 종점이 서피스 안에 있으면 멀쩡한 구간을 깎을 이유가 없다.
• 자를 자리는 _planned_route_points_in_project_crs() 한 곳이다 (Service_Chain.py:28). 체인의 BP·EP·CP가 전부 이 함수를 지나므로 여기서 한 번 자르면 하류가 모두 유효해진다.

입력 자료 실측 (2026-09-01, 2026년 임도 용화):

자료	좌표계	범위
용화.las (VLR)	EPSG 5176	x 208305.7209200.5 · y 367454.8368097.9
용화.tif+.tfw	EPSG 5176 (TOWGS84)	x 208288.7209207.3 · y 367456.2368092.4
노선 .shp	ITRF2000 / UTM-K (라벨 5179)	폴리라인 2,135.9 m · 정점 121

LAS와 정사영상 범위가 서로 일치한다 → 측량 범위가 실제로 거기까지다. 위경도로 datum 보정까지 태워 비교해도 같다 — 노선 경도 129.094721129.108631, LAS 129.093694129.103729. 위도는 완전히 포함, 경도만 동쪽 431 m 초과. 변환 오류라면 남북으로도 어긋나야 하는데 그렇지 않다.

덮임: 정점 121개 중 81개 안쪽, 길이 2,136 m 중 1,400 m(66%). 시점은 안쪽, 누가거리 약 1,420 m부터 벗어나 종점까지 736 m가 빠진다. 끝이 잘린 모양이고 중간이 뚫린 게 아니다 — 2회 비행 중 서쪽 1구간만 받은 것으로 보인다 (기존 프로젝트는 cloud_merged.las 병합본, 용화는 타일 인덱스 없는 단일 파일).

구현 체크리스트:

• 자체검증 — 용화 노선으로 트림 길이·정점 수 확인, 화면에서 노선 평면 확인

---

보조 워크트리 포트 분리 — 메인 8000/5173 · 보조 8001/5174 (2026-08-31 신규)

배경: 한 PC에서 메인 폴더와 보조 워크트리(D:\aislo-wt\sub)를 동시에 띄운다. .claude/는 두 폴더가 링크로 공유하는 한 벌이라, dev_up.py 하나가 자기가 어느 폴더에서 도는지 스스로 알아 포트를 골라야 한다. 경로는 PC마다 달라(집 D:\02_Software_Prog\…, 사무실 C:\Program_coding\…) 하드코딩할 수 없다.

판별 방법: 링크 워크트리는 .git이 파일(gitdir: …), 메인 클론은 디렉터리다. os.path.isfile(ROOT/".git") 한 줄로 갈린다 — git 서브프로세스도, PC별 경로도 필요 없다.

배선 현황 (조사 결과 — 대부분 이미 env로 뚫려 있음):

지점	환경변수	기본값	상태
config/config_system.py:44	SERVER_PORT	8000	기존
main.py:80	FRONTEND_DEV_PORT	5173	기존
vite.config.ts:5	AISLO_API_PORT	8000	기존 (프록시 대상)
.claude/browser_driver.py:38	AISLO_VITE_PORT	5173	기존
.claude/dev_up.py:80	—	8000·5173 하드코딩	이번 수정

config_frontend.ts:14는 API_BASE_URL = "/api" 상대경로 → 프론트 수정 불필요. load_dotenv()가 override=False라 프로세스 env가 추적 파일 .env를 이긴다 → .env 수정 없이 포트 분리 가능.

구현 체크리스트:

링크 공유에서 제외해야 할 것 (조사 중 발견): config/node_modules는 vite 캐시(.vite)와 빌드 출력(.build)을 같이 담고, config_system.py:48의 STATIC_DIR이 그 .build를 서빙한다. main.py:261이 기동 때마다 npm run build를 돌리므로 링크하면 두 백엔드가 같은 산출물을 덮어쓴다. → config/node_modules·openwebcad/node_modules는 보조에서 npm install 따로. venv·national_contours.gpkg(22G)는 읽기 전용이라 링크 안전.

남는 위험 — DB 공유: 두 백엔드가 같은 원격 DB(dsm.chemifactory.com:53306 / aislo_db)를 본다. 같은 프로젝트를 양쪽에서 열면 서로 덮는다. 폴더별 DB 분리는 이번 범위 밖 — 작업 시 프로젝트를 나눠 쓴다.

• 보조 워크트리에서 dev_up.py를 직접 실행해 8001·5174 자동 기동과 메인 환경 무충돌을 확인한다.