zephyr-data-specs / gmns Goto Github PK

Currently the only link attributes that can vary by TOD are allowed_uses and toll: suggest allowing parking, free_speed and capacity to vary by TOD as well.
Also I'm wondering it would not be more consistent with the overall data structure strategy to associate one TOD "card" or "record" (not sure what we're calling these...) with a single attribute that can be specified as a variable, rather than having the card/record format explicitly include all of the attributes that are allowed to change by TOD.

This could be handled as a distinct entry within the signal phase, e.g. a separate list of right-turn-on-red movements (or separate state to distinguish from those that have green); or, more commonly, it is a single tag associated with the movement, and the actual phases in which the movement has this state is determined via logical rules embedded in the modeling software.

@ianberg-volpe

1. Line 31, don't need to import numpy
2. I tested it on bounding box, via
   G_up = ox.graph_from_bbox(42.367,42.361,-71.081,-71.09,network_type='drive') #Kendall Square area of Cambridge, MA
   Suggest adding this line then commenting it out, as an example.
3. Output coordinates. Nodes use lat long, while Geometry uses UTM. Can we make them the same?
   Thanks.

Should be a list of possible values: protected, permitted, etc.

node table uses zone

location uses zone_id

Be consistent about definition and naming.

Make all file names lower case. Matches what GTFS does

PMC Members,

Per the proposed rules in our draft GMNS Governance document, PMC members are asked to indicate their support or opposition to a proposed action, in this case, acceptance of the PR for GMNS v0.90, which is described here:

#40

As this is a code change, lazy approval by the PMC is required.

Lazy approval means that the change is implicitly allowed unless a “-1” PMC vote is received, at which time, depending on the type of action, either lazy majority or consensus approval must be obtained. No quorum is required.

As PMC members you may indicate your position in the following ways

• +1 = "Yes," "Agree," or "the action should be performed."

• -1 = “No,” “Disagree,” or “the action should not be performed.” On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action.

• Abstain = PMC members can abstain from voting. They can either remain silent or express their reason.

PMC members you have one week to vote (by end of day Monday 8/31, Anywhere on Earth), if you so choose. If additional time is needed, please indicate.

Thanks,

Joe

For example, in link_tod:

• would we have multiple entries for each link_id, and time of day for each allowed_uses?
• how would I define an HOT lane?

This is to provide greater consistency with the representation of lines in the link and geometry tables. Instead of x_coord, y_coord, z_coord, one would have
POINT (x_coord, y_coord) or
POINT Z (x_coord, y_coord, z_coord)

Furthermore, wkt provides an option for linear references
POINT M (x_coord, y_coord, lr) or
POINT ZM (x_coord, y_coord, z_coord, lr)

Do PMC members think this change would provide significant benefit?

The initial requirements for GMNS did not resolve the question of tagged vs. delimited format. GMNS Is currently using a delimited format, with well-known text (WKT) for geometry information. Some applications may prefer a delimited format (geojson).

Basic conversions of the link and node tables were tested using QGIS. The process is straightforward: export the layers in question as geojson. Other tools may also exist.

Is the primary key phase_id? Right now this is listed as a foreign key

Question:

• I couldn't find an issue or discussion item where it was decided to change the field names to be abbreviations? What is the thinking behind this?

There are some plusses and minuses:

For Abbrvs:

• can potentially fit things into DBFs, cube, and other places with limits on spaces
• fewer characters to write

Against Abbvs:

• hard to remember which way abrr things (or is that Abbv?)
• less legible
• creates inconsistencies across other formats (i.e. osm, shared streets, etc)

1. it is confusing what it is.
2. what if you have multiple?

GMNS currently uses two data elements to represent a undivided road:

• a pair of road_links, one for each direction, which contain information needed for routing (e.g,, from_node_id, to_node_id, capacity)
• a physical link, which has the length and shape points for the road.
  It may easier for some software packages to have both the shapepoints and the routing information in the same object. Can we do this efficiently without duplicating shapepoints?

For example: If I have a gtfs_stop_id that is at an intersection. Do I have to create a location entry in addition to the node?

It seems like there should be some consistency between the various intersecting files and therefore if it is defined in a "sub file" (i.e. lane or tod) then it should be defined in the base.

Therefore, toll should probably be in the link file

Pertaining to #30, in addition to a primary key, specify what the assumed unique combination of other values exists (i.e. link_id, time of day, allowed uses)

I've been writing some code to be able to validate and process GMNS data as well as writing the spec as a json csv spec per the @frictionlessdata table-schema. In working with the spec a little the biggest issue I see at the moment is the unnecessary duplication of "link" infrastructure between the offroad and road links and the inability to connect it in a one-to-one fashion.

Below is an (incomplete) example of a small grid with offstreet links (red dotted) for walkways and road links (blue). While this may seem duplicative when you can associate a 'sidewalk' with a road link, this is, in fact, the way much of the open street map network is coded in downtown areas...and this is what the network will look like in packages like OSMNX when imported (at least for A and B). There are separate links in the network graph created for each place that the road link intersects the offroad link.

Relationship between links
There is potentially a complex relationship between the offroad links and the onroad links (assoc_road_link_id) as well as offroad links and nodes (assoc_node_id), but I would assume that link 3-->5 would be associated with A-->C and 6-->7 would be associated with A-->B?

I would propose that this relationship need not be exclusive to offroad links and that in fact there may be road links you may want to associate together as well as road nodes that you may want to associate together. I propose the following:

1. offroad and road links and nodes combined into a single table
2. nodes can have 'parent' nodes (this is how GTFS deals with "stops" being part of "stations" and would work for crosswalks too.
3. links can have 'parent' links (will work well for HOV lanes that are separate links)

Is it possible to leave the filed 'end_lr' empty (or other marks) if a segment reaches the end of the corresponding link. In the current definition, each segment has a 'start_lr' and a 'end_lr', which may cause some issues and bring extra checking efforts in certain cases.

For example, in the Small_Network_Examples/Arlington_Signals, the 'end_lr' of segment 5 and 6 are both 300. However, the length of the corresponding link (link_id 31) is 330 from the link.csv file. Based on the definition, the link return back to 2 lanes in 300-330, which may be wrong. Therefore, extra checking efforts are needed in this case.

Hi ya'll,
I wrote out some things that I think will be useful in this repo: https://github.com/e-lo/GMNSpy

In the /spec directory I wrote out the GMNS "spec" as json files similar to the frictionlessdata data table spec and the jsondata spec which enables:
(A) programatic validation including foreign keys; and
(B) auto documentation of the spec which makes sure the documentation is always consistent with the code

There are still plenty of issues and only a basic set of tests, but I think this could be a useful building block.

You can install the latest version from PyPi using pip install gmnspy

LMK what you all think and what you'd like to see!

The lr field in the location table is ambiguous about if it is using link geometry or not.

Suggest: if link_geometry exists, it is used. Otherwise, link geometry is assumed to be a crow-fly distance from A node to B node.

Note: this issue also exists in the segment table.

PMC Members,

Per the proposed rules in our draft GMNS Governance document, PMC members are asked to indicate their support or opposition to a proposed action, in this case, acceptance of the PR for GMNS v0.92, which is described here:

#50

As this is a code change, lazy approval by the PMC is required.

Lazy approval means that the change is implicitly allowed unless a “-1” PMC vote is received, at which time, depending on the type of action, either lazy majority or consensus approval must be obtained. No quorum is required.

As PMC members you may indicate your position in the following ways

+1 = "Yes," "Agree," or "the action should be performed."

-1 = “No,” “Disagree,” or “the action should not be performed.” On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action.

Abstain = PMC members can abstain from voting. They can either remain silent or express their reason.

PMC members will have one week to vote (by end of day Thursday 7/1/2021, Anywhere on Earth), if you so choose. If additional time is needed, please indicate.

Thanks,

Joe

Movements are currently identified either by
mvmt_id - a unique key for the table
combination of ib_link_id and type (e.g., left)

The request is to add a field, mvmt_txt_id (e.g., SBL for southbound left). This field, when combined with the node_id, would provide a third unique identifier, and will match common practice in other applications, such as Synchro.

Proposed syntax would be DDTN, where DD is the direction (e.g., SB, NB, EB, WB, NE, NW, SE, SW). T is the turning movement (e.g., R, L, T) and N is an optional turning movement number (e.g., distinguishing between bearing right and a sharp right at a 6-way intersection)

Templates are helpful for helping organize development from many parties and providing consistent, comprehensive documentation about why, how, etc.

Here is a collection of many to start from: https://github.com/stevemao/github-issue-templates

I (@e-lo ) am happy to implement if given go-ahead by community.

PMC Members,

Per the proposed rules in our draft GMNS Governance document, PMC members are asked to indicate their support or opposition to a proposed action, in this case, acceptance of the PR for GMNS v0.93, which is described here:

#54

As this is a code change, lazy approval by the PMC is required.

Lazy approval means that the change is implicitly allowed unless a “-1” PMC vote is received, at which time, depending on the type of action, either lazy majority or consensus approval must be obtained. No quorum is required.

As PMC members you may indicate your position in the following ways

+1 = "Yes," "Agree," or "the action should be performed."

-1 = “No,” “Disagree,” or “the action should not be performed.” On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action.

Abstain = PMC members can abstain from voting. They can either remain silent or express their reason.

PMC members will have one week to vote (by end of day Wednesday 7/13/2022, Anywhere on Earth), if you so choose. If additional time is needed, please indicate.

Thanks,

Joe

Per the current location table, x_coord and y_coord can be derived from the Link, Ref_Node and LR.

This sets up the potential for having duplicative/conflicting information.

• If x_coord and y_coord are provided...should they be checked against this?
• If conflicting, which should govern?

Suggest deleting x_coord and y_coord or including them as placeholders for calculated values.

definition of "ib_lane" is "Uses lane number"; whereas "ob_lane" is "Uses lane numbers or ranges of numbers"
ib_lane should have the same definition as ob_lane, i.e. support a range of lanes
Also: should indicate the accepted formats for specifying a range of lanes, e.g. "1-3" vs. "1,2,3", etc...

Right now the schema itself is only defined in the wiki. I am suggesting that we define it in 'code' for the following reasons:

1. It is what most other data standards are doing,
2. It make evaluating changes and observing change history and versioning very obvious and straightforward
3. it makes approvals and reviews using pull-requests a lot easier

Modern controllers support more than one configuration whereas the current GNMS specification assumes that there is only one arrangement possible at any given node.
So basically this data structure needs a name or some other identifier other than the node ID itself (which can then be used to refer to it in a "signal timing plan").

The free_speed field in the link specification has the following schema:

"name": "free_speed",
            "type": "integer",
            "description": "Optional. Free flow speed mph",

If GMNS is to be used more generally, this specification is too restrictive. Networks located in countries using the metric system cannot follows this specification (integer speeds in km/h become decimal numbers in mph).

As a solution, I would propose to leave the option to express speeds in km/h. Of course, the length field should then also be expressed in km instead of miles.

In creating a validator or trying to "mesh together" a complete time of day picture, it is really difficult to deal with multiple time of day representation.

Suggest using the time set definitions because they are clearly all defined in a single place and easily understood which ones come together to form a complete calendar.

Using a single representation also eliminates problems that are often caused with conditional requirements.

In order to limit the number of representations of the same thing, suggest limiting the location type (loc_type) in the location table to open street map map feature names...or at least strongly suggest using them.

timeday_set as defined in the wiki make a lot of sense, but requires parsing in order to be legible or useful.

e.g. Monday-Friday 0700-0900 would be 01111100_0700_0900

Suggest an optional time_set_definitions file that would allow using legible names for timeday_set and have each of the information in the variable set name split out into a variable, i.e.

• name (str): legible, i.e. AM Peak
• abbr (str):
• set_id (str): the original timeday_set definition
• holiday
• start_time
• end_time
  etc.

This will also make it easier to translate from GMNS to a static network variable that might vary over time, such as LANES_AM which could be a concatenation of the variable and the time period abbreviation.

Hi,

I stumbled across this repository looking for open data about traffic signal timing. I think the GMNS spec is the first specification I've found. I'm working on a traffic simulation tool called A/B Street. Part of this work has been surveying traffic signals around Seattle and representing the phases in a format referencing OpenStreetMap objects. This example file corresponds to the attached screenshot. The format is defined here, and this doc has more context on the format. A/B Street includes a UI for easily reconfiguring signals; this video demos this (but note the UI has been improved a bit since then).

I'm not totally sure what the goals of GMNS are, but I'm very interested in open data standards for traffic signals, and I have lots of existing code for editing, visualizing, and simulating signal timing. If there's any collaboration that makes sense, let me know!

Thanks,
-Dustin

In order to reduce the number of things that need to be changed when the number of lanes change, suggest making the capacity field in links per lane.

When trying out @e-lo's GMNSpy (#34), I noticed that we have some enums that are in uppercase (allowed uses: SHOULDER, PARKING, WALK, ALL, BIKE, AUTO, HOV2, HOV3, TRUCK, BUS), and lowercase (parking: unknown, none, parallel, angle, other).

One additional attribute that would help complete the currently supported functionality/options is an indicator of whether the offset is measured to the start or the end of the "coord_phase"; both (start and end) are used in different situations

There are required variables in Use Definitions which describe vehicle characteristics which do not necessarily nest within the 'use'.

Specifically, I am thinking of the persons_per_vehicle and pce:

Suggest:

1. separating out vehicle information from use requirements information (or at least making it optional, with a blank invoking some default)
2. allowing uses or use groups to have "AND" "OR" or "NOT" designations (i.e. all bikes but for class 3 e-bikes)

Use requirements are things like:

• max weight
• public transit vehicles
• TNC vehicles and taxis
• commercial vehicles
• minimum pax #

Vehicle information is for differentiating:

• articulated bus
• delivery van
• semi
• electric cargo bike
• electric roadsters

PMC Members,

Per the proposed rules in our draft GMNS Governance document, PMC members are asked to indicate their support or opposition to a proposed action, in this case, acceptance of the PR for GMNS v0.85, which is described here:

https://github.com/zephyr-data-specs/GMNS/pull/17

As this is a code change, lazy approval by the PMC is required.

Lazy approval means that the change is implicitly allowed unless a “-1” PMC vote is received, at which time, depending on the type of action, either lazy majority or consensus approval must be obtained. No quorum is required.

As PMC members you may indicate your position in the following ways

• +1 = "Yes," "Agree," or "the action should be performed."

• -1 = “No,” “Disagree,” or “the action should not be performed.” On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action.

• Abstain = PMC members can abstain from voting. They can either remain silent or express their reason.

PMC members you have one week to vote (by end of day Monday 5/18, Anywhere on Earth), if you so choose. If additional time is needed, please indicate.

Thanks,

Joe

A single signal phase is currently defined as a list of individual cards/records, one for each turning movement. For simplicity -- and ease of eventual validation -- it would be more practical to have a variable-length list indicating all the turning movements associated (having green) with a single phase.

Several places there are not units specified. Default units should be specified:

i.e. width in Lanes should probably be specified as feet

This may be more of a question rather than an issue as its about clarifying specific requirements. I haven’t found any discussion on this question in the documentation so thought I should bring it up.
There are 2 distinct approaches for link shape and each has implications for the spatial information associated with nodes. In the higher level, i.e. somewhat simplified approach, link shape is defined as a center line that connects 2 nodes and nodes are represented as points. In this approach its typical for 2 opposing links to share the same shape points. Road width is not explicit in the shape data (though it could be an attribute of a link), and exact road location is collapsed laterally to an idealized center line. This is convenient for visualizing the network and has enough information for static assignment and some meso models.
The other representation, which is required for micro modelling and some meso models, requires explicit road width and the actual alignment of the road, i.e. offset from the idealized center line (in fact there is no idealized center line, just the exact location of each directional roadway). In this case the link shape no longer aligns with a single idealized center point of the node (and nodes do not generally need an idealized center point). Network representation in navigational data sets (TomTom, HERE) have this level of detail. In this approach, an intersection “node” in the usual sense is a group of intersection points since these offset links will intersect at distinct points inside the intersection area.
With this level of information, traffic simulation software can derive distinct physical geometry for individual lanes and is also able to identify the relative positions of roads that arrive to a node parallel to each other (but with different lateral offset); e.g. freeway ramps vs. mainline freeway lanes. Complex intersections have similar cases. This also touches on the question of whether turn “channels” at intersections are represented explicitly as links or implicitly as attributes.
So the question is whether link shape data in GNMS is intended to reflect an idealized centerline that connects idealized center points of nodes, or whether it represents the actual position of the roadway (and thus a node represents a group of intersection points). In the former case, the simplification would make it logical to allow for multiple links to share the same shape data – e.g. opposing links, and also parallel links, though in the latter case some indication of lateral offset would be necessary. The chosen approach will also impact what levels of modeling (macro/meso/micro) the specification is currently able to support.

Will enable display of movements in a zoomed-in GIS map

Will facilitate multi-modal movements through an intersection (e.g., bicycles using their own phase)

I'd like to flag what I think is a significant drawback of the current data mode for time of day variable. Specifically, I have found it frustrating that:

1. a simple change by time of day requires many entries, and
2. the same table could use a variety of foreign keys which depend on the entry; this makes merge and joins.

I propose that we have the following model to make simple things simple:

link can be overridden by link_tod which can be augmented by link_lanes_tod

• link is treated like the default for the whole day; link_tod has the same attributes as link with the addition of a time of day. This allows simple changes in lanes, tolls or restrictions by time of day to only have one additional table.
• link_lanes_tod specifies changes to certain lanes by time of day with the assumption that the rest remain as they were. This allows a lane restriction to occur on a single lane without having to specify it for the rest of the lanes (assuming there are no restrictions).

Anything in a link can be overridden by a segment file.

link can be overridden by segment
link_tod can be overridden by segment_tod
link_lanes_tod can be overridden by_ segment_lanes_tod

Only meso/micro models will need to specify segments (likely) so you wont make simple merges between macro-scale data more complicated by having to do conditional joins depending on segments vs links.

Currently only "allowed_uses" can vary by TOD: suggest allowing capacity to vary by TOD as well.
In addition, "ib_lane" and "ob_lane" can vary by TOD in some situations: in some cases this may be "derived" information, e.g. lane usage changes in time, but I'm not sure if it can be assumed that all cases would fall under this category.

PMC Members,

Per the proposed rules in our draft GMNS Governance document, PMC members are asked to indicate their support or opposition to a proposed action, in this case, acceptance of the PR for GMNS v0.91, which is described here:

#45

As this is a code change, lazy approval by the PMC is required.

Lazy approval means that the change is implicitly allowed unless a “-1” PMC vote is received, at which time, depending on the type of action, either lazy majority or consensus approval must be obtained. No quorum is required.

As PMC members you may indicate your position in the following ways

+1 = "Yes," "Agree," or "the action should be performed."

-1 = “No,” “Disagree,” or “the action should not be performed.” On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action.

Abstain = PMC members can abstain from voting. They can either remain silent or express their reason.

Due to the holidays, PMC members will have two weeks to vote (by end of day Thursday 1/7/2021, Anywhere on Earth), if you so choose. If additional time is needed, please indicate.

Thanks,

Joe

This is missing the position of the phase on the ring (currently just refers to the ring and the barrier).

The specification for now has no information about movement priority, other than the use of Movement "ctrl_type" to indicate stop and yield.
So, this assumes that any other information about priority, e.g. a left-turn at a signalized intersection that must yield to the opposing traffic, is implicit: i.e. its the same in all networks that this specification is intended to serve. That might be a bit limiting, but perhaps ok for now.
For micro-sim applications there are "gap acceptance" parameters which may vary from location to location and in some cases are adjusted as part of the model calibration. These may be structured in different ways in terms of how defaults are defined (e.g. "left from major street" vs. "left from minor street" for two-way stops).
At the most dis-aggregate level this requires attributes specified for individual pairs of conflicting movements; though it may be sufficient to stick with general categories (like the examples above) which can be modified / over-ridden at individual nodes or movements. Needs discussion.
These categories would have default values which motivates a larger number of categories for "ctrl_type", e.g. so that for different yield cases: e.g. arterial turn channel vs. freeway merge vs. roundabout can have different defaults.