PostgreSQLで管理するカラムの型変換（CAST）に関するメモ
作業メモです。近い将来同じミスで嵌まることが容易に想像できるので、見える落とし穴は潰しておく。
一般的なキャスト
ALTER TABLE句を使います。
ALTER TABLE tablename ALTER COLUMN columnname TYPE hoge;
hogeの部分は指定したい型を記します。intとかvarchaerとかですね。この記述で概ね問題ないんですが、時々エラーで止まります。エラーメッセージは以下のようなものです。
ERROR: column "huga" cannot be cast automatically to type integer HINT: Specify a USING expression to perform the conversion.
「エラー：カラムhugaは自動的に整数型（integer）にキャストすることはできません。ヒント：変更を実行するためにUSING句を使用しましょう。」
指示に従って粛々と実行
対応
上述のクエリにUSING句を追加します。
ALTER TABLE tablename ALTER COLUMN columnname TYPE int USING(columnname::INTEGER);
このエラーの原因、なんとなくわかるけど確証が持てないのでそこは言葉を濁しつつ。
国土数値情報のデータから都道府県ポリゴンを作る
「都道府県のポリゴンってWebに落ちてない？」 「国土数値情報から作ればいいじゃん」
という掛け合いがありましたので、国土数値情報の行政界データから都道府県ポリゴンを作る方法について書いておきたいと思います。 使うものはPostgreSQLとPostGISです。
まずは国土数値情報から全国分の行政界データをダウンロードします。
これをPostgreSQLに取り込みます。取り込むときはPostGIS Shapefile Import/Export Managerを使うと楽ですね。PostGISインストールしてたらプラグインから呼び出しができます。
pgAdminなんかで中身を見るとn03_001フィールドに都道府県名が格納されているのがわかるので、これをキーにしてポリゴンの結合を行います。
CREATE TABLE pref_polygon AS SELECT n03_001 AS pref_name, ST_Multi(ST_Union(geom)) AS geom FROM n03-16_16101 GROUP BY n03_001
これでいけるはず。
PostGISのST_Multiでマルチポリゴンを生成。ST_Unionで結合。GROUP BYで括れるので、都道府県名（n03_001）をキーにします。
東京以外全部沈没 今後50年地価変遷（予測）の可視化
地図の可視化の勉強をしていたところ、こんなTweetを見つけまして
日本は東京以外、超速で地価が下がっていくの図 pic.twitter.com/bzoCQnlZqm
— 重村俊雄 Tosha Shigemura (@shigemuratoshio) 2016年8月1日
東京以外は大体死ぬということなんですが、どこがどの程度死ぬのかわからないので地図化してみました。
都道府県を触ると10年後、20年後～50年後の地価変化が吹き出しで表現されます。基準は現在の地価を基準としているようです。
可視化して思ったんですが、福岡の地価より宮崎の地価のほうが減衰率低いって何事やねん。。俺の知らない間に宮崎県超進化してたりするんです？？
あとは青森と徳島。現在の地価から90%ディスカウントは異常だ。。
使ったものとか
使ったのはPostgreSQL（PostGIS）とQGIS、あとCartoの無償プランです。
データは国土数値情報から行政界ポリゴンを取得してきて、PostGISを使用して都道府県のポリゴンを作成しました。Tweetの数値はQGISの編集モードからコツコツ書き込んでいます。
作ったデータをKMLに加工（これもQGIS）してCartoにデータをアップロードしてみたのですが、約300MBのKMLを上げたらどうしても途中でこけまして、仕方がないので何とかデータを削って50MB程度まで抑えました。
データを削る方法はQGISのポリゴン簡素化、および時系列でのアニメーションを諦めるという2つの手法を用いています。
Cartoでは時間軸を持たせたデータセットを使うことでアニメーションを作れるのですが、都道府県の形状が微妙になるまでポリゴン簡素化しても150MBを切れません。150MBのデータでもアップロードこけるので、今回はアニメーションあきらめました。
もともとのデータがTwitterからの拾い物ですので、問題等ありましたらご連絡をお願いします。
しかしCartoは便利だな。
- 作者: 筒井康隆,山藤章二
- 出版社/メーカー: 角川書店
- 発売日: 2006/06/24
- メディア: 文庫
- 購入: 9人 クリック: 111回
- この商品を含むブログ (135件) を見る
Pythonコードの"if __name__=='__main__':"の意味に関する個人メモ
備忘録です。
nameの条件分岐の意味をちゃんと理解していなかったので。他人に何かを教えるときにはちゃんと理解した上で説明すべきだし、公開しとくと尚良いです。
Pythonのコードを読んでいると、以下の条件分岐がコードの最終行近くに書いてあるのを見かけるかと思います。
def ConfNameSample(): print('これは__name__確認用のサンプルコードです') if __name__ == '__main__': ConfNameSample()
↑のif以降の部分
これはスクリプトとして実行された場合のみ、関数の中身を実行するという条件を表しています。言い換えると、トップレベルファイルとして実行した場合のみConfNameSampleが実行されます。
トップレベルファイルとして実行された場合、nameにはmainが代入されます。一方で、モジュールとしてインポートされた場合には、nameにはファイル名が代入されます。
分かりにくいので補足
例えば、以下の様なPythonスクリプトを作成します。名前は適当で良いですが、今回はsample.pyとしました。defで定義した関数の二行目でnameに何が入っているか確認できるようになっています。
def WhatIsName(): print('__name__の中身を確認するよ！') print(__name__) if __name__ =='__main__': WhatIsName()
これをどっかのフォルダに入れておいて、コマンドプロンプトやコンソールから実行してみます。すると以下の様な出力が得られるはずです。
スクリプト（トップレベルファイル）として実行するとnameの中身はmainになっています。じゃあモジュールとして読み込んだらどうなってるのかも確認してみましょう。
さっきのやつをちょっと修正して
def WhatIsName(): print('モジュールとしてインポートしたときの__name__の中身は') print(__name__)
コマンドプロンプトからPythonの対話シェルに入ってインポートします。モジュールと関数を呼び出すとこんな感じ。
実行スクリプトが事故を起こさないようにするために、ちゃんと記しておいたほうがいいですね。
