Skip to content

Conversation

@aclarry
Copy link
Member

@aclarry aclarry commented Oct 6, 2025

Extract routines from network package methods to support reading standalone network transaction files.

Tested on existing network packages.

Extract logic to read base network transaction out of the method to read
base network from a Network Package.

This exposes a new routine to read a standalone base network transaction
file, which the routine to read from a Network Package piggybacking off
it.
Extract logic to read extra attributes files out of Network Package
routines, creating new routines to read basic extra attributes export
files which the Network Package routines piggyback off of.
@aclarry aclarry requested a review from bccheung October 6, 2025 20:07
@aclarry aclarry self-assigned this Oct 6, 2025
@aclarry
Copy link
Member Author

aclarry commented Oct 6, 2025

@bccheung Note I still need to extract the transit network and transit vehicles reading.

While I do that, I thought I might get your opinion on where these new methods should live. My thought was that maybe they belong in wsp_balsa.routines.io.inro, since they're not really "network package" specific.

@bccheung
Copy link
Member

bccheung commented Oct 6, 2025

@bccheung Note I still need to extract the transit network and transit vehicles reading.

While I do that, I thought I might get your opinion on where these new methods should live. My thought was that maybe they belong in wsp_balsa.routines.io.inro, since they're not really "network package" specific.

It might be worth refactoring the structure. I've already put any AGENT stuff into its own module (agent.py). Maybe it's worth reorganizing things as submodules under something like wsp_balsa.routines.io.emme. For example, the current set of functions in wsp_balsa.routines.io.inro could be moved to wsp_balsa.routines.io.emme.matrix, and the stuff you are working on could be in wsp_balsa.routines.io.emme.network.

We would need to keep some aliases in wsp_balsa.routines.io.inro for backwards compatibility, while also raising a FutureWarning noting that this alias may be removed in future releases.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants