Specification Clarification for node_id and zone_id in node.csv

[asu-trans-ai-lab]

We need to discuss the detailed specifications for node_id and zone_id in node.csv. Specifically, node_id should be an integer, as demonstrated in the standard sample data sets:
https://github.com/zephyr-data-specs/GMNS/blob/main/examples/Lima/GMNS/node.csv

Currently, the specification lists the type as "any," which can cause confusion. Additionally, zone_id might be mistakenly treated as a string or float type, introducing unnecessary complexities for different packages.

See
https://github.com/zephyr-data-specs/GMNS/blob/main/spec/node.schema.json

"fields": [
{
"name": "node_id",
"type": "any",
"description": "Primary key",
"constraints": {
"required": true
}
},

This ambiguity could have downstream implications for from_node_id and to_node_id in the link schema:
https://github.com/zephyr-data-specs/GMNS/blob/main/spec/link.schema.json
To avoid these issues, we should standardize node_id and zone_id as integers in the specifications.

[ssmith55]

In allowing node_id and link_id to be unique ints or strings, we were following the example of GTFS unique_ID. See ID
in https://gtfs.org/schedule/reference/#field-types . An application can certainly further restrict these id fields to be integers. In any event, I would want us to be consistent across all of the ID fields (not just node and zone). Would be happy to discuss further. And, I suppose we could add a note for users to the effect that "some applications require these ID fields to be integers" We can also fork a developmental version where all of the IDs are large integers.

Thank you for the feedback - Scott