今年のGWはオーストラリア…ではなく、WMO第V地区WIS/TDCFワークショップ（URL忘れた）でWISメタデータ関係の講師を務めます。
火曜のぶんのプレゼンがさきほど脱稿。ここ数週間ばかりちょっとどうにかなりそうでしたが、そろそろ峠を越えるでしょうか。
宿のインターネットがずいぶんお値段が張るので、まるでダイヤルアップ時代のように「接続したらtodoリスト」を作って待ち構えています。そう、通信て高価な時代があって、それってとてもワークスタイルに影響するんだよねとか思います。
2013-04-28
2013-04-26
ISO19115-2のCEOPプロファイル、JMSJに出しているとは知らんかった Xie et al. (2007)
R Xie, R Shibasaki, M Ono, 2007: Metadata Development for the Integration of
CEOP Satellite-Observation Data.
J. Meteor. Soc. Japan, vol 85A, pp 487-517.
http://dias.tkl.iis.u-tokyo.ac.jp/metadata/pdf/Xie_CEOP_Metadata.pdf
ISO 19115-2 を継承（たぶん拡張）する形でプロファイルを作った記録。
というか
http://dias.tkl.iis.u-tokyo.ac.jp/metadata/
もブックマークしておくべき。
しかし、いったい誰が査読したんだろうかね。
CEOP Satellite-Observation Data.
J. Meteor. Soc. Japan, vol 85A, pp 487-517.
http://dias.tkl.iis.u-tokyo.ac.jp/metadata/pdf/Xie_CEOP_Metadata.pdf
ISO 19115-2 を継承（たぶん拡張）する形でプロファイルを作った記録。
というか
http://dias.tkl.iis.u-tokyo.ac.jp/metadata/
もブックマークしておくべき。
しかし、いったい誰が査読したんだろうかね。
2013-04-21
2013-04-17
[CF-Metadata] 分光●●という量は波長あたりか波数あたりか周波数あたりか、より一般的には何をもって物理量を同じとするかの問題
ＣＦメーリングリストで標記問題のスレッドが起こっている。
発端
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056412.html
大御所ジョナサンの方針呈示
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056413.html
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056416.html
実務者の賛意
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056415.html
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056419.html
ここで示された方針は、標準名の表に単位が１つしか書かれない以上、２つの計量の単位が物理的次元を異にするようなときは、同じ標準名のもとに収容すべきではない、ということであり、要は
物理的次元が異なる量は異なる物理量とする （※）
ということである。まあ、そうするほかない。逆の裁定がでたら、規定を全部換えたうえで m.s-1 単位の鉛直速度といわゆるωの違いはなくするということだな、と詰め
寄らねばならないところであった。
さて、※は違いだけを書いていて、任意の２つの計量が同じ物理量と判定できるような条件をあたえない。「物理量とは同じ現象に対して同じ単位を持つ計量である」といった安心感あふれる言い方はおそらくできない。同じ現象かどうかに争いがあるのが常だからである。
たとえば単位が同じケルビンであっても、気温と温位と相当温位は常識的に区別されるし、偽断熱相当温位と可逆相当温位を区別する向きもあるだろう。実務上、ホルトンの相当温位とボルトンの偽断熱相当温位を区別せねばならないことは多い。
全部区別すればいいじゃないかといわれるかもしれないけれど、ちょっと修飾語がつくと違った仕切りになるということはままあって、温位時間変化率と相当温位時間変化率を同一視する（同じハコに入れて管理したい）といったことは考えられなくもない。
残念ながらそこに銀の弾丸はないので、用途しだいでございますといって明解な理論なく終わる。
発端
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056412.html
大御所ジョナサンの方針呈示
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056413.html
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056416.html
実務者の賛意
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056415.html
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056419.html
ここで示された方針は、標準名の表に単位が１つしか書かれない以上、２つの計量の単位が物理的次元を異にするようなときは、同じ標準名のもとに収容すべきではない、ということであり、要は
物理的次元が異なる量は異なる物理量とする （※）
ということである。まあ、そうするほかない。逆の裁定がでたら、規定を全部換えたうえで m.s-1 単位の鉛直速度といわゆるωの違いはなくするということだな、と詰め
寄らねばならないところであった。
さて、※は違いだけを書いていて、任意の２つの計量が同じ物理量と判定できるような条件をあたえない。「物理量とは同じ現象に対して同じ単位を持つ計量である」といった安心感あふれる言い方はおそらくできない。同じ現象かどうかに争いがあるのが常だからである。
たとえば単位が同じケルビンであっても、気温と温位と相当温位は常識的に区別されるし、偽断熱相当温位と可逆相当温位を区別する向きもあるだろう。実務上、ホルトンの相当温位とボルトンの偽断熱相当温位を区別せねばならないことは多い。
全部区別すればいいじゃないかといわれるかもしれないけれど、ちょっと修飾語がつくと違った仕切りになるということはままあって、温位時間変化率と相当温位時間変化率を同一視する（同じハコに入れて管理したい）といったことは考えられなくもない。
残念ながらそこに銀の弾丸はないので、用途しだいでございますといって明解な理論なく終わる。
2013-04-16
XSD の ID 型または NCName 型
とある ISO 19139 準拠 XML ドキュメント（つまりは地理メタデータ）を XSD でバリデートすると、id 属性が ID 型にあわないという。どうやら、コンマがだめらしい。
そういわれてみると、一体何が許されるのか知らないのも気味が悪い。
そういわれてみると、一体何が許されるのか知らないのも気味が悪い。
- NCName ::= (Letter | '_') (NCNameChar)*
- NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender
- Letter ::= 英字のみならず漢字など文字っぽいもの
- Letter ::= BaseChar | Ideographic
- BaseChar ::= [A-Z] | [a-z] | [À-Ö] | [Ø-ö] | [ø-ÿ] | [Ā-ı] | [Ĵ-ľ] | [Ł-ň] | [Ŋ-ž] | [ƀ-ǃ] | [Ǎ-ǰ] | [Ǵ-ǵ] | [Ǻ-ȗ] | [ɐ-ʨ] | [ʻ-ˁ] | Ά | [Έ-Ί] | Ό | [Ύ-Ρ] | [Σ-ώ] | [ϐ-ϖ] | Ϛ | Ϝ | Ϟ | Ϡ | [Ϣ-ϳ] | [Ё-Ќ] | [Ў-я] | [ё-ќ] | [ў-ҁ] | [Ґ-ӄ] | [Ӈ-ӈ] | [Ӌ-ӌ] | [Ӑ-ӫ] | [Ӯ-ӵ] | [Ӹ-ӹ] | [Ա-Ֆ] | ՙ | [ա-ֆ] | [א-ת] | [װ-ײ] | [ء-غ] | [ف-ي] | [ٱ-ڷ] | [ں-ھ] | [ۀ-ێ] | [ې-ۓ] | ە | [ۥ-ۦ] | [अ-ह] | ऽ | [क़-ॡ] | [অ-ঌ] | [এ-ঐ] | [ও-ন] | [প-র] | ল | [শ-হ] | [ড়-ঢ়] | [য়-ৡ] | [ৰ-ৱ] | [ਅ-ਊ] | [ਏ-ਐ] | [ਓ-ਨ] | [ਪ-ਰ] | [ਲ-ਲ਼] | [ਵ-ਸ਼] | [ਸ-ਹ] | [ਖ਼-ੜ] | ਫ਼ | [ੲ-ੴ] | [અ-ઋ] | ઍ | [એ-ઑ] | [ઓ-ન] | [પ-ર] | [લ-ળ] | [વ-હ] | ઽ | ૠ | [ଅ-ଌ] | [ଏ-ଐ] | [ଓ-ନ] | [ପ-ର] | [ଲ-ଳ] | [ଶ-ହ] | ଽ | [ଡ଼-ଢ଼] | [ୟ-ୡ] | [அ-ஊ] | [எ-ஐ] | [ஒ-க] | [ங-ச] | ஜ | [ஞ-ட] | [ண-த] | [ந-ப] | [ம-வ] | [ஷ-ஹ] | [అ-ఌ] | [ఎ-ఐ] | [ఒ-న] | [ప-ళ] | [వ-హ] | [ౠ-ౡ] | [ಅ-ಌ] | [ಎ-ಐ] | [ಒ-ನ] | [ಪ-ಳ] | [ವ-ಹ] | ೞ | [ೠ-ೡ] | [അ-ഌ] | [എ-ഐ] | [ഒ-ന] | [പ-ഹ] | [ൠ-ൡ] | [ก-ฮ] | ะ | [า-ำ] | [เ-ๅ] | [ກ-ຂ] | ຄ | [ງ-ຈ] | ຊ | ຍ | [ດ-ທ] | [ນ-ຟ] | [ມ-ຣ] | ລ | ວ | [ສ-ຫ] | [ອ-ຮ] | ະ | [າ-ຳ] | ຽ | [ເ-ໄ] | [ཀ-ཇ] | [ཉ-ཀྵ] | [Ⴀ-Ⴥ] | [ა-ჶ] | ᄀ | [ᄂ-ᄃ] | [ᄅ-ᄇ] | ᄉ | [ᄋ-ᄌ] | [ᄎ-ᄒ] | ᄼ | ᄾ | ᅀ | ᅌ | ᅎ | ᅐ | [ᅔ-ᅕ] | ᅙ | [ᅟ-ᅡ] | ᅣ | ᅥ | ᅧ | ᅩ | [ᅭ-ᅮ] | [ᅲ-ᅳ] | ᅵ | ᆞ | ᆨ | ᆫ | [ᆮ-ᆯ] | [ᆷ-ᆸ] | ᆺ | [ᆼ-ᇂ] | ᇫ | ᇰ | ᇹ | [Ḁ-ẛ] | [Ạ-ỹ] | [ἀ-ἕ] | [Ἐ-Ἕ] | [ἠ-ὅ] | [Ὀ-Ὅ] | [ὐ-ὗ] | Ὑ | Ὓ | Ὕ | [Ὗ-ώ] | [ᾀ-ᾴ] | [ᾶ-ᾼ] | ι | [ῂ-ῄ] | [ῆ-ῌ] | [ῐ-ΐ] | [ῖ-Ί] | [ῠ-Ῥ] | [ῲ-ῴ] | [ῶ-ῼ] | Ω | [K-Å] | ℮ | [ↀ-ↂ] | [ぁ-ゔ] | [ァ-ヺ] | [ㄅ-ㄬ] | [가-힣]
- Ideographic ::= [一-龥] | 〇 | [〡-〩]
- Digit ::= 各種スクリプトの数字類
- [0-9] | [٠-٩] | [۰-۹] | [०-९] | [০-৯] | [੦-੯] | [૦-૯] | [୦-୯] | [௧-௯] | [౦-౯] | [೦-೯] | [൦-൯] | [๐-๙] | [໐-໙] | [༠-༩]
- CombiningChar ::= ベース文字と結合させるための記号類
- [̀-ͅ] | [͠-͡] | [҃-҆] | [֑-֡] | [֣-ֹ] | [ֻ-ֽ] | ֿ | [ׁ-ׂ] | ׄ | [ً-ْ] | ٰ | [ۖ-ۜ] | [-۟] | [۠-ۤ] | [ۧ-ۨ] | [۪-ۭ] | [ँ-ः] | ़ | [ा-ौ] | ् | [॑-॔] | [ॢ-ॣ] | [ঁ-ঃ] | ় | া | ি | [ী-ৄ] | [ে-ৈ] | [ো-্] | ৗ | [ৢ-ৣ] | ਂ | ਼ | ਾ | ਿ | [ੀ-ੂ] | [ੇ-ੈ] | [ੋ-੍] | [ੰ-ੱ] | [ઁ-ઃ] | ઼ | [ા-ૅ] | [ે-ૉ] | [ો-્] | [ଁ-ଃ] | ଼ | [ା-ୃ] | [େ-ୈ] | [ୋ-୍] | [ୖ-ୗ] | [ஂ-ஃ] | [ா-ூ] | [ெ-ை] | [ொ-்] | ௗ | [ఁ-ః] | [ా-ౄ] | [ె-ై] | [ొ-్] | [ౕ-ౖ] | [ಂ-ಃ] | [ಾ-ೄ] | [ೆ-ೈ] | [ೊ-್] | [ೕ-ೖ] | [ം-ഃ] | [ാ-ൃ] | [െ-ൈ] | [ൊ-്] | ൗ | ั | [ิ-ฺ] | [็-๎] | ັ | [ິ-ູ] | [ົ-ຼ] | [່-ໍ] | [༘-༙] | ༵ | ༷ | ༹ | ༾ | ༿ | [ཱ-྄] | [྆-ྋ] | [ྐ-ྕ] | ྗ | [ྙ-ྭ] | [ྱ-ྷ] | ྐྵ | [⃐-⃜] | ⃡ | [〪-〯] | ゙ | ゚
- Extender ::= おどり字の類
- · | ː | ˑ | · | ـ | ๆ | ໆ | 々 | [〱-〵] | [ゝ-ゞ] | [ー-ヾ]
2013-04-12
台風の暴風域に入る確率 あるいは2つの日時を引数にせざるを得ない関数（2つの時間次元とは別）
ある種のデータは、あたかも日時型（＝年月日時分秒）の引数を２つとる関数のように複数の時間に依存する。しばしば「ＧＩＳみたいに簡単じゃなく複数の時間があるのだ」という言葉を自分でも使うのだけど、そのありようが一様ではなく、いろいろの様相があるなあと考えさせられた。
１つめの類型は、OGC WMSで予報データを扱おうとする場合、経緯度に加えて起算日時（initial time あるいは観測などに一般化するために参照日時 reference time と
いうこともある）と対象日時（valid time）を与えないとデータが特定されないよ、というような話。OGCについてはウィキ（http://goo.gl/BO54w）以上に新しい資料があったような気がするが失念して申し訳ない。データ構造としてはデータベースのキーに日時型のカラムが２つ設けるとか、配列の添字に起算日時と予報時間（対象日時と起算日時の差で得られる時間単位つきのスカラー数値）に結びついた番号を用いるといった実現のされかたをする。
２つめの類型は、1時間積算雨量であったり、30年平均値であったり、なにしろ時間方向の統計処理から生み出されるとされるデータ。
第1類型と第2類型は、排他に起こるわけではなく、たとえば降水量の予報ならば、都合3つの日時（起算日時、積算開始日時、積算終了日時）がある。
これらについて最も壮麗な体系を持っているのはGRIB第2版で、参照日時と予報時間が記述できるほかに、第4節というところに任意個の統計処理のリストを記述できて、それぞれに単位付きスカラー数値のパラメタを最大２つ記述することができる。そしてそのベースとなる量（GRIB用語ではパラメタ）は時間ひとつの関数となるような物理量でなければならない（つまり降水量ではなく降水強度のようなものが基底でなければならない）という仕組みにしようとしていた（2008年頃まで）。
なぜ統計処理がリストかというと、4月の毎日19時台の降水量の平均値を過去30年間にわたって平均したもの、みたいな概念がありうるから。
しかし、この偉大なミニマリスト・プログラムはもう悲しいくらいに理解されていない。通報式マニュアルにおいてすらひどい混乱があったので読みとることさえ困難だったくらいである。現実のユーザ受容としては、特に積算値については、たとえば9日23時から10日0時の降水量といわず9日24時の1時間降水量と言いたがるように、「1時間降水量」というパラメタ付き物理量があって、それが瞬間値として与えられるといういいかたが文章上行われるし、データもその概念を反映してほしいと思う人が多い。
べつになにもGRIB2だけをdisりたいわけではなく、他の気象データ形式においても、次元リストをビルトインの固有名詞にしようとする限りは本質的に同じ問題が発生している。19世紀の言語学では言語は総合から分析に進化するなんて言われたけどどうもそうじゃないように、ここではどうも分析至上主義の旗色が悪くて、日射強度の時間積算なんて言わせようとすると嫌がられる。
ここまでは既知の話。いや、まあ、どこにもまとまった議論なんかないだろうが。
さて、今日、「台風の暴風域に入る確率」「熱低が接近する確率」について議論（http://goo.gl/PokKS）していて気がついたのだけれど、３つめの類型かな、と思ったのは、このようなイベント生起確率。
このような量はある日時範囲に対して定義されるのだけれど、それを日時ひとつだけの関数の統計処理として書き下すことが困難である。「ｔ時間の間に暴風域に入る確率」をｔについて微分したものをナントカ確率密度と定義するのは数理的には自由だけれども、実務上は意味不明になるばかりである。
つまり、本来的に日時を２つ引数にとる関数で表わさざるをえない量があることがわかった。少々おおげさに言えば、日時を１つだけ引数にとる関数と統計処理リストに分解しようとするGRIB2のミニマリズムが原理的に否定されるのである。
まあ、システム屋的には、そんな意地悪をいっていても仕方がないので、「統計じゃないことを示す統計処理番号」（実は日本の天気ガイダンスや発雷確率ガイダンスがそうなっている）を導入して追加的メタデータ記述欄を設けるのがいいのだろう。
さて、ECMWFの熱低遭遇確率GPVはどうなるだろうか。
１つめの類型は、OGC WMSで予報データを扱おうとする場合、経緯度に加えて起算日時（initial time あるいは観測などに一般化するために参照日時 reference time と
いうこともある）と対象日時（valid time）を与えないとデータが特定されないよ、というような話。OGCについてはウィキ（http://goo.gl/BO54w）以上に新しい資料があったような気がするが失念して申し訳ない。データ構造としてはデータベースのキーに日時型のカラムが２つ設けるとか、配列の添字に起算日時と予報時間（対象日時と起算日時の差で得られる時間単位つきのスカラー数値）に結びついた番号を用いるといった実現のされかたをする。
２つめの類型は、1時間積算雨量であったり、30年平均値であったり、なにしろ時間方向の統計処理から生み出されるとされるデータ。
第1類型と第2類型は、排他に起こるわけではなく、たとえば降水量の予報ならば、都合3つの日時（起算日時、積算開始日時、積算終了日時）がある。
これらについて最も壮麗な体系を持っているのはGRIB第2版で、参照日時と予報時間が記述できるほかに、第4節というところに任意個の統計処理のリストを記述できて、それぞれに単位付きスカラー数値のパラメタを最大２つ記述することができる。そしてそのベースとなる量（GRIB用語ではパラメタ）は時間ひとつの関数となるような物理量でなければならない（つまり降水量ではなく降水強度のようなものが基底でなければならない）という仕組みにしようとしていた（2008年頃まで）。
なぜ統計処理がリストかというと、4月の毎日19時台の降水量の平均値を過去30年間にわたって平均したもの、みたいな概念がありうるから。
しかし、この偉大なミニマリスト・プログラムはもう悲しいくらいに理解されていない。通報式マニュアルにおいてすらひどい混乱があったので読みとることさえ困難だったくらいである。現実のユーザ受容としては、特に積算値については、たとえば9日23時から10日0時の降水量といわず9日24時の1時間降水量と言いたがるように、「1時間降水量」というパラメタ付き物理量があって、それが瞬間値として与えられるといういいかたが文章上行われるし、データもその概念を反映してほしいと思う人が多い。
べつになにもGRIB2だけをdisりたいわけではなく、他の気象データ形式においても、次元リストをビルトインの固有名詞にしようとする限りは本質的に同じ問題が発生している。19世紀の言語学では言語は総合から分析に進化するなんて言われたけどどうもそうじゃないように、ここではどうも分析至上主義の旗色が悪くて、日射強度の時間積算なんて言わせようとすると嫌がられる。
ここまでは既知の話。いや、まあ、どこにもまとまった議論なんかないだろうが。
さて、今日、「台風の暴風域に入る確率」「熱低が接近する確率」について議論（http://goo.gl/PokKS）していて気がついたのだけれど、３つめの類型かな、と思ったのは、このようなイベント生起確率。
このような量はある日時範囲に対して定義されるのだけれど、それを日時ひとつだけの関数の統計処理として書き下すことが困難である。「ｔ時間の間に暴風域に入る確率」をｔについて微分したものをナントカ確率密度と定義するのは数理的には自由だけれども、実務上は意味不明になるばかりである。
つまり、本来的に日時を２つ引数にとる関数で表わさざるをえない量があることがわかった。少々おおげさに言えば、日時を１つだけ引数にとる関数と統計処理リストに分解しようとするGRIB2のミニマリズムが原理的に否定されるのである。
まあ、システム屋的には、そんな意地悪をいっていても仕方がないので、「統計じゃないことを示す統計処理番号」（実は日本の天気ガイダンスや発雷確率ガイダンスがそうなっている）を導入して追加的メタデータ記述欄を設けるのがいいのだろう。
さて、ECMWFの熱低遭遇確率GPVはどうなるだろうか。
2013-04-10
2013-04-05
2013-04-04
メモ：TT-AvXMLのほうでやっている restful 符号表サービスは表バージョンを意識しているらしいからまあいいかと思った
BUFR表Ｂというのは、（表バージョン、符号、意味）という形の表で、（表バージョン、符号）まで指定しないと一意に意味が決まらないはずなんだけど、９８％の場合は符号だけで一意に意味が決まるという感じなわけです。そんなところで
Linked Data 的な思惑から符号だけをもって作ったＵＲＬを使って restful な符号表をウェブサービスするとプレゼンしたもんだから、大丈夫ですかと聞いたら、大丈夫だというので、まあ詳細はわからないけど問題認識しているならいいんじゃないでしょうか、という話。
https://groups.google.com/a/wmo.int/d/msg/cbs-tt-avxml/C72w5zxYdRg/LEO8eqF8TfsJ
まあ、サービスするだけじゃなくて符号表の管理（提案・採択のプロセス）とリンクしなきゃいけないよ、ということを念押ししておいたので、なんとかなるんじゃなかろうか。
Linked Data 的な思惑から符号だけをもって作ったＵＲＬを使って restful な符号表をウェブサービスするとプレゼンしたもんだから、大丈夫ですかと聞いたら、大丈夫だというので、まあ詳細はわからないけど問題認識しているならいいんじゃないでしょうか、という話。
https://groups.google.com/a/wmo.int/d/msg/cbs-tt-avxml/C72w5zxYdRg/LEO8eqF8TfsJ
まあ、サービスするだけじゃなくて符号表の管理（提案・採択のプロセス）とリンクしなきゃいけないよ、ということを念押ししておいたので、なんとかなるんじゃなかろうか。
2013-04-02
OUTLINE OF THE OPERATIONAL NUMERICAL WEATHER PREDICTION AT JMA 2013
OUTLINE OF THE OPERATIONAL NUMERICAL WEATHER PREDICTION AT JMA は気象庁の現業数値予報モデルの概要を説明したもので、数年に一度発行されています。
http://www.jma.go.jp/jma/jma-eng/jma-center/nwp/outline2013-nwp/index.htm
モデルがどうこう言えた知見はないのですが、FAX図の図郭を説明する地図がカラーになっています。
http://www.jma.go.jp/jma/jma-eng/jma-center/nwp/outline2013-nwp/pdf/outline2013_04.pdf#page=3
ここで出てくるFAX図は、すべてポーラーステレオ図法（※）かメルカトル図法なので、ポーラーステレオ図法の地図の上にならべて描くと長方形と扇形になるのでありました。
※ 北極を中心とする平射図法は気象界ではこう呼ばれる。方言かどうかわからない
http://www.jma.go.jp/jma/jma-eng/jma-center/nwp/outline2013-nwp/index.htm
モデルがどうこう言えた知見はないのですが、FAX図の図郭を説明する地図がカラーになっています。
http://www.jma.go.jp/jma/jma-eng/jma-center/nwp/outline2013-nwp/pdf/outline2013_04.pdf#page=3
ここで出てくるFAX図は、すべてポーラーステレオ図法（※）かメルカトル図法なので、ポーラーステレオ図法の地図の上にならべて描くと長方形と扇形になるのでありました。
※ 北極を中心とする平射図法は気象界ではこう呼ばれる。方言かどうかわからない
2013-04-01
JPEG2000 の codestream の構造
ISO/IEC 15444-1:2000 Annex A "Codestream Syntax" に規定がある。
なんというか、わかった気になるための概要。
・コードストリームはマーカー・マーカーセグメント・データの羅列である。
これらはすべてオクテットの倍数（BUFRと同様にパディングが行われる）。
・マーカーは 0xFF で始まる２オクテット。名前がついている。
・マーカーセグメントはマーカーの種類によって異なる構造を持つ固定長メタデータで、マーカーの種類によってはまったく存在しないこともある。
セグメントが存在する場合には、先頭２オクテットがセグメント長（セグメント長自身を含むがマーカーは含まない）。
・コードストリームは巨視的にみると次のような構造を持つ：
メインヘッダ, (タイルヘッダ, データ)+, EOC{FFD9}
・メインヘッダはSOC{FF4F}で始まるマーカー群である。
・タイルヘッダはSOT{FF90}で始まりSOD{FF93}で終わるマーカー群である。
SOTに続くセグメントの第4オクテット（SOTの最初＋6オクテット）から32ビットがタイル長で、SOTの最初からデータの終わりまでの長さである。SODに長さを書かないでSOTに書くのは読み飛ばしを効率化しようとしているのだろう。
・マーカーで素人眼にも見るべきものは、COM{FF64} つまりコメントで、セグメント第2-3オクテットが種別（0がバイナリ、1がISO 8859-15文字列）、そのあとが任意長の文字列である。まあ実際
のところ "Creator: JasPer Version 1.900.1" が入っている。
ほんとうはファイルをダンプして確認するといろいろ発見もあるだろうのだが、まだやっていない。
あとはウェーブレットとかよう説明せんので、たぶん読書ノートはこのへんでお仕舞い。
なんというか、わかった気になるための概要。
・コードストリームはマーカー・マーカーセグメント・データの羅列である。
これらはすべてオクテットの倍数（BUFRと同様にパディングが行われる）。
・マーカーは 0xFF で始まる２オクテット。名前がついている。
・マーカーセグメントはマーカーの種類によって異なる構造を持つ固定長メタデータで、マーカーの種類によってはまったく存在しないこともある。
セグメントが存在する場合には、先頭２オクテットがセグメント長（セグメント長自身を含むがマーカーは含まない）。
・コードストリームは巨視的にみると次のような構造を持つ：
メインヘッダ, (タイルヘッダ, データ)+, EOC{FFD9}
・メインヘッダはSOC{FF4F}で始まるマーカー群である。
・タイルヘッダはSOT{FF90}で始まりSOD{FF93}で終わるマーカー群である。
SOTに続くセグメントの第4オクテット（SOTの最初＋6オクテット）から32ビットがタイル長で、SOTの最初からデータの終わりまでの長さである。SODに長さを書かないでSOTに書くのは読み飛ばしを効率化しようとしているのだろう。
・マーカーで素人眼にも見るべきものは、COM{FF64} つまりコメントで、セグメント第2-3オクテットが種別（0がバイナリ、1がISO 8859-15文字列）、そのあとが任意長の文字列である。まあ実際
のところ "Creator: JasPer Version 1.900.1" が入っている。
ほんとうはファイルをダンプして確認するといろいろ発見もあるだろうのだが、まだやっていない。
あとはウェーブレットとかよう説明せんので、たぶん読書ノートはこのへんでお仕舞い。
登録:
投稿 (Atom)