prasinos' work memo

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

CEE308 読書4 NAD27

* NAD27 以前: NAD02 (Bowie, 1914: Special Publication 19).

* 西部の三角測量網の最後の arc が閉じたのが1926年、そこで全体の再調整が企画されてNAD27となったわけである。

* 原点をMeades Ranch, Kansas にとったのは、鉛直線傾斜の比較考量によって J.F. Hayford が決めた(人はどうでもいいだろうけどいちおう比較くらいはしたということで)

* Clarke 1866 楕円体は以前から使われていた
スポンサーサイト

DAYMET

モンタナ大学林学部が作ったUS48州の毎日の格子気象データ(1980年~19
97年)。 http://www.daymet.org/ で公開されている。1km格子のDEM(地形
データ)と地上観測だけがインプットで、何やら傾斜による日射や最低気温時の水の
凝結は考慮したモデルによっているのだという。残念ながらリアルタイムではない。

科学面。実際問題として、そのへんを考慮した高解像度の気象データが欲しいという
応用面の要請はよくわかる。が、地点観測だけがインプットというのはいかにもメソ
スケールとして弱い、とか、グローバルな応用、とかいった観点から、気象の客観解
析とうまくリンクできないかなあと思う。きっと彼らもそう思っているだろう。そう
いう場合、ミクロスケールの気象の

技術面。GIS で解析する用のデータ形式は .fltimg という拡張子になっていて、こ
れは要は浮動小数点数の羅列である。したがって、この形式が好まれることがわかる
し、この形式を ArcGIS で使うときのマニュアルが得られるわけである。

GPS の森

URLメモだけでごめん。GPSを使った環境学習支援システムだそうだ。MAPTEACH に似ている。

CEE308 読書2: 測地系

●はじめに

・伝統的に、水平と鉛直は異なる測量の体系を持ち、異なる測地基準 datum の体系を持っている。

・土地登記簿など、過去の記録を参照することはあるので、測地基準間の簡単な移行はできない。{米国でも土地登記簿があるんだ。}

●ジオイドに対する楕円体の位置づけ(単天文台法)

・原点と第一方位を決めたら、そこで天文学的に経緯度と第一方位角を測定する。
・これをもって原点・第一方位とする。つまり、原点においてジオイド面と回転楕円対面が平行であると仮定する。これが測地基準を定義するひとつの方法(単天文台法 single astronomical station method) である。
・この仮定による嘘は、{回転楕円対面がマトモな地心基準のものに対して傾いているので}測量範囲が広くなると顕在化する。
・注意。原点以外の場所においてはジオイドは回転楕円体面に対して傾いているので、天文緯度と測地緯度は一致しない。

●天文測地法

・複数のラプラスステーションにおいて経緯度を測定するのが、第二種の測地基準の定義方法(天文測地法 astro-geodetic method)である。この場合、全ラプラスステーションにおける鉛直軸の傾き deflection の二乗和を最小にするように測地系の位置が定められる。どれかひとつのラプラスステーションが原点に選ばれる{前文と矛盾してません?}。

・ラプラスステーションというのはフランスの数学者ピエール・シモン・ラプラスに由来する名前で、なるべくチェーンに近いところで方位角と経度を測定することでチェーン上の累積誤差を制御しようとするものである。天文・測地系間の経度・方位角の差はラプラス方程式というもので書かれる。{ラプラス方程式といってもいろいろあるのだが何かはよくわからない}

・この方法は近年オーストラリアで用いられた。事前にラプラスステーション間で測量網の準備計算をし、天文観測をした後にジオイド傾斜の算出を行う。

・利点:対象領域全域にわたってジオイド傾斜を見積もり、全体を通じたジオイドの平均的な面を楕円体に合わせるので、広域について適用できる。

・だいたい、1国程度の測地系ならばジオイド高を10m以内にするような楕円体を探すことができる。

・欠点は原点において鉛直線傾斜が残ることであり、もし楕円体が変更されると鉛直線傾斜が変わったりする。また、鉛直線傾斜の計算の前に楕円体の向き付けを仮定しなければならない{なんで?}。

●衛星測地系

衛星観測で用いられる測地系は、地上とはまったく違う決められ方をする。地球重心を中心として天体暦と同様に相対論を考慮したジオポテンシャルモデルを用いる。{これは本質的にはデカルト座標だが、}普通は地理的座標{緯度経度}を算出するために楕円体を用いる。

●測地系間の差異

複数の三角測量ネットワークが重なっている領域では、測地系によって同じ点の座標は異なる。これは

・異なる楕円体
・異なる鉛直線傾斜
・原点における異なるジオイド高

から来ている。

・鉛直線傾斜の絶対値{原点における値のことだと思う}の経緯度成分はシステムの平行移動をもたらす。
・方位角測定における deflection はシステムを回転させる。
・水平基準点のスケールの相違はシステムの拡大をもたらす。

これらによって、異なる2つの測地系を連結する正確な一般的な方法は存在しない{?}。

大陸間弾道弾の開発に当たって測地系が連結していないことが問題となり、統一測地系を開発する機運が生じた。

●測地基準の連結

3つの一般的な方法がある。

1.3次元アフィン変換(狭領域用)
2.衛星観測を用いる。衛星以前の時代は日食・星の掩蔽をつき位置カメラで撮影
3.重力観測による

●1940 年以前の測地系

「現時点」{たぶん80年代}における最善の方法は、世界の4大ブロック毎に支配的な測地基準に対してデータを変換することだ。これは、各国が日常的利用のための測地データを変換しなくてはならないということではない。

●北アメリカ測地基準1927 (NAD27)

原点:カンサス州ミーズランチ Meades Ranch, KA
φ = 39°13′26″.686, λ = 261°27′29″.494
楕円体: Clarke 1866
方位:天文測地法を修正したもの

南北アメリカで共通して用いられた。NAD 83 に更新され、楕円体は the 1980 Intl ellipsoid となった。

●欧州測地基準 (ED)

原点:東ドイツ、ポツダムにあるヘルメルト塔
φ = 52°22′51″.45, λ = 13°03′58″.74
楕円体:Intl ellipsoid
方位:天文測地法

欧州、中東、アフリカ、ロシアで用いられた。

●東京測地基準

原点:東京天文台
φ = 35°39′17″.51, λ = 139°44′40″.50
楕円体:ベッセル楕円体
方位:単天文台法

日本、朝鮮、旧満州で用いられた。
不幸にして東京はジオイド傾斜が急なところにあったので、原点から離れたところでのジオイド傾斜はきわめて大きい。

●印度測地基準

原点:カリナプール(中印度)
φ = 24°07′11″.26, λ = 77°39′12″.57
楕円体:エベレスト楕円体

東南アジアで用いられた。楕円体が一番古いし、東南アジアでは基準点網が弱いので、一番怪しい立場である。

●Hiran

レーダー技術による測量で、EDM 装置に似た原理の Shoran システムを改良したものである{なんだこりゃ?}

ともかくこれで北米基準と欧州基準が連結されるらしい。1:100 000 もの精度が達成されるものの、もともとの測地基準が古くてそこまでの精度がなく、どうしたもんだろう状態。

CEE308 読書ノート 1: 地球の形

●地球が丸い効果

標高1000mのところで水平の長さ2000mをとると、海面上の長さは 1999.68m である。

●扁平さが知られた時期

1730 年代から地球の扁平さは知られていた
{ニュートンの力学的予想か? ペルーとラップランドに行ったフランス測量隊で決着がついたと思っていたのだが}

●回転楕円体は ellipsoid か spheroid か

本当は三軸不等かもしれない一般の楕円体が ellipsoid で、2軸等長の回転楕円体は spheroid というのだが、「球みたいだけとちょっとずれている形一般」をも spheroid というので、結局のところ測地学畑では ellipsoid (of revolution) という。

●ジオイド

ジオイドは北半球中緯度で凹み、南半球中緯度で膨らんでいることから、洋梨型という人がいるが、その凹凸はたかだか 20m 程度である。楕円体の扁平による長短軸の長さの差が 21km もあるので、それを絵に描いたらばジオイドの凹凸などは全く読み取れない。

DBとデータの間

NuSDaS のデータモデル再考。

我々は種別だけで識別されるデータをデータセットと呼ぶ。そして、データ入出力の最小限の単位であるところのデータレコード(XY二次元格子)がそのデータセットの中に散在している、というデータモデルである、と今まで考えてきた。

そして、3次元・4次元データレコードの導入によって「最小限のデータ操作単位としてのデータレコード」の概念が崩壊したので、データセットの中に「格子データとみなせる領域」を作る必要が生じた。そこで、「格子データとみなしたい範囲」の最大をとろう、ということで、「XYZ・要素・予報時間・メンバ」の6次元格子を最小単位と考えることにして、「データショット」と命名してもらった。

しかし、これは入出力に偏った見方であった。

メタデータについて考えると、「種別によって異なる」「基準時刻によって異なる」「メンバによって異なる」と考えられるので、基準時刻とメンバは同じ空間にあるべきで、むしろ「XYZ・要素・予報時間」の5次元が問題である。この5次元がデータセットとデータレコードの中間にあるべきドメインである。

これを仮にデータベースと呼ぼう。

データベースの発見が遅れたのは、メンバがデータベースの外に出るか中に入るのかが揺れていることである。こういう揺れ方は怪しからんと言われがちなのだけれども、私は業務プロセスをよく反映いいことなのではないかとも思う。

OSI 参照モデル

前々項で OSI 参照モデルみたいなものの GIS 版の絵を描いた。今から思い返してもこれはすごいことだ。

こういうのを概念の世界できちんと交通整理しておくと、どこぞのプロトコルスタックみたいなもので互換性も確保しやすいし、仕事の努力が分散しないことになる。第一誰が何をやっているか話すときの言葉になる。こういうものを作る人たちは、必ずや将来学ぶべきものを生み出す。

読者各位嘘だと思うならば、 OSI 参照モデルができてからインターネット革命が起こるまで何年かかったか考えて見てくれたまえ。今はその途中なのだよ。

と書こうと思って、はたと気がついたのは、
OSI 参照モデルがいつできたのか知らない
ということである。それどころか、一体 ISO 規格の何番で規定されているのかも知らなかった。

これはとても恥ずかしいことである。半可通もいいところだ。

さて調べようと思うと、 google をうまく使うのは難しい。原典に当たらずに書かれた、原典に当たるつもりのない人たちのための文書ばかり引っかかってしまうので。結局のところ ISO のとこでサーチして ISO/IEC 7498-1:1994 "Information technology -- Open Systems Interconnection -- Basic Reference Model: The Basic Model" を得た。やっぱり私のように不器用な人間にはこういう組織がきちんとしていてくれるとても助かる。

さて、 7498-1:1994 は 7498:1984 の改訂版であって、要は最初は 1984 年だ。しかし、インターネットの系譜を考えるなら、結局ダメになってしまったネアンデルタール人の話をしても仕方がないのであって、 DoD four-layer model(※) が開発された 70 年代に遡らなければいけないようだ。やっぱり、理論から実用に20年はかかるのである。

ところで、※のリンクは答えが判ってしまってから google 様に教えてもらった OSI モデルの説明からたどったもんである。このページもまた含蓄深い。

二重母音の初めの音だけが聞こえる

前項で沿岸浸食の話をちょっとし(ようと思ってリンクだけし)たが、それが問題になっている Ozaukee County, WI について話しているのを聞いていると「尾崎カウニー」と聞こえるのよね。 [aU] (SAMPA記法について)が [a] にしか聞こえない。

そこで思い出したのだけれど、 Style Network の "How do I look?" も「ハドゥアル?」にしか聞こえない。中には丁寧に発音する人もいるのだけど、まあ音楽に乗せて歌おうとしたら二重母音に短母音と同じ時間しかかけられないのだから、どこかが弱くなるしかないのだろうと考えた。

そう思って google してみたら、やっぱり世間でも二重母音の後半てのはそんなに時間をかけないものであることは普通に認識されていることであるらしい。つーかこの本俺借りて読んだことないか(別に推奨するわけではない)。

鳥頭....

相互運用性スタック

またしても金曜セミナーレポート。時たまとんでもなく有益な講演が入るので、イザというときに出撃できる体制をとっておくことはやっぱり望ましい。

State Cartographer's Office の人が来て「Moving towards a services-oriented architecture (SOA) for geospatial applications」とかいうタイトルで話をしてくれた。前半はOGC, ISO, NSDI あたりを中心とする世界情勢で、後半はそれを受けた SCO の取り組みである。

大変申し訳ないが SCO のことはちょっと置いておかせてもらって(いや、その、沿岸浸食は大事な問題ですよ。)、世界情勢の話。

●人物相関図

UML みたいな組織相関図をみせてもらったわけだけれど、 ISO/TC 211 が軸で、メンバー国としての米国機関は窓口は ANSI 実働は FGDC で、一方で ISO に対してアドバイゾリ・メンバーたる OGC があってそこに米国政府の声たる FGDC が戦略メンバーとして仕切っておる、というような感じである。ぼくら地方政府の声は FGDC を通って世界に行くことになるってなまとめ。

以上、面倒なので作図は読者の宿題とするが、要はもはや世界は一つである。

どうでもいいが、矢印の上に「is a national member of」と書いてあるととてもわかり易い。

●FGDC メタデータはもう古い!

そんでもって、ISO/TC 211 はいろいろ規格を作っているわけで、メタデータの規格が既にできているのだという。しかも、今まで宇宙の中心視されてきた FGDC Metadata Standard 正式名称 Content Standard for Digital Geospatial Metadata (CSDGM) とは別物で、世界は ISO に向かっているのだという。
これは驚天動地の新事態である。
いままで FGDC std が世界の最終形態で、これを勉強しようと思っていたが、急遽番号もわからない ISO 規格に方針転換だ。

●相互運用性スタック

さて、連中は相互運用性を確立しようとしているのだが、ただ闇雲にプログラムと仕様を寄せ集めているわけではなくて、ネットワークの OSI 参照七階層モデルのようなスタックモデルを確立している。

絵をみて感動した。OpenGIS Reference Model (ORM) の 56 ページ目を見てほしい。なんていうと誰も見ないので、












階層標準の例
サービス統合・ワークフローWSFL, XLANG, ISO19119
サービス発見UDDI, OGC-Catalog
サービス記述WSDL, ISO19119
サービスOGC SF, Coverage, 座標変換, WMS
バインディングHTTP, SOAP, COM, CORBA, SQL, J2EE, ...
データ形式、スキーマ、および意味 HTML, XML/S, RDF, XMI, OGC-GML, OGC-WKT/WKB
データ表現とエンコーディングASCII, ASN.1/DSR, XML
通信プロトコルTCP/IP, HTTP, SSL, SMTP, FTP, IIOP


というのだ。直感でこれまで知っていたものを強引に割り当てると、












階層これまで知っていた例
サービス統合・ワークフロー何たら作業ふんたらシステムとか命名されるやつ
サービス発見THREDDS, STARS, Pandora Redirection
サービス記述上のためのメタデータ標準
サービスOpenDAP, ADDE, STARS ファイル転送層, Pandora NRD
バインディング上とどう違うのかよくわからん
データ形式、スキーマ、および意味 HTML, NetCDF Conventions, f32 format
データ表現とエンコーディングASCII, XDR, XML, NetCDF
通信プロトコルTCP/IP, HTTP, SSL, SMTP, FTP, LDM


といったところだろう。間違っていても知らん。

ともかくである、これまで「データ表現とメタデータ形式を分けよう」だとか「サービス発見とサービスを分けよう」だとかちまちま考えていたのが、一気に完成形八階層を見せられてしまったわけで、先進国に迷い込んできた悲哀と感動と興奮がないまぜである。

...なんて嘆いている場合ではない。勉強するのだ。

GIS Day Expo

GIS Day Expo に行って来た。いや、行って来たじゃなくて、運営を手伝わないといけない義理があったような気もしないこともないのだが、私も色々それどころではなかったし、気にしないことにしよう。ごめん。そんでもって色々。

●ウィネバーゴ郡

ちょっとした縁でウィネバーゴ郡のエンジニアと知り合いになり、今日も行ったら居たのでびっくりした。

ウィネバーゴはGISについては超先進郡なのである。

そもそもウィネバーゴ郡はウィスコンシンの東部、オシュコシュ市を中心としたウィネバーゴ湖沿いの地方で、オシュコシュといったら日本では子供服ブランドのオシュコシュBゴッシュくらいしか知られていないだろう。まあ私も他には EAA Airshow くらいしか知らない。

そんなことはどうでもいい。

当郡のウェブサイトを見ると、GISのサイトが見られる。これがおっそろしくすごいので、10インチくらいの解像度の航空写真が重ねられたり、土地区画のリンクをたどって所有者を含む登記情報が見られたり、FEMA の水害リスク評価(何かの損害保険料に関係する)が見られたり、もうやり放題である。

所有者が見られちゃっていいのか? ってのは疑問に思ったが、日本だってIT化されてないだけで法務局に行きさえすれば登記簿は見られるのだから、原理的には同じことだ。しかし、量的変化は質的変化をもたらす(ヘーゲル)ってなわけで、名簿屋さんが住所から名前をバルクで検索できるのは、いささか意味合いがアレではないだろうか。ま、この辺はプライバシーと情報公開の線引きをどう決めるか次第という問題であって、ウィスコンシンは州法で原則公開に倒してしまっており、引っ越した途端にドカドカとダイレクトメールがやってくるというのは要するにそれだからだろう。

で、このウェブサイトが Linux と U-Minnesota Mapserver で作ってあるというのだ。どことは言わないが売り物の GIS と比べてフレンドリーで云々、なるほど説得力のある話だ。しかし、悲しいかなウィネバーゴはマイノリティーで、どこを見回しても Arc 何チャラばかりとのこと。

●ESRIなど

それでもまあ ESRI のブースに行って ArcWeb サービスなんかの話を聞いてきたわけだ。実際にデータサービスをするにはどういうコストがかかるのか知りたいわけだけど、どう聞いていいのかよくわからないので、あまり突っ込んでは聞けなかった。

カーナビに気象情報

ホンダがやるらしい。

安い両替屋

あるよ、という話。ここが最善かどうかは知らんが慌てて都市銀行に行くよりよさそうだ。コインも買ってくれる。はてなQより。

NHK「朝のバロック」の主題は

バッハの Sheep May Safely Graze というらしい。ほんとかどうかよくわからない。

JMU SIC

Brynda told me that there is a cool description of OGC written by Spatial Information Clearinghouse for Humanitarian Mine Action of the James Madison University.

This SIC seems to be a kind of class like our IES400.

新データモデルのメモ

みなさんこんにちは。この忙しいのに、格子データなのに、NetCDF では気に食わないので新データモデルを設計するなんて大それたことをしているのである。さて、何が気に食わないといって、あまり本質的なところではないのだが、

・長い年月を経たり、多様な活動をしたりして生じる多数のデータセットをマネージする機構がまったくない。
・多変数のデータが同時に生成されることはよくあるが、別々に書き出ししなければならない API のため、それ以上の高速化ができない。

といったところなのだろうと思う。で、前者の問題は NuSDaS1 においてほぼ解決済み(整理するだけ)なので、後者が問題である。高速化というと情報系の人には軽蔑されそうであるが、こちとらそれで食っているのであるから勘弁してもらおう。

さて、答えからいうと、NC 的データセットに "data" という1個だけの変数をドカーンと置いて、element (GRIB 語でいうところの parameter) も次元にしてしまえばよい。軸変数も格子状メタデータも全部 "data" の横並びにすればスキっと解決。今まで data を特別扱いするようなことをウジウジ考えていたが、配列の入出力 API を2通り用意するのは馬鹿げている。

旧変数属性であるが、element 軸を有する配列にするほかなかろう。文字長が悩ましいが、許してもらおう。

さて、ようやく問題であるが、

・ある時あるルーチンで作成されたデータセット (NetCDF 的データセット)
・時を越えて上の狭義データセットを集めたもの (NuSDaS1 的データセット)

をどう区別した用語にするか。これが問題です。

OGC の提供する教育的コンテンツ

を探せといわれた訳である。ターゲットピーポーは郡役場の LIO。
そりゃないだろう。
あるわけがない。いやそんな消極的な考えを抱いてはいけない、と思いつつも、やっぱりみつからない。

強いて言えば誰が読んでもよさそうなのはVision & MissionHistoryくらいなもので、具体的に何をやってるのと問うといきなりOGC Process, OpenGIS Specifications なんてトップギアに入ってしまう。かすかな希望を抱いて Events をクリックしてみると、ISO/TC 122 Plenary の案内が....

えーと、どのくらい無茶かというと、インターネットってなに?と聞いた直後にいきなり RFC Publication ProcessRFC Index を見せるようなものである。読まされるほうにしたら無茶も大概にしてくれといいたくなるだろう。だから、中身も検討せずにこれが教育的マテリアルです、と安易にレポートすることはできない。んー困った。

が、しかし、話をそらすと、そもそも OGC のやっていることは RFC Publication Process みたいなものなのだから、広く一般に広報宣伝する必要があるのかどうだかよくわからない。今回のことは困ったが、全体としてみたら、まあいいや、なのかなあ。

流域の計算

GIS の考えでは、DEM (格子地形データ) があれば、流域(正確には、与えられた点の上流領域)なんてものはクリック一発で求まるのである。裏は取っていないがソコラのパッケージ GIS でもみんなできるだろう。

伝統的には、流域というのは何か行政界のように固定したブロックで、世界は何個かの流域に排他的に分解されるだと考えているけれど、まあそれは便宜上そうなっているわけで、たとえば水防のようなアプリケーションで言ったらそれだけではなくて、任意の点の関数として与えられる流域が知りたいこともあるわけである。

ま、それをダイナミックに知りたいかどうかはちょっと微妙かもしれないけれども、単に目から鱗が落ちたという話。

NASA が OpenDAP を採用へ

雑誌みたいな表題で恐縮だけれども、NASA (アメリカ航空宇宙局) の Earth Science
Enterprise が The Earth Science Data Systems Standards というのをやってい
て、RFC というの文書シリーズを作ってどっかのインターネットみたいな運用をして
いる。それで、OpenDAP を採用するというプロポーザルが出ているのであった。DODS
UG では「助けてやろうぜ運動」呼びかけ中。

http://spg.gsfc.nasa.gov/rfc/004/

ところで、これ、どういうブログツールだかしらないが、インストールしてそのまま
使っているので、日本人が見に行くと日本語で表示されて、すごく偽物くさい雰囲気
が漂っている。

関数電卓エミュレーション

パソコンが普及して以来関数電卓を持っていない。それどころか、平方根の計算できる電卓を最近入手した始末である。

そんな私でもちょっとした機会に三角関数を計算して見たいと思うことはあるわけで、強引にやってしまおうと思ったわけである。理科年表の巻末の多項式(連分数もありますけど)を試して見ると、けっこう精度がよかった。だいたい3項とれば、45度まで3桁の精度を出す。以下、±キーを持ち、除数で√が使える電卓での手順である。

sin θ [0 < θ < 1 程度まで 3 桁正確]

MC AC θ × = M+ ÷ 20 - 1 =± × MR ÷ 6 - 1 =± × MR √


cos θ [0 < θ < 0.95 程度まで 3 桁正確]

MC AC θ × = M+ ÷ 12 - 1 =± × MR ÷ 2 - 1 =±


tan θ [0 < θ < 0.75 程度まで 3 桁正確]

MC AC θ × = M+ ÷ 5 - 3 =± ÷ MR = ÷ = - 1 =± ÷ MR √ = ÷=


arctan y [0 < y < 0.9 程度まで 3 桁正確] (7日改訂)

MC AC y × = M+ ÷ 11 × 5 - 1 = ± × MR ÷ 5 × 3 - 1 = ± × MR ÷ 3 - 1 = ± × MR √ =


arcsin y [0 < y < 0.7 程度まで 3 桁正確] (7日追記)

MC AC y × = M+ + 1 = × MR ÷ 2.3 + 1 × MR ÷ 6 + 1 × MR √ =



arctan, arcsin は収束が悪いので係数をちょっとチューンしてある。しかしまあ、なんというか、これを暗記できるだろうか。しかも対数の計算には手も足も出ない。やっぱり関数電卓を買わないといけないのではないか。

眠いときに限って電話がたくさんか かってくる


今日は4回も電話がかかってきた。うち3回間違い電話。
1回は「おめでとうございます。?個の質問に答えていただくだけで????ドルを
さしあげます」
.... そんな怪しいお金要りません。

大統領選と関係するのか?

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。