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

Add csv output support to NACCulator #126

Open
s-emerson opened this issue Jan 21, 2022 · 1 comment
Open

Add csv output support to NACCulator #126

s-emerson opened this issue Jan 21, 2022 · 1 comment

Comments

@s-emerson
Copy link
Contributor

From Ben Keller at NACC:
And, finally, we have an internal request to change nacculator so that it generates CSV. One of our developers was going to look into this, but maybe someone there could do it faster. This comes from Janene Hubbard who consults with people dealing with the fixed width fields.

NACCulator's default output is in fixed-width .txt format to account for NACC's standard submission format. They have requested that NACCulator have the option to output to .csv format instead. An example of what this output could look like is given in the NACC quarterly data freezes, where each participant has a separate row for each visit event. Right now, REDCap exports use separate columns for the variables in different visit events using prefixes (fu_ for the followup packet and tele_ for the telephone followup packet, for example). The new csv option for NACCulator would essentially remove the prefixes from the REDCap export and combine the "separate" columns for the same variable into one column. So, for example, mocacomp, fu_mocacomp, tele_mocacomp, and tip_mocacomp would all be combined under the "mocacomp" column, with each value belonging in a different row depending on visit number.

@michael-bentz
Copy link
Contributor

michael-bentz commented Jan 5, 2023

Thoughts on how to output to csv

  • we need an extensive list of all keys (headers are different for every type of form)
  • we can't use records, we can't use a single form or single packet because they don't hold header information
  • might be able to reverse engineer set_blanks_to_zero or set_zeros_to_blanks because they contain the logic to apply the correct fixed width

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

No branches or pull requests

2 participants