色の知覚(1)太陽光

太陽光の分光強度分布 (National Renewable Energy Laboratory)

 色彩に関してはこれまで先人の膨大な研究の積み重ねがある.その一端を紹介し,色の物理的性質から生理的反応への橋渡しについて考察する.

 今回は太陽光について調べた.データベースは主に National Renewable Energy Laboratory から取った.日本国内にも太陽光についてのデータベースは気象庁新エネルギー・産業技術総合開発機構がデータを公開している.

“色の知覚(1)太陽光” の続きを読む

第 6 章 空間データをインポートする (Beginning Spatial with SQL Server 2008)

 多くの空間アプリケーションがカスタム定義の空間機能を組み合わせている.例えば顧客セットの局在と,広く受け入れられた表現の空間データ,地球上の汎用性のある特徴,例えば国や州の境界線,世界の主要都市の局在および主要な道路や鉄道の経路などである.この情報は自分自身で作成するよりも,多くの代替可能な資源が存在しており,そこから普通に使うための空間データを取得して空間アプリケーションに搭載できる.

 本章では,そこから一般公開された空間情報を取得できる資源,そこでそのデータが普通に提供されるフォーマットおよびその情報を SQL Server にインポートするのに使える技術を紹介しよう.

空間データの資源

 空間データ資源は豊富に存在し,教育機関や政府機関と同様,さまざまな商用データベンダーからも取得でき,無料で情報を利用可能である.Table 6-1 に空間データを無料でダウンロードできる少数のインターネット資源の詳細を示す.

Table 6-1. 無料でダウンロードできる空間情報資源
資源 詳細
http://www.census.gov/ 米国国勢調査局地理学部は高品質の空間情報を保有しており,それには地名辞典,郵便番号集計エリア (ZCTAs), TIGER 道路・河川・鉄道データベースおよび他の多くの地理的エンティティを包括している(合衆国限定).
http://geodata.grid.unep.ch/ 国連地理データポータルは地球,国家,地域および準地域統計および空間データを含み,それらをカバーするテーマ,つまり淡水,人口,森林,排出,気候,災害,健康および GDP としてカバーする.
http://biogeo.berkeley.edu/gadm/ グローバル行政区データベース (GADM) は国境線,州,国家および全世界をカバーするのと同等の 1 個の ZIP ファイルとして保有しており,バークレイのカリフォルニア大学が運営している.
http://earth-info.nga.mil/gns/html/ アメリカ国家地理空間情報局 (NGA) の GEOnet ネームサーバー (GNS) は全ての外国の地名の公的リポジトリであり,局在,行政区分および品質に関する情報を保有する.
http://geodata.gov/wps/portal/gos 合衆国政府『地理空間ワンストップ』地理データウェブページは分類されたリンクを保有し,様々な資源は生態学,地質学,健康,交通手段および人口統計に関して地域をカバーする.

 第 4 章で示したように,SQL Server 2008 の静的空間メソッドはそれぞれ,WKT 表現からでも WKB 表現からでも GML 表現からでも同時に一つの空間データのアイテムを生成できるだけである.しかし,Table 6-1 に列挙したような空間データ資源はさまざまな他の種類の空間フォーマットを蓄積している可能性があり,何千もの一個一個のアイテムを一つのドキュメントに記述している可能性がある.ゆえに,静的メソッドを使用していては,それらの資源から直接 geography データや geometry データを生成することはできない.

 本章の残りで,利用可能ないくつかの一般的な空間データの代替フォーマットについて議論し,このデータを SQL Server 2008 にインポートするのに使える技術を説明する.

表形式の空間データをインポートする

 間違いなく空間データではないが,もっとも豊富な(そしてもっとも簡素な)無料で利用可能で一般に場所の名前から取得される地理情報の資源とは,各場所の位置を記述した一組の緯度と経度座標である.これらの資源は関連する他の情報,つまり人口や経済指数の列を保有している可能性もある.このフォーマットで表現された情報は一般に「地名辞典」として知られており,測地情報の辞書である.

 仮に地理時点のような緯度と経度(または投影座標系からの北座標と東座標)を含むデータの構造化テーブルから空間情報をインポートしたいなら,一つの静的メソッドを使って geography 型か geometry 型の Point オブジェクトを生成でき,それはデータの各アイテムを表現した座標値に基づいている.これには次のステップが関与している.

  1. SQL Server 2008 の提供するバルクインポートメソッドの一つを使って構造化データを新規テーブルにインポートする.つまり,OPENROWSET および BULK INSERT T-SQL ステートメント,BCP ユーティリティあるいはインポート・エクスポートウィザードである.
  2. ALTER TABLE ステートメントを使ってテーブルに新しい geography 型または geometry 型の列を追加し,由来する空間データを保持する.
  3. T-SQL の UPDATE ステートメントを静的メソッドと共に使って新しい列に投入する.それはインポートされたデータ内の列の座標値に基づいている.

 このアプローチを説明するため,アメリカ地質調査所 (USGS) の提供する地震データのファイルを使って例を示したい.USGS は無料で利用可能なデータベースを数多く作成しており,ウェブサイト http://www.usgs.gov からダウンロードできる.その一つに直近 7 日間のリアルタイムで世界規模の地震のリストがあり,http://earthquake.usgs.gov/eqcenter/catalogs/eqs7day-M1.txt のリンクから直接ダウンロードできる.このファイルはコンマ区切りのデータリストであり,各地震のさまざまな属性を列フォーマットで保有しており,内容は Table 6-2 に列挙して記述してある.

Table 6-2. eqs7day-M1.txt ファイルのデータ列
詳細
Src データに貢献するネットワーク資源の識別子,2文字
Eqid この地震の一意の識別子
Version バージョン番号
Datetime 記録の発生した日の文字列
Lat 震源地の緯度,EPSG:4326 空間参照系で記述
Lon 震源地の経度,EPSG:4326 空間参照系で記述
Magnitude 地震のマグニチュード,各観測所で計測した地震波で決定される
Depth 震源地の深さ,キロメートルで測定
NST 報告した観測所の数
Region 地震の発生した地域を記述した文字列

 このデータを取得するには次のステップに従う.

  1. ウェブブラウザを開き,アドレスバーに次のように URL をタイプする:http://earthquake.usgs.gov/eqcenter/catalogs/eqs7day-M1.txt. Figure 6-1 に例示すようにブラウザは最新のコンテンツを表示する.
  2. このファイルをアクセスできる場所に保存する.「ファイル」メニューから「保存」(または「ページを保存」.ブラウザの種類による).名前と場所を促される.この例ではファイル名を eqs7day-M1.txt, 保存場所を C:\Spatial フォルダーと想定している.

注記 eqs7day-M1.txt ファイルは直近の 7 日間のデータで常にアップデートされているため,実際の内容は本章で説明したものとは異なる.

テキストファイルをインポートする

 SQL Server 2008 にデータをインポートする方法は数多く存在する.この例ではインポート・エクスポートウィザードを使い,データを資源から目標に向かって移動し,簡潔なパッケージを一つずつ生成してもらうことにする.そのステップは次の通りである.

  1. SQL Server Management Studio のオブジェクトエクスプローラーペインからデータをインポートしたいデータベース名を右クリックして「タスク」を選択し「データをインポート」と進む.
  2. インポート・エクスポートウィザードが開く.「次へ」をクリック.
  3. ウィザードの最初のページはデータソースを選択するよう促してくる.スクリーン最上部にある「データソース」ドロップダウンリストから Flat File Source を選択する.
  4. ブラウズボタンをクリックして先に保存しておいた eqs7day-M1.txt テキストファイルへとナビゲートする.Open をクリックする.
  5. デフォルトでは接続のための Text Qualifier フィールドは none にセットされている.eqs-7day-M1.tst テキストファイル内部の文字列はダブルクオーテーションで囲まれており,この値をダブルクオート文字 (“) に変更する.
  6. eqs-7day-M1.txt テキストファイルにはヘッダー行が含まれているため,最初のデータ行を列名にするにチェックを入れる.
  7. ペイン左側の詳細オプションをクリックする.各列を順番にクリックし,右側の属性ペインから,データ型の値を修正し,値に適合するように OutputColumnWidth フィールドを修正する.Table 6-3 に示す.
  8. 適切な変更を加えたなら,次へのボタンをクリックする.ウィザードは目標を選択するように促してくる.
  9. SQL Server 2008 インスタンスとデータベースの詳細を入力し,次へをクリックする.
  10. ウィザードはソースとなるテーブルとビューを選択するよう促してくる.デフォルトではウィザードは自動的に目標テーブルを新規作成し,その名前は eqs7day-M1 となるため,次へをクリックする.
  11. パッケージを保存して実行するスクリーンで,完了をクリックする(仮に SQL Server 2008 Express, Web あるいは Workgroup Edition を使っているなら,このスクリーンはパッケージを実行するとなっている).パッケージの要約が出現し,詳細を確認するよう促される.
  12. 完了をクリックしてパッケージを実行する.

注記 SQL Server 2008 Express, Web または Workgroup Edition ではインポート・エクスポートウィザードを使って即座に実行するだけのパッケージを作成できる.ウィザードによりパッケージを保存するには,SQL Server Standard, Developer あるいは Enterprise Edition を使わなければならない.

Table 6-3. USGS 地震テキストファイル接続のための列の属性
名前 データ型 OutputColumnWidth
Src string [DT_STR] 2
Eqid string [DT_STR] 8
Version string [DT_STR] 1
Datetime string [DT_STR] 50
Lat double-precision float [DT_R8]  
Lon double-precision float [DT_R8]  
Magnitude float [DT_R8]  
Depth float [DT_R4]  
NST two-byte signed integer [DT_I2]  
Region string [DT_STR]  

 実行が成功し,テキストファイルから目標のテーブルにインポートされた行数が記述されているのを知らせるメッセージを受け取るだろう.では,閉じるをクリックしてウィザードを閉じよう.

 我々の新しいテーブルの中身を見てみよう.新しいクエリウィンドウを開き,次のコマンドを発行する.

 テキストファイルから挿入されたデータを Figure 6-2 に示すように見ることができる.

地理型の列を加える

 各地震の位置は現在その eqs7day-M1 テーブルに記述されており,経度と緯度の座標値は Lat 列と Lon 列を使って蓄積されている.SQL Server により提供されるいかなる空間メソッドを使うためにも,geography 型や geometry 型を使う代わりに,これらの座標を使って各地震の表現を生成する必要がある.Lat および Lon 列が正確な位置を記述した地理座標を含んでいるため,geography 型を使って表現された各地震を表現する Point オブジェクトを生成することにする.テーブルに Location という名の geography 型の新しい列を追加するため,次の T-SQL クエリを実行する.

空間データを移入する

 eqs7day-M1 テーブルに新しい geography 型の列を追加したところで,今度はそこに各地震を表現する Point geometries を移入する必要がある.geography 型の Point() メソッド,これはそれの基づく SRID 4326 と共に Lat および Lon 列の内部に含まれる値を提供するが,を使ってこれを行うことができる.次に,SQL の UPDATE ステートメントを使ったこのメソッドの結果としての Location 列の値をセットしよう.Location 列に移入するために,次のコードを実行する.

 ここに示すように,影響した多くの行の数を受け取るだろう.影響される行数はダウンロードしたデータセット内の地震の数による.

 Location 列の内容を調べるため,今度は次のクエリを走らせよう.

 結果は以下の通りである.

 Point() メソッドを使って,Location 列に地球表面上の各地震の震源地の緯度と経度を表現する Point geometries を移入することができた.しかし,地震の起源の地点(爆心地)は通常地球内部の地下数十から数百マイルの深いところにある.eqs7day-M1 データセット内では,震源地の深度はキロメートルで表現され,Depth 列に記録されている.代わりに各地震の震源地の位置の表現を可能にするためには,Location 列内で Point それぞれを定義し,Depth 列の座標値に基づき Location 列に追加の z 座標を付加する必要がある.このために Point() メソッドを使うことはできないが,それは二つの座標値しか取らないためであり,WKT 構文に基づく静的メソッドを使うことができ,それは z 座標をサポートしている.

 次のコードが示すのは,代わりに STPointFromText() メソッドを使って Location 列を更新する方法であり,各地震の緯度,経度および深度に基づく一個の Point の WKT 表現を生成することによる.Depth 列が地球表面から下の距離を表現するため,各 Point の z 座標は Depth 列の負の値に基づいてセットされる.

 今度は eqs7day-M1 テーブルに含まれる各地震の震源地を表現する Point を含んだデータを選択しよう.次の通りである.

 結果は次の通りである.

チップス 一度 Location 列に各地震の Point 表現を移入したら,元の緯度,経度および深度の列は削除して構わない.仮にでも元の座標値の取得が必要になったら,Lat, Lon および Z 属性を使うことができる(詳細は第 11 章で解説する).

Keyhole Markup Language から空間データをインポートする

 KML は Keyhole 社により独自に開発された GML ベースの言語であり,EarthViewer アプリケーション内で使われる.2004 年に Google が EarthViewer と共に Keyhole を買収し,今では有名になった Google Earth プラットフォーム (http://earth.google.com) を開発するための基盤として Google が使っている.KML フォーマットはそれ以来何度かの改訂を経ている(執筆時点での最新バージョンは KML 2.2)が,Google Earth で使われる空間情報を蓄積するネイティブフォーマットであり続けている.2008 年,KML は Open Geospatial Consortium に空間情報標準フォーマットとして採用され,今や最新の KML 仕様の実装は OGC ウェブサイトで見ることができる.アドレスは以下の通り. http://www.opengeospatial.org/standards/kml/

 KML が Google Earth コミュニティ内部で使われユーザーの作成した空間データをシェアしている一方,より広いインターネットコミュニティの間では Google Earth プラットフォームの人気と快適さは,KML はますます教育と研究目的で使われるようになってきていることを意味しており,それは救急や災害時のサービスのような重要なアプリケーションにおいても同様である.OGC による標準採用とも相まって,KML は空間データの互換性にとって,ますます重要なフォーマットになりつつある.

KML を GML と比較する

 GML のように,KML ファイルは空間機能,つまり Points, Paths (LineString と同等のもの)および Polygons を記述するため異なる種類の地理インスタンスを保有する可能性がある.しかし,GML フォーマットが(WKT および WKB のように)純粋に地理的特徴の形態と位置を記述する目的で使われる一方で,KML ファイルはそれらの特徴がスタイルを整えられ,グラフィカルなディスプレイで表現される方法を付加的に指定する.

 KML ドキュメントフォーマットを説明するため,http://code.google.com/apis/kml/documentation/kml_tut.html で利用可能なサンプルコードから取得した Path の KML 表現を Listing 6-1 に示す.

 この KML 表現は,問題にしている LineString の純粋な地理属性を記述するのに必要とされるよりも,多くの情報を含んでいることに注意されたい.多くの異なるスタイルおよび記述要素が存在する.仮にこの同じ機能を GML フォーマットを使って記述しようとすると,そこには形態に関する要素しか含まれていないため,Listing 6-2 に示すようなコードを要求するしかない.

KML を GML に変換する

 高度に構造化された XML の性質の利点の一つは,明示的な変換を指定して XML の一つの方言から別の方言に変換することが比較的たやすいことである.生成して必要な変換を適用することにより,(Listing 6-1 に示したように) KML から(Listing 6-2 に示したように) GML に変換することは可能であり,geography 型および geometry 型の GeomFromGml() メソッドを使ってそれを SQL Server に課すことができる.KML から GML に変換するためには,次の変換が起きなければならない.

  1. 純粋にスタイルや記述的な属性を記述する KML 要素を削除する.それらは GML ファイルには全く関係がない.これらの要素とは <LookAt>, <visibility>, <styleUrl>, <Style> および <name> である.
  2. 地理的属性に関連するそれらの要素の内容を取得し,それらを同等の GML 要素で置換する.Table 6-4 に示す.
  3. <coordinates> 要素の内容を操作し,それには KML geometry における各 point の座標が含まれるが,同等の GML の <postList> や <pos> 要素の適切なフォーマットにする.
    1. 各座標値のタプル間に使われるセパレーターのコンマをスペースに置換する.
    2. 仮に KML <coordinates> 要素内部の座標値が高度 (z) 座標で記述されているなら,この値は無視する.
    3. 二つの残りの座標の順を逆転させ,緯度-経度の順に記述する.
Table 6-4. 地理 KML 要素および相当する GML
KML GML 詳細
<GeometryCoolection> <GeometryCollection> Geometry Collection 要素を示す
<Polygon> <Polygon> Polygon geometry を示す
<LineString> <LineString> LineString geometry を示す
<Point> <Point> Point geometry を示す
<outerBoundaryIs> <exterior> Polygon の外部境界を示す
<innerBoundaryIs> <interior> Polygon の内部境界を示す
<coordinates>a <pos><posList> geometry の座標リストを含む要素

a GML においては,<pos> 要素は <posList> 要素とは明確に区別される.<pos> 要素は(1 点の Point geometry を定義するのに使われるように)単一の座標タプルを保有し,<posList> 要素は(LineString や Polygon におけるように)複数の座標タプルを保有する.

付記 KML において全ての multielement geometry はGeometry Collection として表現される.MultiPoint, MultiLineString または MultiPolygon geometry と同等である特異的な同種の要素は存在しない.

付記 GML 標準の初期バージョンには <coordinates> 要素が含まれ,それは KML で使われるものと酷似している.しかし,これは GML バージョン 3.1.0 で非推奨となり,SQL Server 2008 では提供されない.その代わり,必ず <posList> 要素または <pos> 要素を使わなければならない.

 Listing 6-1 に示した KML ドキュメントから,Listing 6-2 に示した同等の GML 表現に変換するのに必要な変化を起こすために使いたいなら,いくつかの方法が存在する.例えば,XQuery を使うこともできるし,あるいは,Extensible Stylesheet Language Transformation (XSLT) を使うこともできる.XQuery および XSLT は共に World Wide Web Consortium (W3C) により管理される承認された標準である.それらが変換し XML データを問い合わせるのに使われる方法のさらなる情報は,W3C ウェブページのそれぞれ http://www.w3.org/TR/xslt.html および http://www.w3.org/TR/xquery/ を参照されたい.しかし,二つの XML フォーマット間の簡単な変換を実行するだけのいかなる方法も,次に述べる制約に苦しむことになるかも知れない.

  • オリジナルの KML ファイルに含まれる何か記述的・スタイリング要素を失うかも知れない.そこには GML では表現できない,各 geometry インスタンスについての有用な付加情報が含まれている可能性がある.
  • ソースドキュメントに対して実行する検証やエラーチェックが存在せず,有効な geometry を生成するかどうかチェックできない.例えば,変換された GML 表現から geography 型の Polygon インスタンスを生成するためには,空間の領域を保有するそれらのリングのポイントは反時計回りの順で列挙しなければならないが,それはオリジナルの KML <coordinates> 要素内で列挙されているのとは違うかも知れない.

 仮にもっと堅牢な方法を使って KML データを SQL Server 2008 にインポートしたいなら,この目的に特化したサードパーティ製のツールが利用できる範囲を調査したくなるだろう.本章の最後にそのいくつかを列挙する.

付記 KML および GML は単なる XML ベースの空間データフォーマットではない.例えば,GPS Exchange Format (GPX) は多くの携帯型 GPS デバイス間でデータをシェアし蓄積するのに使われる XML フォーマットである.

ESRI shapefile format からデータをインポートする

 shapefile フォーマットは Environmental Systems Research Institute 社 (ESRI) により設計され維持されている.最初に開発されたのは GIS のスイート ARC/INFO の用途のためであり,shapefile は今や,あらゆる種類のシステム間で空間情報を変換するのに使う非常に一般的なフォーマットとなっており,ほとんどの商用空間データに提供されるフォーマットである.時間とともに,巨大な空間データセットが ESRI shapefile フォーマットで作成されるようになってきた.

 shapefile フォーマットで提供されるデータセットは一般に “a shapefile” (単数形)と呼ばれるにも関わらず,これは少し誤称である.というのは,単一の shapefile は実際にいくつかのファイルを保有しているからである.与えられた shapefile データセットに関連する各ファイルは同じファイル名を持ち,それにファイルの拡張子が続く.

  • .shp: SHP ファイルは生の幾何学的形態データである.各 SHP ファイルはただ一種類の geometry 形態を保有することができる.Points, LineStrings あるいは Polygon である.
  • .shx: SHX ファイルは shapefile のインデックスを維持し,shapefile ドキュメント内のすべての形態のインデックス登録を一つ保持する.各インデックス登録は SHP ファイル内に記録された関連する形態の始点と長さとを記述する.
  • .dbf: DBF ファイルは各形態の付加的な,非空間属性を保有する.例えば,アメリカの州を表現した Polygons を含む shapefile 内で,DBF ファイルは各州の名前,その人口,あるいはその州都を保有している可能性がある.
  • .prj: PRJ ファイルは,表現された地理データの座標における投影法についての詳細を保有し,同じフォーマットが sys.spatial_reference_systems テーブルの well_known_text 列で使われている.SQL Server に shapefile をインポートする時には,このファイルは正確な空間参照識別子 (SRID) を定義するのに必要とされる情報を保有している.

付記 shapefile フォーマットではいかなる検証ドキュメントも SHP ファイルおよび関連する SHX ファイルを保有していなければならない..dbf および .prj 拡張子を有するファイルは任意であり,そのデータに関する付加的な情報を保有する.

サンプル Shapefile データを取得する

 shapefile フォーマットから SQL server にデータをインポートする方法を説明するため, カリフォルニア州の 郵便番号エリア集計 (ZCTAs) を表現する米国国勢調査局からのデータを使おう.ZCTAs は米国国勢調査局の 2000 年の調査により定義され,米国郵政公社で使われる 5 桁の数字の郵便番号のための配送エリアにほぼ相当する.ZCTA の地域の ESRI shapefile は,カリフォルニア州のものなら直接米国国勢調査局のウェブサイトからダウンロードできる.URL は http://www.census.gov/geo/cob/bdy/zt/zt06_d00_shp.zip. である.

 この ZIP ファイルをダウンロードして内容を解凍する.次のファイルが含まれている.

  • zt06_d00.shp
  • zt06_d00.shx
  • zt06_d00.dbf

 SHP ファイルはこれらのうちで最大サイズであり (4,560 KB), 各 ZCTA を表現する Polygon の形態を定義する生データを保有している.SHX ファイルはインデックスファイルであり,shapefile 内の各形態の始点と長さを記録している.純粋に空間情報を表現している各 ZCTA を保有しているこれら二つのファイルに加えて,DBF ファイルは関連する付加的なデータの列を保有し,それは Table 6-5 に列挙して記述してある.

Table 6-5. zt06_d00.dbf ファイル内のデータの列
記述
Area 各 ZCTA の内部の面積,平方キロメートル
Perimeter 各 ZCTA の外周長,キロメートル
ZT06 D00 自動的に生成した連続する形態の番号
ZT06 D00 ID ユーザー定義の形態の番号
ZCTA ZCTA の参照する 5 桁の番号
NAME ZCTA に同じ
LSAD 法的/統計的地域の記述コード.2文字の領域で法的あるいは統計的地域の種類のエンティティに対応.5 桁の ZCTA コードのため,通常は Z5 とする.
LSAD_TRANS 各形態の LSAD に関する記述.ZCTAs の場合は ‘5-Digit ZCTA’ となる.

チップス zt06_d00.dbf に含まれるさらなるデータについては http://vcgi.org/metadata/BoundaryOther_ZCTA2000.txt に相談されたい.

 ZCTA shapefile に関連する PRJ ファイルが全く含まれていないことに注意されたい.ならば,どうやって座標を定義するために使われる空間参照系を知ることができるのだろう?米国国勢調査局ウェブサイトをさらに検索すると,メタデータのページが見つかった.それは http://www.census.gov/geo/www/cob/zt_metadata.html にあった.このページは ZCTA データが NAD 83 基準点に基づく地理座標系を使って定義されていることを記述している.いかなる空間参照系の WKT 表現でも,使用される座標の種類の表現のキーワードで開始しなければならないことを我々は知っている.ZCTA データにおいて使われる地理座標系では,これは GEOGCS である.我々はまた,空間参照系の WKT 表現が,それに基づく基準点の名前,ここでは NAD83 だが,それを記述しなければならないことも知っている.この情報から,我々はこの空間参照系のための適切な識別子を sys.spatial_reference_systems テーブル内で検索することができる.次のクエリを使う.

 一行の結果が返ってくる.

 さて,この shapefile に含まれるデータをインポートするにあたっては SRID 4269 を使うべきである.この空間参照系は地理座標に基づいているため,空間データを蓄積するためには geography 型を選択しよう.この情報を基に,今やデータを shapefile から SQL server にインポートする準備が整った.

Shapefile データを Shape2SQL を使ってインポートする

 Shap2SQL は人気の,簡単なアプリケーションであり,shapefile データを SQL Server 2008 に搭載することに特化して設計された.SQL Spatial Tools パッケージの一部としてダウンロード可能であり,無料で利用可能である.次の URL からダウンロードできる.http://www.sharpgis.net/page/SQL-Server-2008-Spatial-Tools.aspx

 SqlSpatialTools zip アーカイブを ダウンロードして解凍したら,Shape2Sql.exe ファイルをダブルクリックしてアプリケーションを搭載する.最初に Shape2SQL を実行した時には Figure 6-3 に示すようにデータベース接続の詳細を入力するよう促される.

 Database Configuration ダイアログボックスでは,shapefile をインポートしたい SQL Server 2008 インスタンス名を入力し,サーバーに接続するのに必要な認証のいずれかを入力する.次に適切なデータベースをドロップダウンリストから選択し,OK をクリックする.

 データベースの構成が完了したら,Shape2SQL アプリケーションのメインウィンドウが表れる.Figure 6-4 にShape2SQL アプリケーションを示し,先に保存したカリフォルニア州 ZCTA データをインポートするのに必要な設定を示してある.

 カリフォルニア州 ZCTA データをインポートするのに適切なオプションを設定するために次のステップに従う.

注意 shapefile を Shape2SQL を使ってインポートするためには,SHP ファイルと SHX ファイルは必ず同じ場所に保存されていなければならない.仮に関連する DBF ファイルが同じ場所に保存されていると,各形態に関連する付加的な,非空間属性を DBF ファイルから SQL Server テーブルの列にインポートすることが可能となる.

注意 仮にでも shapefile が .prj 拡張子のあるファイルを保有するなら,必ず対応する SRID を手動で指定し,PRJ ファイル内に含まれる詳細を適合させなければならない.Shape2SQL は対応する SRID を自動では設定してくれない.

付記 付加的なデータ列は関連する DBF ファイルに含まれるデータに基づいている.仮に DBF ファイルが存在しないなら,各シェイプに関連する付加情報をインポートすることはできない.

  1. スクリーン右上のコーナーにある…ボタンをクリックし,shapefile を選択する.保存しておいた zt06_d00.shp ファイルの位置を探してハイライトし,Open をクリックする.アプリケーションは shapefile 内で見つかった形態の数と種類を表示する.zt06_d00.shp ファイルはこの場合,2490 個の Polygon 形態を保有していた.
  2. Database Properties セクションでは Server フィールドをチェックして適切なサーバーとどのデータベースにデータを挿入するかを指定する.仮に詳細を変更する必要があるなら,Configure ボタンをクリックして Database Configuration ダイアログボックスを開く.
  3. Geometry Properties セクションはアプリケーションウィンドウの左下にあり,次のオプションを使ってデータを SQL Server にインポートする方法を指定する.
    • Replace existing table: このオプションをチェックすると,仮に指定した名前のテーブルが既に存在する場合,それは削除され,インポートされた形態データを含む新しいテーブルに置換される.チェックしないなら,代わりにデータは既に存在するテーブルに追加される.仮に指定した名前のテーブルが存在しないなら,このオプションの有無に関係なく新しいテーブルが作成される.
    • Planar Geometry/Geography (Spheric): 挿入するデータがインポートされる列のデータ型を定義するオプションをここから選択する.Planar Geometry 型を選択すると geometry 型が使われることになり,Geography (Spheric) を選択すると geography 型を選択することになる.カリフォルニア州 ZCTA データは地理座標を使って定義されており, Geography (Spheric) を選択する.
    • Set SRID: 形態のどの座標が定義されるかの空間参照系を識別する整数値の入力は必須である.仮に shapefile が .prj 拡張子を持つファイルに関連して由来するなら,ソオンファイル内に含まれる詳細に対応する SRID を選択すべきである.仮に PRJ ファイルが存在しないなら,代わりに該当ファイルに関連する他のメタデータを検査するか,あるいはデータの提供者に接触するかして,適切な空間参照系を必ず見つけ出さなければならない.このオプションはすでに定義された座標が存在する空間参照を識別することを特記しておく.それは,そこにデータを投影したい空間参照系を識別するものではない.カリフォルニア州 ZCTA に関しては,SRID には 4269 と入力する.
    • Create Spatial Index: このオプションがチェックされると,Shape2SQL は自動でデータの挿入されるテーブルに空間インデックスを生成する.空間インデックスは特定の空間クエリの速度を改善し,これの詳細については第 14 章で議論する.
    • Table Name: この値はデータのインポートされるテーブル名を定義する.仮にテーブルが既に存在しており,Replace Existing Table オプションがチェックされていない場合,このテーブルのスキーマは shapefile からインポートされるデータ列に必ず適合しなければならない.デフォルトのテーブル名はソースの shapefile のファイル名と同じであり,ここでは zt06_d00 となる.
  4. Attribute セクションはウィンドウ右下にあり,次のオプションを使ってデータのどの列をインポートするかを指定する.
    • Geometry Name: このフィールドはインポートされた空間データを保持する geometry 列または geography 列の名前を定義する.デフォルトの列名は geom である.地理座標に基づくデータをインポートしようとしているため,ここは geog に変更する.
    • ID Column Name: テーブル内の各行に一意の ID を導入したいなら,ここにその列名を入力すべきである.この値は生成されたテーブル内に IDENTIFY(1, 1) の整数列を生成し,その列に基づいた主キーを作成する.仮に ID 列を作成したくないなら,この値は空のままにしておく.
    • Optional attributes box: Attribute セクションの最後のボックスでは,オプションの付加的なデータ列に,shapefile 内に関連する各形態をインポートするか否かを選択することができる.インポートしたい各属性のチェックボックスをクリックする.各属性は SQL Server テーブル内のそれ自身の列に対応する.
  5. 選択したオプションを満たしたら,Upload to Database ボタンをクリックする.

 Shape2SQL アプリケーションがインポートを完了したら,次のクエリを SQL Server Management Studio で実行してデータをテストできるようになる.

 結果は次の通り.

サードパーティ製の変換ツールを使う

 本章で議論してきた技術は,さまざまな簡素な手法であり,SQL Server 2008 にさまざまなフォーマットの空間データをインポートすることができる.しかし仮に,既存の巨大なフォーマットの空間データをインポートするつもりなら,この目的のために設計された専用アプリケーションを使う,もっとふさわしい方法が存在することに気がつくだろう.空間データを SQL Server 2008 が使えるフォーマットの一つに変換するのを促進するのに利用可能なツールは数多く存在する.これらのツールのいくつかは無料で利用可能である一方で,他のツールは Microsoft の空間パートナーによって開発された商用ツールである.このセクションでは有用と思われるツールのいくつかを紹介する.

商用ツール

 SQL Server 2008 をサポートする商用ツールの多くは空間データの完全抽出,変換,搭載 (ETL) プロセスを提供しており,多くの異なる空間データ型の間での変換を可能とする.ファイルフォーマット自体の単純な変換に加えて,これらのツールはまたファイル内に保有するデータの再投影をも提供しており,データの視覚化と解析も同様である.いくつかの商用ツールを次に示す.

  • ArcGIS (バージョン 9.3 およびそれ以上)は,長期確立した業界標準の ESRI (http://www.esri.com) からの GIS プラットフォームで,SQL Server 2008 と共に発展して空間データの操作,解析およびプレゼンテーションのすべての側面をサポートする多くのツールを提供してきた.
  • Manifold (http://manifold.net) もまた SQL Server 2008 に直接接続して数百の空間データフォーマット,再投影および空間データの視覚編集間の変換とインポートを提供する.
  • Feature Manipulation Engine (FME) は Safe Software (http://www.safe.com) の設計で,広範囲のフォーマット間の空間データの変換を促進するが,それもまた基本的な視覚化ツールに含まれる.スタンドアロンのデスクトップアプリケーションに加えて,FME は SQL Server Integration Services (SSIS) を拡張し,既に存在する SSIS プロジェクトの一部として複雑な空間 ETL を実行することもできる.

無料ツール

 仮に二つのフォーマット間での単純な変換しか必要としないなら,代わりに次に示すソースの内の一つを調べたくなるに違いない.

  • FWTools (http://fwtools.org) は様々な有用なオープンソースの GIS コンポーネントを含むパッケージであり,OGR ライブラリおよび空間データ間の変換のためのコマンドラインツールも含まれる.
  • Spatial Order (http://spatialorder.com/downloads.htm) は多くのコマンドライン変換ツールを無料で提供するコンサルタントファームであり,そこには ESRI shapefile フォーマットから GML へのツール (shp2gml) や ESRI フォーマットから WKT へのツール (shp2wkt) も含まれる.
  • Zonum Solutions (http://www.zonum.com) は ESRI shapefile フォーマットと Google Earth KML ファイル間の変換ユーティリティを提供し,座標系と基準点の範囲の間の変換能力も含まれる.

要約

 本章では,そこで空間データが提供されている様々なデータフォーマットについて,またそれらのデータを SQL Server 2008 にインポートする方法について習得した.特に,本章では次の点についてカバーした.

  • 多くの代替可能なファイルフォーマットが存在しており,空間情報はそこで普通に提供されており,表形式の地理情報や ESRI shapefile および Google Earth でも使用される KML ファイルフォーマットを含む.
  • 多くの資源があり,そこから自由に利用できる空間データをインターネット経由で取得可能である.その資源から取得したデータは品質とカバー率は様々な範囲にある.空間データをダウンロードして重要なアプリケーションに使いたいなら,まずそのデータの精度に注意すべきである!
  • 表形式で提供される簡単な空間情報は,インポート・エクスポートウィザードを使ってインポートできる.T-SQL の UPDATE ステートメントと同時に geography 型の Point() 静的メソッドを使い,テーブル内の各行の座標値から geography 型または geometry 型の列を移入する.
  • z 座標を含む表形式の情報から空間データのアイテムを構築するには,各座標値に基づく geometry の WKT 表現を手動で構築できる.次にその表現を STPointFromText() のような関連する WKT メソッドに通す.
  • KML は GML 同様 XML ベースの空間データフォーマットである.二つのフォーマット間にはいくつかの類似性があるが,重要な違いもある.SQL Server を使って KML から GML に変換するためには,各 KML 要素を該当する GML 要素に変換しなければならない.
  • Shape2SQL は無料のツールであり,ESRI shapefile フォーマットから SQL Server にインポートするために設計されている.
  • 他にも,SQL Server に互換性のある空間データを変換したりインポートするための多くのツールがある.

第 2 章 SQL Server 2008 で空間データを実装する (Beginning Spatial with SQL Server 2008)

 前章では,空間参照系の背後にある理論を紹介し,異なる種類のシステムが地球上の特徴を記述する方法を説明した.本章では,これらのシステムを適用して SQL Server 2008 における新しい空間データ型を使って空間情報を蓄積する方法を学んでもらう.

データ型を理解する

 SQL Server テーブル内のあらゆる変数,パラメータおよび列は特定のデータ型であるとして定義される.このことは SQL Server がどんな種類のデータ値をフィールドに蓄積されるか,いかにして使われるかを示している.いくつかの一般的に使われるデータ型を Table 2-1 に列挙・記述している.

Table 2-1. 一般的ないくつかの SQL Server データ型
データ型 使用法
char 固定長文字列
datetime 日付と時刻の値,精度は 3.33 ミリ秒
float 浮動小数の数値型
int  -231 から 231-1 までの範囲の整数
money 財務型,通貨型
nvarchar 可変長,ユニコード文字列

 SQL Server 2008 は特に空間データ型を保持する意図で2つの新しいデータ型を導入した.geography 型と geometry 型である.Table 2-2 参照.

Table 2-2. SQL Server 2008 での空間データ型
データ型 使用法
geography 測地ベクトル空間データ
geometry 平面ベクトル空間データ

 両者のデータ型は共に空間データを蓄積するが,互いに明確に区別され,異なる方法で使われる.SQL Server 2008 において空間データのアイテムを定義する時はいつでも,使う情報が geometry 型なのか geography 型なのかを蓄積するのに選択しなくてはならない.

注記 geometry という単語は本書においては2つの異なる意味を持つ.混乱を避けるために geometry (テキストフォーマットなし)の語句は地球上の特徴である Point, LineString および Polygon を指すことにする.geometry 型と言う場合は geometry データ型を指すことにする.本書ではこれ以降,この慣習を使うことにする.

空間データ型を比較する

 2つの空間データ型にはいくつかの類似点がある.

  • いずれも geometry の範囲内で空間情報を表現する.Points, LineStrings および Polygons である.
  • 内部的には,両データ型共に空間データを同じ形式のバイナリーデータストリームとして蓄積する.
  • どちらのデータ型からデータのアイテムを使う時でも,.NET フレームワークに基づくオブジェクト指向メソッドを使わなければならない.これの詳細については次章で述べる.
  • 両者とも同じ標準の空間メソッドを数多く実装しており,その種類のデータの計算の解析および実行を行うことができる.

 しかし,2つの空間データ型の間には多くの重要な違いも存在し,Table 2-3 に概要を示してある.データベース内のデータを使うために計画する方法に応じて,適切なデータ型を選択しなければならない.

Table 2-3. geometry 型と geography 型の比較
プロパティ geometry 型 geography 型
地球上での形態 平坦 丸い
座標系 投影(または平面) 地理的
座標値 デカルト (x, y) 緯度と経度
計測単位 座標系と同じ sys.spatial_reference_system で定義
空間参照識別 非強制 強制
SRID 初期設定 0 4326 (WGS 84)
大きさの制限 なし 半球以上のオブジェクトは生成不能
リングの方向 重要でない 重要

 これらの違いの特徴は,2つのデータ型の詳細を読むと,より明確になる.

Geography データ型

 geography 型の最も重要な特徴は,測地空間データを蓄積するということである.これは地球が曲面の形態をしていることを考慮している.geography 型を使って空間データを操作する時には SQL Server は結果を出力する際に角度演算を行っている.これらの演算は,問題となる空間参照系で定義される地球の楕円体モデルに基づいて計算される.例えば,仮に geography 型の地球の表面上の2つの地点を結ぶ直線を定義しようとする場合,その直線は参照楕円体に沿った曲線となるだろう.geography 型では,あらゆる2地点間の直線はすべて(その直線が LineString のセグメントであれ,Polygon リングの辺縁であれ)実際には大楕円弧となる.つまり,地球表面上の直線は参照楕円体の頂点および中心の両者を含む平面から形成される.これを図示したのが Figure 2-1 である.

座標系

 geography 型は,世界の三次元の球体モデルに基づいており,このデータ型を使って geometry を定義した地点の各々の位置を指定するには地理座標系を使わなければならない.地理座標系を使う時にはこれらの地点の座標は経度と緯度の角度で表現されることを銘記されたい.

計測単位

 geography 型が経度と緯度の角度計測を使って地点を定義するために,座標値は通常,角度で測定される.これらの角度座標は地点の位置を表現するのに有用であるが,地点間の距離やいくつかの地点で囲まれた面積を計測するにはあまり役に立たない.例えば,空間参照系 EPSG:4326 を使ってフランスのパリの位置を 48.87°N, 2.33°E と記述することはできる.同じ参照系を使ってドイツのベルリンの位置を 52.52°N, 13.4°E と記述することもできる.しかし,パリとベルリン間の距離を知りたい場合に,角度で答えを記述して 11.65° 離れていると言われても,役に立たないだろう.おそらく,それらの間の距離は 880 km とか 546 マイルとか言ったほうが,より役に立つだろう.

 これを考慮して,geography 型を使って空間データの任意のアイテムで計算を実行する時には,その結果は,空間参照系に関連する sys.spatial_reference_systems テーブルの unit_of_measure 列で指定した線形計測単位で返される.例えば,空間参照系 EPSG:4326 に使われる計測単位を調べるには,次の T-SQL クエリを走らせる.

 結果は次のとおりである.

 これにより,geography 型で蓄積され,EPSG:4326 空間参照系を使って定義されたデータに対して実行された任意の線形計算の結果はメートルで記述される,ということが分かる.先に与えられた座標に基づいてパリとベルリン間の距離を計算するには,次の T-SQL コードを実行することである.

 結果はメートルで表現される.

注記 上述の構文が理解できなくても悲観することはない.次章でこれを説明する.ただこのクエリが,パリとベルリンを表現する geography 型の points を生成すること,そしてこれらの最短距離を計算してくれることを知っていればよい.

 ほとんどの空間参照系はメートルに基づいており,geography 型を使って計算された距離は普通メートルで表記され,面積は平方メートルで表記される.

空間参照識別子

 geography 型を使ってデータのアイテムを蓄積する時はいつでも,そこから座標を取得する空間参照系に対応した適切な SRID を提供しなければならない.SQL Server 2008 はその計算において地球の曲面の関連するモデルに適用する空間参照系に含まれる情報を使い,適切な計測単位で任意の線形法で結果を表現する.提供された SRID はそれゆえに sys.spatial_reference_systems テーブル内の空間参照でサポートされるものの一つに相関していなければならない.

 仮に geography 型のデータを蓄積する時に異なる SRID を提供したなら,そのデータを使って取得したどんな方法でも,異なる結果を取得することになるだろう.なぜなら,その計算は異なる測地パラメータに基づいているからである.

大きさの制限

 技術的な限界から,SQL Server は geography 型で蓄積される一個のオブジェクトの最大サイズに制約を課している.この制約の効果とは,geography 型を使うすべての geometry は新規に生成されたものであれ計算の結果であれ,一つの半球内に適合しなければならないというものである.この文脈でいうところの半球とは,北半球とか南半球などの地球の所定の面を指すのではなく,地球上の任意の一点を中心とした地球表面の2分の1のことを指している.この大きさを超えるオブジェクトを生成しようとすると,次のエラーを受け取ることになる.

 この制限ぎりぎりを扱うには,巨大な geography オブジェクトをいくつかの小さなオブジェクトに分割して,それぞれが関連するサイズの限界以内に収まるようにすることだ.例えば,地球上の海面を表現するための単一の Polygon オブジェクトを持つのではなく,複数の polygon を定義してそれぞれが個々の海洋を表現するようにすればよい.組み合わせることで,これらの小さなオブジェクトは海洋表面全体を表現する.

注記 geography 型に課せられた制約は半球より大きな面を持つ geometry だけに適用されるのではなく,同じ半球状にないならどんな geometry にも適用される.例えば,geography 型を使って北極点と南極点の二つを表現する MultiPoint geometry を生成することはできない.

リングの方向

 前章で示したエラーメッセージを見直してみよう.無効な geography インスタンスの一般的な理由として「…ある polygon が誤ったリングの方向を持っている」とある.これは何を意味するのだろう?第1章で述べたリングは閉じた LineString であったが,Polygon geometry は一つかそれ以上のリングからなり,面の辺縁は Polygon 内部にあると定義している.リングの方向とは「方位」,または順序,つまりそこから Polygon がスタートするポイントを指している.

 geography 型は地球の測地モデルを定義しており,それは連続する曲面である.地図投影から想像で生成されるのと違って,そこには辺縁は存在しない.世界中を一方向に廻り続けることもできるし,スタートした位置に戻ることもできる.これが Polygon リングのポイントを定義した時の特徴になるのは,球体モデルを使う時,Polygon 内部に含まれるリングのどちら側なのか曖昧さが残る.Figure 2-2 を考える時,赤道周辺に描かれたポイントのシリーズがどの外部リングの Polygon のどちらを描いているのだろう.Polygon 内部に含まれる領域は北半球か南半球のどちらを表現しているのだろう?

 この曖昧さを解決するには geography 型を使って Polygon のポイントを定義する時に,SQL Server 2008 がその領域を Polygon 内部に含まれるリングのポイント間の経路の「左側」として扱うようにし,リングの「右側」にあるポイントは全て除外する.Figure 2-2 で与えられた例では,仮に想像の中で示された方向に向かってリングの経路に沿って歩くと,左側にある領域は北となり,示した Polygon は北半球を表現することになる.これを別の視点から考えると,宇宙から地球上の一点を直接見下ろしていると想像することになる.仮に反時計回りに囲まれたポイントのリングだとすると,それらのポイントは Polygon 内部に含まれる(そのリングの経路の左側に存在しなければならないからである).仮に,代わりに時計回りの方向のリングのポイントに囲まれているとすると,それらのポイントは Polygon の定義内部には含まれていないことになる.

注意 仮に小さな polygon リングのポイントを誤った方向で定義すると,その結果のオブジェクトは「内側と外側が入れ替わった」状態になる.地球表面の大部分を含めて,直線状のリングの小さな領域を除いて.これは,地球表面の2分の1以上をカバーできる geography 型は存在しないというサイズの制約を破壊することになるため,エラーを引き起こす.ある Polygon の内部を含める時は,反時計回りにポイントを定義するように注意されたい.それはその領域が,ポイントを結ぶ経路の左側に含まれるからである.

 geometry のスペースを切り取る領域を定義する内部リングにとって,リングの方向はどうなるのだろう?「内部」とか「外部」という分類は,連続した曲面の表面からなる geography 型のリングには簡単に適用できない.事実,geography 型の内部の Polygon はリングを何個でも含めることができ,それぞれが球体の空間を Polygon 内部に含まれるポイントに分割し,かつそれらのポイントは除外されている.これらのリング全てが外部リングまたは内部リングとみなすことができる.これを示すために Figure 2-3 に二つのリングを含む geography 型の Polygon の適切なリングの方向を示した.矢印は各リング内のポイントの方向を示しており,Polygon により囲まれる領域をグレーで示してある.

Geometry データ型

 geography 型と対照的に,geometry 型は空間データを平面上にあるものとして扱う.すべての空間演算の結果,二点間の距離は簡単な幾何学的手法を使って算出される.この平面アプローチは Figure 2-4 に図示した.覚えておくべき鍵となる原則とは,リングのポイント間に引かれた経路の左側の領域が Polygon 内部に含まれること,右側が除外されることである.

座標系

 geometry 型は平坦な二次元の平面上で作用し,その平面上の任意のポイントは一組のデカルト座標 (x, y) を使って定義される.その geometry 型は,次の座標系の型のうち任意の一つからの座標を蓄積するために使われうる.

投影座標系

 geometry 型は投影座標を蓄積するには理想的であり,x および y 座標のペアは投影空間参照系から取得された東座標値と北座標値を表現している.この例では,投影のプロセスは既に角度地理座標を平面上にマップ済みであり,その上で geometry 型が適用される.

地理座標系

 緯度と緯度の「非投影」geographic 座標は直接 geometry 型の y および x 座標にそれぞれ割り当てられる.これは非投影地理座標系のように見えるかも知れないが,実際には投影系の一例でもあり,それは正距円筒図法を生成するのに使われる手法だからである.

自然平面座標系

 これらの座標は x および y 値で表現される任意の地理空間データを表現するが,地球の特異的なモデルに関連しているわけではない.これらのデータの例は地域の調査の収集や小地域のトポロジー計画など曲率が無関係なもの由来なのかも知れないし,コンピュータ支援設計 (CAD) パッケージから取得されたもの由来なのかも知れない.

計測単位

 geometry 型を使う時,ポイントのデカルト座標は定義された軸,特に計測単位で表現された軸に沿った原点からそのポイントまでの距離を表現する.geometry 型は,その座標値に基づいた単純な平面計算を使うため,その結果は geometry 型を使ったいかなる演算も座標値自身と同じ計測単位で表現される.例えば,多くの投影座標系の北座標と東座標とはメートルで表現される.これはユニバーサル横メルカトル図法 (UTM) および多くの国立グリッド参照系にあてはまる.仮に geometry 型を使ってこれらの系から取得した座標に基づいて空間データを蓄積しようとすると,長さと距離もまたメートルで測定されることになる.仮にgeometry 型を使って面積を計算しようとするなら,その結果は,座標値を定義するのにどんな計測法が使われていようと,この例では平方メートルだが,二乗になる.仮にしかし,フィートで測定された投影空間参照系からの座標を蓄積しようとするなら,その結果はいかなる計算もフィートで表現され,面積は平方フィートになる.

注意 最初に,geometry 型は「非投影」地理型の座標値である緯度や経度を蓄積するのに使われる可能性があり,直接に y 座標と x 座標をマップすると述べた.しかし,緯度と経度は角度座標であり,一般に度数で測定されるということを思い出そう.仮に geometry 型を使ってこの方法で情報を蓄積すると,ポイント間の距離もまた度数で測定されることになり,Polygon で囲まれた面積は度数の二乗で測定されることになる.これはほぼ間違いなく,望む結果ではないだろう.だから geometry 型をこの方法で使う時には注意を払うこと.

空間参照識別子

 geometry 型は地球の曲率をまったく考慮せず,SRID 内で記述された計測単位にも関係しないため,異なる SRID を提供しても,geometry 型を使って取得される結果に違いをもたらすことはない.これは把握するのが難しい概念である.先の章で,座標のいかなる部分も,投影座標であれ地理座標であれ,関連する SRID と共に記述しなければならないと書いた.それは座標系が地球上の一点を参照できるようにするためである.仮に geometry 型を使って投影座標系からの座標を蓄積しようとすると,SRID が提供されたところで違いがないとはどういうことなのだろう?

 その答えは,SRID が必要なのは投影参照系であって,地球上の位置を一意に識別するために座標をまず定義するためである,ということになる.しかし,一度それらの値を取得してしまえば,全てのさらなる操作は,その上でデータを基本的な幾何学的手法を使って実行される.地球の曲率への対処方法についてのいかなる決定も,任意の地点が投影像の上に存在する場所を記述する座標の定義の過程で,既になされている.

 例えば,geometry 型を使う時,座標 (0, 0) 地点と座標 (30, 40) 地点間の距離は常に 50 単位になるはずであり,その座標系がどんな空間参照系を使っていようが,どんな単位で表現していようが無関係である.地点 (0, 0) と地点 (30, 40) で表現された実際の地球上の形態は問題にしている系によって変わってくるが,これは geometry 型のデータが計算に使われる方法には影響しない.

 geometry 型の空間オブジェクトを使って操作を実行するためには,各ポイントの座標を取得した空間参照系が何であるかは違いをもたらさない.すべて同じ系から取得する限りは.

一貫したメタデータを確保する

 結果に違いをもたらさないからと言っても,投影座標系に基づくデカルト座標データを蓄積するのに geometry 型を使う時は,関連する SRID を指定すべきであり,その由来する座標を使う空間参照を指定するためである.その空間参照系は重要な付加情報を保有しており,それらの座標を地球上の特定の位置に関連づけるものである.全ての座標セットと共に SRID を明示的に記述することは,この重要なメタデータを保持するだけではなく,異なる空間参照系を使って定義された空間データのアイテムの計算を誤って試みるのを防いでくれる.それは望まない結果をもたらすからである.

付記 sys.spatial_reference_systems テーブルは単に測地空間参照を保持するだけであり,それは geography 型を使って計算を実行するのが必要だからである.投影参照系に適切な SRID を見たければ,次のウェブサイトを見るとよい.http://www.epsg-registry.org/

非測地空間データの保存

 geometry 型は平面座標を蓄積し,標準的なユークリッド法を使って SRID を必要とせずに計算を実行するため,x 座標と y 座標で記述できるならいかなる空間データでも蓄積でき,地球の形態の特定のモデルを必要としない.これは倉庫内のアイテムの位置を保有するような,有限の小規模アプリケーションには有用である.この場合,位置はローカルの原点からの x および y 座標により定義される.地球の表面全体に適用される投影座標系を使う必要はない.

 geometry 型はまた,ある座標系で表現された他の自然平面幾何データを蓄積するのにも使われる.例えば,仮に製造業の行程の詳細な構成要素を蓄積したデータベースを持っているとすると,geometry 型の列を各構成要素の形態を記録するのに使うことができるだろう.

 geometry 型を使ってこのような方法で空間データを記録する時,どんな幾何的形態であっても SRID 0 を使って定義すべきである.これは SQL Server に,その座標は特定の空間参照系に由来するのではなく,特定の計測単位を持たない座標値として扱うようにと教えることである.

リングの方向

 Figure 2-5 を考慮すると,それは Polygon リングを図示したものであり,平面上に geometry 型を使って定義された北半球を表現している.

 geography 型を使った同様の Polygon と違って(Figure 2-2 に示したが),Figure 2-5 における Polygon に含まれる領域は明確である.たとえポイントが時計回りをなすような,リングの方向が逆であっても,そのリングに囲まれた領域はなおも北半球を表現する.geometry 型においては,リングの方向は,Polygon リングのポイントがその中で方向を特定されるのだが,重要ではない.実務上の用語でいうと,次のポイント座標で定義されるリングは

例えばだが,次のポイントで特定する扱われ方と同様に扱われる.

 Polygon で切り取られる空間の領域を含む内部リングを定義する時,これらは時計回りであれ反時計回りであれ指定できる.ただし,外部リングの内部に完全に収まっている限り,あるいは,互いに交差したり一方が他を包含していない限りではあるが.

適切な空間データ型を選択する

 2つのデータ型の間の主な違いを見てきたところで,どんな状況ではどちらを使うべきなのかと,おそらく戸惑うだろう.それは重要な疑問であり,決定的な答えは存在しないが,次のリストがいくつかの一般的なガイドラインとなるだろう.

  • 仮に緯度と経度のデータ(例えば GPS 装置由来,Google Earth 由来,または他のウェブ由来など)を使う場合は,geography 型を使うこと.デフォルトでは 4326 SRID を使っている.
  • 仮に投影座標系を使っている場合には(例えば平面の地図を収集しているなど)geometry 型を使い,地図投影および基準点に使われている SRID を使うこと.
  • 仮に地球に対して特に何も定義されていない x, y データを使っている場合には,geometry 型を使い,SRID は 0 とすること.

 これらの一般的な規則に加えて,多くの追加因子が存在し,この節で記述しているが,意思決定の助けとして考慮すべきである.適切なデータ型の選択は,空間データベースの効率的な設計の確保の最初の一歩であり,ゆえにこれらの要素を決定する前に注意深く吟味すること.

一貫性

 SQL Server 2008 において空間データの複数のアイテムを使った操作を実行するために,すべてのデータは同一の空間参照系,同一のデータ型を使って定義されなければならない.geometry 型と geography 型のデータを同一のクエリ内で混在させることは不可能であり,同一のデータ型であっても異なる SRID を使って定義されたアイテムの操作を実行することも不可能である.仮にそのようなことをしても,SQL Server は NULL を返すだろう.

 仮に,既に空間データが存在していて,そのデータをシステムに集積したいなら,ゆえにデータが既に収集されたフォーマットに適したデータ型を使うべきである.例えば,仮に National Grid of Great Britain 系から収集した投影データを持っているなら,そのデータは geometry フィールドに蓄積すべきであるし,SRID は 27700 を使うべきである.仮に GPS システムから収集した緯度座標と経度座標を使っているなら,geography 型と SRID 4326 を選択すべきである.

付記 SRID は座標値がその中で定義されたシステムについての情報を提供することを思い出そう.それはシステム自身について言及するものではないが.ゆえに単純に,異なる空間参照内でそれらを表現する目的で,異なる SRID 値を既存の座標に提供することはできない.ある空間参照系から別の系へと座標値を変換するには,データを再投影しなければならない.SQL Server 2008 はいかなる再投影メソッドも提供していないが,数あるサードパーティ製のツールはこれが可能である.例えば OGR2OGR は OGR Simple Feature Library (http://www.gdal.org.ogr/index.html) の一部である.

精度

 geometry 型は地球の表面を平面に投影した投影系に基づく平面モデルを使う.先の章で説明したように,いかなる三次元表面の投影プロセスも,この方法ではそこで表現される特徴はある程度の歪曲に至り,それは面積や形状,距離あるいは方向に影響してくる.これはつまり,geometry 型を使うということは,特定の空間操作の結果は必ず歪曲するということであり,使われる投影法,特にその上での計算が基づく地球の表面の一部に依存するということである.

 一般的に言えば,投影される表面積が大きくなるほど,発生する歪曲は大きくなる.小さな面積にわたるこれらの歪曲の影響はかなり最小化されるにも関わらず,大規模なアプリケーションや地球規模のアプリケーションにとっては,geometry 型を使って取得したいかなる結果の精度も,geography 型を使って(そこには投影による歪曲が存在しない)取得した結果と比較すると,決定的なインパクトがある.小さな空間領域のみをカバーする多くのアプリケーションにおいては,米国の特定の州の内部を含むようなものは,関連する州の平面を投影する geometry 型を使って実行した計算結果は,十分に正確だろう.しかし,精度を犠牲にした投影法に基づく演算は,長距離に渡るほど,geography 型の方がより適した選択肢となってくるだろう.

世界の果て

 地球自身とは違い,投影法の結果として歪曲が発生する極端な例として,投影地図には「果て」が存在することである.geometry 型を使って投影空間データを蓄積する時,辺縁と交差するデータを定義するのに必要な状況を特に考慮する必要がある.典型的に発生するのは,geometry あるいは計算結果が 180th 子午線や地球の両極のいずれかと交差する時である.

 これらの歪曲が geometry 型を使った計算に影響する方法を説明するため,バンクーバーと東京間の最短直線距離を計算することを考えてみよう.平坦な geometry 型はグリニッジ本初子午線を中心とした投影法に基づいており,その結果は Figure 2-6 に示したように見えるだろう.

 対照的に,geography 型は連続した,地球の球体モデルを使い,そこには投影の結果として紹介した辺縁は存在しない.東京-バンクーバー間の最短距離として geography 型を使って得られた結果は Figure 2-7 に示したようなものになる.

 Figure 2-6 と Figure 2-7 に示した経路を比較すると,geometry 型の結果は,地図の境界を超えることができないために,より長い経路を描き,アメリカ全土,ヨーロッパ全土およびアジア全土を横切っていることが見えてくるだろう.対照的に,geography 型を使って取得された結果は太平洋を横切る最短経路を示しており,実際の地球の球体に基づいた正確な答えを表現している.

 これらの課題のさらなる説明は,所与の投影において地図の辺縁を拡張して geometry インスタンスを定義しようとする時に発生する.Figure 2-8 はロシアを表現する Polygon geometry をハイライトしてあるが,グリニッジ本初子午線を中心とした正距円筒図法として描いてある.

 ほとんどの Polygon が東半球に含まれるにも関わらず,ロシアの最北東地域(チュコトカ自治区)は実際に地図の辺縁と交差しており,西半球にも表れている.この投影法に基づく geometry 型を使うことは,ロシアを単一の Polygon geometry を使ってこの方法で表現することが不可能であるということである.代わりに,各々の形態を表現するには二つの要素を含む MultiPolygon geometry を使う必要があり,オリジナルの形態を二つに分割された地図の辺縁で生成されたものである.

 本章で提示された問題の両者は,geometry 型のための適切な空間参照系を選択することで,いくらかの範囲で緩和しうる可能性があり,その中で問題の特定の geometry は地図の辺縁と交差しなくなる.そのような投影の例として Figure 2-9 を示す.しかし,これは一つの特定例の問題を回避する一方で,完全には解決していない.つまり,仮に新しい地図が異なる投影法で生成されたとしても,今度は新しくできた辺縁の周辺の局在が常に問題となるだろうからである.

 仮に投影地図の辺縁と交差せざるを得ない geometries の状況を扱うことを期待するなら,データを蓄積するには geography 型がよりましな選択肢となるだろう.

表現

 geography 型は地球の三次元モデルを操作するため,仮に geography 型を地図で表現しようとすると,まずそれを投影する必要がある.以前議論したように,これは歪曲をもたらす.Figure 2-7 で与えられた例のように,geography 型は正確に2点間の最短直線経路を叩き出すが,仮にその結果を投影地図に表示しようとすると,この「直線」は歪曲されカーブして表示されるだろう.この歪曲の正確な効果は使われる地図投影の特性によって異なる.

 Figure 2-9 は Figure 2-7 で示したのと同一の東京-バンクーバー間の経路を描いてあるが,メルカトル図法を使って投影してあり,150° 経線を中心としてある.geography 型を使って計算した経路は球体にプロットするとまっすぐの線分として見えるが,平面の地図上ではカーブして見える.これは投影による歪曲効果による.

付記 しばしば大楕円弧を見るだろう.geography 型における2点間の最短経路であるが,目的地間の航空機の取る最適経路を図示するために航空便に使われる地図上では(Figure 2-9 に示すように)曲線として描かれる.

 逆に,geometry 型は既に平面上に投影されたデータに基づいているため,地図上に結果を表示するにあたって,さらに歪曲を導入する余地はまったくない.geometry 型における「直線」がまっすぐであるのは,地図上に描かれた時に限られる.その地図とは,地点が取得された空間参照系と同一の投影法を使って投影されて提供されたものである.

 仮に地点間の直線を表現しようとしてデータを使うつもりなら,そしてその線を地図上でもまっすぐに投影したいなら,geometry 型を選択すべきであり,その上に結果の表示される地図に対応する空間参照を選択すること.

パフォーマンス

 球面演算の実行にはデカルト演算よりも多くの計算資源を使用する.結果として,geography 型を使った楕円体モデルの空間演算は geometry 型を使う同等の操作よりもはるかに計算量が多くなる.これは地球の測地モデル,例えば距離や長さ,あるいは面積などの地理オブジェクトなどに基づく指標を計算しなければならない geography 型にのみ影響する手法である.地球のモデルを考慮する必要がない場合,例えばオブジェクトのポイント数を数える場合や特徴を表現するのに使う geometry の種類を記述する場合でも,物体の属性を返すメソッドを使ういかなる時でも,geography 型と geometry 型の間でパフォーマンスに違いはない.

標準への準拠

 次のウェブサイト http://www.opengeospatial.org/ によると,Open Geospatial Consortium (OGC) は「非営利,国際的,自発的なコンセンサス標準化機構で,地理空間および位置ベースのサービス標準化の発展を目的とする」.OGC は多くの空間データを扱う業界全体の標準を管理する.これらの標準に従うことで,異なるシステムでもコアレベルの一般機能を確保でき,それは空間情報がさらに簡単に異なるベンダー間やシステム間で共有されることを意味する.2007 年 10 月に,Microsoft は OGC に主要な一員として参加し,SQL Server 2008 に実装された空間データ型は OGC により定義された標準に拠るところ大であった.

 geometry 型は SQL Specification v1.1.0 (http://opengeospatial.org/standards/sfs) のための OGC Simple Features に従い,標準に合致させるために必要なメソッドを実装する.

 geography 型は geometry 型と同一のメソッドを多く実装するが,要求された OGC 標準には完全には従わない.

 こういう訳で,仮に SQL Server 2008 において,認められた OGC 標準に準拠する空間メソッドを使用するのが重要であるなら,geometry 型を使用すべきである.

空間データはどのように蓄積されるか

 geometry 型および geography 型は共に可変長データ型である.これの意味するところは,int 型や datetime 型のような固定長データ型とは対照的に,空間データの蓄積に実際に必要なストレージの量は,データの記述するオブジェクトの複雑性に依存するということである.

 SQL Server 2008 はgeometry 型および geography 型を含む情報をバイナリーデータストリームとして蓄積する.各ストリームは,記述された geometry の種類,使われる空間参照系,およびオブジェクト内の頂点の全体の数などの基本情報を定義したヘッダーセクションで開始される.このヘッダーはその直後に geometry 内の各 x および y 座標値(または経度・緯度)が続き,8 バイトのバイナリーフォーマットで表現される.オブジェクトがその定義内に持つ頂点が多いほど,このバイナリーストリームも長くなり,それゆえに必要なストレージスペースも大きくなる.

注記 SQL Server 2008 は各座標を倍精度浮動小数点型で蓄積し,それは IEEE バイナリ浮動小数点演算標準 (IEEE 754-2008) に準拠している.このフォーマットは浮動小数点を 15 桁の有効数字で蓄積することを可能とする.つまり,サブミリメートルの精度で一般にはどの位置でも十分な精度で記述できる.

 次のリストで空間データのいくつか一般的なアイテムを蓄積するのに必要なストレージスペースの例を提供している.

  • 2つの座標値で定義された一個の Point geometry は通常 22 バイトのストレージスペースを占める.
  • 2つの Point で定義された1個の LineString は最小で 4 つの座標(緯度と経度,または x 値および y 値で始点と終点からなる)を保持しており,38 バイトを占める.
  • 1個の Polygon geometry の占めるスペースは,マークアップする頂点の数に依存して変動する.Polygon により定義されたどんな内部リングも Polygon を蓄積するために必要とされるスペースを増加させる.

 geometry または geography オブジェクトに使われるデータストレージスペースには,特異的な最大サイズというものは存在しない.しかし,SQL Server 2008 にはどんな種類の巨大なオブジェクトであれ,全体の制約というものが存在し,それは 231-1 バイトが上限である.これは varbinary(max) 型や varchar(max) 型のようなデータ型と同等の制約であり,データの各個別のアイテムにとってのほぼ 2 GB に匹敵する.この制限を超過するには,大変に複雑な geometry オブジェクトを保存しなければならない!もし必要なら,多くの個別のオブジェクトが許されたサイズ内に適合するまで,複雑な geometry を分解する,と覚えておくとよい.

チップス T-SQL の DATALENGTH 関数を使って,任意の geometry および geography データのアイテムの蓄積サイズに使われるバイト数の値を見ることができる.

データ型間の変換

 geometry 型が,投影座標系,地理座標系あるいは自然平面座標系を使って定義される geometries を蓄積するために使われることを思い出そう.対照的に geography 型は,地理座標系を使って定義される geometries を蓄積するためだけに使われる.両者の空間データ型は地理座標データを蓄積するのに使われるため,geography 型を使って蓄積されたいかなるデータでも,代わりに geometry 型を使って表現できる.しかし,二つのデータ型の間で変換するために CAST 関数や CONVERT 関数を簡単に使うことはできない.仮に次のクエリを走らせて試してみよう.

 だが,次のエラーが返ってくるだけだ.

 そのエラー記述は,露骨な変換が許可されていないこと,つまり,それぞれのデータ型の扱いの含意を理解するのを確保するよう SQL Server により故意の制約が課せられていること,そして,意図せずデータを交換しないことに注意されたい.しかしこのような場合がある.geometry 型で利用できる関数が存在して,geography 型を使ってデータが蓄積されているのにその型では利用できない関数がある場合には,データ型相互間でのデータ変換が有用である.geography 型から geometry 型へ変換するためには,どちらのデータ型のアイテムの値であっても,バイナリーストリームとして表現できるという事実を代わりに活用することができる.次の例では,geometry 型変数 @geom は geography 型変数 @geog のバイナリーストリーム表現に基づいてセットされる.

 すべての geography 型のアイテムが geometry 型として表現できる一方,すべての geometry 型のアイテムが geography 型として表現できるわけではない.geometry 型から geography 型に値を変換するためには,存在する geometry 型のインスタンスの x, y 座標値は,「必ず」サポートされる測地空間参照系から緯度と経度の座標を取らなければならない.また,そのデータは必ず geography 型の必要とする他の全てに従わなければならない.例えば,リングの方向や大きさの制約などである.これらの設定が全て適合していれば,geometry 型インスタンス @geom のバイナリー表現から geography 型インスタンス @geog を生成することができる.

 しかし仮に,何も蓄積していないとか,投影座標系からの東座標だけとか,あるいは他の非測地データの場合,それは geometry 型でしかデータを蓄積できないということになり,geography 型に変換することはできない.

注意 geometry 型と geography 型の間で空間データのアイテムが変換されるようなケースというのは,比較的まれである.技術的に可能であるとしても,常に論理的に意味を成す訳ではない.もしデータ型の間で変換する必要を感じたなら,それは空間データのあなたの設計が間違っていることを示唆している.

テーブルを空間的に有効にする

 適切な空間データ型を選択したら,空間データを蓄積する計画のために SQL Server のテーブルに列を追加しなければならない.二つの方法がある.新規にテーブルを作成するか,既存のテーブルに新たに列を追加するかである.

テーブルの新規作成

 SQL Server データベース内に空間データの蓄積を可能にするために必要な特殊な属性も機能も存在しない.ただ必要なのは,最低一つの geography 型か geometry 型の列を含むことである.geography 型も geometry 型も既に登録済みであるため,T-SQL の CREATE TABLE ステートメントを使ってgeography 型か geometry 型のフィールドを含むテーブルを作成すればよい.次の通り.

 この例では,二つの列,つまり CityName と CityLocation を持つテーブルを作成しており,前者は 255 可変長文字列を保持し,後者はその都市に関連する空間データを保持するのに使われ,geometry 型である.

既存のテーブルへの追加

 SQL Server の空間機能を使う利点の一つは新しい geometry 型または geography 型の列を既存のテーブルに追加できることであり,空間情報をシームレスに既存のデータアイテムと一緒に集積できることである.

 既存のテーブル Customer は次の顧客情報のフィールドを持っていると仮定する.

 今度はこのテーブルに付加的な空間フィールドを追加して,各顧客の住所を記録したいと仮定する.特に問題なく,ALTER TABLE ステートメントを使って他の全てと同様に geography 型でも geometry 型でもフィールドを既存のテーブルに追加することができる.次の通りである.

 この方法でテーブルを拡張することにより,既存の顧客データと共に空間メソッドを使うことが可能となり,何名の顧客が確保したエリア内部にいるのか,ある特定の顧客が最も近い店舗からどれだけ離れたところに住んでいるのか,というような疑問に答えることができるようになった.

共通 SRID を強制する

 ある地点の座標は空間参照系が与えられた時にのみ意味をなす.SQL Server 2008 は同一の列の中に異なる空間参照由来のデータオブジェクトを蓄積することを許可しているが,機能を実行する時には,すべての空間データアイテムは同一の空間参照を使って定義されなければならない(例えば同一の SRID を持つなど).異なる系由来の座標を使って演算を実行しようとすることは,異なる通貨の金額の合計を算出しようとすることに例えることができる.

25 ドル足す 12 ポンドは 37 … 何だって?

 このような無意味な計算を偶発的に実行してしまうことを避けるため,SQL Server は異なる空間参照系で定義されたデータの計算を許可していない.どんなメソッドを使っても,かかる結果は NULL になる.

 仮に列内に一つの特定の空間参照系だけに基づいたデータしか蓄積しないと分かっているなら,その列に制約をつけることで同一の SRID を全アイテムに強制することができる.次のように,ADD CONSTRAINT ステートメントを使用するだけである.

 この例では enforce_srid_geographycolumn と呼ばれる制約条件をつけた.これは Customer テーブルの CustomerLocation フィールドに挿入されたすべての空間オブジェクトは SRID 4326 を使うよう定義するのを強制するものである.仮に異なる SRID に基づく geography  型のオブジェクトを挿入しようとすると,次のようなエラーを受け取ることになるだろう.

 結果として,この列由来のいかなる二つのデータアイテムを使っても計算を実行できるが,それは同一の空間参照系に基づいて定義されていることを知っている場合である.

要約

 本章では,SQL Server 2008 が geometry 型および geography 型の空間データを実装する方法について学んだ.

  • geography 型は測地空間データを使い,地球の曲率を説明する.
  • geometry 型は平面の空間データを使い,そこでは全てのポイントが平面上にある.
  • 適正な近似を選ぶ際に考慮すべき因子は多く存在する.与えられたアプリケーション,精度,表現,標準への準拠および存在するすべてのデータの一貫性である.
  • 内部的には SQL Server は空間データをバイナリ値のストリームとして蓄積する.
  • 既存のテーブルに空間データを追加するには ALTER TABLE を使うか,T-SQL 構文で空間データを扱えるテーブルを CREATE TABLE を使って生成する.
  • 空間データ列に挿入する際には,確実に SRID を持つデータだけを確保するよう制約を追加できる.

第 1 章 空間情報を定義する (Beginning Spatial with SQL Server 2008)

 空間データをデータベースで扱うにあたりどうしても避けて通れないのが,空間データがデータベース内でどう扱われているかを知ることである.

 EXCEL のオブジェクトも本質を知っているわけではないが,プロパティやメソッドを知ることで「どう動いているか」は見当がつく.SQL Server でも同じことである.

“第 1 章 空間情報を定義する (Beginning Spatial with SQL Server 2008)” の続きを読む

USGSの地震データをインポートし,データベースのバックアップを取る

地震発生地域のヒートマップ

 USGS (United States Geological Survey) はアメリカ地質調査所とも呼ばれ,全世界の地震データを蓄積しているデータベースである.

 かつてここの地震データをダウンロードしたことがあった.合計 72 万件にも及ぶ巨大なファイルである.どのリンクからダウンロードしたのか,今となっては記憶が定かでない.ファイルのプロパティを見ると 2017 年 11 月作成となっていた.これを SQL Server にインポートする.

“USGSの地震データをインポートし,データベースのバックアップを取る” の続きを読む

国勢調査から5歳階級の人口推移を調べる

日本人口の年齢階級推移(国勢調査より筆者作成)

 人口統計は最も重要な基幹統計の一つである.総務省の e-Stat は確かに有用であるが,かゆいところに手が届かない.例えば「市区町村ごと,年齢5歳階級ごとの人口構成の国勢調査ごとの推移を知りたい」という要求には全く無力である.

 主として技術的な理由によるものと,統計調査の粒度の細かさによる.技術的な理由としては,データベースの画面表示セル数の上限を容易に超えてしまうデータ量になってしまうことである.しかし,根本的な理由は調査の粒度の細かさである.

 2005 年以前と 2010 年以降とでは調査の精度が違う.今後は高精度なデータファイルが e-Stat に掲載されていくものと思われるが,2005 年以前に関しては都道府県より細かい粒度は存在しない.そこを求めると手作業になってしまい,現実的ではない.国立社会保障・人口問題研究所ならデータを持っているかもしれない.

 2020 年は国勢調査の年にあたる.総務省にはできるだけ細かい粒度でのデータ掲載を望むものである.

“国勢調査から5歳階級の人口推移を調べる” の続きを読む

今後25年間の日本の都市の将来推計人口を EXCEL VBA で描く

データ系列のマーカースタイルを消去

 これまでは日本の都市人口の過去の推移を見てきた.総務省には日本の都市人口の推移予測がある.今回はこのデータをグラフにする.

 データを可視化するにあたり,重要なのは引き算である.強調すべき系列のみを強調するために,VBA の知識が欠かせない.

 グラフの系列にデータラベルを表示する方法にはいくつかある.

“今後25年間の日本の都市の将来推計人口を EXCEL VBA で描く” の続きを読む

SQL Serverに接続してインポートしたテーブルを結合する

新しいクエリ名が表示されている

 データベースに接続して一つのテーブルをインポートするのは比較的簡単であるが,複数のテーブルを結合した状態でインポートする方法が長らく分からないままだった.

 Power Query を使ってクエリを結合する方法で解決したので備忘録がてら記事とする.

“SQL Serverに接続してインポートしたテーブルを結合する” の続きを読む