小ネタ集

個別の記事にするまでもない、GISニワカならではの小ネタや失敗を五月雨に記します。ときどき追記するかもしれません。

検索ボックスのオートコンプリート

JavaScriptによる検索ボックスのサジェスト／オートコンプリートの方法については、ネットを探せば例がいくらでも出てきます。ユニコード正規化したりひらがな・カタカナを同一視したりなど、日本語特有の手間を加える必要はあるかもしれません。

肝心の候補を列挙する仕組みは、市区町村名をキー、経緯度を値とする配列を用意しておき、入力文字列とキーとが前方一致するものを探すだけ。文字数が少ないこともあり、１万件程度ならいまどきのコンピューターは瞬時に探し終えます。件数がもっとずっと多くても、多少遅延させる・ワーカーに投げる・候補数を制限するなどすれば操作性は落ちないはず。

はんけトケでは、この配列中に見つからなかったら（かつオンラインなら）外部のジオコーディングAPIを使う、との二段構えになっています。具体的には国土地理院のジオコーディングAPIで、JSON形式で複数の候補を返してきます。が、実装もユーザーとしての操作も面倒になるためこちらはサジェスト表示せず、１つ目の候補の経緯度を即採用しています。乱暴ですが、ここにまで至る入力は具体的な住所である確率が高く、あまり問題ないでしょう。

市区町村名のローマ字表記データ

オートコンプリート検索をローマ字でもできるようにしたい。そのためには、市区町村名のローマ字表記を網羅したデータが必要です。でも、いったいどこにあるのでしょうか。

ネットを探すと、民間有志のオープンデータがいくつか見つかりました。どうやらいずれもカナの市区町村名を機械的にローマ字変換したもののようです。実用上問題なさそうですが、もしあるのなら公的なデータが欲しいところ。

以前e-Statでデータを漁っていたとき、ローマ字表記の含まれたファイルを見かけたことはあるのですが、それが何だったか覚えておらず、ちょっと探してみても見つかりません。英語版の検索ページから探してはどうか、と思い立って開いてみると、なんとすぐ意外なところに見つけました。

e-Stat英語版のデータ検索フォームに市区町村の選択リスト（region candidate）があり、その各要素が「市区町村コード＋ローマ字名」なのです。内部のデータベースだかファイルだかをJavaScriptで流し込んでいるらしく、詳細は不明ながらまずまず公的なものと見なしてよさそう。市区町村の名前リストにすぎないため、いわゆる「データベースの著作物」にも当たらないでしょう。

画像フォーマットの落とし穴

何かしらのバイナリーデータをブラウザーに読ませるには、可逆（ロスレス）圧縮可能なPNGその他の、ブラウザーが標準対応している流通用画像フォーマットにしてしまうのが最も簡単で効率的でしょう。ただし、注意が二点あります。

一点は、ロスレスといいながら、実は多くの場合そうではないこと。アルファチャンネルを含む画像をエンコードする際、最適化の影響で値が変化してしまうことがあるのです。作業用ではなく流通用のフォーマットなので仕方ありませんが、このため事実上、RGBAすべてのチャンネルを使って情報を格納することができません。

そしてもう一点、こちらは危険な大問題。環境によっては画像を展開するウェブAPIにバグがあり、なんとそのせいで情報が壊れてしまうのです。どの環境かというと、やはりのiOS版Safari、具体的にはiOS26版です。バグ報告はしてみたものの、iOS26.2現在まだ修正されていません。

バグが生じること自体は仕方ありません。気づいたら直せばいいのです。が、厄介なのはこのバグが気づかれにくいことと、気づいても一般には無問題とみなされ対処が後回しにされかねないことです。なぜなら、「展開した画像の色味が視認できぬほどほんのわずか変化する」との“軽微な”現象だから（ちなみに、色変換のたぐいが一切起こらぬようメタ情報やAPIへの指示やOS設定にまで注意してみても結果は同じ）。いかにも優先度が低そうでしょう。いや、ひょっとするとバグではなくSafariの新たな仕様なのかもしれません。

ヒトが眺めるだけの画像なら、確かに問題ありません。しかし、データを処理するプログラムにとっては、値が±１変わってしまうだけでも一大事です。

たまたまiOS版Safariの特定バージョンの問題に気付いたためやり玉に挙げてしまいましたが、そもそも厳密であるべきデータを、鑑賞が本来の目的である流通用画像として扱う手法には、こうした危うさが常に潜在していると考えられます。

なぜ人口計算が「概算」なのか？

アプリ内の精度の説明からおおよそ察しがついたかもしれませんが、はんけトケの人口計算が概算なのは、メモリー節約のため、計算に用いる人口メッシュデータを対数化しているから。16ビットの原数値を８ビットの対数にしています。

その後データの持ち方を変えたため、現在はそこまでケチらなくてもいいものの、概算と断っているほうが気楽なのでそのままにしています。

そもそも、５年周期かつ秘匿・補完上等の国勢調査の人口にせよ、刻一刻と変化するリアルタイム人口にせよ、１人単位の“正確”な数値にこだわる意味がどれほどあるのか。法的・学術的な根拠として（つまり日常の営みとは別の次元で）用いる以外、そんなことに汲々（きゅうきゅう）とするのは計算機やデータにヒトが使われる現代病の感があり、利益もないのに与したくありません。

もっとも、対数でなくしたほうが処理が速いため、いずれ気が向いたら、そして各ブラウザーの使えるリソースがもっと底上げされたら方針を変えるかもしれません。だとしても、こうした統計はしょせん概算・近似にすぎないことは強調しておきたいと思います。

地図の翻訳を避ける

地図を含むウェブページを機械翻訳すると、地図の表示が遅くなることがあります。原因は、地図が書き換わる（要素の内容が変化する）たびに翻訳エンジンがその翻訳を試みるため、のような気がします。そこで、地図の親要素に「translate="no"」属性をつけてみたら改善しました。

ただし、効き目は実装依存、ブラウザーや翻訳エンジンによりけりです。translate属性を無視するものもあるため、たとえばシャドウDOMにしてみるとか、翻訳を避けられそうな策をいろいろ試してみるといいかもしれません。変な副作用が生じると面倒なので、うちはそこまでしていませんが。

複数の名を持つ河川

検索情報に国土交通省の河川データ（の一級河川のみ）を加えたとき、妙なバグに悩まされました。いくつかの河川がなぜか検索できないのです。

具体的には、たとえば大阪平野を貫く「淀（よど）川」。全国にいくつかある他の淀川は出てくるものの、肝心の大阪の淀川が出てきません。

あれこれ調べてみて、やっと原因がわかりました。

作成したプログラムでは、全国の河川名の重複に対処するため、「河川コード」をキーにして情報を整理していました。河川コードとは、わが国の河川を一意に区別する公的な番号、つまりIDです。このコードを主とし、河川名を従としてぶら下げることにすれば、名前がいくら重複したってかまわないわけです。

ところが、河川の名前で注意すべきは重複だけではありませんでした。なんと、同じコードの河川が複数の名前を持つことがあるのです。

くだんの淀川の場合、大阪では「淀川」ですが、琵琶（びわ）湖のほうへさかのぼるにつれ京都では「宇治川」、滋賀では「瀬田川」と名前が変わります。支流などと同じく、こうした区間は別々のコードになる（さもなければひとつの名前に統一される）ものとてっきり思い込んでいましたが、そうはなりません。国土交通省のデータでは、あくまで同じ“淀川”の河川コードに対し、細切れのレコードごとに名前だけが変えられています。

にもかかわらず、たまたま最初に出てきた名前「瀬田川」ひとつだけを河川コードにぶら下げて了としていたため、「淀川」でこれを検索することができなかったのです。人によっては常識なのでしょうが（一級河川の約１パーセントが複数名を持つ）、開発者はこのことを念頭に置いて河川を扱わねばなりません。

URLのQRコード

GISに直接関係ない小ネタ。はんけトケの一部のページに、サイトのURLの二次元コード（QRコード）を載せています。それを作るとき、URLをすべて大文字にしています。すると、小文字の場合に比べてコードが小さく単純になります。

この現象は、QRコードの仕様によるもの。QRコードの「入力モード」すなわち文字エンコーディングには、数字・英数字・バイナリー・漢字の４種があります。符号の情報量（出力コードの大きさ）は、次の表のとおり数字＜英数字＜バイナリー＜漢字の順に大きくなります。

URLは英数字モードかと思いきや、効率の劣るバイナリーモードになるのが常です。英数字モードでは英大文字・数字・わずかな記号しか使えず、URLの記述は普通これらに収まらないため。そこでURLを大文字にし、英数字モードに適合させてやるのです。

ただし、この手が使えるのはルートパスのURLだけ。URLの仕様では、プロトコル（「https://」）とドメイン名（「hanketoke.com」）は大文字・小文字が区別されませんが、パスは区別されるため、（もともと大文字でない限り）大文字化して含めることができません。対応文字種にない「?」を要するクエリーも不可です。

IndexedDBが使えない？

地図・地理情報のような大きめのデータのローカル保存にIndexedDBを使うことがあるかと思います。主要モダンブラウザーはみな対応しているものの、使えない状況もあります。割り当て容量が満杯、というのもひとつの原因ですが、意外なのがブラウザーのプライベート／プライバシーモード。

いや、大抵のブラウザーでは問題なく使えてセッション終了と同時に消える、との運用です。しかし、またもや登場iOS版Safariのプライベートモードでは、「使おうとした時点で失敗」します（iOS 26.3で確認）。ちなみに、IndexedDB APIが存在するか否かの判定は真が返ります。

安全のための仕様なのか、一過性のただのバグなのかは不明（それともわたしの環境だけ？）。いずれにしても、通常モードでちゃんと動くからといってIndexedDBのエラーハンドリングをサボってはいけません。

用語・注釈

前方一致について

検索対象データの構造や検索クエリーの傾向によっては、部分一致が適する場合もある。ただし、部分一致ではユーザーの意図せぬ候補が多く出すぎるきらいがある。かといって前方一致・部分一致をいちいちユーザーに選ばせると使い勝手が落ちてしまう。
前方一致結果→部分一致結果の順に候補を並べてやるとよいかもしれない。あるいは、通常は前方一致で、２つ以上の語句を入力されたらあいまいなクエリーと見なして部分一致させるとか。

ユニコード正規化

ユニコードでは、ひとつの字形に対して複数の表し方があり得る。たとえば「ガ」という字形は、「ガ」と１文字でも、「カ」＋「濁点」の２文字（合字）でも表すことができる。こうした表し方をどれかに統一することをユニコード正規化という。
文字列を正規化しておかないと、見た目は同じでコードの異なる字が混在する恐れがあり、検索やソートにおいて具合が悪い。

ワーカー（ウェブワーカー）

JavaScriptにおけるバックグラウンド実行スレッド。

ジオコーディングAPIについて

こうしたAPIを利用する際は、結果をキャッシュするなどしてアクセス数を減らす工夫をするのが望ましい（APIサーバーの設定さえ適切ならブラウザー任せでよいはずだが）。一般論としては、取得データの権利問題が生じないよう、キャッシュの寿命はセッション内に限るのが無難。

カナのローマ字変換について

カナをローマ字に変換するアルゴリズムは案外厄介で、未検証の変換結果データはおいそれと採用しにくい。公的なデータを求めたさらなる理由は、ローマ字の表記方式を当該機関なりの根拠・方針とともに統一するため。

「最適化の影響で値が変化」について

エンコーダーによっては、アルファ値がこっそり量子化されることがある。より一般的なのはRGB値の変化で、完全に透過な（あるいはアルファ値を掛けた結果色が意味を失うような）ピクセルは、「どうせ見えないんだからいらないよね」とばかりに色情報が捨てられてしまう（RGB＝０になるなど。ちなみに事前乗算ではない）。
ならば常に一定値以上になるようアルファ値にゲタを履かせればいいかというと、経験上それも当てにならず、そもそも泥縄的にすぎる。

「RGBAすべてのチャンネル」について

RGBAがダメならRGBでいいではないか。そのとおりだが、画像は一般にRGBであってもRGBAとして展開され得るため、メモリー効率が悪いかもしれない。素直にRGBとして展開されたらされたで、アライメントの都合でアクセス効率が落ち得る。

「危うさが常に潜在」について

述べたとおりPNGのような“可逆”コーデックでさえ値が軒並み変化してしまう時点で、すでに危険信号は出ている。「ヒトが見るのに差し支えなければ多少いじってもいいだろう」、というのが流通用画像フォーマットの運用。

「こうした統計はしょせん概算・近似にすぎない」について

はんけトケを使って「この範囲の人口は本当にぴったりこの人数だ」などと解する人はまさかいまいが、一般論として一言申し添える必要はあるのでは。リテラシーへの配慮もさることながら、ポストトゥルースへの悪用を今日懸念せねばならないことは、GISとて例外ではない。

翻訳エンジンについて

文章の翻訳精度が年々向上している一方、HTML構造の理解にはどの翻訳エンジンも不思議なほど無頓着なまま。translate属性はまだいいほうで、ruby要素を未だまともに理解してくれないのが困る。日本語のアクセシビリティーを上げるつもりで振り仮名を入れると、外国語への翻訳結果がおかしくなってしまう。

QRコードについて

英数字モードに対応していないジェネレーターもたまにあるので注意。