2012年7月30日月曜日

右鎖骨骨折

7/25の夜に自転車で転けて右鎖骨を骨折しました。上り坂を漕いでて、段差が無いと思って歩道上に上がろうと乗り上げたら、段差があって、引っかかって転んだという、間抜けな話です。思いっきり体重かけて右に傾けたから、そのまま右肩の方から落ちました。  前回は、左肩の上から打ち付けたので、3つに割れてしまいましたが、今回は、右肩の背中側から打ち付けたので、右端が真っ二つに折れました。今回は重たいザックを背負っていたので、背中側の衝撃が緩和された分、肩に集中してしまった側面もありそうです。  考えるに、自転車のフレーム・サイズが体格と比べて小さ目なので、転けた時にテコの原理で勢いよく肩の方へ衝撃が大きくなるのかな?というのを感じました。それは、前回に怪我した時から感じてた事なのですが・・・。嫁さんに、もう自転車通勤危ないから止めた方がいいんじゃない?と言われて、フレームサイズの話をしたら、ぶち切られました。買う時に嫁さんも乗れるよう、ギリギリ小さめのサイズだけど選択した事なんか、すっかり忘れてて、サイズ合わせたのに小さいは無いだろみたいな事言われました。  チャリの鎖骨を保護する通勤用の簡単なプロテクター欲しいです。シリコン系の衝撃吸収素材(卵が割れないやつ)を肩甲骨から肩の上部ぐらいまでを覆ってしまい、タスキがけのスタイルで装着というぐらいで、用足りる気がしてます。いろいろとググっても、なんかピンとくるやつが無いです。LEATT のが、ネック・プロテクターぐらいのもので、肩用があればいいんだけど…  とりあえず、手術してプレート埋め込みと除去は、ほぼ確定な感じですね orz

2012年7月19日木曜日

QGis Python Plugin と日本語の周辺2

環境

  • Windows 7 x64
  • Quantum GIS Lisboa 1.8
  • GDAL/OGR 1.9.1

   いろいろと思考錯誤していて、GDAL/OGR がどのように多言語に対応しようとしているのか、わかってきました。
QGis Python Plugin と日本語の周辺1 に書いていたコードは、実はベストプラクティスでは無い事が判明いたしました。

  まずは、基本的なおさらいから…
Linux, mac 等の環境では、UTF8 で文字コードを取り扱うのが基本になります。それに対して Windows では MBCS がベースで、プログラム内部の文字コードは、MBCS か UNICODE(UCS2) を選択します。Visual C++ のコンパイルオプションで、どちらを選択するか可能なのですが、もう少し中身を説明すると、Windows API には、MBCS 系の文字コードを引数にとる HogeA という大文字 A をサフィックスにとるものと、UNICODEの文字コードを引数にとる HogeW という大文字 W をサフィックスにとるものが対になって存在します。C言語では、単に
#ifdef _UNICODE
#define Hoge HogeW
#else
#define Hoge HogeA
#endif
というように、マクロで切り替えているだけなのです。   ですので、MBCS系の文字コードでコンパイルをしていても、UNICODE系のAPIをコールする事は可能となっています。

  ここから、本題に入ります。QGIS では、GDAL_FILENAME_IS_UTF8 = YES を前提としています。それは、どのようなトリックかというと、ogr2ogr.exe 等の実行ファイルのパスは MBCS でないと実行できません。ところが、コマンドラインのオプション引数は MBCS である必要は、ありません。極端な話、UTF8 の文字コードをコマンドラインのオプション引数に渡しても問題ありません。   GDAL/OGR の shape ドライバでは、Windows 環境かつ、GDAL_FILENAME_IS_UTF8 = YES であれば、UTF8で引き渡された文字コードを内部で UNICODEに変換して、ファイル操作を行うように書かれていました。この手法でいけば、windows 付属の iconv.dll では、UTF8 と UNICODE 間の変換さえ、うまく行けば、IO(入出力回り)の文字化けに対応できる事になります。

  では、どうすれば日本語のファイルをコマンドラインから扱う事ができるか?
GDAL_FILENAME_IS_UTF8 = NO というような設定は、実は一切不要でして、サクラエディタなどのUTF8が扱えるエディタを使って、バッチファイルを作成し、ファイルを保存する時に、文字コードを「UTF8」にして保存してやればOKでした。QGISのインストール先を日本語の混じったフォルダ下にしなければ、これで、問題なく動くはずです。
UTF-8で書かれたバッチファイルを実行する事です。

問題は、Python で、どうやって UTF-8 な文字コードを subprocess.call に引き渡す事ができるのか。ここが、わかりませんorz...。decode encode('utf-8') してやっても、文字化けします。どうも、スクリプトは自由度が低くて相性の悪さを感じます(>_<)。 2012/07/24 追記:"日本語" の "語" が python の文字コード変換で文字化けするので、自前で DLL を作成して、その中で文字コード変換するようにした。 2012/08/30 追記:その3に続く

2012年7月18日水曜日

GDAL shape driver を深追いしてみた…

どうにも、GDAL(1.9.1)/OGR shape driver が日本語のファイル名を受け付けないので、コードを追ってみました。
VSIFilesystemHandler *VSIFileManager::GetHandler( const char *pszPath )

{
    VSIFileManager *poThis = Get();
    std::map<std::string,VSIFilesystemHandler*>::const_iterator iter;
    int nPathLen = strlen(pszPath);

    for( iter = poThis->oHandlers.begin();
         iter != poThis->oHandlers.end();
         ++iter )
    {
        const char* pszIterKey = iter->first.c_str();
        int nIterKeyLen = iter->first.size();
        if( strncmp(pszPath,pszIterKey,nIterKeyLen) == 0 )
            return iter->second;

        /* "/vsimem\foo" should be handled as "/vsimem/foo" */
        if (nIterKeyLen && nPathLen > nIterKeyLen &&
            pszIterKey[nIterKeyLen-1] == '/' &&
            pszPath[nIterKeyLen-1] == '\\' &&
            strncmp(pszPath,pszIterKey,nIterKeyLen-1) == 0 )
            return iter->second;

        /* /vsimem should be treated as a match for /vsimem/ */
        if( nPathLen == nIterKeyLen - 1
            && strncmp(pszPath,pszIterKey,nIterKeyLen-1) == 0 )
            return iter->second;
    }
    
    return poThis->poDefaultHandler;
}
  "\" 記号文字を "/" 記号文字で置き換えしようとしているのか?これ、SJIS だと典型的にハマるパターンですね。 "表" という SJIS コードは、16進数で表すと 0x955C になります。一方 "\" という ASCII コードは、16進数で表すと 0x5C になります。日本語SJISの取り扱いでは、それぞれの char コードの範囲が SJIS の第1バイトかどうかを調べて、第一バイトに該当した時には、第2バイトもSJISコードなので、ASCII コードとしては処理をしないという条件分岐が必要になります。  SJISが出来た当初は、ASCII と被らないで、なるべく2バイト内に納めて漢字の表現をしないといけなかった事情があるので、この設計は仕方ない事ではありますが、特殊すぎます。  とにかく、こういう罠があるので、内部では UNICODE(UCS2)か、UTF8にすべきなんですが、まじうざい。いっその事、標準で ufopen とか、UTF8 のパスを受け付ける関数とかが、めっちゃ欲しいです。 標準で ufopen とか、UTF8 のパスを受け付ける関数とかが、めっちゃ欲しいです。 標準で ufopen とか、UTF8 のパスを受け付ける関数とかが、めっちゃ欲しいです。 標準で ufopen とか、UTF8 のパスを受け付ける関数とかが、めっちゃ欲しいです。 2012/07/19 追記: ここのコードをトレースしてみたが、何をやりたいのか、ちょっとピンと来ない…。
pszIterKey:/vsigzip/
pszIterKey:/vsimem/
pszIterKey:/vsisparse/
pszIterKey:/vsistdin/
pszIterKey:/vsistdout/
pszIterKey:/vsistdout_redirect/
pszIterKey:/vsisubfile/
pszIterKey:/vsitar/
pszIterKey:/vsizip/
ソースファイル名を渡して、そいつが、これらのデバイスにマッチするかどうかを見ているようである。日本語だと、何故、こんなところで失敗するのか?もっと他の部分をあたってみるか… 同日 追記: VSIFilesystemHandler というクラスで、ファイルシステムの文字コードによる違いを吸収しているようだ。なんとも壮大で、頭がクラクラする。 iConv を使っている場合もあるようだが、 ifdef で iConv を使うか、WinAPIを使うか、切り替えてるので、バイナリ配布物の状況がよくわからない。QGis で配布されているやつは、iConv を使うコードでコンパイルされているのだろう。ところが、FOSS4GJP の情報によると Windows版 iConv のコンパイルは、いろいろと文字コードセットに対する対応が足りないらしく、正しく動作していないらしい。  Windows では、環境変数 GDAL_FILENAME_IS_UTF8 = YES が設定されていた場合には、ファイル名を UTF8 から UNICODE に変換して、UNICODE(UCS2)のファイル名を _wstat にかけている。  どうも、この _wstat に渡すパスあたりで、こけている感じだ。一生懸命、wchar_t にしているが、内部で利用されているパスは、生のMBCSなので、_wstat にかけたいがためだけのコードに留まってしまっている。複雑になった割には報われていないという印象だ。 同日 さらに追記:  stat のコードで失敗してるのかなぁと思ったが、そういう訳でもないらしい。いろんなバージョンで、試行錯誤してたので、DLL HELL に陥ってたのかも…。

GDAL windows 版は何を想定しているのか?

日本語対応の処方箋をogr2ogrに施してみたが、どうも、マシンによって挙動が異なるので、深追いしていました。そしたら、こんなコードにぶつかった。
int VSIStat( const char * pszFilename, VSIStatBuf * pStatBuf )

{
#if defined(WIN32) && !defined(WIN32CE)
    if( CSLTestBoolean(
            CPLGetConfigOption( "GDAL_FILENAME_IS_UTF8", "YES" ) ) )
    {
        int nResult;
        wchar_t *pwszFilename = 
            CPLRecodeToWChar( pszFilename, CPL_ENC_UTF8, CPL_ENC_UCS2 );

        nResult = _wstat( pwszFilename, (struct _stat *) pStatBuf );

        CPLFree( pwszFilename );

        return nResult;
    }
    else
#endif 
        return( stat( pszFilename, pStatBuf ) );
}

 これ、何を意図しているかというと、Windows 環境では、GDAL_FILENAME_IS_UTF8 = YES と環境変数に設定されている場合には、ファイル名等の文字コードを UNICODE(UCS2) wchar_t 型から、UTF8UTF8から、UNICODE(UCS2)wchar_t型 に変更してあげましょうというコードになります。  ところが、おかしいです。まず、細かい事ですが、defined(_WIN32) であって、defined(WIN32)では無い。次に、windows ce の場合は、UNICODEのアプリケーションを組む事になってたと思います。そろそろ windows ce はオワコンなんで、この部分は、もう関係無くなります。次に、そもそも現在は MBCS(Multi Byte Code Set)でコンパイルされているので、UNICODEであるはずがありません。前提条件が異なっている。仮に UNICODE でコンパイルしたとしたら、今度は、他のコードが大混乱に陥る事が容易に想像できます…。  うーん・・・ここで MBCS を UTF8 に変換してあげても、既存のIO関係のコードが MBCS 前提で動いてたりすると、もうお手上げに近いですね。CPLFopen とか、CPLFclose CPLFseek みたいな関数を用意してあげないと、ちょっと厳しいですね。UTF8をUNICODEに変換する事で、ウィンドウズの文字コード問題を乗り切るという方針で組まれているようです。

2012年7月15日日曜日

アンチキュレーションの時代

  また、Google+の考え方が変わってきたので、ここらで書いておきたいと思います。

  まず、はじめに、Google+ の楽しみ方について語ってみたいと思います。 これは、あくまで自分の観測範囲での私見です。観測範囲が異なれば、また違った意見があるとも思います。 Google+に登録してみたけど、これって一体何が面白いの?Facebook と、どう違うの?登録したけど、何も起こらないし、訳がわからないよ!そう感じている人も多いのではないでしょうか?そう、SNSにロール(役割)があるとすれば、リアルな知り合いとの交友は facebook があるので、Google+ でリアルな知り合いとの交流を望んでも、無駄に交友コストが高くつくので、この方面での活用は、今の所無いと考えて良いと思います。そうすると、主体は、知らない人で、かつ、趣向が合いそうな人との交流がメインになってきます。そこを促進するためには、まず、自分のプロフィールに、どういう交流を望むのかを明確に表明しておく必要があります。サークルに入れるかどうかの判断で、プロフィールと直近の投稿は必ず目を通します。その上で、どのレベルのサークルに入れるかを決めて振り分けします。プロフィールは重要な要素だと思います。そうした上で、次にやる事は、サークル候補の中から、めぼしい人を探して、自分のサークルに入れるという作業が必要になります。最低でも30名ぐらいは、自分のサークルに登録しないと、スタートラインにすら立てないと思います。これは必須の作業です。いきなり知らない人をサークルに入れて大丈夫かな?と感じるかもしれませんが、大丈夫です。そうしないと、始まりません。今度は、サークルに入れた人の投稿が流れてくるのでコメントを入れるようにしましょう。SNSの根幹は交流なんで、コメントしない事には話になりません。ただ例外は、あります。人がコメントしたくなるような投稿を続ける事です。ここら辺は、バランスが難しいです。有用な投稿にコメントが来ても、無視していれば、あぁ、この人にコメントしても、のれんに腕押しだからなぁと思われてしまいます。かと言って、ベタベタとコメントされても、あぁ、コメントしたいけど、後がめんどくさいなぁ?なんて敬遠されるかもしれません。投稿していて、誰もコメントしてくれないから虚しいと感じるかもしれませんが、みんな意外とストリーム(投稿が流れる画面)を読んでいたりします。コメントが無いからと言って、いちいちガッカリしない事です。朝の挨拶ストリームというのがあって、挨拶するのも手です。これを拡大していくと、挨拶だけで無駄な時間を費やしてしまいますので、限界があり、善し悪しあるとは思いますが、挨拶し続けてると人と人との距離感は縮まります。

  大多数の人が歩いている道があれば、そこは、避けて通りたい自分は、やっぱり変な事を考えてしまいます。キュレーションは、あるとは思いますが、Google+を見てると、強烈なキュレーションというのは違うかな?と感じるようになりました。たまたま、Google+に凄い人が多いからなのかもしれません。なんで、この人にサクられた(サークルに入れられた)のかな?と思いながら、とりあえずサクり返す(サークルに入れかえす) 事は、よくあるのですが、ある日突然、コメントをもらって深い体験(掘り下げた話になる)入る事もあります。そういう体験が続くと、面白さも広がりも出てきます。あと、自分の趣向と異なる人に対する自分の許容度も上がってきたように思います。キュレーターはいますが、絶対的な存在でもない。キュレーションは才能だとも思いますが、キュレーターを軸に回っている感じでもない。キュレーターを目指してる人にとって、Google+は、難しいSNSかもしれません。とりあえず、今、自分の中ではGoogle+が面白いです。

2012年7月12日木曜日

小樽寿司食べ歩き祭り

 ここんところ、Google+ の投稿で済ませてしまっている傾向が強いので、ちょっと反省して、ブログを更新です。

 小樽の寿司食べ歩き祭りに行ってきました。5店舗が競演する形で4品づつ計20カン。たまに回転しない寿司を食べるのも良いもんです。チケット2枚分を自分・嫁・坊ちゃん(小学校2年)で分けました。


 最初は、しかま寿司さん。カウンターの前で握ってもらって、緊張感があります。中トロは坊ちゃんにとられて食べられませんでしたが、穴子がめちゃくちゃ旨い。エビも普段食べてるものとは格が違いました。


 腹が減っていて、大和屋さんでは写真を撮るの完全に忘れてしまいました(>_<)。中トロが肉厚でボワーン。甘エビも普段食っているのとは格が違う感じ。嫁さんは、大和屋さんが好きだと言ってました。

 政寿さんは、サービスが行き届いていました。イカの包丁の入り方がオツな感じで感動しました。カンパチも回転寿司で食べるカンパチとは違って、美味かったです。時しらずは、坊ちゃんに取られて食べられませんでした。



 町のさんは、庶民的な感じのお店、テーブルの上が汚いのは戴けませんが、安くて旨いものを!というのをモットーにされてました。もちろん、美味しいです。


日本橋さんは、今回、一番気合が入っていたように思います。緊張感があって、凄い良かったです。山わさびののったマグロも美味しく、ホタテも、ちょっと前まで生きてたコリコリの食感、ウニも美味しかった。タコが柔らかくて、いい仕事をしていたらしいのですが、坊ちゃんに取られて、食べられませんでした。


 各店、ガリと、お吸い物と、お茶が異なるので、味比べをするのも楽しかったです。

QGis Python Plugin と日本語の周辺1

QGIS の python plugin を書いていて、やはり日本語の処理に四苦八苦したので、判明した事をチビチビと書いていこうと思います。ノウハウが溜まる度に書き足すつもりなので、その1としました。どれぐらいの頻度で続くのかは、書いてる本人にもわかりません。

 文字コードの国際化に関する状況は、刻々と変化する可能性が高いので、環境を明記しときます。
  • Windows 7 (x64)
  • GDAL 1.9.1
  • Quatom GIS Lisboa 1.8.0

 Windows 環境において、GDAL/OGR あたりで、日本語のファイル名を使おうと思ったら、環境変数「GDAL_FILENAME_IS_UTF8」に「NO」と設定しないと、ogr2ogr 等のコマンドでファイル名が不正だとエラーにされてしまう現状があります。

 それなら、思い切ってコントロールパネルの「システム環境設定」に、GDAL_FILENAME_IS_UTF8 = NO と設定してしまえば良いじゃないか?と設定したら、ものの見事に嵌りました。なんと、QGISでshapefileを開こうとするとエラーになってしまいます。なんてこったい!QGIS内部では、UTF8でファイル名を扱っている雰囲気が漂ってます。これに関しては、現段階では確認できていません。

 プラグインのコードで、QFileDialog からファイル名を取得するコードを見てみましょう

    fileName = QFileDialog.getSaveFileName(None,QString.fromLocal8Bit("Select a file:"), "", "*.tapgis")
    if fileName.isNull():
      return
    fname = unicode(fileName.toLocal8Bit(),'mbcs')
  はい、ウィンドウズでは、ファイル名はOEMの文字コードセットになりますので、multi byte char set  つまり、SJIS(CP932)になっております。python なんて、ほとんど知らねぇよだったので、unicode という名前の関数が、文字コード・セットを指定して文字列を初期化する関数だと判るまでに丸一日費やしました。
  さて、こいつを ogr2ogr のコマンドに引き渡すとします。

  実はファイル名に半角スペースが混じっている場合には、”path" というようにダブルクォーテーションでパスを括ってやらなければなりません。逆に半角スペースが混じっていない場合には、path というようにダブルクォーテーションで囲ってはいけません(何この仕様・・・くたばれ)。という事情は、すっ飛ばします。
  # ogrvars には "-overwrite" 等のオプション文字列が渡される
  def CallRWTools(self, infile, outfile, ogrvars):
    import os
    try:
      import subprocess
      path = str(QgsApplication.prefixPath()).rsplit('/', 2)[0]
      pcmd = path + '\\bin\\ogr2ogr';
      fmt = '%s -f "tapgis" %s %s %s'
      cmd = fmt % (pcmd, outfile, infile, ogrvars)
      # ファイル名がUTF8ではないという状態に変更
      os.environ["GDAL_FILENAME_IS_UTF8"] = "NO"
      subprocess.call(cmd.encode('mbcs'), shell=True)
      #cmd3 = "echo " + cmd + " > " + outfile + ".txt"
      #subprocess.call(cmd3.encode('mbcs'), shell=True)
      #cmd2 = "notepad " + outfile + ".txt"
      #subprocess.call(cmd2.encode('mbcs'), shell=True)
    finally:
      # ファイル名がUTF8であるという状態に戻す
      os.environ["GDAL_FILENAME_IS_UTF8"] = "YES"
  はい、QGIS 内部では、GDAL_FILENAME_IS_UTF8 = YES を前提としているので、コマンドを呼び出す間だけ、GDAL_FILENAME_IS_UTF8 = NO に変えてコールします。あと、WIndows シェルでは mbcs なので、encode('mbcs') してやらないと、正しいコマンド引数になりません。

  ここまで書いても、日本語の問題は残ります。今度は、ogr2ogr のオプション文字列が mbcs のままドライバに渡されるためです。自分の書いたドライバでは、sqlite3_open という関数をコールしているので、OGRDriver の OGRDataSource::Open, OGRDataSource::Create という関数内で渡されたファイル名が mbcs なので utf8 へ文字コード変換してやる必要がありました。   また、OGRDataSource::CreateLayer に渡されるレイヤ名は、変換元のデータソースのOGRDriver の実装に依存している状態なので、どんな文字コードが渡されるのか、未知数です。shape driver の実装では、-nln オプションでレイヤ名を指定しない場合には、ファイル名からレイヤ名を生成しているので、mbcs の文字コードが来ました。注意しなければならないのは、これは Windows の日本語OS 独特の状況においてのみ発生します。Windows の Laten1なOSの環境では、おそらく Laten1の文字コードが来るという結果になるでしょう。-nln オプションも生の文字コードが渡されるので、同様の結果になります。

  このように、locale でなんとかしようという発想は、破綻するので utf8 で統一的に扱う必要性が高いと思います。いちいちロケール指定してたら大変です。ウィンドウズの場合は、CPACP を有効活用する方向が望ましいと思います。 2012/07/19 追記: その2に続く 2012/09/05 追記:結局、ウィンドウズ環境では、GDAL_FILENAME_IS_UTF8 = YES を前提にコードが書かれてあるので、その1のアプローチはダメダメでした。

2012年7月10日火曜日

旭川モクモク・フェスタ






モクモク・フェスタに行ってきました。家具の街でもある旭川市。モクモク・フェスタでは、掘り出し物もあり、楽しみです。
今回は、坊ちゃんのお守りで、トンカン・トンカン・・・木のロボットを制作しました。戦利品は、ソファーの皮の余り生地で作ったポーチと名刺入れ、それにニャンコな筆立て。ポーチには、mac の電源コードとかを入れてます(^^;


macbook mid 2010 モデルをSSD化

macbook 2010 ホワイト・モデルも使い倒そうと、SSD化する事にしました。SSD256G も安くなって、Amazon で 17k ぐらいで買えます。あと、別にDVD要らんやろ?という事で、秋葉館のmacbayのセットを買いました。  macbook の構成は、HDD 512G を windows用に280G程度確保していたので、移行には苦労しました。メインの用途は、嫁さんのウィンドウズ環境をSSD環境に移す事。最初は、VMWare Fusion 4 で仮想化させて使おうと思ってました。ひっそりと、windows -> mac への移行です。ただ、pc2mac というツールを使って移行させようと思ったのに、Windows の構成を調べに行った段階で、unexpected termination で落ちて移行できませんでした。残念に思いながら、mac 付属の disk utility を駆使しても、どうにもパーティションサイズの違いが吸収できない。数日トライ&エラーで成功したのは、winclone というツールを利用する方法。 参考にしたのは、
http://macbootcamp.net/software/winclone.html
http://tukaikta.blog135.fc2.com/blog-entry-196.html
http://tukaikta.blog135.fc2.com/blog-entry-45.html
それでも、何度かトライ&エラーしたので、ポイントを書いておこうとおもいます。
  • コピー元のwindowsパーティションは、Tools メニューのShrink(縮小)をかける
  • Shrink(縮小)、復元、Expand(拡張)、を行った直後は、再起動をかけてWindowsを起動させ、scandisk を実行させておく事(起動時に実行する状態になる)
  • 環境設定で、dmgではなく、特別な圧縮イメージを使用するように設定しておく
  • ひとつの作業が終了しても、慌てないで、winclone を強制終了させないで、終了させるよう心がける
  • システム環境設定で、省エネルギーの可能な場合はハードディスクをスリープさせるのチェックを外しておく。
  • bootcamp パーティションを復元(コピー)する場合、Windows を先にインストールしておく(NTFSの状態でないと失敗する、boot の設定がうまく反映されないかもしれない)
 こんな所です。あと、SSDは、DVD-Drive 側に付けた方が良いです。というか、HDDをDVD-Drive側に付けると、HDDへの電源供給がバチッと絶たれて、若干心臓に悪いです。USB-Disk化したDVDですが、両面テープで金属板とプラスチックの間を固定した方が良いです(振動がひどい)。  SSD化すると、感動するぐらい速いです!対費用効果抜群です!!!

2012年7月2日月曜日

FOSS4G HOKKAIDO 2012 で発表しました

FOSS4G HOKKAIDO 2012 で発表してきました。資料は、こちらになります。  15分間に3つもテーマを入れるのは、詰め込み過ぎたかもしれません。これでも、まだネタは有って、テーマは絞りました。デモも交えようかと考えていたのですが、さすがに時間的にちょっと無理で、断念しました。  最初のDynamicTileというやつですが、会社のデモページの機能選択で「地図色塗り解析」というやつで使用されています。実際には、php側で画像ファイルはディスク上にキャッシュをかけていて、1日に1回ぐらいのリセットをかけてます。他には、機能選択の「レイヤ設定」で画面左に出てくる「表示レイヤ選択」というやつも、該当します。こいつも、レイヤの組み合わせで合成したやつをディスク上にキャッシュをかける仕組みになっています。  今年の春に参加した DevFestX の感想でも、ぼやいているように、FusionTable というやつと似てます。時期的には、開発されたのは同時期ぐらいだと思われます。  2番目のタブレット型GISは、現在進行形で開発しているものです。道内の自治体に1カ所だけ納品しています。一般売りできるように、改良を重ねてます。ビデオを制作してもらったので、自分が解説するより、わかりやすいかな?と思って、そのまま流しました。宣伝になってしまいますが、3番目の発表に続く文脈なので、ご容赦ください(^^;  3番目のGDAL/OGRの話は、先ほど発表された基盤地図対応GDAL/OGRを見て、ここら辺の話をできる人間って、そんなにいないのかな?と思って、まとめてみました。若干会場を置き去りにしてしまったかもしれません...。  発表中の   Android 用 Proj4j は、こちら   GDAL/OGR スタートアップ・キットは、こちら  になります。GDAL/OGR の方は、QGis を C:¥OSGEO4W という場所にインストールした事を前提にしていて、検索パスを書いてます。パスが違ってうまく行かない場合には、cmake_modules/FindOGR.cmake というテキストファイルを編集して、試してみてください。CMakeLists.txt の冒頭に cmake のコマンドの使い方が書いてあります。ドキュメント無しは、ちょっと味気なかったですね...。  何かあったら、Google+ 沖 観行 まで、メンション飛ばしてください。あと、OSGeoJP の ML にも登録するようにしますので、よろしくお願いします。  最後に、北海道地図の朝日さま、原田さま、デジタル北海道の三好さま、日頃仕事でお世話になっている北海道地図さま、OSGeoJP 関係者の皆様、ありがとうございました。