{"id":13654279,"url":"https://github.com/zephyr-data-specs/GMNS","last_synced_at":"2025-04-23T08:32:02.731Z","repository":{"id":40684289,"uuid":"232607072","full_name":"zephyr-data-specs/GMNS","owner":"zephyr-data-specs","description":"General Modeling Network Specification","archived":false,"fork":false,"pushed_at":"2025-04-17T18:18:42.000Z","size":42697,"stargazers_count":119,"open_issues_count":18,"forks_count":16,"subscribers_count":12,"default_branch":"main","last_synced_at":"2025-04-18T08:36:45.346Z","etag":null,"topics":["highway-network","network","road-network","specification","transportation-planning"],"latest_commit_sha":null,"homepage":"https://zephyr-data-specs.github.io/GMNS/","language":"Jupyter Notebook","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/zephyr-data-specs.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE-2.0.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2020-01-08T16:29:22.000Z","updated_at":"2025-04-14T10:16:10.000Z","dependencies_parsed_at":"2024-07-28T01:25:33.195Z","dependency_job_id":"26e947c2-ddd1-48e1-a506-3f40f5455de6","html_url":"https://github.com/zephyr-data-specs/GMNS","commit_stats":{"total_commits":438,"total_committers":4,"mean_commits":109.5,"dds":0.5228310502283104,"last_synced_commit":"4f3f31546609fdc23de5957aa169340650b7f905"},"previous_names":[],"tags_count":4,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zephyr-data-specs%2FGMNS","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zephyr-data-specs%2FGMNS/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zephyr-data-specs%2FGMNS/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zephyr-data-specs%2FGMNS/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/zephyr-data-specs","download_url":"https://codeload.github.com/zephyr-data-specs/GMNS/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250399525,"owners_count":21424197,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["highway-network","network","road-network","specification","transportation-planning"],"created_at":"2024-08-02T02:01:26.226Z","updated_at":"2025-04-23T08:31:57.721Z","avatar_url":"https://github.com/zephyr-data-specs.png","language":"Jupyter Notebook","funding_links":[],"categories":["Producing Data","awesome-open-transport","Recently Updated","Planning Data Specifications","Uncategorized"],"sub_categories":["Other multimodal data formats","1. Open Data Standards","[Oct 02, 2024](/content/2024/10/02/README.md)","Transportation","Uncategorized"],"readme":"# General Modeling Network Specification (GMNS) \n\nVolpe/FHWA partnership with [Zephyr Foundation](https://zephyrtransport.org).\n\nThe General Modeling Network Specification (GMNS) defines a common machine (and human) readable format for sharing routable road network files.  It is designed to be used in multi-modal static and dynamic transportation planning and operations models.  \n\nHow do I use GMNS?\n1.  Read the [__specification reference__](spec) to learn about the GMNS format. GMNS is described in json files, and is implementation-agnostic.  A GMNS network might be stored as a series of delimited text files, as a [database](usage/database), or in some other way.   \n2.\tLook at our [__small examples__](examples), including a freeway interchange, a portion of a multimodal city network, and a small city.\n3.\tRead the [__documentation__](https://zephyr-data-specs.github.io/GMNS/), which describes the specification in markdown.  \n4.\tBuild and test your own small network. We have basic tools in Python and R for [__conversion__](usage/conversion) and [__validation__](usage/validation).\n\n[Changelog](docs/changelog.md) for recent releases.  \n\n## GMNS Overview\nVersion 0.96 includes the following features for use in static models:\n-\tConfiguration information and use definitions.\n-\tNode and link files, to establish a routable network. \n\nFor dynamic models, this version includes the following optional additional features:\n-\tA segment file, with information that overrides the characteristics of a portion of a link.  \n-\tA lane file that allocates portions of the right-of-way. Lanes include travel lanes used by motor vehicles. They may also optionally include bike lanes, parking lanes, and shoulders. \n-\tA segment_lane file that specifies additional lanes, dropped lanes, or changes to lane properties on a segment of a link.\n-\tA movement file that specifies how inbound and outbound lanes connect at an intersection\n-\tLink, segment, lane and movement time-of-day (TOD) files, that allocates usage of network elements by time-of-day and day-of-week. \n-\tSignal phase and timing files, for basic implementation of traffic signals.\n\n_Table: Use of the specification in macro, meso and micro models_\n\nComponent of the data specification\t| Macro Models\t| Meso and Micro Models\n--- | --- | --- \nPhysical network elements on the map |\tNodes, links | Nodes, links\nConnecting the elements\t| Nodes and links\t| Movements and lanes\nLink capacity\t| Link capacity\t| Emergent property of lanes and the model used\nIntersection capacity\t| Not considered\t| Emergent property of lanes, movements and traffic controls\nSpeed\t| Link speed\t| Link speed and movement delay\nPedestrian network\t| ped_facility field on the link table\t| ped_facility field on the link table, or separate lanes or links representing the pedestrian facilities\nTraffic controls\t| Node, link, movement\t| Movement and signal tables\nElements that vary by time of day| \tNot used\t| link_TOD, link_lane_TOD, segment_TOD, segment_lane_TOD, movement_TOD\n\n\nMembers of the Zephyr Foundation project, [General Travel Network Data Standard and Tools](https://zephyrtransport.org/projects/2-network-standard-and-tools/), and other interested stakeholders are invited to review and comment on the specification. In developing this specification, we consulted existing open-source specifications, including SharedStreets, OpenDrive, MATSim, Network EXplorer for Traffic Analysis (NEXTA) or DTALite, TRansportation ANalysis SIMulation System (TRANSIMS),  Aequilibrae , Highway Performance Monitoring System (HPMS), All Road Network of Linear Referenced Data (ARNOLD), the Florida Transportation Modeling Portal (FSUTMS), and the Synchro Universal Traffic Data Format (UTDF). \n\n\n## General GMNS Concepts\n### Time of Day\nThere are two parts to implementing a time of day change. First, the default behavior of a link, segment, or lane (how it operates the majority of the time) is recorded on the \"main\" link, segment, or lane tables. Then, [time-of-day](docs/spec/TOD.md) (TOD) tables can be used to modify how the component functions during certain time of day (and day of week) periods. \n\nThe first part is necessary even for components that do not exist outside of a specific time of day. For example, a reversible lane requires two records on the lanes table: one associated with the link it normally moves with, and one with the link in the opposite direction. The allowed_uses field will be None for these non-peak times on the opposite-direction link, but the lane is still necessary so that the TOD attributes can be linked to it. You can find our examples of reversible lanes and other time of day changes [here](examples/TOD_Examples).\n### Difference between Lane Field and Lanes Table\nOn links and segments, there is a field called `lanes`. The number of lanes in the lanes table associated with a link may not always match this value. This  field is maintained for compatibility with static models, where the Lanes table may not be used. Here, it is treated as the number of permanent lanes (not including turn pockets) open to motor vehicles. \n### Inheritance\nMuch of this specification works in terms of inheritance and parent/child relationships. For example, segments (child) inherit attributes from links (parent). To avoid repetitive data, GMNS assumes that attributes left blank on a child are the same as its parent. See the [inheritance relationship chart for more details](spec#inheritance-relationships).\n### Pedestrian Facilities vs Allowed Uses vs Separate Links\nWhether pedestrians are allowed on a link on the network can be represented in multiple ways. The `ped_facility` field in a link or segment describes the type (if any) of built facilities specifically for accommodating pedestrian travel. The `allowed_uses` field is more general and shows if it is possible for a pedestrian to walk along this link. For example, there could be a low-traffic road with no explicit pedestrian facility, but is part of the pedestrian network. For more detailed networks, GMNS also allows undirected links to be used to specifically represent pedestrian facilities, such as sidewalks. \n### Approach to Transit\nWe recommend incorporating GTFS for transit modeling needs. GTFS (General Transit Feed Specification) is a widely used and well-defined specification for transit. GMNS allows [locations](docs/spec/Location.md) that represent transit stops to link to GTFS stops with the `gtfs_stop_id` field and ad hoc fields can always be added to meet your needs. \n\n## FAQ\n### What are the goals of GMNS?\nThe objective of General Modeling Network Specification (GMNS) is to provide a common human and machine readable format for sharing routable road network files. It is designed to be used in multi-resolution and multi-modal static and dynamic transportation planning and operations models. It will facilitate the sharing of tools and data sources by modelers.\nFor additional information on GMNS goals, history and requirements, please see the [wiki](https://github.com/zephyr-data-specs/GMNS/wiki).  \n### What type of system can be represented in GMNS?\nGMNS is made to be flexible, multimodal, and multiresolution. Many of the fields and tables are optional depending on how detailed of information you have for your system. At a high level, GMNS simply models a network of nodes and links. However you can put in as much detail as required by adding lanes, movements, geometry information, etc.  \n### How do I represent geometry shapepoints?\nThere are two ways in GMNS to represent geometry shapepoints for links. Shapepoints can be recorded as well-known text (WKT) in the `geometry` field of the [link table](docs/spec/Link.md) or shapepoints can be placed in the separate [geometry table](docs/spec/Geometry.md) and keyed to the link table through the `geometry_id` field.\n### How do I represent sidewalks?\nIn the [link table](docs/spec/Link.md) there is a field to indicate a pedestrian facility (`ped_facility`). You can also represent the pedestrian network (sidewalks, crosswalks and other paths) as its own network with its own links.  See the [Cambridge example](examples/Cambridge_Intersection).  \n### How do I represent bicycle facilities?\nIn the [link table](docs/spec/Link.md) there is a field to indicate a bicycle facility (`bike_facility`). To represent a bicycle network in more detail, additional options include representing on-road bike lanes as explicit lanes in the [lane table](docs/spec/Lane.md) or representing other bicycle facilities (e.g., shared use paths, separated bike lanes, contra-flow bike lanes) as their own links.    \n### How do I represent street furniture and curbside regulations?\nLocations and segments can be used for purposes like these. The [location table](docs/spec/Location.md) is way to represent point information on a link and the [curb_seg table](docs/spec/Curb_seg.md) or [segment table](docs/spec/Segment.md) can represent information for a portion of a link. Both are defined by a linear reference along a link. Remember, the user may add ad hoc fields to any table in GMNS to represent any type of information that is important to their network.\n### What counts as a lane for the lanes field on a link or segment table?\nOnly vehicle travel lanes traversing the entire link are counted in the `lanes` field in the [link table](docs/spec/Link.md). This may not be the same as the number of associated records in the [lanes table](docs/spec/Lane.md), which can represent lanes of any type, such as bike lanes, shoulders, or reversible lanes (more on reverisble lanes in [our time of day change examples](examples/TOD_Examples).\n### What is needed to define a time-of-day (TOD) change?\nA TOD file can’t exist without the link, lane, segment, etc. having been defined on the base table first. See [time of day, above](#time-of-day). \n### How should I represent transit data in GMNS?\nYou can link a GTFS stop id in the location table. We recommend using GTFS as your primary means of representing transit networks as it is well-established and widely used. For more discussion on the representation of stops in GMNS see [Issue #12](https://github.com/zephyr-data-specs/GMNS/issues/12).\n### Are there standardized values for fields such as node_type and allowed_uses?\nThere are several fields which require a type input, such as `node_type`, where GMNS does not provide a standardized list of values. However, we do recommend using the Open Street Maps (OSM) standards as a guide, particularly [highway features](https://wiki.openstreetmap.org/wiki/Map_Features#Other_highway_features) and [amenities (transportation)](https://wiki.openstreetmap.org/wiki/Key:amenity#Transportation). For more discussion on this see [Issue #10](https://github.com/zephyr-data-specs/GMNS/issues/10). \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzephyr-data-specs%2FGMNS","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fzephyr-data-specs%2FGMNS","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzephyr-data-specs%2FGMNS/lists"}