게시판 답변이 생성됐습니다
-
글
-
어떤 종류의 데이터가 담긴 파일인지는 모르겠으나, HDF5 형식으로 된 파일로부터 Group이나 Dataset이 아닌 Attribute에 해당되는 항목들을 읽어야 하는 경우인 것으로 보입니다. 아마도 Group이나 Dataset에 해당되는 항목들을 읽어오는 작업은 이미 하신 것 같습니다. 언급하신 scale_factor나 add_offset은 아마도 Attribute의 범주에 해당되는 항목들일 것으로 보이는데요. HDF5 형식의 파일로부터 Attribute에 해당되는 항목들을 추출하는 과정은 약간 복잡합니다. 저도 이 방법에 대하여 완벽하게 이해를 하고 있지는 못하지만 그냥 제가 아는 한도 내에서 답을 드려보겠습니다. 대략적인 과정은 다음과 같습니다. 예제 HDF5 파일은 IDL 디렉토리 내에 딸려오는 hdf5_test.h5인 경우로 가정합니다.
file = FILEPATH(‘hdf5_test.h5’, SUBDIRECTORY=[‘examples’,’data’])
fid = H5F_OPEN(file)
gid = H5G_OPEN(fid, ‘images’)
did = H5D_OPEN(gid, ‘Eskimo’)Attribute라는 것은 각 데이터셋마다 존재하기 때문에, 여기서는 한 예로서 예제 파일 내에서 images 그룹에 속하는 Eskimo라는 데이터셋을 대상으로 합니다. 그러면 위와 같은 과정을 거쳐서 특정 데이터셋에 해당되는 id 정보를 did라는 변수로 뽑아냅니다. 이 상황에서 먼저 다음과 같이 attribute가 총 몇개가 있는지 확인합니다.
n_att = H5A_GET_NUM_ATTRS(did)
PRINT, n_att이 예제에서는 실제로 7개라고 나옵니다. 인덱스로는 0~6이 존재한다는 것입니다. 이제는 인덱스를 하나 정하고 해당되는 attribue의 고유 id 번호를 뽑아내야 합니다. 예를 들어 네번째 attribute에 대해서 이러한 작업을 하려면 다음과 같은 명령을 실행해야 합니다.
aid = H5A_OPEN_IDX(did, 3)
그리고 이 attribute의 이름을 보기 위하여 다음과 같은 명령을 실행합니다.
att_name = H5A_GET_NAME(aid)
HELP, att_name그러면 이 예제에서는 다음과 같이 해당 attribute의 이름이 출력됩니다.
ATT_NAME STRING = ‘IMAGE_COLORMODEL’
사실 모든 attribute들의 목록을 한꺼번에 뽑아낼 수 있으면 좋은데, 그럴 수 있는 방법이 보이지 않습니다. 따라서 이와 같이 인덱스별로 이름을 출력하다보면 사용자가 원하는 이름의 attribute가 있는지 확인이 가능할 것입니다. 여기서 원하는 attribute의 인덱스를 찾았다면 다음과 같은 명령을 실행하여 실제 그 attribute 정보를 추출합니다.
att = H5A_READ(aid)
HELP, att대략 이와 같은 방식이 될 것 같습니다. IDL에서 HDF5 형식의 파일을 다루는데 사용되는 코드들의 일람은 IDL 도움말에서 다음과 같은 섹션에서 볼 수 있습니다.
Contents -> Routines (by Topic) -> Input/Output -> HDF5 Routines
아마 파일로부터 데이터를 읽는 방법과 관련하여 이 내용을 이미 참조하셨을지도 모르겠습니다. 근데 HDF5의 경우는 netCDF 등과 같은 타 포맷과는 달리 루틴들의 종류가 많아서 내용을 파악하기가 쉽지는 않습니다. 일단 제가 알려드린 내용을 참조해보시길 바랍니다. 만약 제가 알려드린 내용만으로는 별 도움이 안된다면 아무래도 더 깊은 내용은 직접 찾아보셔야 할 것 같습니다.
함수형 부프로그램에서 RETURN은 하나만 유효합니다. 위와 같이 하시면 RETURN, k 만 제 역할을 할 뿐 뒤에 있는 RETURN, kd 는 아무 역할을 못합니다. 그리고 RETURN 명령은 한번만 유효하며, RETURN으로 되돌려줄 수 있는 항목의 갯수도 하나로 고정됩니다. 만약 함수형 부프로그램이 두 개의 항목들을 한꺼번에 되돌려주도록 하고자 할 경우에는 두 항목들을 구조체(Structure)의 형태로 묶고, RETURN은 이 구조체 하나를 되돌려주도록 하는 것이 좋습니다.
result = {k:k, kd:kd}
RETURN, result즉 함수 부프로그램에서는 이와 같이 정의해둡니다. 그리고 주프로그램에서는 다음과 같이 활용하면 됩니다.
result = lore(x)
k = result.k
kd = result.kd이와 관련하여 아래 링크의 내용을 참조해보셔도 좋을 것입니다.
한가지 첨언을 좀 드리자면, 제가 알려드린 두가지 방법들은 프로그램의 내용을 수정하고 디버깅하는 목적으로만 사용하고, 최종적으로 완성된 프로그램은 결국은 PRO~~END로 둘러싸인 형태가 되도록 하는 것이 좋습니다. 그렇게 하지 않으면 메모리 영역이 서로 겹치면서 예기치않은 문제가 발생할 수도 있기 때문입니다. 프로그램은 오직 프로그램 자체의 독자적인 메모리 영역에서 돌아가게끔 하는 것이 가장 좋습니다.
말씀하신 “변수감시창에 저장한다”는 것은 a1, a2와 같은 항목들이 “변수감시창에서도 보이도록 한다”는 것과 마찬가지 의미입니다. 그런데 이미 말씀드린 것처럼, 프로그램 영역의 메모리와 변수감시창 영역의 메모리는 서로 별개입니다. 만약 두 영역이 서로 만나게끔 하려면 두가지 정도의 방법이 있습니다. 첫번째 방법은 위에서 ChoiYoun님께서 올리신 댓글에서 언급된 바와 같이 프로그램 내에 STOP 명령을 넣어주고 실행하는 것입니다. 그러면 프로그램이 실행되다가 STOP 명령 부분에서 중단되고, 이 때 프로그램 영역의 항목들이 변수감시창 영역에서도 보이게 됩니다. 두번째 방법은 프로그램의 제목 부분을 비활성화시킨 채 실행하는 것입니다. 제가 이전 댓글에서 적어놓았던 코드의 내용을 다음과 같이 수정하여 실행하는 방법입니다.
;PRO test
FOR i=1,2 DO BEGIN
rtf=’a’+STRING(i,format='(I0)’)+’=read_tiff(“190910_’+STRING(i,format='(I0)’)+’.tif”)’
result=execute(rtf)
ENDFOR
HELP, a1, a2
END물론 이 내용이 담긴 코드 파일은 여전히 test.pro가 되겠지만, PRO로 시작되는 제목 부분을 이와 같이 주석처리한 상태로 실행하면, 프로그램 내에서 생성되는 a1, a2와 같은 항목들이 변수감시창 영역에서 바로 나타나게 됩니다.
그러면 처음에 언급하셨던 loaded DLM: TIFF 에러는 이제는 더 이상 발생하지 않는건가요? 그렇다면 별 문제 없이 작업이 진행되고 a1, a2와 같은 항목들이 생성되는 것이 정상입니다. 다음과 같이 HELP 명령을 사용하여 이들의 존재를 확인해볼 수 있습니다.
PRO test
FOR i=1,2 DO BEGIN
rtf=’a’+STRING(i,format='(I0)’)+’=read_tiff(”190910_’+STRING(i,format='(I0)’)+’.tif”)’
result=execute(rtf)
ENDFOR
HELP, a1, a2
END이렇게 HELP 명령을 삽입한 상태로 프로그램을 실행했을 때 a1, a2에 관한 정보가 출력되는지 확인해보시기 바랍니다. 만약 a1, a2 항목에 대한 정보(배열 구조 및 배열 내 값들의 자료형)가 제대로 출력된다면 프로그램이 정상적으로 작동하는 것입니다. 다만 한가지 덧붙인다면 위와 같은 프로그램에서 생성되는 a1, a2 등의 항목들이 존재하는 영역은 프로그램의 메모리 영역입니다. 이 영역은 IDL 인터페이스의 변수감시창에서 나타나는 메모리 영역과는 완전히 별개입니다. 처음 질문하실 때 “변수공간”이라는 용어를 사용하셨는데 혹시나 IDL 인터페이스의 변수감시창을 뜻하고자 하셨던 것은 아니었는지 궁금합니다.
일단 readtiffstack이라는 기능은 IDL에서 기본적으로 제공되지 않습니다. 해당 파일명이 readtiffstack.pro인 것으로 봐선 아마도 외부에서 가져와서 사용중이신 IDL 프로그램인 것으로 보입니다. 제 어림 짐작으로는 아마도 TIFF 파일을 읽는 기능을 수행하는 IDL 내장함수인 READ_TIFF를 내부적으로 사용하고 있지 않을까 추측은 됩니다. 어쨌든 원래 하셨던 것처럼 EXECUTE를 사용하지 않고, 다음과 같이 그냥 일반적인 방식으로 사용했을 경우에도 작업이 정상적으로 수행되는지를 먼저 확인해보는 것이 좋을 것 같습니다.
a1=readtiffstack(‘190910_1.tif’)
언급하신 것과 같은 에러 메시지는 읽고자 하는 파일을 제대로 찾지 못했을 때 주로 발생합니다. 예를 들어 TIFF 파일을 읽는 기능을 수행하는 IDL 내장 루틴인 READ_TIFF 함수를 사용하는 상황에서, 만약 읽고자 하는 파일을 제대로 찾지 못했을 경우 다음과 같은 에러가 발생합니다. 여기서는 ‘my_tif.tiff’라는 파일이 실제로는 존재하지 않는 상태에서 실행하였습니다.
IDL> img = read_tiff(‘my_tif.tiff’)
% Loaded DLM: TIFF.
% READ_TIFF: my_tif.tiff: Cannot open따라서 혹시라도 이와 비슷한 에러가 발생했을 경우라고 한다면, 읽고자 하는 TIFF 파일들을 프로그램이 혹시 제대로 못찾는 상황인지 여부를 먼저 확인해보시길 권장합니다.
우선 맨 처음 질문해주신 분의 글을 보면 아래와 같은 링크를 제시하셨는데, 사실 저 링크를 눌러보면 shape 파일의 이용과는 전혀 무관한 게시물로 연결됩니다.
http://blog.daum.net/swrush/105
혹시 위의 링크가 아닌 아래와 같은 링크의 게시물을 언급하시려고 했던 것은 아닌지, 아니면 전혀 다른 다른 게시물이었던 것인지 궁금합니다.
http://blog.daum.net/swrush/454
원래 언급하고자 하셨던 내용이 위 링크의 게시물이 맞다면, 사실 그 게시물에서 사용된 예제 shape 파일에서는 대한민국의 모든 시/도 경계가 제대로 반영되어 있지는 않습니다. 그냥 본토 및 일부 섬 지역들로만 나눠져있는 것 뿐입니다. 행정구역상으로 정확한 시/도 경계에 대한 자료는 저도 정확히는 모르지만 국토지리원이나 다른 정부기관으로부터 받아야 하는 것으로 알고 있습니다. 정확히 어떤 기관에서 어떤 형태로 제공하는지는 저도 자세히는 모릅니다. 만약 제공된다면 각 행정구역 별 경계선을 구성하는 경도/위도 좌표값들로 구성되어 있지 않을까 짐작은 됩니다.
어쨌든 이러한 데이터를 확보할 수만 있다면, 표출에 있어서 지도를 먼저 그리고 그 위에 행정구역 경계선들을 중첩하는 것이 가능할 것입니다. 그리고 대한민국 영역을 커버하는 2차원 격자(또는 픽셀) 자료가 있다면, 각 행정구역별로 경계선 내부에 위치한 격자들을 선별하고 이에 따른 후속 처리가 가능할 것입니다. 다만 2차원 데이터를 구성하는 격자들 중에서 특정한 폴리곤의 내부에 있는 것들만 선별하는 작업에 있어서는, 위의 댓글에서 언급된 POLYFILLV라는 IDL 내장함수를 사용하는 방법도 있고 또는 외부 라이브러리인 Coyote 라이브러리에 있는 INSIDE라는 프로그램을 사용하는 방법도 고려해볼만 합니다.
우선 오류가 난다고 하셨는데 구체적인 증상이 무엇인지를 알려주셔야 합니다. 그냥 오류가 난다는 말씀만 하시면 답변 드리는 입장에서는 도와드리가 매우 어렵습니다.
일단 처음에 올리셨던 코드와 나중에 추가하신 내용을 참조해서 나름 답을 드린다면, 두번째 파트의 반복구문 내에 다음과 같은 내용이 있는데요.
IF count EQ 0 THEN BEGIN
PRINT, ‘NO FILE TO READ’
ENDIF아마도 해당되는 asc 파일이 하나도 없을 경우를 위하여 삽입된 내용으로 보입니다. 그런데 이렇게만 해두면 count의 값이 0일 경우 읽을 파일이 없다는 메시지는 출력하지만 그 상태로 반복구문 내의 작업은 계속 진행될 수 밖에 없습니다. 그러면 이후에 등장하는 ii를 사용하는 반복문이 제대로 실행될 수 없고 오류가 발생하게 됩니다. 이러한 문제를 방지하려면 위의 IF문을 다음과 같이 바꾸는게 좋습니다.
IF count EQ 0 THEN BEGIN
PRINT, ‘NO FILE TO READ’
CONTINUE
ENDIF이렇게 하면 count가 0일 경우에는 메시지를 일단 출력한 뒤 반복문의 다음 회차로 바로 건너뛰게 됩니다. 그렇게 해야 해당 asc 파일이 전혀 없을 경우에 다음 회차로 알아서 넘어가도록 하는 것이 가능합니다. 그리고 그 뒷부분을 보면 READCOL 명령이 사용된 부분이 다음과 같이 나와있는데요.
Z = FLTARR(nl)
P = FLTARR(nl)
CO = FLTARR(nl)
C2H6 = FLTARR(nl)
C2H2 = FLTARR(nl)
HCOOH = FLTARR(nl)
CH3OH = FLTARR(nl)
CO2 = FLTARR(nl)
READCOL, file, Z, P, CO, C2H6, C2H2, HCOOH, CH3OH, CO2, ~~~~여기서는 Z, P, CO 등과 같은 배열의 형태를 미리 규정한 다음에 READCOL을 사용할 필요는 없습니다. 어차피 READCOL 명령의 실행 과정에서 파일 내의 값들을 하나하나 읽어가면서 각 배열마다 값을 채워넣기 때문에, READCOL 명령이 실행된 후에 Z, P, CO 등의 배열들이 생성됩니다. 그래서 여기서는 그냥 다음과 같이 READCOL 명령만 바로 사용하면 됩니다.
READCOL, file, Z, P, CO, C2H6, C2H2, HCOOH, CH3OH, CO2, ~~~~
물론 원래 하셨던대로 한다고 해서 오류가 나거나 하지는 않지만, 굳이 필요없는 여러 줄의 라인들은 제거하여 코드의 내용을 조금이라도 단순화시키는 것이 좋습니다.
그리고 질문하시는 내용과 관련하여 전체적으로 말씀을 드리고 싶은데요. 처음에 올리셨던 질문의 내용을 보면, 제가 보기에는 데이터 처리 작업을 위한 전반적인 아이디어에 대한 문의의 성격이 강한 것으로 보입니다. 그런데 이렇게 되면 Q&A 게시판에서 질문과 답으로 주고받기에는 너무 광범위한 문제입니다. 작업을 구체적으로 진행하면서 마주하게 되는 구체적인 이슈에 대해서라면 Q&A 게시판에서 소화가 가능하겠지만, 그냥 전반적인 아이디어를 얻고자하는 경우는 Q&A가 아닌 컨설팅의 영역에 가깝습니다. 따라서 좀 더 범위를 좁혀서 구체적인 이슈에 관한 질문으로 해주시면 답을 드리는 입장에서도 더 명확하고 구체적인 도움을 드릴 수 있다는 점을 염두에 둬주시면 감사하겠습니다.
올려주신 질문의 내용만 봐서는 데이터 파일들의 체계를 파악하기가 좀 힘든데요. 아마도 제 추측으로는 전반부의 내용에서 언급된 csv 파일 내에 약 15~16년치의 데이터가 수록되어 있는 것으로 보이고, 후반부에서 언급된 asc 파일들은 년+월에 대하여 나눠진 파일들로 보입니다. 그리고 csv 파일로부터는 년, 월, 일 등 날짜에 해당되는 정보들만 읽어오고, asc 파일로부터는 z, p, co 등의 데이터 값들만 읽어와야하는 상황인지요? 언급하신대로 어떤 파일로부터 z, p, co 등의 데이터를 읽어왔는데 그 데이터들을 년월일 별로 구분하고자 한다면, 데이터와 함께 날짜 정보도 함께 읽어와야 합니다. 그러면 asc 파일 내에도 년월일 등의 정보가 있어야 할 것이고, 그 정보를 읽어와서 년월일 별 배열로 얻은 다음 이 배열에 대해서 WHERE 같은 함수를 써서 원하는 날짜별로 추출을 하는 등의 과정을 거쳐야 할 것으로 보입니다.
그래서 csv와 asc 파일의 정보들이 총망라된 상태에서 날짜별 추출을 하고자 하는 경우인지, 아니면 asc 파일 각각에 대해서만 그런 추출을 하고자 하는 경우인지 궁금합니다. 주신 정보만으로는 저로서도 더 이상 자세한 도움을 드리기는 힘들 것 같습니다.
올리신 코드를 보면 PLOT 함수에서 X축 데이터가 x2라고 되어 있는데, 이 데이터가 어떤 값들을 담고 있는 것인지요? X축이 날짜/시간이 되게 하려면 X축 데이터는 Julian date 값들로 구성된 배열이 되어야 합니다. 예를 들어 y가 100개의 값들을 담고 있는 배열이라고 하면, 동일한 갯수의 Julian date 값들로 구성된 배열이 X축 데이터로 사용되어야 합니다. 예를 들어 이 배열이 tjs라고 한다면 대략 다음과 같은 형태로 PLOT 함수를 사용해야 합니다.
p = PLOT(tjs, y, ~~~~)
만약 tjs와 같은 배열이 없을 경우에는 직접 만들어야 할 수도 있습니다. 그럴 경우에는 TIMEGEN 함수를 사용합니다. 이 함수의 사용법은 아래 링크를 참조하시면 됩니다.
http://blog.daum.net/swrush/275
그래서 갯수가 서로 동일한 tjs 및 y가 확보된 후에는 PLOT 함수를 사용하여 그림을 그리면 됩니다. 이 때 TICKUNITS 속성을 사용하여 X축 눈금의 간격을 제어할 수도 있고, XTICKFORMAT 속성을 사용하여 눈금별 문자의 형식을 제어할 수도 있습니다. 날짜 기반의 플롯을 그리는 방법에 관해서는 아래 링크를 참조하시면 됩니다.
http://blog.daum.net/swrush/188
그리고 축 눈금 문자의 형식을 제어하는 일반적인 방법에 관해서는 아래 링크를 참조하시면 됩니다.
http://blog.daum.net/swrush/275
다만 질문하셨던 것처럼 1109 대신 11/09와 같이 표시되도록 하려면, 다음과 같은 형태로 포맷 코드의 내용에 “/” 문자를 삽입하면 됩니다.
‘(C(CMoI2.2, “/”, CDi2.2))’
올려주셨던 GRIB 파일은 현재로서는 IDL의 어떤 버전에서도 읽지 못한다는 것을 본사 기술팀에서도 확인을 해주었습니다. 그래서 본사에서도 이 이슈를 버그로 인정하고 개선책을 찾기로 한 상태입니다. 하지만 수정이 된다 하더라도 차후의 버전에서의 얘기가 될 것이기 때문에, 안타깝지만 현 시점에서는 IDL에서 이 파일을 직접적으로 읽을 수는 없습니다. Python에서도 PyGRIB라는 라이브러리가 있긴 한데, 이 파일은 이 방법으로도 읽히지 않는 것 같았습니다. 따라서 이 파일을 제대로 읽기 위해서는 NOAA의 Weather and Climate Toolkit 또는 WRGIB와 같은 다른 도구들을 이용하는 것이 좋지 않을까 합니다.
예 저도 파일을 읽어보고 동일한 문제가 발생하는 것을 확인했습니다. 윈도우즈나 Mac OS용 IDL에서는 GRIB_API_ERROR로 시작하는 문구들은 뜨지 않고 그냥 Passed array is small이란 메시지만 나오긴 하는데, 그래도 제대로 읽히지 않는 것은 마찬가지입니다. 이 이슈가 파일 자체의 문제인지 아니면 IDL의 GRIB 파일 읽기 기능상의 문제인지에 대해서는 좀 더 확인을 해보고 판단해야 할 것 같습니다. 혹시 이 파일이 다른 곳에서는 정상적으로 잘 읽히고 사용되고 있는 파일인지 궁금합니다. 어쨌든 이 문제에 대해서는 현재 확인중이므로 결과가 나오면 다시 알려드리겠습니다.
우선 배열을 추출할 때 [1, *]의 형태가 아닌 완전한 1차원 형태로 추출하려면 REFORM 함수를 사용하면 됩니다. 즉 다음과 같이 사용합니다.
lat = REFORM(conc[0, *, 0, 0, 0])
그런데 올려주신 nc 파일 내에는 제가 보기엔 경위도 좌표 관련 정보가 없는 것 같습니다. 변수 및 전역속성 목록을 지난번 질문하실 때에도 올려주셨지만, 변수 4종과 전역속성 20종의 세부 항목들 중 어디에도 안보입니다. 물론 변수 4종의 목록을 확인해보면 XLONG, XLAT이란 이름은 등장하는데 실제로 그런 이름의 변수는 파일 내에 존재하지 않습니다. 언급하신 conc는 그냥 5차원 배열로 저장된 데이터값들에 해당되기 때문에 그 배열 내에 경위도 좌표 정보가 들어가있지는 않은 것 같습니다. 따라서 질문하셨던 것과 같은 방식으로 conc로부터 lon이나 lat 정보를 가져올 수는 없을 것으로 보입니다. 아마도 경위도 위치 및 범위에 대한 정보는 이 nc파일과는 별도로 따로 확보해야 하는 것 같습니다. 언급하신 (120, 40) 및 (0.01, 0.01)과 같은 정보는 아마 질문자께서 따로 확보하신 정보일 것으로 생각됩니다.
따라서 이미지를 맵상에 중첩 표출한 결과가 제대로 된 결과일 것이냐에 대해서는 제 3자 입장에선 판단을 할 방법이 없습니다. 확보하신 경위도 위치 및 범위에 대한 정보를 이용해서 표출을 해보시고 직접 판단하셔야 할 문제라고 봅니다.
올리신 코드의 내용을 보면 경도 범위가 100~150도이고 위도 범위가 30~55도인 지도를 표출한 상태에서 이미지의 위치는 (100, 30)이고 이미지의 크기는 가로 1도 세로 0.3도의 크기로 표시하도록 되어 있습니다. 따라서 링크해주신 것과 같은 결과가 나오는 것은 당연히 맞습니다. 따라서 전체적으로는 제대로 작업을 하신 것으로 보입니다. 다만, 저도상에서 이미지 전체가 차지하는 영역의 크기가 겨우 1도x0.3도가 되지는 않을 것입니다. 제 짐작이지만 어쩌면 이미지 격자 한 픽셀이 차지하는 영역과 이미지 전체 영역 사이의 혼란이 있었던 것은 아닌가 싶기도 합니다. 어쨌든 이미지의 지도상의 위치 및 커버리지의 경위도 범위에 대한 정확한 정보를 .nc 파일로부터 추출하여 그 정보를 이미지 표출 과정에 적용해야 할 것으로 보입니다.
