京都の場所・道・解説を共通で利用する基盤
場所と道の正確さを土台に、地域を探す・ツアーを組む・現地で理解する体験をつなげる構想です。
構想提案・未実装 / 2026年11月5日
寺の場所を調べ、入口を確かめ、そこまで歩ける道を登録する。この仕事を、サービスごとに繰り返す必要はありません。同じ場所と道を参照すれば、サイトでは訪問先を紹介し、builderでは行程を組み、現地では見るものに合った解説を届けられます。
京都のエリアと寺社の関係を表示。場所の紹介から、訪問できるツアーへつなぐ。
写真で訪問先を選び、移動・滞在・費用の目安を見ながら、同行ツアーを組み立てる。
ゲストの現在地と進行に応じ、その立ち位置で分かる解説をスマホへ届ける。
社内では、Louisの下見・撮影位置とNotionの知識を同じ場所へ結び付けます。共通で利用するのは確認した地理情報で、個人の生の移動履歴ではありません。
地図の絵は背景、点・線・面はその上に重ねるKETの情報です。GISは、この重ね合わせを編集・検索する仕組み。地図を一から描く必要はありません。
「光明院」と「Kōmyō-in」のような別表記は同じ対象の候補です。名前と距離だけで自動合併せず、施設・資料を照合します。地名の文字列をIDそのものにはしません。
Place / 場所寺院、神社、庭園に加え、市場・街路・御所・街区も対象。親寺院と塔頭などの関係も保持。
Waypoint / 地点実際に人が立つ位置。施設の代表ピンとは別。
Path / 道始点・終点、道の形、方向、路面、通行条件。
Area / エリア行政区域とKETの観光地区。境界の根拠と版を持つ。
Guide / 解説見る対象・立ち位置・言語・文章や音声の版。到着条件は別に結ぶ。
Route / 行程道と地点を順番に参照。場所の情報は複製しない。
この六つに、営業時間・閉鎖などの変動条件、画像・音声の権利、確認根拠、配信する版の目録を結び付けます。すべてを一つの「寺社ページ」に詰め込みません。
サイトでは、寺院Aを地域から探し、どんな庭があるかを見る。builderでは、入口までの移動と滞在を行程に入れる。セルフガイドでは、入口で拝観の案内、庭の立ち位置で鑑賞の解説を出す。
同じ地理情報でも、ゲストへ伝える内容とタイミングは違います。Notionの詳しい知識をそのまま読み上げず、見える形から意味へ進む現地用原稿を作り、公開確認した版を使います。
五区分は既存データでdecided（決定済み）の枠です。今回のゼロベース検討では、その枠と新しく定義する境界を分けて評価します。枠を変更する場合は、KETの担当者との採用判断と変更理由を記録します。京都市の山間部も対象に含め、宇治などは市外として区別します。
同じ版の主分類では重複と空白を検出します。未定義範囲は「未確定」と見せ、確定済みの自動判定に混ぜません。施設がまたがる場合は交差関係を残し、一覧用の主な所属と各入口の実所属を分けます。トレイルは通過地区を区間単位で持ちます。
一つの寺院と、そこへつながる道を選びます。その場所と道が三つの用途に渡り、一度の修正がそれぞれへ反映されるかを確かめます。現地の位置や解説も試したうえで、対象を広げます。京都全体の測量や全機能の開発を、最初に済ませる必要はありません。