Provided list of initial interviewees, schedule, and early feedback on the process
Reflections
Scheduling challenges
Sending topics in advance was helpful to interviewees
Too early to report any themes
Consensus reached that WSP should continue current approach
Non-consortium interviews have been very helpful
Marty and Ben’s perspectives and ideas were very different
Up to 6 sounds like a reasonable number of non-consortium interviewees
Check back in in about 2 weeks with feedback from interviews to date
Establish 3 visions (inward facing)
Objectives
The objectives will set the roadmap to those visions, which would include the product and project management, for example.
Currently working on 9-10 objectives that WSP can present at a future update.
Behavioral representations
Software
Issues Review
Issue 640: maz_to_maz tables potentially cause duplicate index key error in los.py when using zero-based zone_id setting
Issue related to some original code that was developed as a hacky solution.
Resolving this issue is necessary to keep legacy code functional.
Pull request forced 64-bit integer format, but then this fix causes problems later on.
Jeff is working on a fix to make this work with/without sharrow, multiprocessing, etc. This hasn’t been resolved yet, but he is working on it. ETA is approximately a week but unsure.
Lessons learned: try not to hack things with original code and instead utilize generalized/standard libraries. These tools are used by many other people for various application and leads to more robust solutions instead of building something on our own that just fixes one thing which could break later on under different circumstances.
Issue 658: home_is_rural appears incorrectly defined in MTC example (and others)
This issue led the consortium to consider if they are in the business of building the infrastructure but not validating the details/implementation?
Issue created to let others know this is an issue in the example, so they know it’s not necessarily correct.
There is likely a simple fix but haven’t landed on or implemented a solution.
Implication is that this can vary from region to region.
This might be a good example of something that an input checker could address.
Next steps: Assign to Lisa this issue
Lisa Zorn (MTC) would be willing to investigate if this is an error or not. (ARC’s area types go up to 7 so this could be where the variable came from and it’s not a mistake.)
Issue 656: tot_tours Hidden in Non-Mandatory Tour Frequency Code
This issue is an example of not great programming, where the creation of a variable is buried in the code. Suggestion that this should be moved to be user-defined in the alternatives file by adding a total tours in the alternatives as a new column in the file instead of code that calculates it.
This is being computed within the code but there is an opportunity for someone to create a variable that uses that name and then it gets written over. There’s not a process that prevents this.
On the flip side, there’s a possibility of user error for someone to not update this field correctly, if moved to alternatives file.
*** Next steps**: RSG to make a change, but a solution wasn't established by the end of the meeting. Some considerations included:
Suggestion to make the variable more descriptive, not just tot_tours – but that’s more work.
Potential for people to not see that there is a change required to the spec file.
Make sure this change is included in the Release Notes.
Better to make it crash, with a good crash note, so that it forces people to change their spec file to make it compatible with the release.