42,000以上のアルプスの山小屋、ビバーク地点、山頂をマッピングする作業には、独自の技術的課題があります。それは、「Jagdhütte」や「Rosskopf」のように、多くの地点が同じ名前を共有していることです。この問題を解決するため、biwak.infoは階層的なスラッグシステムを導入しました。これにより、一意で共有可能なURLを生成すると同時に、一度公開されたリンクは、基礎となる地理データが変更された場合でも機能し続けることを保証しています。
スラッグレジストリの技術的実装を担当した開発者の肖像です。
アルプスの非一意な名称という課題
アルプスの地理において、名前は異なる谷の間で頻繁に繰り返されます。例えば、「Jagdhütte」という名前は70の異なる地点に現れます。単純な名前からURLへのマッピングを使用すると、衝突が発生し、例えば /p/jagdhuette という単一のURLでは、それら70の地点のうちの1つにしか対応できなくなってしまいます。
開発者は異なる命名サフィックスの影響を測定し、ほとんどの重複は同じ国内で発生するため、国名を追加してもほとんど助けにならないことを発見しました。地域を追加することで重複の数は約半分に減少しましたが、残りの大部分の競合を解決するには標高データが必要でした。
階層型スラッグ生成ロジック
システムは、最短の一意なスラッグを生成するために特定の優先順位に従います。まずプレーンな名前を試行し、それが使用中の場合は地域を付加し、それでも使用中の場合は標高を付加し、最終的な手段として一意のOpenStreetMap IDを付加します。
正しい地域を特定するために、システムは簡略化されたNatural Earthの境界を使用してポイント・イン・ポリゴン判定を実行します。簡略化された境界のために地点がポリゴン外に位置する場合、システムは最も近いポリゴンを特定して正しい地域サフィックスを割り当てます。
このプロセスは、優先順位に従って候補を生成するジェネレーターを通じて自動化されています。これにより、チロルにある「Rosskopf」のような場所は /p/rosskopf-tirol となり、より具体的な場所は /p/rosskopf-tirol-2257 となることが保証されます。
レジストリによるURLの安定性の確保
動的なデータシステムにおける大きなリスクの一つは「スラッグ・ドリフト」です。これは、新しいエントリを追加した際に、新しいデータに対応するために既存のエントリのURLが変更されてしまう現象です。これを防ぐため、biwak.infoは発行されたすべてのスラッグを特定のOpenStreetMap IDにマッピングする、コミットされたスラッグレジストリを維持しています。
レジストリは3つの厳格なルールに従います。レジストリ内のスラッグは別の場所へ移動することはありません。地点は、現在の名前に適合している限りレジストリのスラッグを保持します。そして、新規または名称変更された地点には、階層から利用可能な最初の候補が割り当てられます。
このアーキテクチャにより、たとえソースデータに2つ目の「Matterhorn」が追加されたとしても、元の「Matterhorn」は /p/matterhorn というURLを保持し、新参者はサフィックス付きのスラッグを割り当てられるようになります。
トレードオフと制限
システムは読みやすさを優先していますが、すべての地点に対して完全に人間にとってフレンドリーなURLを保証できるわけではありません。現在、458の地点は、名前を共有しておりソースレコードに標高データがないため、スラッグにOpenStreetMap IDを必要としています。
レジストリは、これまでに発行されたすべてのスラッグをマッピングする成長し続けるファイルです。ソートされたJSONファイルであるため、開発者がドイツ語のウムラウトを「u」から「ue」に変更した際のようなスラッグ規則の変更は、読み取り可能なgit diffとして出力され、影響を受ける数千のURLを簡単に監査できるようになっています。