小ネタ集

個別の記事にするまでもない、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です。このコードを主とし、河川名を従としてぶら下げることにすれば、名前がいくら重複したってかまわないわけです。

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

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

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

用語・注釈

前方一致について: 検索対象データの構造や検索クエリーの傾向によっては、部分一致が適する場合もある。ただし、部分一致ではユーザーの意図せぬ候補が多く出すぎる嫌いがある。かといって前方一致・部分一致をいちいちユーザーに選ばせると使い勝手が落ちてしまう。
前方一致結果→部分一致結果の順に候補を並べてやるとよいかもしれない。あるいは、通常は前方一致で、２つ以上の語句を入力されたらあいまいなクエリーと見なして部分一致させるとか。
ユニコード正規化: ユニコードでは、ひとつの字形に対して複数の表し方があり得る。たとえば「ガ」という字形は、「ガ」と１文字でも、「カ」＋「濁点」の２文字（合字）でも表すことができる。こうした表し方をどれかに統一することをユニコード正規化という。
文字列を正規化しておかないと、見た目は同じでコードの異なる字が混在する恐れがあり、検索やソートにおいて具合が悪い。
ワーカー（ウェブワーカー）: JavaScriptにおけるバックグラウンド実行スレッド。
ジオコーディングAPIについて: こうしたAPIを利用する際は、結果をキャッシュするなどしてアクセス数を減らす工夫をするのが望ましい（APIサーバーの設定さえ適切ならブラウザー任せでよいはずだが）。一般論としては、取得データの権利問題が生じないよう、キャッシュの寿命はセッション内に限るのが無難。
カナのローマ字変換について: カナをローマ字に変換するアルゴリズムは案外厄介で、未検証の変換結果データはおいそれと採用しにくい。公的なデータを求めたさらなる理由は、ローマ字の表記方式を当該機関なりの根拠・方針とともに統一するため。
「ほとんどは海」について: 大雑把な概算だが、日本全域を３千キロメートル四方とすれば、その面積は900万平方キロメートル。その内、国土の面積は約38万平方キロメートル。
「最適化の影響で値が変化」について: エンコーダーによっては、アルファ値がこっそり量子化されることがある。より一般的なのはRGB値の変化で、完全に透過な（あるいはアルファ値を掛けた結果色が意味を失うような）ピクセルは、「どうせ見えないんだからいらないよね」とばかりに色情報が捨てられてしまう（RGB＝０になるなど。ちなみに事前乗算ではない）。
ならば常に一定値以上になるようアルファ値にゲタを履かせればいいかというと、経験上それも当てにならず、そもそも泥縄的にすぎる。
「危うさが常に潜在」について: 既述のとおりPNGのような“可逆”コーデックでさえ値が軒並み変化してしまう時点で、すでに危険信号は出ている。「ヒトが見るのに差し支えなければ多少いじってもいいよね」、というのが流通用画像フォーマットの運用。
翻訳エンジンについて: 文章の翻訳精度が年々向上している一方、HTML構造の理解にはどの翻訳エンジンも不思議なほど無頓着なまま。 translate属性はまだいいほうで、ruby要素を未だまともに理解してくれないのが困る。日本語のアクセシビリティーを上げるつもりで振り仮名を入れると、外国語への翻訳結果がおかしくなってしまう。

（最終更新：2026-02-07）