Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cube Export to OMX #2

Open
danielsclint opened this issue May 14, 2019 · 4 comments
Open

Cube Export to OMX #2

danielsclint opened this issue May 14, 2019 · 4 comments
Assignees
Labels

Comments

@danielsclint
Copy link
Contributor

After #1, create a Cube export script to export the necessary skims to OMX. A sample script is available on the OMX project site.

@danielsclint
Copy link
Contributor Author

If would be really cool to use the skim manifest file from #1 to iterate through the exports. This would eliminate duplicate naming of the skim files in the scripts making updates easier and less error prone.

@sidharthanr
Copy link
Member

I was able to use the sample script linked above to export the Cube skim to OMX skim. One highway skim with three core took 1.75 minute. Cube 6.4.3 was needed as mentioned in the page (did not work in Cube 6.4.2).
I am thinking of writing a Python script to read the manifest file and write a Cube script to export all the skims, similar to what is done in SFCTA CHAMP model. Any suggestions?

@danielsclint
Copy link
Contributor Author

I don't really like building scripts dynamically unless absolutely necessary. They are really hard to debug and test. Here are two ideas, I don't know if either would work, but consider evaluating before going down the dynamic scripting:

  1. Read in the manifest csv in Cube script and iterate over it in Cube. I know reading a CSV in Cube is a pain, but it would save you from a dynamic script.

  2. I don't have the Cube documentation, but take a look at Blocks sections in the cube scripting. Here is an example of blocks in the MTC transit assignment that I did last year. Could you create a master script and just build dynamically the pieces you need?

If these options are not plausible, then go down the dynamic scripting route. I could also be missing something, so feel free to share the SFCTA script too.

@sidharthanr
Copy link
Member

Okay, I will try approach #1, reading directly in a Cube script.
SFCTA CHAMP controls everything from Python, so it is a different approach. Here is a sample script.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants