まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タイミングいいのか悪いのかわかりませんが、新型コロナウィルスの影響でしばらくしばらく千葉県に引きこもることになりそう・・・って所から今回のブログネタを思いつきました。

オープンソースで公開された東京都の新型コロナウィルス感染症対策サイトが話題になりました:
https://stopcovid19.metro.tokyo.lg.jp/

2020032601


オープンソースで公開されていることに加え、扱うデータもオープンデータを活用していることで他の自治体へも活用される動きが広がっています。スピード感も含めオープンソースやオープンデータはこういう時に強いですよね。


そんな流れに触発されたこともないわけではないのですが、自分もオープンデータを使ったサービスを作れないだろうか、それもできれば比較的得意としている地図情報を使う形で、、、といった経緯の中で1つアイデアを思いついて簡単な実装までしてみました。

技術的な説明は後述しますが、まずは動いているサービスをご覧ください。 PC またはスマホのブラウザで以下のサイトにアクセスしてください:
https://dotnsf.github.io/geojsonjapan/

2020032501


上記のような東京を中心とした日本地図が画面いっぱいに表示されます。画面左上の+ーで拡大縮小したり、マウスのドラッグ(スマホの場合はピンチイン/アウトやスクロール)で表示位置を変更することができます。

その上で、日本地図の陸地部分のどこかをタップすると、そのタップされた地点がどの都道府県に属しているのかがポップアップで表示される、というものです(下図は東京都の皇居付近をタップした時の様子):
2020032502


サービスとしてはただこれだけなんですが、そこそこの精度を実現しています。例えば千葉県の、チーバ君でいえば鼻の先端部分のこのあたり、、、
2020032503


千葉県民であれば常識だと思いますが、千葉県は四方を太平洋、東京湾、利根川、そして江戸川に囲まれていて、川にかかる橋を除けば全ての県境が水の上、と思われています。実際ほぼその通りなんですが、上記部分を拡大してみるとこんな感じになっています:
2020032504


向かって右側が利根川、左側が江戸川で、この2つに挟まれた三角州部分。そのわずかな先端部分だけはなぜか千葉県ではなく茨城県になっているのでした。そういった細かな県境がこのサービスではどうなっているかというと・・・ ちゃんと対応しています:
2020032505


また千葉県に関して言えば、富津岬の先にある2つの海堡も含めて対応しています。千葉県に限らず、そこそこ細かな所までは対応した都道府県判定ができていると思っているサービスです:
2020032506


もともとは「ジオロケーションを使って利用者の位置情報を取得して、香川県からのアクセスだとわかったら・・・ (^^; 」などと考えながらはじめた取り組みだったりしたのですが、対応範囲を日本の全都道府県にして、更に地図情報を連携させた結果がこういう形になりました。これ自体が何らかの直接の役に立つものではないと考えていますが、後述する技術要素も含めて今後更に精度を高めるためのカスタマイズをしたり、今後は「地形から場所を推測する」なんてことにも挑戦したいと考えていたりします。


以下、このサービスを実現するにあたっての技術要素の紹介です。興味ある方は引き続きご覧ください。

まずこのウェブサービスアプリケーションはオープンソースとして公開しています。興味ある方はこちらもどうぞ(実質的には index.html だけで実現しています):
https://github.com/dotnsf/geojsonjapan


次にこのサービスの URL (https://dotnsf.github.io/geojsonjapan/)を再確認いただきたいです。わかる人はわかると思うのですが、Github Pages を使って公開しているサービスです。要は Github のリポジトリを使い、静的なファイル(index.html)をウェブサーバーで表示することで、このサービスは成立しています。つまり外部 API 連携を含めたバックエンド機能を一切使わずに実現しています。では改めてその制約条件の上でどのような仕組みやロジックでこのサービスを実現しているか、わかりますか?


このサービスを実現する上で、以下のような実装をしています:
  1. 地図情報に OpenStreetMap 、地図操作ライブラリに Leaflet.js を使って、ブラウザ上に日本地図を表示する
  2. 各都道府県ごとの geoJSON ファイルを使って、日本地図上に各都道府県ごとの透明なレイヤーを重ねる。その際にレイヤーがタップされた場合に都道府県名がポップアップされるようなハンドラを定義する
  3. 各都道府県ごとの geoJSON ファイルはオープンデータとして提供されているものから作ったファイル(japan.geojson)を利用する。index.html からこの geoJSON ファイルを AJAX で取得して利用する

つまりオープンソースのツールと、オープンデータだけで作ったサービスということになります。

geoJSON ファイルについては補足しておきます。geoJSON とはこの地球上における緯度・経度、およびこれらの配列を用いて点、線、多角形、多角形の組み合わせを JSON ベースで表現する標準フォーマットです。上述の Leaflet.js も geoJSON に対応しており、関数一発で geoJSON のレイヤを地図上に追加することができたり、そのレイヤに対するクリックイベントハンドリングなどが実現できます。

今回公開したこのサービスでは、上述のように国土地理院から提供されている地球地図日本のデータを geoJSON ファイル化したものを使っています。このファイル(japan.geojson)を index.html からAJAX を使って読み込み、各都道府県の feature データごとに Leaflet.js の geoJSON メソッドでレイヤに追加しています(同時に bindPopup メソッドでレイヤがタップされた時の処理も定義しています)。オープンソースとオープンデータだけでここまで作れちゃうんですねー。

なお都道府県レベルではなく市区町村レベルで同様のことができるかというと、国土交通省の行政区域データを使って作られたものは存在しているので、仕組み上はそのままでもできないことはないと思います。一方で市区町村レベルとなるとデータ量がかなり膨大となってしまうため、そのままデータだけ変えて実現してしまうと通信料(量だけでなく料)の問題が発生しかねないと思っています。

一方このデータの精密度について、充分であるとは思いますが、まだまだ厳密性に欠ける部分もあります。例えばいわゆる「飛び地」データは僕が知る限りで試した範囲では存在していませんでした(つまり未対応)。例えば有名な所では埼玉県に囲まれた東京都練馬区西大泉町はこのデータでは「埼玉県」扱いになっています:
2020032602


また実際の geoJSON データを地図上に重ねてマッピングしてみると、そこまで正確とは言えない内容でした(※そもそも地図データ側がどこまで正確か、という問題もあるとは思っています):
2020032507

↑上述の富津岬部分の geoJSON データ、結構荒い・・・


ただ大事なことは API のようなブラックボックスではなく、ここまでの基礎情報がオープンデータとして提供されており、オープンソースのツールや標準化によってここまで実現でき、必要であれば自分で手元のデータを改良(カスタマイズ)して使うこともできるような形で実現できている、という点です(geoJSON は飛び地のようなデータにも対応したフォーマットです)。オープンデータとフロントエンド機能だけでここまで実現できるようになっていることには、あらためて位置情報サービスの人気や広がりを意識するし、今後のさらなる広がりにも期待できます。

以前にも似たようなものを何度か作ったことがあったのですが、その最新改良作品です。 ツイッターでのつぶやき内容を元に自分の性格を分析して、その内容が時間とともにどのように変化していくか、を視覚化するというものです。

実際に自分の3月21日時点でのツイートを元にためしてみた結果がこちらです。なお現時点でスマホで表示する場合はレイアイトが最適化されていないため画面を横にして御覧ください:
https://personality-transition.mybluemix.net/transition/6f24cd50fa6f528cdd3162aadb716b03

2020032101


画面は最上部にシェア用のアイコンが並んだ下に性格を分析した本人の twitter アイコンと名前が表示され、その下に IBM Watson Personality Insights API を使った分析結果の「性格分析」と「消費行動動向」が表示されます(「消費行動動向は初期状態では省略表示されているので、内容を表示するには三角形部分をクリック(タップ)してください)。

性格分析はビッグ5と呼ばれる5つの性格要素(知的好奇心、誠実性、外向性、協調性、感情起伏)に加え、ニーズ(共感を呼ぶ度合い)&価値(意思決定に影響を及ぼす要素)という7つのカテゴリを更に細分化した結果がレーダーチャートで表示されます:
2020032102


また消費行動動向はその性格から結びつく消費行動の度合いが表示されます(色の濃い方がその要素が高く、薄い方が低い、という意味です):
2020032103


画面最下部にはスライダーが表示されています。初期状態では一番右にセットされていて、これは時間的に一番新しい分析結果が表示されていることを意味します:
2020032104


このスライダーを左に移動していくと少しずつ前の(古い)性格分析結果や消費行動動向が表示されていきます。自分の性格が時間とともにどのように変化していったのか/変わらない要素は何か といった内容がわかるようになる、というものです:
2020032105


このページの画面右上のリンクから皆さんのツイートでも試すことができます。興味ある方はぜひ挑戦してみて、よろしければその結果を SNS でシェアしてみてください:
https://personality-transition.mybluemix.net/transition/6f24cd50fa6f528cdd3162aadb716b03



以下、このサービスを実現する上での技術要素の説明です。なおソースコードは公開していますので興味ある方はこちらも参照ください。なお IBM Cloud を使って動かす想定のコードとなっており、後述の IBM Watson やデータベース機能含めて無料のライトアカウントの範囲内でもデプロイ可能な内容となっています:
https://github.com/dotnsf/personality_transition


このサービスは Node.js で実装していますが、サービスを実現する上で利用しているライブラリは大きく3つです。1つ目は Twitter のログイン認可を実現するための OAuth 、2つ目は認可したユーザーのツイートを取得するための Twitter API 、そして3つ目は取得したツイート内容から性格分析を行う IBM Watson Personality Insights API です。

なお、ここで使っている IBM Watson Personality Insights は IBM Cloud から提供されている IBM Watson API の1つで、テキストの内容を使用単語レベルで分析し、そのテキストを記述した人の性格や、その性格毎の購買傾向を取得する、という便利な API です。日本語を含む5ヶ国語に対応しています。詳しくはこちらも参照ください:
https://www.ibm.com/watson/jp-ja/developercloud/personality-insights.html


おおまかな処理の流れとしては、まず OAuth2 で Twitter にログインしてもらうことで、そのユーザーの権限で Twitter が操作できるよう認可します。そして Twitter API でユーザーのタイムライン内容を取得します。 この時に直近の 200 ツイートを取得します。この 200 件のツイートを投稿時刻の順に 40 件ずつ5つのブロックにわけます。そして各ブロック毎のツイート内容をそれぞれまとめて IBM Watson Personality Insights API を使って性格分析を行います(つまり1回の処理で Twitter のタイムライン取得 API を1回、IBM Watson Personality Insights API を5回実行します)。このようにすることでツイートの内容を時間で区切って直近のものから少しずつ時間を遡りながら5回ぶんの性格分析を行い、その結果を上述のようにスライダーバーで時間ごとに表示/非表示を切り替えることで実現しています。

機能的にはこれだけでもできるのですが、このサービスでは「分析結果をシェア」できるようにしました。シェアするためには(シェアされた人はツイートを取得せずに分析結果を見ることができる必要があるため)分析した結果をデータベースに格納する必要があるため、データベースも併用しています(あくまで分析結果を保存するためのもので、ツイート内容は保存していません)。

また上述のような仕様であるため、仮に Twitter 上で非公開アカウントとしているアカウントに対しても(本人の権限でツイートを取得することになるので)性格分析を行ったり、その結果をシェアすることができます(公開許可されていない人や、そもそも Twitter アカウントを持っていない人でも分析結果を見ることができます)。ただしあくまで分析結果だけがシェアされるのであって、ツイート内容がシェアされるわけではない点はご安心を。


このデモサービスでは Twitter のツイートを元に性格分析を行っていますが、必ずしも分析元はツイートである必要はありません。1人の人が書いた文章であればよいので、メールなり、社内掲示板なりからテキストを取得することができるのであれば理論上は可能です。ただし1回の性格分析におけるテキストの単語数が少ないと充分な精度がでない結果となることも考えられます。ある程度の単語数が含まれるテキストを取得できる必要があります(このサービスでは上述のように 40 ツイートぶんのテキスト内容をひとまとめにして分析しています)。

また IBM Watson Personality Insights API の特徴でもあるのですが、単にテキスト内容とその単語傾向から性格を分析するだけでなく、購買行動への傾向と合わせた実行結果を得ることができます。つまりまだ何も買っていないユーザーに対してでも、その購買傾向を調べた上でレコメンドを出したり、特定興味分野の広告を出したりする、といった使い方にも応用ができるもので、特に今回のデモではその時間変化にも着目できるようにしています。応用の幅が非常に大きな API であると考えていて、その一部が伝わればいいと思っています。

 

ブラウザ内で動作するウェブアプリケーションの中で「別ウィンドウで画面を開く」という操作をしたい場合に大きく以下の2つの方法があります:
(1)target="_blank" 属性のついた <a> タグをクリック/タップする
(2)JavaScript の window.open 関数を実行する


より一般的な方法は(1)だと思っています。リンク時に使う <a> タグに target="_blank" という属性を含めておくことで常に新しいブラウザウィンドウを(ブラウザによっては別タブを)開いて、その新ウィンドウの中でリンク先ページが表示されるというものです。比較的簡単に実装できる方法です。

※ <a> タグの target 属性は本来は「ウィンドウを指定して開く」機能です。例えば <a target="abc" ..> というタグをクリックすると abc という名前のウィンドウを探して(存在していない場合は新ウィンドウを作って abc という名前で管理して) abc ウィンドウの中で目的先のリンクを開きます。再度同じ <a> タグをクリックすると、(ユーザーが消していない限り)既に abc ウィンドウは存在しているのでその abc ウィンドウの中で目的のリンクが再び開く、という動作をします。 ただし taget="_blank" という指定があった場合のみ例外的に「常に新しいウィンドウを開く」という挙動になります。


一方の(2)は「 JavaScript の処理の一環として新しいウィンドウを指定した属性と URL で開く」という関数を使って実現する方法です。利用者から見た挙動はあまり変わらないのですが、内部的には「ポップアップ」という扱いになり、違いは多くあります:
・ウィンドウサイズが指定できる(わざと小さいウィンドウで開く、といったこともできる)
・スクロールバーやメニュー、アドレスバーの有無などを指定できる
・タブブラウザであっても新しいウィンドウを作って開く
・JavaScript だけで実現できる(ライブラリ化できる)

例えば SDK などの機能をライブラリとして提供する側の立場で新しいウィンドウで何かを表示する、という機能を実現しようとすると、前述の <a> タグを使う方法は(利用者がわざわざ指定どおりの <a> タグを記述しないとできないため)逆に不便だったりします。一方で JavaScript だけでできるこの方法であれば SDK の一部としてその機能を実装しておき、その機能ごと JavaScript ライブラリを提供すればよいので利用者の負担を軽くすることができます(結果的にサポートの負担も減ると思われます)。

といった違いがあって、実装の違いにも現れることになります。


さて、この後者の方法は「ポップアップ」として扱われると書きましたが、このポップアップは特に iOS の Safari ブラウザでは扱いが面倒なものの1つです。具体的にはポップアップ機能自体がデフォルトでオフになっており動きません(つまり上述の window.open で別ウィンドウを開こうとしても開きません)。ここまでは他のブラウザでも同様なのですが、他ブラウザの場合はポップアップをしなかった旨を画面に通知して(そこで利用者は気づくことになって)ポップアップを許可することができ、次回以降の window.open 実行時にポップアップウィンドウが表示できるようになります。しかし iOS の Safari ブラウザではポップアップをしなかったことをユーザーに通知することもないため、ユーザーからすると「何も起こらなかった」ようにしか見えない(エラーメッセージが表示されるわけでもないため、許可すればよいと気づくこともない)のでした。


iOS Safari でポップアップが開くようにするには、あらかじめ Safari アプリケーションの設定でポップアップを許可する(ポップアップブロックを無効にする)必要があります。以下その手順の紹介をします:


iOS Safari でポップアップブロックの設定を変更するには「設定」-「Safari」を選択し、「ポップアップブロック」と書かれた設定項目を探します。過去に一度も変更したことがなければ下図のように「ポップアップブロックは有効(= window.open では新しいウィンドウは開かない)」になっているはずです:
2020031601


ポップアップウィンドウを表示するよう変更したい場合は、この設定を下図のように OFF に切り替えます。設定はこれだけです:
2020031602


この状態で再度 Safari を使って window.open が実行される状態を作ると、まず以下のような確認ウィンドウが表示されます。ここで「許可」をタップすると初めて window.open が実行されて新しいウィンドウが開いて処理を続けることができるようになります:
2020031603



なお、ここで書かれた手順を実行しておくと、先日のブログエントリで紹介した LIFF の新機能を実装したアプリケーションを iOS の Safari からも実行することができるようになります(つまりポップアップを有効にしないと LIFF の shareTargetPicker が動かないようです):
http://dotnsf.blog.jp/archives/1077179113.html


このページのトップヘ