The current zone_id field in node.csv is generated based on activity types and boundary statistics from osm2gmns, and the zone IDs are assigned sequentially. For MPO planning users, they have their own TAZ files or zone centroids. I suggest integrating the taz2zone() from grid2demand function directly into osm2gmns og.generateNodeActivityInfo(net). We can add an additional parameter for zone.csv so that the zone_id in node.csv can be rewritten based on the nearest zone_id, determined by the geometry or point coordinates of each zone. This approach seems the most natural way to complete the function. One can test this feature using the standard Chicago sketch network or the Sioux Falls 24-node network. that is, the Chicago sketch network's zone_id system will be used in the osm2gmns generated node.csv and the readily available demand.csv file from Chicago sketch can be used further traffic assignment.
The current zone_id field in node.csv is generated based on activity types and boundary statistics from osm2gmns, and the zone IDs are assigned sequentially. For MPO planning users, they have their own TAZ files or zone centroids. I suggest integrating the taz2zone() from grid2demand function directly into osm2gmns og.generateNodeActivityInfo(net). We can add an additional parameter for zone.csv so that the zone_id in node.csv can be rewritten based on the nearest zone_id, determined by the geometry or point coordinates of each zone. This approach seems the most natural way to complete the function. One can test this feature using the standard Chicago sketch network or the Sioux Falls 24-node network. that is, the Chicago sketch network's zone_id system will be used in the osm2gmns generated node.csv and the readily available demand.csv file from Chicago sketch can be used further traffic assignment.