2026.09.23 泊まれる場所4,223 立ち寄りスポット59,693 営業中を確認したキャンプ場1,005 note を読む

「新宿」が5つ並んでも見分けられない。全国9,073駅を足してから直した話

スタンプの目的地に駅と空港とフェリーを足した。
写真も路線名も自動で集めたつもりが、いちばん有名な駅だけが空欄のままだった。

スタンプラリーの目的地に、駅と空港とフェリーターミナルを足した。

これまではキャンプ場や道の駅が中心で、車で行く場所しか登録できなかった。
電車で回る旅もコースにしたい、という話から始まった作業だった。
OpenStreetMap から拾ってきて、駅9,073か所、空港192か所、フェリーターミナル821か所。
ここまでは順調だった。

写真と路線名を、自動で集めようとした

スポットのカードには写真が要る。
9,073駅ぶんを手で集めるのは無理なので、Wikimedia Commons の座標検索を使った。
駅の位置から半径300メートル以内にある写真を拾って、ファイル名に駅名が入っていれば採用する。
路線名は Wikidata から取った。

一晩回して、駅の写真は91.5%、路線名は88.7%まで埋まった。
悪くない数字だと思った。

ところが、埋まっていない駅の一覧を眺めていて手が止まった。
新宿。池袋。渋谷。東京。
いちばん有名な駅ばかりが、きれいに空欄で残っていた。

ふたつの取りこぼしが重なっていた

調べたら、原因は別々のところに二つあった。

ひとつめ。
Commons の座標検索を回すスクリプトに、駅名から「駅」を取り除いた語幹が3文字未満ならスキップするという条件が入っていた。
「新宿」は2文字。
「池袋」も「渋谷」も「東京」も2文字。
短い語で検索すると関係ない写真を拾ってしまうので、誤爆を防ぐために入れた条件だった。
それが、日本でいちばん有名な駅を全部弾いていた。

ふたつめ。
路線名を取っていた Wikidata に、そもそも「新宿駅」「池袋駅」の項目が無かった。
これは意外だった。
渋谷駅は項目があったが、路線の情報は空だった。
小さな無人駅の項目はきちんとあるのに、大ターミナルほど手薄になる。

つまり、自動で集める仕組みが二つとも、いちばん必要とされる駅だけを外していた。

会社名は、別の場所から取れた

同じ駅名がいくつも並ぶとき、区別に効くのは路線名だ。
Wikidata が使えないなら別の出どころが要る。

OpenStreetMap の駅ノードには operator というタグが付いていて、そこに鉄道会社名が入っていた。
しかもこちらは、こちらのデータベースの識別子と一対一で結びつく。
座標で近いものを探す必要がなく、取り違えようがない。

これで「池袋(西武鉄道)」「池袋(東京メトロ)」「池袋(JR東日本)」と並ぶようになった。

乗り入れ路線のほうは、もう少し手間取った。
OpenStreetMap の路線データを見ると、路線に登録されているのは駅そのものではなく、停車位置という別の点だった。
駅の識別子で照合しても当たらない。
道理で、以前この方法で試したときは9%しか埋まらなかったわけだ。
停車位置の座標と駅名で突き合わせ直して、90.2%まで持っていった。

空港と港は、名前で探すのをやめた

空港の写真は37%、フェリーは1.6%しか埋まっていなかった。
こちらも原因を見に行った。

紋別空港の近くにある写真のファイル名は「Monbetsu 20201008122441.jpg」。
とかち帯広空港のは「Obihiro airport ....jpeg」。
ローマ字だった。
日本語の駅名で探していたので、当たるはずがない。

Wikidata のほうも名前が食い違っていた。
とかち帯広空港は「帯広空港」、札幌丘珠空港は「札幌飛行場」、富士山静岡空港は「静岡空港」。
正式名称と通称が入り混じっている。

ここで考え方を変えた。
空港も港も、数キロ以内に同じ種類の施設が二つ存在しない。
名前で照合する必要がそもそもない。
座標だけで、いちばん近いものを採ればいい。

空港は半径3キロ、港は1キロで突き合わせた。
フェリーの写真は13件から169件に増えた。

本番に流す直前で、事故を止めた

手元で整えたデータを本番へ移す段になった。
1万件ぶんの更新文を作って、流す直前に念のため本番側を確認した。

手元の「6798番」は近文駅。
本番の「6798番」は河原パーキングエリアだった。

番号が一致していなかった。
そのまま流していれば、パーキングエリアのデータが駅のデータで上書きされていた。

番号は環境ごとに順番に振られるので、片方だけに行が増えるとずれる。
頭では分かっていたのに、作った更新文はその番号を頼りにしていた。
OpenStreetMap 由来の識別子を結合の鍵に書き直して、先頭300件が本番に実在することを確かめてから流した。

やってみて思ったこと

自動で集める仕組みを作ると、埋まった数字を見て安心してしまう。
91.5%と出れば、残りは細かい取りこぼしだろうと考える。

今回は逆だった。
残っていたのは細かいものではなく、いちばん目立つものだった。
しかも、それを弾いていたのは誤爆を防ぐために自分で入れた条件だった。

数字を見て終わりにせず、埋まらなかったほうの一覧を眺める。
そこに知っている名前が並んでいたら、たいてい仕組みのほうが間違っている。

おかげで、コースも組めるようになった。
全国47都道府県ぶんと、五能線や只見線を乗り継ぐ旅、電車と船で津軽海峡を渡る旅。
そのあたりの話は、立ち寄りスポットとスタンプコースで見られる。

まる子パパ

まる子パパ

会社員。受託開発のエンジニアで、その前は寿司職人・長距離運転手・農業。 技術ブログは、キャンプの合間に踏んだバグと、AI・Web開発の運用の失敗を書いています。 このサイト自体が、開発に携わっているCMS「コンテナ」の稼働中の実例です。 このサイトについて

—

ほかにも書いています

note・スタンプ

※noteは運営者が個人で書いているものです。

技術ブログ一覧へ戻る