Fujimod
Try your camera firmware in the browser and build Fujimod SD boot files.
京都の地下鉄・近鉄・バスを、現在地と公式運行情報から自動で案内する My Map。
Translation pending
LifestyleGitHub @at5tram98-hashOnlineOwner unconfirmed
Have you tried it? One tap is enough. No sign-in needed.
Repository information has not been collected yet.
No updates detected yet. GitHub releases will appear here.
My Map — 京都の乗換案内。Yahoo!検索、定期券、折り返し設定と、ポケロケ・近鉄の公式画面取得/日本語OCRに対応。
Translation pending
Taken from the repository README
Loading the full README.
Read the full README ↗京都市営地下鉄烏丸線・近鉄京都線・京都バス・京都市バスを、公式時刻表、現在地、公式運行情報、利用可能なリアルタイムデータから案内するPWAです。
公開アプリ: https://at5tram98-hash.github.io/kyoto-transit/
公開UIは「今」「検索」「時刻表」「運行情報」「設定」の5タブです。「今」には現在地に応じた次便とコンパクトな検索導線を置き、「検索」では条件指定を含む経路検索を行います。乗車判定、接近表示、定期券、折り返し検索をアプリ内で完結させます。
確認できない時刻・停留所・リアルタイム値を作りません。データの優先順位は、鮮度90秒以内の実測、補正予測、公式時刻表です。時刻表との照合が成立しない到着分数は 時刻未確定 とし、駅数や固定分数から架空の到着時刻を生成しません。
Cloudflare Workerは公式サイトやODPTから取得した情報を正規化し、直近成功値をKVへ保存します。公開リポジトリへ生のGTFS ZIPや秘密鍵は保存しません。
Cron Triggerは 15 * * * * で、毎時15分に1ステップだけ更新します。worker/static-refresh.js の9段階カーソルを順番に進め、通常は約9時間で1巡します。
odpt:kyotobusodpt:citybusodpt:subwaysubway:currentsubway:oppositekintetsu:current:southkintetsu:current:northkintetsu:opposite:southkintetsu:opposite:north主なKVキーは static:<operator>、manual:subway:<pattern>、manual:kintetsu:<pattern>、static:last-refresh です。
ODPT地下鉄GTFSが対象日に有効かつ最近更新されている場合はGTFSを優先します。それ以外は worker/manual-subway-feed.js が京都市交通局の15駅の公式発車表を読み、同方向の時刻を一対一で照合した全線feedを使います。
中間駅へ固定2分刻みの時刻を補いません。終着駅だけは同方向の発車表が存在しないため、直前駅からの2分を導出した場合に meta.terminalArrivalDerived: true を記録します。駅間照合が十分に成立しない場合はfeed生成自体を失敗させます。
クライアントはODPT固有の停留所IDも駅名から内部の Kxx IDへ正規化します。自動乗車判定と「同じ路線の列車」表示は同一の静的feedを使用し、feedがなければ固定駅間時間による代替列車を生成しません。
worker/manual-rail-feed.js が京都〜大和西大寺の公式発車表を取得します。南行25方面、北行25方面の合計50発車表を読み、同じ tx を持つ列車を駅間で結合して平日・土休日の静的feedを生成します。対象は普通・急行で、有料特急等は対象外です。
接近表示は公式列車位置を、同日の静的時刻表の方向・種別・行先・位置・遅延と照合して到着残分を算出します。照合できない列車は位置そのものは表示できますが、駅セル数から所要分数を作らず 時刻未確定 とします。
京都市バスは公式接近画面を直接解析します。停留所ごとの全方面を公式の「全選択」1ページで取得し、方面は公式の行先表記で照合します(運行終了の行、快速系統、英字を含む方面コード、北3にも対応)。公式サイトは正式名(例: 「四条烏丸(地下鉄四条駅)」)でしか系統を返さないため、上流への問い合わせだけ正式名へ変換します。系統一覧は6時間キャッシュし、公式画面と食い違った時だけ取り直します。直近の成功値はCache APIへ毎回、KVへは同じキーにつき5分に1回まで保存します。途中停留所の正確な予定時刻を取得できない便では停留所順だけを表示し、2分刻み等の時刻を補いません。北3は公式の全停留所時刻表を使い、乗車中も各停留所の予定時刻を表示します。
京都バスは公式時刻表に加え、公式「京都バスナビ」の区間接近一覧(/api/kyotobus/approach)から予定時刻・発車予測・到着予測・通過停留所数・のりば・混雑を読みます。乗車判定では予定発車時刻が一致する同じ便の「まもなく発車」を実測根拠とし、乗車中は到着予測と予定の差を遅れとして到着見込みへ反映します(公式予測と表示)。発車後に一覧から消えた場合は最後の公式の遅れを保持します。京都バスの停留所画面(国際会館駅前・京都産業大学前・烏丸丸太町・千本丸太町)では同じ京都バスナビの発車予測を時刻表の上に表示します。40系統は京都産業大学の授業日カレンダー(平日A・平日A水曜=公式の「水曜A」・平日B)、臨時は平日・土曜・休日のダイヤで引きます。公式時刻表ページの取得に失敗した場合は、直近に取得できた同じページの保存版(最長7日、取得時刻を明示)を使います。ODPT_CONSUMER_KEY が設定された環境ではGTFS/GTFS-RT VehiclePosition・TripUpdatesも利用します。キーがない場合はODPTのリアルタイムAPIを安全に503へ落とします。
設定の「自動乗車判定」と「今」の「…」メニューから3つのモードを選べます。FullAutoは乗車の自動判定と便の特定を行い、Autoは接近情報の表示のみ(乗車は手動で選択)、低電力は位置情報を低精度・低頻度(最大60秒間隔)にして自動判定とピクチャインピクチャを止めます。ピクチャインピクチャは利用者の操作でのみ開始し、乗車前は最寄り停留所の接近、乗車中は次の停留所・駅と残り時間を表示します(キャンバスを無音の映像として表示)。
地下鉄は位置情報が取れないため、最後に位置を確認した地下鉄駅を15分間保持し、加速度センサーの「走行・停車」の回数と時刻表から便と現在駅を絞り込みます(停車中の駅から遅れも推定)。確定には車内アナウンス(マイク)などの便を特定できる根拠が必要です。近鉄⇔烏丸線の直通列車は静的時刻表上で竹田を境に分かれているため、北行きは近鉄公式の列車ページの竹田発時刻(なければ一意な候補)で地下鉄の同じ列車へつなぎます。南行きは時刻表で直通を判別できないため、アナウンスの行先・近鉄側の降車駅・竹田手前の確認カードのいずれかで近鉄線へ続けます。
折り返しの反対方向の列車は端末内の地下鉄・近鉄の時刻表から求め(取得できない場合のみ公式の駅時刻表)、開いた時点で「この先の各駅で間に合う最初の反対列車」と「通過した駅へ戻る時刻」をおすすめとして表示します。
系統板は全画面で共通です。京都市バスの循環系統(200番台)は橙、その他の系統は青、京都バスは公式の系統色、地下鉄烏丸線は「K」、近鉄京都線は「B」の路線記号で表示します(public/js/line-badge.js、色は vnext.css の --line-* トークン)。経路詳細は区間ごとに路線色の線、系統・行先・乗車時間・区間運賃を表示します。バス接近の詳細では、路線データの停留所順と公式の「何停留所前」から手前6停留所とバスの位置を示します。方向を行先表記から一意に決められない場合は停留所名を出しません。
通常は公式DOMを直接解析します。市バスまたは近鉄の目的要素が消えた場合だけ、Cloudflare Browser Renderingの構造化視覚抽出をサーバー側で実行します。
視覚抽出の値はそのまま採用しません。駅名、隣接駅、進行方向、停車/駅間、遅延範囲、停留所前数などをコード側で再検証し、条件を満たさない結果は破棄します。視覚抽出も成立しない場合は直近成功値と予測へ切り替え、取得失敗を「運行なし」と解釈しません。診断はKVと隠しログへ記録します。
public/js/search-core.js が静的ダイヤ探索を担当し、public/js/planner-worker.js のModule Web Worker上で実行します。到着時刻指定など探索回数が多い検索でもメインUIを塞がない構成です。検索を中断した場合はWorkerも終了します。
対応条件:
静的feedが未準備の事業者は候補から外し、架空便へフォールバックしません。
端末のGPS軌跡、速度、方位、GPS精度、時刻表、公式列車位置・接近情報、利用可能な車両位置を採点します。時刻表だけでは乗車を確定せず、交通機関固有の移動・方向・位置など複数の根拠が十分に一致した場合だけ自動確定します。差が小さい場合は2〜3候補を提示しますが、候補を1回タップしただけでは乗車状態へ移行しません。便名・行先・判定根拠を確認したうえで「この便に乗車中・案内を開始」を明示的に押した場合だけ手動確定します。
乗り物の速度で移動中(徒歩を除く)かつ時刻表または公式実測の便がある場合は、自動確定せずに「この便に乗りましたか?」と候補を提示します。「乗った便を選ぶ」からは、移動の根拠がなくても最寄り駅・停留所の今の便を一覧し、確認画面で明示的に選べます(ホームや地下でも利用可)。iPhoneのSafariは利用者の操作で許可するまでモーションセンサーを提供しないため、「今」に「モーションセンサーを使う」を表示します。許可はこのボタンからだけ求め、許可済みの端末では次のタップで再有効化します。市バスの実測根拠は接近表示と共有する /api/citybus/arrivals の結果から、同じ系統で行先表記が候補の下流停留所に一致し、1停留所前以内の便だけを採用します。
候補を提示する時は、画面下からせり上がる非モーダルの乗車確認シートに主候補・根拠・別の候補(最大2件)を表示します。シートを上にスワイプする(または「この便で乗車案内を開始」を押す)と乗車案内を開始し、下にスワイプ・「あとで」で3分、「乗車していません」で10分同じ候補を出しません。乗車中・再照合中・ほかのタブでは表示しません。モーションセンサーの許可は、失敗した再有効化を不許可として保存せず、次のタップで再試行します。
乗車中は、電車では車内案内表示器(LCD)風の表示(種別・行先帯、次駅と駅番号、列車マーカーが滑らかに進む次の駅々)、バスでは次の停留所と先の6停留所の時刻付きタイムライン(降車・終点の印付き)に切り替わります。乗車案内の終了はアクションシートで確認し、更新・便の検索などの待ち時間はナビゲーションバー下端の進捗バーで示します。動きを減らす設定ではこれらのアニメーションを止めます。
GPS精度が悪い場合は位置一致の重みを下げます。バスでは次停留所が約220mまで近づいた場合に通知し、終点到着も位置と停止状態から確認します。
「今」は電車・バス・周辺の3状態へ切り替わります。電車とバスの乗車画面は次の停車地点、終点の到着見込み、各駅・停留所の予定と遅れを反映した時刻を表示します。地下で位置情報が途切れた場合も乗車案内を保持し、時刻表からの推定であることを表示します。途中時刻がない市バス便には時刻を補いません。
電車の折り返しは駅から探す方法と好きな反対方向の列車を選ぶ方法を維持しています。終点も選択でき、ホーム移動時間を指定して乗換余裕を確認できます。選択した折り返しは「今」に表示し、乗車中の遅れが変われば余裕も更新します。反対方向の便の全駅時刻を取得できる場合は、実際に乗車した後に同じカードから帰りの乗車案内を開始できます。反対方向の列車の時刻は予定のため、実際の番線・運行状況は駅で確認してください。バス乗車画面には折り返し機能を表示しません。
時刻表の便詳細と経路検索の結果からも「この便に乗車中」で案内を開始できます。検索の到着駅を越えた終点までの時刻を元の公式便から取り直し、遅れを二重加算しません。現在の営業日に利用できる便だけを対象にし、全駅時刻がない便には開始操作を出しません。
乗車中の便・推定遅れ・選んだ折り返しは端末内に保存し、再読み込み後に有効な案内だけを再開します。位置座標やGPS履歴は保存しません。時刻付きの便は到着見込みの30分後、選択中の折り返し列車を待つ場合はその発車5分後、時刻不明の市バス便は開始3時間後を再開期限とします。手動終了した便は再開しません。終点は90秒以上の連続した新しい位置情報と停止状態で確認し、同じ駅での待機を遅れに加算し続けません。
周辺画面では、近くの地下鉄駅の両方面に1時間以内の発車予定を表示します。公式全駅時刻表を共有し、同じ分のGPS更新では予定を再走査しません。通信失敗時は当日分の保存済み時刻表を使い、その旨を表示します。
定期券は設定画面で明示的に有効化した場合だけ追加額へ適用します。
npm ci --ignore-scripts
npm run check
npm test
npm run build
npm run test:browser
npm run test:pwa
npx wrangler deploy --dry-run --config worker/wrangler.jsonc
Node.js 22以上を使用します。ブラウザが未導入の場合は npx playwright install --with-deps chromium webkit を実行します。BROWSER_EXECUTABLE_PATH で既存Chromiumのパスを指定でき、BROWSER_ENGINE=webkit npm run test:browser でWebKitを検証できます。スクリーンショットと結果JSONは既定で /tmp/my-map-browser、BROWSER_ARTIFACT_DIR を指定するとそのディレクトリへ出力します。
CIでは構文、公開UIの旧実装残骸、20秒更新、通信タイムアウト、リアルタイムAPI、地下鉄固定2分ロジックの不在、Module Web Worker探索、視覚フォールバック接続、GTFS、時刻表、乗車判定、運賃、祝日、予測復旧などを回帰テストします。公開前にChromiumとWebKitで320〜1280pxの明暗両テーマ、乗車画面、折り返し、通信競合、キャッシュ、PWAを検証し、スクリーンショットを保存します。ブラウザ検証の運行データは固定フィクスチャで、公式サイトの実運行情報の可用性・正確さを保証するものではありません。
Workerの STOP_NAMES が未設定の場合は同梱の市バス停留所カタログから対象を検証します。明示した配列(またはJSON配列)の設定があれば、その制限を優先します。
ODPT_CONSUMER_KEY はWorker secretとしてのみ登録します。未設定環境では京都バスのODPT GTFS/GTFS-RT実取得だけが無効で、それ以外の機能はキーを捏造せず安全に動作します。
mainへの反映後、GitHub Pagesのワークフローが自動テスト・Chromium/WebKit検証を通過してからサイトを公開します。Workerに変更がある場合は別の Cloudflare Worker公開 ワークフローが既存の my-map-capture を更新します。Worker公開にはリポジトリのGitHub Actions secretsに CLOUDFLARE_API_TOKEN が必要です。複数アカウントを持つ場合やトークンでアカウント一覧を取得できない場合は CLOUDFLARE_ACCOUNT_ID も設定します。トークンは対象アカウントのWorkers Scripts編集・KV編集など必要な公開権限に限定し、コードやログに値を記録しません。既存Workerの変数・secret・KVを維持します。
npm run verify:production は設定を変更せず、公開HTML・Service Worker・乗車画面のファイルの版と、本番WorkerのBrowser Rendering/KV、公開元に対するCORS、当日の地下鉄全駅時刻表・発車表、市バス接近情報と近鉄列車位置を読み取ります。ODPTキーが設定済みの場合は京都バスの実測も確認します。確認結果は /tmp/my-map-browser/production-report.json に保存します。別の環境は APP_URL、CAPTURE_API_URL、APP_ORIGIN で指定できます。Pages公開後のCIは EXPECTED_BUILD_VERSION も指定し、今回公開した版が配信されていることを確認します。接続確認の失敗時は公開済みサイトとは別のジョブに原因を記録します。
npm run verify:all-providers は任意連携も必須として検証します。京都バスODPT未設定は blocked_external を記録して失敗終了し、公式時刻表fallbackで実測確認を代替しません。キーは有効なものをWorker secretに登録し、ソース・チャット・ログに記載しません。全仕様の実装と実機受入の状態は 78節の対応表 を参照してください。
表示言語は「設定 → 表示 / アクセシビリティ → 言語」から日本語・Englishを選択できます。操作表示を切り替えても旅程と保存設定を保持します。公式の未翻訳駅名・停留所名・運行お知らせは原文を表示します。
npm run test:pwa はGitHub Pagesと同じ /kyoto-transit/ 配下で複数の版と複数のウィンドウを動かし、更新待ち、選択後の乗車・折り返し復元、古いウィンドウのモジュール、オフライン再読み込み、未知の版の拒否、取得失敗時の旧版維持を実ブラウザで検証します。通信断はテストサーバーが接続を切断して再現し、未保存のURLに接続できないことも確認します。CIはChromiumとWebKitの両方でこの検証を実行します。
PWA検証の運行APIは、別の公開元のHTTPサーバーが固定データを返します。Service Workerの通信もHTTP経路で検証し、CORSの公開元を確認します。テストで配信するモジュールのAPI接続先だけを置換し、本番の接続先は変更しません。
更新ボタンのない旧公開版の sw.js?v=... 登録は、完全なファイル保存が成功してから新版へ移行します。起動処理は安定したURLへの切り替えと再読み込みを完了してからアプリのモジュールを読み込み、旧版のキャッシュとの混在を防ぎます。その後の更新は利用者の操作で行います。画面読み込みは導入済みの完全なアプリを即座に表示し、新版の取得は並行して行います。旧公開版のService Workerを使った移行と圧縮配信もPWA検証に含めます。
保存されていない版のモジュールにはHTTP 410を返します。別の版を代わりに渡さず、通常のHTTPエラーとして扱うことで、更新確認が続けられることもPWA検証で確認します。
クラウド環境の通信制限で本番Workerにアクセスできない場合、接続確認は blocked を記録して失敗として終了します。固定データのブラウザ検証の成功を本番データの確認として扱いません。