(日本語概要V2)本リポジトリは、愛知県阿久比町のコミュニティバス「アグピー号」を対象に、GTFS の shapes.txt を実際の道路形状に沿って生成・補正し、より正確な GTFS フィード(feed_version 5.0)を構築する R スクリプト(make_complete_feed.R、基本パッケージのみで動作)を提供するものである。あわせて、生成した経路形状を国土地理院タイル上で対話的に可視化し Shapefile として保存するツールと、shape_dist_traveled により車両位置を経路上で内挿した知多半島5事業者の時空間シミュレーター用データを収録しており、設定パラメータを変えるだけで全国の自治体の GTFS データに対応できる。 V2.3では、乗車中にブラウザ上でGPS座標を記録し、標準的なGPX形式で書き出すウェブアプリ(gpxlogger_app_ja.R、gpxlogger_app_en.R)を追加した。測位時刻の採用、1秒間隔への間引き、測位精度(accuracy)のGPXへの記録、取得エラーのメタデータへの埋め込みといった改良を実地の走行ログをもとに施しており、名古屋市営バスの一路線を全区間乗車した63.5分・3,774点のログを動作例として同梱している。なおGPXファイルは特定の運行の詳細を指し示すため、日付は2026-04-01に変更してマスクしており(時刻は実測値、取得は2026年度の平日)、本データはGTFSデータ作成の研究を目的として公開するものである。 (日本語概要V1.2)本スクリプトは、公共交通のオープンデータ形式である GTFS の shapes.txt を R で読み込み、国土地理院タイルを背景とした対話的な地図上に路線形状を可視化するツールである。カラーバリアフリー対応の単色表示に対応しており、GIS ソフトで利用可能な Shapefile 形式への変換・保存も可能である。設定パラメータを変更するだけで全国の自治体の GTFS データに対応でき、東浦町・知多市の GTFS データで動作確認済みである。 このツールの開発には Anthropic の Claude (claude.ai)とGemini をコード支援として使用しました。 This repository provides tools for generating and validating GTFS shapes.txt for community bus services in Japan, developed around the Agui Town (Aichi Prefecture) community bus "Agupii-go." The associated preprint — a Data Descriptor documenting both workflows, the complete corrected GTFS feed (feed_version 5.0), and a pre-registered field validation protocol — is available on SSRN: https://ssrn.com/abstract=7105058 Version 2.3 Updated Version 2.3 adds a browser-based GPS logger (gpxlogger_app_ja.R, gpxlogger_app_en.R) that records coordinates during a ride and exports them as a standard GPX file, together with a field-tested log and screenshots of the application in use. The two source files are functionally identical; they differ only in interface language and in the default base map (GSI tiles for the Japanese edition, OpenStreetMap for the English one, since GSI tiles cover Japan only). The logger was rewritten after examining an earlier field log. It now timestamps each point with the fix time reported by the Geolocation API rather than the event delivery time, throttles recording to one point per second, and writes the reported positional accuracy into the GPX element. Geolocation errors are logged and embedded in the GPX metadata, so that gaps in a track can be attributed either to a failed fix or to a suspended recording. The Wake Lock API keeps the screen active while logging, and the reset control is guarded by an interlock and a confirmation dialog. The included log (gps_log_higashi_junkai_masked.gpx) was recorded over a complete circular route of the Nagoya City Bus network: 63.5 minutes, 3,774 points, with a median reported accuracy of 8 m and one-second intervals maintained throughout. It demonstrates that the workflow holds for a run longer than the services examined in Agui Town. The shapes.txt derived from it was checked against official stop coordinates and against the Ministry of Land, Infrastructure, Transport and Tourism bus route data; those results are reported in the associated manuscript rather than deposited here, as this repository remains centred on Agui Town. Because a trajectory identifies a particular vehicle run, the calendar date has been replaced with the placeholder 2026-04-01; times of day are as observed. The log was recorded on a weekday in Japanese fiscal year 2026. The route was ridden end to end, so the track represents the line itself rather than an individual journey. Version 2.2 Updated Version 2.2 adds the Agupii-go layer of a five-operator space-time transit simulator for the Chita Peninsula region: a per-minute vehicle-trajectory dataset (agui_trajectories_light.csv), the corresponding route polylines (agui_routes_light.csv), and the reproducible generation script (make_agui_sim_data.R, base R only) that derives both from the corrected GTFS feed (feed_version 5.0) in this record. Compared with the previous simulator data (built on the V4.3 feed), this version makes three improvements. First, vehicle positions are now interpolated along the shape geometry via shape_dist_traveled rather than as straight lines between stops, so vehicles are rendered on actual roads (verified: all generated positions lie on their shapes). Second, it fixes a double-counting defect in the previous trajectory data, which emitted two rows per trip at every stop-boundary minute and inflated the on-screen simultaneous-vehicle totals; the new data contains exactly one row per trip per minute. Third, the corrected terminal stops of trips 108 and 207 (feed V5.0) are reflected. In addition, a full cross-check of every trip against the operator's official printed timetable (https://www.town.agui.lg.jp/cmsfiles/contents/0000003/3892/busjikoku.pdf) revealed that nearly all trips end with a final arrival at Agui-ekimae, printed below a thick rule (interpretable as a repositioning movement on which passengers may remain aboard and alight), and that trip 101 performs an additional station loop (Agui-ekimae → Miyazuyamada-iriguchi → Miyazu Danchi → Agui-ekimae). These station-return legs are included in the trajectory data as an interim extension: they are drawn along existing shape corridors traversed in reverse (real roads), except the short Esperansu-Maruyama → Agui-ekimae leg, which is temporarily rendered as a straight line. A future version will incorporate these arrivals into the GTFS feed itself (as stop_times entries with pickup_type=1 / drop_off_type=0, expressing the thick-rule semantics in standard GTFS vocabulary) together with regenerated shapes, after which the interim extension block will be removed. Version 2.1 Updated Version 2.1 adds a complete, corrected GTFS feed for the Agupii-go community bus (nine files, feed_version 5.0, distributed as output_agui_gtfs.zip), together with a reproducible R script (make_complete_feed.R, base R only, no external packages) that builds the feed from the previously published V4.3 GTFS files (see the predecessor record, DOI: 10.5281/zenodo.20575685) combined with this repository's network-based shapes.txt and shape_index.csv. The script performs four groups of corrections: (1) it reassigns per-trip shape_id values so that each of the ten distinct stop patterns — including two loop-direction variants of the same stop set and short-turn services — references its correct geometry, and adds direction_id; (2) it resolves duplicate stop_id entries in stops.txt (143 rows reduced to 77 unique stops), selecting among conflicting coordinates by a deterministic nearest-to-shape rule; (3) it appends the missing terminal stops of trips 108 (Fukuzumien-Takadai-Minami) and 207 (Shinden-mae), identified by cross-checking the feed against the operator's official printed timetable; and (4) it adds route_color, agency_lang, and a newly created feed_info.txt (a GTFS-JP required file), and extends the service period to cover all listed calendar exceptions. All corrections are recorded as data inside the script, so the feed can be regenerated deterministically from the inputs. The published output_agui_gtfs.zip was verified to be byte-identical to the script's output in an independent environment. Zenodo record v2.1 corresponds to GTFS feed_version 5.0; this record now supersedes the GTFS files in the predecessor record, which is frozen as the dataset accompanying its SSRN preprint. Version 2.0 Updated Version 2.0 adds a network-based method for generating shapes.txt directly from openly published bus-stop coordinates and timetable data, without requiring a GPS survey. Stop-to-stop paths are derived as shortest paths over a road-network graph built from MLIT's National Land Numerical Information bus-route data (N07), with stops snapped onto the network. An optional via.csv file lets users correct segments — such as one-way turnaround loops with no intermediate stop — where the shortest path deviates from the actual route; this correction mechanism, and its rationale, is a general-purpose addition intended to be reusable for other municipalities. To our knowledge, this is among the first published, reusable methods for generating GTFS shapes from open bus-stop and timetable data alone, offering a resource-free alternative for small municipal bus operators that cannot afford a dedicated GPS survey. Both an R implementation (make_shapes.R, using igraph) and a Python implementation (make_shapes.py, using networkx) are provided, following the same algorithm and producing the same output format. During development, the two implementations were confirmed to produce byte-identical output on the author's environment (R 4.3.3 / Python 3.12, Linux); this was a one-time developer-side check, and the Python version has not been independently re-verified by the author since. Users of the Python script are encouraged to compare its output against the R version's shapes.txt in their own environment before relying on it. Quantitative validation is planned as future work: on-board GPS ride logs will be acquired on all Agupii-go routes using the logging application in this repository and compared against the network-based shapes; the logs and results will be added in a future version. Full usage instructions, input/output specifications, and the via.csv format are documented as comments at the top of each script (make_shapes.R, make_shapes.py, make_map.R). Note on file naming: As of v2.0, the files shapes.txt and shape_index.csv in this repository refer to the network-based method described above. The v1.2 fieldwork GPS log (gps_log_20260620_004858.gpx) and its generation script (V1_2_gpx_to_gtfs_shapes.R) remain available; the GPS-derived shapes.txt can be regenerated from them at any time. Earlier versions (v1.0–v1.2): This tool reads GTFS shapes.txt, a standard open data format for public transportation, using R, and visualizes route shapes on an interactive map with the Geospatial Information Authority of Japan (GSI) tiles as a background. It supports color-barrier-free single-color display and can convert and save data in Shapefile format for use in GIS software. By modifying the configuration parameters, the tool is compatible with GTFS data from municipalities across Japan, and has been tested with GTFS data from Higashiura Town and Chita City. Version 1.1 added a web-based application that enables users to reliably record GPS coordinates in real time during field surveys and export them as standard GPX logs, so that post-fieldwork logs can be visualized together with GTFS spatial routes (shapes.txt) for desktop review. Live demo: https://moteki.shinyapps.io/gpxlog/ Version 1.2 added a streamlined workflow to automatically generate GTFS shapes.txt from raw GPX logs, enabling direct creation of high-precision spatial routes through actual passenger tracking on community buses. Additionally, the dynamic GPS visualization script was updated to align with rail transport characteristics for realistic train operation simulation. By incorporating a sequential velocity-based filtering algorithm, this version efficiently filters out instantaneous GPS jump coordinates caused by multipath errors to ensure smooth, unidirectional track rendering. The interface was further refined with standardized English controls and a locked 500-millisecond refresh cycle, delivering a highly stable, artifact-free desktop playback experience for rigorous transport analysis. Live demo: https://moteki.shinyapps.io/gps_player/ AI disclosure: This work was developed interactively via claude.ai, using Anthropic's Claude and Google's Gemini across versions. For v2.0 specifically: code development (the R and Python shapes.txt generation scripts, the map-visualization script, and the via.csv correction mechanism) was carried out using Claude Fable 5; this documentation was prepared using Claude Sonnet 5.