-
Notifications
You must be signed in to change notification settings - Fork 13
Meeting Notes
Billy Charlton edited this page Nov 2, 2023
·
12 revisions
- Navigation is not great. Need home, way to get back. PAVE has scenarios along the top and detail picker on the left like Covid-sim.
- Having a configurable top-bar would be nice
- Panels all run together, the top borders don't separate things enough. Visually overwhelming
- Use color and contrast instead of underlines to delineate separate panels
- But Billy notes KN's dashboard with several one-column CSV outputs in his BENE dashboard. Make sure that doesn't get broken
- PAVE carousel: to better wrangle the wall of twenty pie charts. Perhaps with left-side picker instead of next/prev buttons
- KPI panel: PAVE did this, can we combine panels in an uber-panel? With a joint heading?
- Full-page mode instead of scrollable main content panel. As an option.
Goal: We want to create a clear roadmap of how Viz works at VSP and for MATSim beyond. Two clear use cases have emerged: curated project websites, and analysis of scenarios/runs during project development.
About creating dashboards:
- R script creates a general dashboard, but it isn't very useful
- Namav project (and others) have their own R scripts which use the MATSim-R library but do their own things
- Many people would like a Java-based MATSim Contrib which produces SimWrapper outputs "ready to go"
- KN has previously warned to "never trust an analysis you didn't write yourself" hence no one uses the Analysis contrib
- KN also would like a general MATSim dashboard, and has asked for this many times over many years!
- Non-VSP users of MATSim likely do not even know about MATSim-R
About using SimWrapper generally:
- Configuration is inconsistent across plugins, docs are not great, and implementation is buggy
- The plots are not labeled very explicitly -- what are we actually viewing when we look at "Mode Choice" etc. The details are hidden.
- Interactive use is very difficult compared to desktop software; theoretically simple things e.g. dragging network files onto a map don't work, for example
About developing the product:
- Billy as the Bottleneck In Chief
- Development has always followed the needs of individual projects, instead of following a roadmap:
- Original code from Covid-sim
- which was modified to support PAVE and AVOEV
- Then the SimWrapper general site was built with for Hamburg and KomoD:next specifically
- Then SFCTA/ActivitySim funded specific improvements to Shapefile and file management
- This "random walk" did not result in a clean implementation
And yet, the promise is there and people want SimWrapper to be useful and to succeed. So how do we get there?
- simwrapper folders and hierarchy of runs
- outward facing vs... internal debugging
1) The R library
- Someone (TBD) will refactor the MATSim-R code to produce a small set of useful simwrapper dashboard tabs
- Moritz/Johanna/Tilmann?
- That should be based on the example bar/line/area charts that are already there
- Clean up / prune the extraneous code
- Consider splitting MATSim-R into an R library that people can use in the IDE interactively; and a simwrapper-dashboard creator
2) the MATSim SimWrapper Contrib
- There was not a lot of enthusiasm for the contrib in the meeting, but Christian and Billy both agree this is still important. SimWrapper needs to be well-integrated with MATSim.
- Thought experiment: if the core R SimWrapper library code is actually not that much code (and task 1 above will clean up it greatly), then the equivalent code in Java is also likely not going to be huge. And might be easier to integrate and easier to get uptake from the team! So this is still a worthy task.
- Obviously projects can use the MATSim-R library too! For now, "yes to everything".
3) File storage / layout / of runs
- Existing runs on public-svn are not really simwrapper-ready
- Not helpful for comparisons
- Once we have a decent basic dashboard we will revisit this -- perhaps running the dashboard script on all the public-svn run folders, etc
- Comparison mode needs some real design
- Let's save this for the next meeting
Billy is going to do a big bugfixing spree to try and get SW 2.x back into working shape; SFCTA and others have found a lot of bugs in the latest release.
Johanna and Friedrich are getting feedback from SHKs and staff (although lots of people are away on vacation right now).
Feedback so far includes:
- Documentation is incomplete and in some cases outdated.
- We need better examples
- Confusion about what files can be opened: network files MUST be be
output_network*etc.
Johanna and I had a discussion about the "filename-based" approach of SimWrapper; this works great for us nerds, but end users are really not used to this.
- File name extensions usually specify what the type of a file is, but that just Does Not Work for us: all matsim outputs end in
.xml.gzregardless of their content; likewise.csvfiles are CSVs, but what is actually inside them? Coordinates? Etc? - It might be possible to read the header or first lines of an XML file to augur its content type. Inefficient but better than filename-based?
- Drag/drop files into the file viewer to trigger this explore-mode? That's how VIA does it, but even VIA doesn't know what a file is until you tell it.
To be addressed in the roadmap:
- Focused feedback from users: VSP internal and external users (SFCTA, SANDAG, WSP, Sydney)
- Improved example data
- Redesign front page (at least) to be more inviting to new users, and more useful for existing users
- "Professionalize" the tool. Now that SW 2.0 is out, we have time to fix some regressions and also address some longstanding shortcomings:
- new testing framework and test-data for its use
- improve documentation for beginners instead of just API reference
- consistency: look at YAMLs "holistically" and try to align everything. Things like filters, column selection, etc, are not 100% consistent and that's really confusing users
- componentize internal plugins: shapefile viewer especially is enormous and needs refactoring. Unit testing beforehand so we don't have regressions!
- The official MATSim run dashboard: the R script works but no one is using it. Why not, are the summaries not useful, or is the R language the barrier? Could we instead have a simwrapper "contrib" written in Java that does essentially the same thing but is part of a standard (Java) MATSim run?
- Staffing. VSP should consider adding another student assistant to help with the JavaScript front-end code