You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we currently have set up ActivitySim, there are a number of different ways that we have "data dictionaries" that translate coded variables into meaningful names:
Sometimes more than one of these are employed, and sometimes they have conflicting definitions (oof!).
It might be useful to establish a formal expected format of data dictionaries (e.g. a YAML spec), which could be committed directly to version control along with a model definition. This could be useful in (a) automatically validating input data, and (b) constructing visualizations that can be enhanced with meaningful descriptions.
One of the downsides of adding such a formatting spec is that, unless agencies can use this instead of what they do now, it will add an additional layer of things that model developers/editors need to maintain -- or risk getting out of sync and having even more conflicting definitions.
Should we have a formal metadata formatting spec for ActivitySim?
No, existing dictionary systems work fine
0%
Yes, this sounds useful
100%
Yes, and I have a specific proposal for what the format spec should be that I put in the comments below
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
As we currently have set up ActivitySim, there are a number of different ways that we have "data dictionaries" that translate coded variables into meaningful names:
Sometimes more than one of these are employed, and sometimes they have conflicting definitions (oof!).
It might be useful to establish a formal expected format of data dictionaries (e.g. a YAML spec), which could be committed directly to version control along with a model definition. This could be useful in (a) automatically validating input data, and (b) constructing visualizations that can be enhanced with meaningful descriptions.
One of the downsides of adding such a formatting spec is that, unless agencies can use this instead of what they do now, it will add an additional layer of things that model developers/editors need to maintain -- or risk getting out of sync and having even more conflicting definitions.
2 votes ·
Beta Was this translation helpful? Give feedback.
All reactions