全体像 同じ場所から三つの用途へつなぐ。
具体化 記録・編集・配信の責任を決める。
検証 現地と三つの用途で成立を確かめる。
まず一つのルートで、三つの使い方をつなげる 同じ入口や道を、三つの用途へ渡せるかを最初のルートで確かめます。 一つのルートを登録 サイト・builder・セルフガイドで使う
同じ入口や道を、三つの用途へ渡せるかを最初のルートで確かめます。 最初に作るのは、一つのルートの詳しい地図です。ただし、その情報を自社サイト、古荘のtour builder、セルフガイドのどれでも使えるように設計します。対象を小さくするのは、同じ情報を本当に使い回せるか確かめるためです。
依頼で示された要件：三つの用途の共通で利用 今回の提案：データの構造・運用・試し方 未実施：地理DBの構築、スマホと現地での試験
参考サイトの「こう記録する案です／実装前に決めること／検証」の読み方を借りた、別案件の資料。地理基盤を、無理に事業用のリーンキャンバスへ当てはめてはいません。
設計上の決め事 具体的な一件 テストカード 作る順序 判断が必要なこと 根拠・既存構想 データから配信までの関係 場所、解説、商品条件は別々に編集し、採用したIDと更新番号を一つの目録にまとめます。 編集する情報 確認した版をまとめて配信
場所、解説、商品条件は別々に編集し、採用したIDと更新番号を一つの目録にまとめます。 場所とエリア 各場所に、どの地区に属するかを記録します。
→
地点と道 場所の入口や鑑賞する地点を、道の接続と結ぶ。
→
行程と解説 通る道の順序と解説を選び、利用条件を確かめます。
担当する保存先で編集する 場所、紹介文、知識、素材、商品条件は、それぞれ担当する保存先で直します。
→
届ける情報の更新番号をそろえる どの場所・道・解説の更新番号を使い、誰に見せるかを目録に残す。
→
三つの用途へ届ける サイト、古荘のbuilder、セルフガイドが、必要な情報を読み出します。
上の段は、場所や道、解説のつながりを示しています。下の段は、担当者が情報を編集してから各サービスへ届けるまでの流れです。サービスごとに別の台帳を作るのではなく、同じ場所のIDと、確認した更新番号を使います。
各場面で、どう動く仕組みにするか 登録した場所を、そのまま販売対象にはしない 登録、掲載、商品としての提供は別の判断です。購入者向けの解説には利用権の確認も必要です。 社内の登録 公開・同行・セルフガイドの利用条件
登録、掲載、商品としての提供は別の判断です。購入者向けの解説には利用権の確認も必要です。 こう記録する案です 寺社や道ごとに、社内確認だけに使うのか、サイトへ掲載できるのか、ガイド同行やセルフガイドで利用できるのかを記録します。有料の解説を届けるときには、購入者がその解説を利用できるか、配信する側でも確かめます。 なぜ必要か 場所が登録されたことは、立入り・商用解説・音声配信・販売の許可を意味しません。旅程が計算できても予約は確定しません。 実装前に決めること セルフガイドの価格、使える期間、返金や問い合わせへの対応を決めます。施設の規則と素材の利用権も確認します。 具体例と、気を付けること builderの総費用は、地理基盤が返す距離・時間と、既存の商品価格・別払い費用を組み合わせて表示する案です。地理DBへ独立した料金表を複製しません。交通・施設の費用は出典・確認時点付きの目安とし、販売価格・提供枠・決済は商品／予約系の責任として照合します。
セルフガイドの提供形態の法的整理も販売前に確認します。ガイド同行型builderの既存構想は変更せず、共通データの別の利用先としてセルフガイドを置きます。
入口が正しいことと、今日入れることは別 座標の細かさだけで正確とは判断せず、位置の根拠と営業時間などの確認を分けます。 GPSで観測した位置 公式図と現地で確かめた入口
座標の細かさだけで正確とは判断せず、位置の根拠と営業時間などの確認を分けます。 こう記録する案です 入口の座標が合っていても、今日は閉まっているかもしれません。そこで、位置を確かめた根拠、通行できる条件、解説の根拠、情報を確認した日、公開や販売に使える範囲を、それぞれ記録します。 なぜ必要か 地理的に正確でも立入不可の道があり、実測した入口でも営業時間が古いことがあります。「確認済み」一語では利用判断ができません。 実装前に決めること 入口、分岐、鑑賞する場所について、どこまでの位置誤差なら使えるか、何で確かめるかを決めます。 具体例と、気を付けること 根拠は項目ごとに持たせます。公式境内図は門の位置関係、GPSはその日の観測、現地写真は目印の確認に使えますが、どれか一つで全項目の正しさを証明しません。小数点の桁数と実測精度も別です。
緯度・経度を保存するときには、地球上の位置を表す基準をそろえます。その候補がWGS84です。Webへ渡すGeoJSONでは、経度、緯度の順に書きます。距離や面積は、座標の数字をそのまま引き算せず、メートルで計算できる方法を使います。標高には、何を基準にした高さかと出典を別に残します。
地図で交差していても、曲がれるとは限らない 線が交差していても接続しない例です。曲がれる分岐だけを、道のつながりとして登録します。 橋の上を通る道 橋の下を通る道
線が交差していても接続しない例です。曲がれる分岐だけを、道のつながりとして登録します。 こう記録する案です 橋の上と、その下を通る道は、地図では交差します。でも、その交点で道を移ることはできません。道は入口や分岐で区切り、どこからどこへ実際に進めるかを登録します。向き、路面、階段、移動手段、通行条件も、その区間に結び付けます。 なぜ必要か 橋と橋の下の道は、地図で交差していても曲がれません。寺の中心同士の直線では、歩ける旅程になりません。 実装前に決めること 最初のルートで、どこまでの道を確認するかを決めます。未確認の区間を候補へ出す場合の扱いも定めます。 具体例と、気を付けること トレイル途中の鑑賞する地点は、道のどの位置に結び付くかを持たせます。道を分割・修正したら参照も移行し、古い地点が失われないようにします。移動時間は向き・傾斜・歩行条件で変わり、GPSの一回の記録を標準時間にしません。
公共交通は別の接続区間として、停留所・乗降・乗換・待ち時間・時刻表の基準日を扱います。取得していないの時刻を架空に補わず、検証した静的目安から始め、必要なら利用条件を確認した交通データへつなぎます。
行きたい場所を、実際に巡れる順番にする 行程には移動だけでなく待ち時間や滞在も入れ、最終受付に間に合うかを確かめます。 入口どうしを結ぶ 移動と滞在を時間内に収める
行程には移動だけでなく待ち時間や滞在も入れ、最終受付に間に合うかを確かめます。 こう記録する案です ゲストが訪問先を選んだら、出発する場所、使える時間、関心、歩くペースをもとに行程を組みます。移動、待ち時間、現地での滞在、解説、余裕時間を見積もり、営業時間や最終受付、予約の必要性と照合します。難しい組合せには、その理由を添えます。 なぜ必要か 写真で選ぶ楽しさを、実際に案内できる行程へつなぐためです。GPSによる到着案内は、ガイド同行型builderの必須機能にしません。 実装前に決めること 既存builderの訪問先、時間、費用の項目と対応させ、担当者が確認すべき条件を決めます。 具体例と、気を付けること 道の距離・標高、実測所要時間、ガイドが採用する時間見積りを区別します。ガイド同行の可否・ガイドの空き・料金は商品側へ問い合わせる構造にし、「行程候補が成立」「依頼を送った」「予約確定」を分けます。
今回、参照したのはbuilderの検討資料です。稼働中APIや計算処理との互換性を実証したものではありません。解説時間は滞在時間に含むのか別の時間として加えるのかかを定義し、二重加算を避けます。
近くに着いたら知らせ、見る場所は確かめる 大まかな到着はGPSで捉え、塀の内外や近い立ち位置は、必要なら手動やQRで確かめます。 寺の近くで到着候補 庭を見る場所で解説を選ぶ
大まかな到着はGPSで捉え、塀の内外や近い立ち位置は、必要なら手動やQRで確かめます。 こう記録する案です スマホが寺の近くに来たら、まず案内の候補を出します。その後、位置の新しさや誤差、どれだけその場にいたか、歩く順番を見て、適切な案内を選びます。塀の外から入場済みとは判断せず、庭の中の細かな立ち位置は、必要に応じて本人の選択やQRで確かめます。 なぜ必要か 同じ庭の近い立ち位置、塀の外と中、上階と下階をGPSだけで安定して分けることは難しいためです。 実装前に決めること 各地点でどの範囲に反応するか、何をもって到着とするかを決めます。再訪したり、逆順で歩いたり、地点を飛ばしたりした場合も試します。 具体例と、気を付けること 到着ルールには、対象地点・形状・利用ルート／段階・有効な測位条件・競合の優先・再提示条件を持たせます。固定の半径や秒数を根拠なく決めません。同じ解説を位置揺れで繰り返さず、隣の候補と競合したら選択画面へ戻せるようにします。
画面を開いたWeb/PWAでの案内と、画面ロック中の通知は別の実装要件です。PWA化だけで後者を保証しません。ロック中の体験を必須にするなら、ネイティブ機能を使う方式も比較し、OS制約・通知遅延・電池消費を実機で確認します。
解説は、目の前にあるものから始める 立ち位置と視線を解説へ結び付けます。音声を最後まで聞いたことと、理解したことは分けて確かめます。 目の前の庭を見る 見える形から意味を知る
立ち位置と視線を解説へ結び付けます。音声を最後まで聞いたことと、理解したことは分けて確かめます。 こう記録する案です 庭を見ている人には、まず目の前の石や砂、建物との関係を伝えます。そのうえで意味や背景へ進む原稿を作ります。見る対象と立つ場所、見る方向を解説に結び付け、日本語と英語、短い説明と詳しい説明、文章と音声の対応も管理します。 なぜ必要か 専門知識がない人でも、景色→意味→背景の順に理解できるためです。長い知識ノートがあるだけでは、現地の理解を保証しません。 実装前に決めること 最初に何を解説するかを選びます。聞き手の予備知識、言語、説明の長さを想定し、理解できたかをどう確かめるか決めます。 具体例と、気を付けること 基本体験は「立ち止まる→対象を確認する→解説を開く」。歩行中の画面注視や施設内での意図しない大音量を避け、初回の音声再生は本人が開始します。史実・伝承・解釈、根拠と利用権を、原稿と公開確認で分けて扱います。
再生完了率は理解の証拠ではありません。試用時には「何を見て、何を理解したか」を本人の言葉で確かめ、誤解された箇所を原稿・写真・立ち位置のどこで直すか判断します。
圏外になる前に、使う案内を保存する 経路と解説を保存して使います。圏外では新しい閉鎖情報を受け取れない限界も伝えます。 出発前に保存 圏外では最終確認日時を表示
経路と解説を保存して使います。圏外では新しい閉鎖情報を受け取れない限界も伝えます。 こう記録する案です 出発前に、歩く経路、解説、写真や音声、到着を判断する条件をスマホへ保存します。いつの内容か分かるように更新番号も付けます。背景の地図は、端末への保存と配布が認められるものを選びます。案内の利用期限と、通行情報を最後に確認した日時は分けて表示します。 なぜ必要か 山道で通信できないことを前提にする一方、圏外の端末へ新しい閉鎖情報が即時到達するとは約束できません。 実装前に決めること スマホへ保存する範囲と容量を決めます。どの情報をいつ再確認し、古いままならどの案内を止めるかも定めます。 具体例と、気を付けること 取得した内容の期限と、通行情報の新しさは別です。開始前に最新条件を確認し、圏外では最終確認時点を表示します。位置拒否時は手動で使える案内を残します。OSが位置取得を止めている状態の自動到着も保証しません。
有料コンテンツのオフライン利用権の期限と端末の扱いは、販売条件とともに設計します。公開紹介データと有料配信を分け、地理範囲への進入を購入済みの証拠にしません。
行政区と、KETが案内に使う地区を分ける 同じ場所に、行政上の所属とKETの案内上の所属を持たせます。図の区切りは説明用です。 行政区の境界 KETの地区と主な所属
同じ場所に、行政上の所属とKETの案内上の所属を持たせます。図の区切りは説明用です。 こう記録する案です 京都市や行政区の境界は、公的な資料から取り込みます。洛北や洛東などの観光エリアは、KETが何を基準に分けたかを記録します。所属を仮に決めた場所と、確認した境界から所属を求めた場所は、見分けられるようにします。境界を直したときには、以前の区分もたどれます。 なぜ必要か 洛東などの呼称を残しつつ、独自に切った線を公的境界として見せずに済みます。境界変更時も過去の分類をたどれます。 実装前に決めること 既存の五区分を出発点に、主な所属を選ぶ基準、境界、未確定の範囲の見せ方を決めます。地区を加えたり変えたりした場合は、理由と採用の判断を残します。 具体例と、気を付けること 採用案は、施設の主な所属を確認した代表入口などの明示した基準で一つ決め、またがる地区との関係を別に残す方法です。入口やトレイル区間の実所属を親施設に合わせて書き換えません。境界のない地区を地理計算で確定したものとして表示しません。
市域全体の未登録・未確認を可視化し、まず実際に使う地区の境界を作ります。将来は同じ版の地区面の隙間・重なりを点検し、全域を管理できる状態へ広げます。
同じ情報を直す場所は、一つに決める 情報の種類ごとに編集先を決めます。一つのDBへ全部を詰めるのではなく、同じ場所を参照します。 地理・Notion・素材・商品 同じ場所IDでつなぐ
情報の種類ごとに編集先を決めます。一つのDBへ全部を詰めるのではなく、同じ場所を参照します。 こう記録する案です 場所や道は地理データ、学習ノートや原稿はNotion、サイトの紹介文は既存Atlasで編集します。写真や音声の権利は素材の台帳、価格や予約枠は商品・予約の仕組みが受け持ちます。それぞれに共通の場所IDを結び、確認した内容をまとめて各サービスへ渡します。 なぜ必要か 「一つの土台」は、全部を一つのDBへ移す意味ではありません。同じ事実を複数の画面で手入力し直すことをなくします。 実装前に決めること 誰が編集し、誰が内容を確かめ、誰が公開を決めるかを定めます。各保存先をどう接続するかも確認します。 具体例と、気を付けること NotionのDomain・Type・Tags・Parentは維持し、ページIDと場所IDの対応を追加する案です。地域所属の正本をNotionのタグと地理側で二重に編集しません。解説は公開確認時点の本文を固定し、Notionの後日の編集で配信済みの音声と不一致にならないようにします。
配信する内容の目録は、使う場所・道・条件・解説・素材のIDと版を固定します。一般公開用、購入者用、社内用の出力は、この目録から必要な部分だけ生成し、同じ配信版番号を持ちます。全用途へ全情報を配る意味ではありません。
昔の行程を残しながら、今日の閉鎖を知らせる 過去の行程は再現できても、閉じた道を今日歩けるとは案内しません。 保存した行程 現在の閉鎖を優先して照合
過去の行程は再現できても、閉じた道を今日歩けるとは案内しません。 こう記録する案です 保存した行程には、作ったときに使った情報の更新番号を残します。一方、閉鎖や提供停止には、対象の場所・道と有効な期間を記録します。オンラインで行程を作るときや歩き始めるときは、現在の閉鎖情報を優先して確認します。 なぜ必要か 古い旅程を再現できることと、今日そのまま歩けることは別だからです。 実装前に決めること 閉鎖などの変更をどこで受け付け、誰が確かめるかを決めます。確認の頻度と、保存済みの行程へ知らせる方法も定めます。 具体例と、気を付けること 入口変更は新しい位置版を作り、既存ルートの影響対象を抽出します。安全上の閉鎖は通常更新を待たず、該当区間を除外又は保留。解説だけの修正で、道を別に手編集する必要はありません。
旧版は参照できても「現在利用可」とは表示しません。緊急情報を取得できない端末では、最終確認時点と限界を示します。正しい地図が現在の安全を保証するとは扱いません。
Louisの下見と、ゲストの現在地を使い分ける 私生活を含むGPS原本は制限した保存先へ。共通地図には、確認して採用した道や地点だけを渡します。 Louisの下見は確認資料 ゲストの現在地はその場の案内
私生活を含むGPS原本は制限した保存先へ。共通地図には、確認して採用した道や地点だけを渡します。 こう記録する案です Louisが利用を認めた下見の記録は、入口や道を確かめる資料にします。ゲストの現在地は、その場でどの案内を出すか決めるために使い、まずはスマホの中で判断する方法を検討します。同じ座標の形式を使っても、移動履歴を保存する目的や、見せてよい範囲は別です。 なぜ必要か 同じ座標形式を使えても、履歴の保存目的と配信範囲は違います。共通で利用するために私生活の軌跡を移す必要はありません。 実装前に決めること 下見のどの期間、どの記録を使うか確認します。将来ゲストの行動を分析する場合は、その目的と同意、保存期間を別に決めます。 具体例と、気を付けること Traccar、GPXなどの観測を、観測時刻・鮮度・精度・有効性・欠測付きで受け取る入口を用意します。長い欠測を直線で補い、実在する道として採用しません。写真の時刻照合も、撮影者・時差・誤差の確認が必要です。
GPSの元記録は制限された保存先に残し、共通地図には確認して採用した地点・経路だけを登録。正確な公開入口を提供することと、個人の写真のGPSを公開することを分けます。
編集する道具と、情報を届ける仕組みを分ける 作業台、保存先、配信先の役割を分けます。ここに描く道具は採用候補です。 QGISで位置を編集 共有保管から各サービスへ
作業台、保存先、配信先の役割を分けます。ここに描く道具は採用候補です。 こう記録する案です 地図を見ながら編集する道具にはQGIS、共同で保存して位置関係を調べる仕組みにはPostgreSQLとPostGISを候補にします。試作や受渡しにはGeoPackage、Webへ渡す形式にはGeoJSONが使えます。道具を先に決めず、役割と既存システムへの接続を確かめてから選びます。 なぜ必要か ファイルだけの手編集は小さな検証に向く一方、複数用途の権限・版・同時更新は別に設計する必要があります。 実装前に決めること 既存DBで扱えるか、どの程度の負荷と費用になるかを確認します。編集する人の使いやすさと、背景地図の利用条件も比べます。 具体例と、気を付けること PostGISはDBへ地理検索を加える機能です。今すぐ別サーバーを契約する決定ではありません。初期のデータの構造検証をファイルで行っても、共通で利用段階で二重編集する正本にはしません。
背景地図、行政境界、登山道、標高、写真・音声は出典と権利が異なります。閲覧できることと複製・商用利用・オフライン配布できることを分け、供給元ごとに確認します。費用は地図配信、保存、計算、音声制作、現地確認、継続更新に分けて見積もり、金額は未決です。
地域から探しても、地図から選んでも、同じ寺へ進む 一覧、地図、場所のページが同じ場所IDと地域の所属を参照します。 エリアから寺社を探す 紹介ピンと入口を切り替える
一覧、地図、場所のページが同じ場所IDと地域の所属を参照します。 こう記録する案です サイトのエリアページ、地図、寺社の一覧は、同じ地域の所属を使います。どの入口から探しても同じ寺社ページへ進めるように、場所IDと既存URLを対応させます。紹介用のピンと、現地で向かう拝観入口は、目的に応じて表示を分けます。 なぜ必要か 地域ページと地図で寺社の所属が食い違うと、探し方が分断されます。紹介用ピンと、現地で行く入口も用途が異なります。 実装前に決めること 地区の範囲と、地図を開いたときに見せる範囲を決めます。紹介ピンと入口の切替、地域での絞込み、公開する情報も定めます。 具体例と、気を付けること 既存AtlasMapProfileの概略ピンは紹介用として保持。精密な入口は別のWaypointから取得します。地図の初期表示範囲はエリア面や対象地点から生成し、点の座標と混同しません。拡大時の形状を単純化しても、所属判定の正本は変えません。
出力は一般公開可能な場所・文章・形状だけ。購入者用の解説や個人のGPS記録は含めず、公開可否はpublicSafe等の意味を精密な公開入口と両立するよう更新します。未確認の地域や境界は暫定表示にし、確定した地図と区別します。
対象のデータを読み出す処理はatlasQueries.ts・atlasRoutes.ts・atlasMap.ts。新しい正本から旧画面向けデータを生成して移行し、既存slug・IDとページ導線を保持します。確認した版ではDESTINATION_ATLAS_PUBLIC=falseで、地域ページは非公開設定、地図はdev用試作です。ここは将来の公開設計であり、現行の公開機能とは呼びません。
寺院Aを登録すると、何がつながるか 場所・入口・道・立ち位置を別々のIDで結ぶ例です。実在施設の配置や距離ではありません。 寺院Aと拝観入口 庭の立ち位置と解説
場所・入口・道・立ち位置を別々のIDで結ぶ例です。実在施設の配置や距離ではありません。 以下は、寺院Aを例にした記録の見本です。IDも説明用に付けたもので、実際の座標や所要時間、経路を登録したものではありません。
記録 持つ内容 結び付く先
場所 place-A 寺院A、別名、施設情報、主な所属、確認状態 既存AtlasのID、Notionページ、商品スポット 地点 point-A-entry 拝観入口、位置の根拠、目印 場所Aと接続する道 道 path-01 分岐から入口までの形状、方向、時間根拠、通行条件 始点・終点のID、途中の鑑賞する地点 地点 point-A-view 立ち位置、見る対象、方向、現地確認 庭園、解説、必要時の到着ルール 解説 guide-A 日英の原稿版、短い／詳しい説明、音声版、権利 鑑賞地点、内容の根拠、利用可能商品 行程 route-01 道の順序と向き、滞在時間、選択した解説 共通配信版、商品側の提供条件
一か所だけ入口を修正 したら、サイトの入口表示、builderの接続、セルフガイドの到着対象が、次の配信版で同じ位置版を参照する。これが共通で利用できたかの確認になります。公開紹介ピンまで入口へ強制的に動かす必要はありません。
実際に使えるか、六つの場面で確かめる 以下は、これから試すための案です。誰が、何件を、どれだけの期間で試し、どの結果なら次へ進むかは、開始前に決めます。データがつながることと、ゲストが理解し満足すること、商品に需要があることは、別々に確かめます。
T01 / 提案・未着手
一度の更新が三つの用途に渡るか 一度直した入口が、三つの画面で同じ位置になるか。 一度直した入口が、三つの画面で同じ位置になるか。 確かめたいこと 同じ登録から出力できれば、サービス別の転記をなくせる。 試し方 入口位置、地区境界と所属、閉鎖条件、解説を各正本で一度ずつ更新し、新しい配信版から三つの用途の試作を生成する。閉鎖条件は地理データの保存先内の運用条件記録に置き、開始前に受付・確認担当を割り当てる。 見るところ 共通ID・版、サイトのエリアページ／地図／一覧、builderの候補所属、セルフガイドの地域表示を照合。境界版・所属の一致、転記回数、参照先が見つからない記録、旧旅程の再現と現在閉鎖の優先も確認。 結果を見て決めること 各用途が同じ更新版を参照し、二度目の手編集が不要なら共通で利用成立。個別の修正が必要なら範囲を広げず、データの構造か変換を直す。 T02 / 提案・未着手
場所と道は、現地の動きに合うか 現地で曲がれない交点を、曲がれる道にしていないか。 現地で曲がれない交点を、曲がれる道にしていないか。 確かめたいこと 確認の根拠がある位置と接続を使えば、入口違いや通れない近道を避けられる。 試し方 選んだ実在ルートで入口・分岐・道を資料と下見で照合し、橋の上下・逆向き・閉鎖の試作も確認する。 見るところ 入口の一致、接続の正しさ、位置誤差の記録、距離・標高の算出根拠、利用可否と未確認区間。 結果を見て決めること 対象ルートの接続が一致し、閉鎖や未確認を利用可と誤認しなければ次へ。地図の見栄えだけでは合格にしない。 T03 / 提案・未着手
スマホは適切な場所で案内できるか 塀の外、位置の揺れ、逆順でも、意図した案内を選べるか。 塀の外、位置の揺れ、逆順でも、意図した案内を選べるか。 確かめたいこと 大まかな到着判定と地点選択を組み合わせれば、近接地点でも誤解説を抑えられる。 試し方 対象のiPhone・Androidで、進入・位置揺れ・逆順・再訪・通信断・権限拒否・画面ロックを現地で試す。 見るところ 誤提示、見逃し、通知遅延、手動での復帰、電池影響。OS／ブラウザ／アプリ方式ごとに記録。 結果を見て決めること 開始前に合意した許容値で判定。細地点が成立しなければ手動／QRへ、ロック中が成立しなければ方式か約束を変える。 T04 / 提案・未着手
解説で、見ているものを理解できるか ゲストが実物を指し、自分の言葉で意味を説明できるか。 ゲストが実物を指し、自分の言葉で意味を説明できるか。 確かめたいこと 対象と立ち位置を明確にした解説なら、事前知識がないゲストも景色と意味を結び付けられる。 試し方 前提知識の異なる試用者に、実物を見ながら対象言語の解説を使ってもらい、自分の言葉で意味を説明してもらう。 見るところ 見る対象を特定できたか、理解した内容、誤解の箇所、長さと操作負担。 結果を見て決めること 狙った核心を理解できたかを、事前に定めた観察基準で判断。再生完了や好意的感想だけで合格にしない。 T05 / 提案・未着手
builderの行程が、時間と提供範囲に収まるか 移動と滞在を足した行程が、受付時間内に収まるか。 移動と滞在を足した行程が、受付時間内に収まるか。 確かめたいこと 入口間の移動と施設条件を使えば、選択変更後も成立理由を説明できる。 試し方 訪問先の追加・削除・逆順・交通変更、最終受付超過、未知の営業条件を含む候補を組み立て、担当が根拠と実地時間を照合する。 見るところ 移動／待ち／滞在の内訳、費用の参照先、不可・要確認の理由、提供可否。 結果を見て決めること 不可を可として出さず、時間や費用の二重計上がなく、商品側の確認へ接続できれば次へ。見積りを予約確定とは表示しない。 T06 / 提案・未着手
公開範囲と更新を、二人で維持できるか 社内のGPSや未公開原稿が、ゲストの画面へ出ていないか。 社内のGPSや未公開原稿が、ゲストの画面へ出ていないか。 確かめたいこと 情報ごとに正本と担当を決めれば、私有情報を混ぜず、営業・閉鎖変更を追える。 試し方 未購入・購入者・社内の出力を比べ、個人のGPS記録混入、未公開原稿、有料配信の認可、期限切れ、担当引継ぎを確認する。 見るところ 誤配信、確認待ち項目、更新に必要な手数・時間、見落とした変更と原因。 結果を見て決めること 見せてはいけない情報の配信やGPS混入は修正してから提供。更新負担が大きければ公開対象や道具を絞り、無人で維持できるとは見なさない。 作る順序と、先へ進む条件 登録件数より、同じ情報が実際に使えるかを先に確かめます。 一つのルートで試す 三用途と現地で確認して広げる
登録件数より、同じ情報が実際に使えるかを先に確かめます。
対象と共通のデータ仕様を決める 場所・地点・道・エリア・解説・行程の意味、ID、公開範囲、版を定義。既存データとの対応表を用意する。次の条件：三つの用途に必要な情報がデータの構造に入り、価格・予約や個人履歴との責任境界が明確。 京都市の土台と、一つのルートを登録する 市域と行政区、寺社の候補台帳、既存エリアを重ねる。対象ルートの入口・分岐・鑑賞地点・道・解説を確認する。次の条件：対象区間の根拠と未確認が見える。全市の候補・未登録・位置確認・案内利用可を区別できる。 三つの用途へ試しに出力する サイトの地域表示、builderの行程試作、スマホの案内試作を同じ配信版から生成する。次の条件：T01・T02・T05・T06の関連検証で、転記・参照ずれ・見せてはいけない情報の配信が残らない。 現地体験を確かめる 実機で到着案内を試し、実物と解説が結び付くかを見る。提供条件・問い合わせ・更新方法も確定する。次の条件：T03・T04と必要な再検証で提供方法を選べる。販売は規則・権利・料金条件を確認してから別途判断。 地区ごとに広げる 登録漏れと境界を点検し、更新にかかる時間を見て対象を拡大する。次の条件：未確認範囲を隠さず、二人で維持可能な規模であること。京都市全域の精密化を初期開発の前提にしない。 今、決める順番 位置を使う体験を先に決め、それに合う道具と費用を選びます。 画面を開いた案内 ロック中の通知は方式を比較
位置を使う体験を先に決め、それに合う道具と費用を選びます。 提供体験の線引き。 セルフガイドで画面ロック中の到着通知まで必須か。データデータの構造は両方式へ対応させ、初期試作では開いた画面で成立を確かめる案。最初の対象。 現行の案内経験があり、寺院の入口・鑑賞地点・屋外の分岐を含む一つのルートを選ぶ。具体名や採用範囲は未決。エリアの試案。 既存の五区分と地区を地図へ重ね、境界で迷う場所から検討する。呼称だけを先に全件へ付けない。運用と費用。 正本を編集する担当、確認・公開の担当、更新時間と利用条件を決めてから、保管・地図配信の道具を採用する。これらは実装を始める前の判断候補。今回、Louis・古荘の合意済みの決定として記録したものではありません。
他の方法と比べ、なぜこの案か 方法 利点 今回の目的に対する限界 Notionだけで管理 知識と分類をすぐ整理できる 道の接続、地理計算、到着判定の共通正本には不足 一つの地図ファイルだけで管理 個人の編集・初期試作に軽い 権限・版・複数用途の配信運用を別途設計する必要 アプリ別の台帳 各アプリを独立に作りやすい 同じ入口・地区・閉鎖情報を複数回直すことになる 共通の意味とID＋用途別出力 三つの用途と社内知識を、同じ場所に結べる 最初に記録の境界・更新責任・配信契約をそろえる必要
既存Atlasとの対応を、消さずに作る 既存の紹介文や導線を残し、概略ピンを精密な入口へ読み替えないように移行します。 既存AtlasのIDとURL 新しい地理情報へ対応させる
既存の紹介文や導線を残し、概略ピンを精密な入口へ読み替えないように移行します。 確認したrepository版はf6f4ffa。五大エリアは全件decided、地区にはdecidedとdraft-onlyが混在します。これは既存の編集状態であり、新しい境界の測量・確定まで済んだという意味ではありません。
今あるもの 共通基盤での扱い 残す情報 major / middle area KET観光エリアの親子へ対応。枠の決定状態と境界の確認状態を分ける ID・slug・親・sortOrder・status・紹介文 uji-extension 洛南の市外拡張という既存関係を保持し、京都市外の行政所属を別に持つ draft-only状態、平等院などの参照。市内境界に宇治を含めない spot 場所IDへ対応。寺社以外の市場・街路・御所・街区も対象に含む 既存ID・URL、種別、priority・status・sourceNotes 概略mapProfile サイト紹介用プロフィールとして残す publicSafeの保護。入口・実経路へ読み替えない headline / summary / role / whyMatters / routeLogic 掲載用編集文はAtlasの既存コンテンツを編集正本にする Notionは学習・原稿本文。根拠へ参照し、同じ掲載本文を二重編集しない access / photoPlan / sourceNotes等 access内の地理・運用事実は移行時に共通記録へ分離し参照生成。写真計画・編集状態はAtlas側に残す 一項目ずつ対応を確認し、旧フィールドの意味と固有情報を落とさない
切替前の確認対象 npm run check:destination-atlas-dataと、atlasQueries.ts・atlasRoutes.ts・atlasMap.ts、/dev/destination-atlas/mapの参照を新データの構造へ対応。ID・URL・親・表示順・公開状態・写真GPS保護と、今回の精密な入口・境界の契約を検証します。データを登録しただけで公開フラグを有効にせず、サイト公開は別途承認します。
現在は五区分を保つ案ですが、ゼロベース検討で変更が必要と判明した場合は、理由・担当者との採用判断・日付・旧新対応を残します。既存decidedを無断で未決へ書き換える操作はしません。
既存資料との関係と、まだ確かめていないこと 既存Atlasは、移行元として生かす 参照した仕様には安定ID、五大エリアと地区、概略表示点、個人の写真GPSの分離があります。一方、「現段階では複雑なGIS・経路エンジンを作らない」という従来段階の範囲もあります。
新要件はその範囲を越えるため、採用するなら同じ仕様を更新します。概略ピンを入口に読み替えず、既存ID・URLと共通場所IDの対応を残し、旧画面向けデータを生成してから切り替える案です。
移行で守るもの 既存のID、slug、親参照、表示順、紹介内容、写真GPS非公開。旧データ契約の検査と、地図・一覧・ページのデータを読み出す処理を新データの構造に合わせて更新し、新旧参照の一致を確認してから編集元を切り替えます。今回、その変更はしていません。
builderとは、共通化と商品範囲を分ける 既存検討資料は、写真で場所を選び、公共交通を含む移動・滞在・総時間・費用を見ながら、ガイド同行の貸切ツアーへつなぐ構想です。セルフガイドは、そのbuilderの既存商品範囲には含まれていません。
本案は両商品を合併する提案ではなく、同じ地理情報を使えるようにする提案です。既存コード・APIとの接続や、実際のゲスト利用は未検証です。
参照資料・技術の確認先 GPSの運用経路はKET内部のTraccar運用資料を参照しました。個人の接続情報はここへ掲載しません。Notionの構造はこの会話で共有された情報を保持する設計で、今回liveの全ページ・プロパティを再取得してはいません。
トレイルの照合先は京都一周トレイル等の公式案内、府・市の通行情報、地形図と現地確認を候補にします。比叡山・大津などへ市境をまたぐ経路も、共通IDと行政所属で保持でき、京都市内へ座標を押し込めません。今回は経路の収集・通行確認は未実施です。
この資料の機能・方式は設計提案です。各製品の採用可否、実機挙動、利用許諾をこの資料で実証したものではありません。GPSの元の履歴は今回取得していません。
この資料の現在地 この資料には、会話で求められた三つの使い方と、それを実現するための設計案をまとめています。どの情報を記録するかだけでなく、誰が更新し、どう届け、何を試してから次へ進むかまで記しました。設計案は、まだ採用や実装が決まったものではありません。
今後の合意は「対象の論点／採用・修正・保留／理由／次に確かめること」として、この資料へ追記する想定です。静的HTMLなので、ブラウザでの入力は保存されません。
これは設計を相談するための資料です。現在地の取得や予約、入力の保存は動きません。図は仕組みを説明するために描いたもので、実測した位置や確定した境界ではありません。道具も採用前の候補です。
全体像と共通構造 具体化・検証ノート URLを知る人が閲覧できる共有版。個人の位置履歴・社内の接続情報は含めていません。