3.4M 태양광 패널 데이터셋(GM-SEUS v2) 뜯어보기: DuckDB+GDAL+QGIS로 바로 분석하는 법

미국 전역의 태양광 패널을 “어디에, 얼마나” 깔려 있는지 한 번에 보고 싶었던 적 있나요?
이번에 공개된 GM-SEUS(미국 지상형 태양광) v2 데이터셋은 그 질문에 꽤 현실적인 답을 줍니다.

GM-SEUS v2 핵심 업데이트: 2.9M → 3.4M 패널

v1이 약 290만(2.9M) 패널을 담고 있었다면, v2는 342만(3.4M+) 패널로 확장됐어요.

단순히 패널 수만 늘어난 게 아니라 패널/어레이(배열) 데이터가 리프레시됐고, 무엇보다 신규로 ‘옥상(rooftop) 어레이’ 데이터셋이 추가된 게 포인트예요.

이런 변화는 시장/정책 분석뿐 아니라, 지도 기반 서비스(입지 분석, 에너지 인프라 모니터링) 입장에서도 “한 단계 더 쓸 만해졌다”는 의미로 해석할 수 있어요.

분석 스택 구성: GDAL + DuckDB(Spatial/H3) + QGIS

이 글의 원문 작성자는 데이터 처리에 GDAL 3.9.3, 분석은 **DuckDB**를 중심으로 진행했어요.

DuckDB는 spatial 확장으로 지오메트리를 읽고, h3 확장으로 **헥사곤 그리드 집계(heatmap)**를 빠르게 만들 수 있어요. 여기에 parquet, json, lindel 같은 확장까지 얹어서 “로컬에서 빅데이터급 GIS 분석”을 깔끔하게 해냅니다.

지도 시각화는 데스크톱 GIS의 표준인 **QGIS 4.0.1**로 마무리했고, Esri 베이스맵은 QGIS 플러그인(HCMGIS)으로 붙였어요.

데이터 받기와 전처리 포인트: GPKG → Parquet 변환이 핵심

데이터는 Zenodo에서 3.4GB ZIP으로 제공되고, 내부에 GeoPackage(GPKG) 파일들이 들어 있어요. 여기서 중요한 실전 팁은 “바로 분석하지 말고 Parquet로 변환하라”는 점이에요.

원문에서는 DuckDB로 ST_READ()로 GPKG를 읽은 뒤, 좌표계를 EPSG:4326(WGS84)로 변환하고(ST_TRANSFORM), 좌표 순서도 정리(ST_FLIPCOORDINATES)한 다음 Parquet로 떨궜습니다.

또 하나 눈여겨볼 부분은, 공간 데이터 검색/렌더링 성능을 위해 힐베르트 커브(HILBERT) 기반 정렬을 걸어 저장 순서를 최적화했다는 점이에요. 이런 처리를 해두면 이후 특정 지역만 잘라보는 워크로드에서 체감 성능이 달라져요.

레코드 규모 정리: Rooftop 5,822 / Arrays 18,980 / Panels 3,429,157

v2는 크게 3종 데이터로 볼 수 있어요.

• Rooftop Arrays(옥상 어레이): 5,822건
  컬럼별 NULL 비율을 보면 azimuth, capMWAC, capMWDC, tilt 등이 NULL이 87~90%대로 높아요. 즉 “위치/형상은 있으나 발전 특성 메타데이터는 덜 채워진 소스가 많다”는 신호예요.
• Arrays(지상형 어레이): 18,980건
  설치연도(instYr)는 1985~2025 범위로 꽤 넓고, 용량(capMWAC/DC) 같은 필드도 상대적으로 잘 채워져 있어 “정량 분석”에 더 유리해 보입니다.
• Panels(패널 단위): 3,429,157건
  패널 단위는 사실상 “도형의 바다”라서, 저장 포맷/압축(ZSTD)과 행 그룹 크기 같은 물리 설계가 분석 생산성을 좌우해요.

H3 헥사곤 집계로 Heatmap 만들기: 지역 분포를 한눈에

원문은 H3_LATLNG_TO_CELL()로 H3 해상도 4(resolution 4) 헥사곤에 레코드를 집계해 heatmap을 만들었어요.

이 방식이 좋은 이유는 단순해요. 점/폴리곤을 그대로 그리면 너무 무겁고 지역 비교가 어려운데, H3로 묶으면
(1) 지도 렌더링이 쉬워지고 (2) 지역별 밀도 비교가 직관적이 됩니다.

또 “헥사곤별로 가장 많이 등장한 Source(데이터 출처)를 색으로 칠하기”도 했는데요. 이건 데이터 품질/편향을 찾는 데 꽤 유용합니다. 예를 들어 특정 주/카운티는 OSM 비중이 높고, 다른 지역은 USPVDB 비중이 높다면 “동일 기준의 탐지/정의가 아닐 수 있다”는 가설을 세울 수 있죠.

품질 관찰: 옥상 어레이는 소스별 윤곽 품질이 제각각

옥상 어레이는 특히 “소스마다 폴리곤 성격이 다르다”는 부분이 흥미로웠어요.

어떤 소스는 건물 외곽을 보수적으로 따라가고, 어떤 소스는 더 유기적인(혹은 거친) 형태로 잡혀요. 심지어 gspt 소스는 큰 원(circle)로 대충 표시하는 경우도 있어, 같은 지역을 보더라도 시각적으로 “탐지했다/안 했다”가 혼재될 수 있습니다.

원문에서도 LA 지역 예시를 들며 옥상 데이터는 5천여 건 규모라 커버리지 개선 여지가 크다고 언급해요. 즉, 옥상 태양광 분석을 하려면 v2만으로 “완전한 지도”를 기대하기보다는, 다른 데이터(건물 풋프린트/항공사진/전력 데이터)와의 결합을 전제로 접근하는 게 현실적이에요.

실전 사용 시나리오: 이 데이터로 무엇을 할 수 있을까?

이 데이터셋은 단순 구경용이 아니라, “바로 일에 갖다 쓰는” 시나리오가 명확해요.

• 재생에너지 입지/확장 분석: 연도(instYr)와 용량(capMWAC/DC)로 증가 추세를 빠르게 볼 수 있어요. 지역별 설치 붐이 언제 왔는지 확인하면 정책/인허가 흐름과 연결하기 좋습니다.
• 공급망/시공 시장 리서치: 어레이의 mount(설치 방식), modType(모듈 타입) 분포를 보면 어떤 기술 조합이 주류인지 감이 와요. 예를 들어 단축/이축 추적(single/dual axis) 비중은 발전 효율/부지 특성과 연결됩니다.
• 지도 기반 제품(데이터 검증/보강): Source별 편차가 커서, 오히려 “어느 소스가 어느 지역에 강한가”를 찾아 보강 전략을 세울 수 있어요.
• 오탐지 탐색: 원문에서 Ivanpah 사례처럼 패널로 보였지만 사실 **거울(헬리오스탯)**인 경우도 나옵니다. 컴퓨터비전/원격탐사 기반 데이터라면 이런 에지 케이스를 전제로 QA 룰을 만들어야 해요.

마무리: “3.4M”은 시작이고, 강점은 DuckDB로 바로 만져진다는 점

GM-SEUS v2는 패널 342만 개라는 스케일 자체도 크지만, 더 중요한 건 로컬 환경에서 DuckDB로 쉽게 다룰 수 있게 설계했다는 점이에요.

다만 옥상 어레이처럼 소스별 품질 편차/커버리지 한계가 보이기 때문에, 목적이 정밀할수록 “추가 데이터 결합 + 검증”이 필요합니다.

여러분이라면 이 데이터로 어떤 지도를 먼저 만들어보고 싶나요? (예: 특정 주의 연도별 설치 확산, 카운티별 AC/DC 용량 히트맵, 소스 편향 비교 등)