shiny app for populating metadata files

[aurielfournier]

I'm starting to work on a shiny app to take the generated metadata templates and make them such that a user who does not know R, can populate them with the needed details.

[aurielfournier]

#27 we now have a shiny app that allows the user to fill in some of the cells and write out a file.

[aurielfournier]

But we need to make it so that it writes out a .csv

Right now it does ASCII and RDS.

[khondula]

for bounding box/spatial coverage, mapedit might be useful https://www.r-spatial.org/r/2017/06/09/mapedit_0-2-0.html to create a new spatial extent, or display a bounding box based on min/max coordinates in the dataset

[aurielfournier]

@khondula would that be for a shiny app for users to define their bounding box? Instead of entering the numeric values?

[aurielfournier]

It now outputs a .csv file of the populated attributes.csv metadata file.

Next up is the biblio, access and creators.csv apps.

this could be done with a tabbed shiny app or four separate apps.

[aurielfournier]

#36 #38 #35 creates the new shiny apps for creator, biblio, access shiny apps

[aurielfournier]

Next step would be bringing all of these together into one app.

[khondula]

I think these functions might need to be added to the namespace?

would that be for a shiny app for users to define their bounding box?

@aurielfournier yes, maybe showing them what the bounds are if they have coordinates entered (so they can confirm no silly lat/lon errors), or if they don't know coordinates they can draw a box like on http://geojson.io/

[aurielfournier]

Gotcha! I can work on the bounding box as well.

And yes, you are right, I forgot to add them. Will work on it shortly

[khondula]

might be good to coordinate with @amoeba re: #41

[amoeba]

Sounds good @aurielfournier @khondula!

[amoeba]

I just ran through these and they look great @aurielfournier! I'm so glad you sat down and joined us on day two.

I had an idea while I was using them I thought I'd run by you. Is this the right workflow to, for example, edit the access metadata?

access_df <- read.csv("data/metadata/access.csv", stringsAsFactors = FALSE)
editAccess(access_df)

What do you think about defaulting to doing the first line for the user by assuming each of the CSVs is at the conventional path (./data/metadata/{type}.csv) so the user only has to do this to get their data spiced?

create_spice()
editBiblio()
editAccess()
editAttributes()
editCreators()
write_spice()
build_site()

Also, would it be alright if I renamed these functions to use snake_case instead of camelCase just for consistency's sake?

[annakrystalli]

Was just about to add the suggestion above by @amoeba.

My suggestion would be for the function to take an argument for the path to the file that is to be edited but for the argument to default to here::here("data", "metadata", {type}.csv). The function would then read and write the file back out using that path.

[aurielfournier]

You are right @amoeba that is how its currently written, but I agree with you and @annakrystalli it would make more sense to have the function do all that for the user. I shall get that done over the weekend!

[amoeba]

Most excellent!

[annakrystalli]

🙌

BTW, we've already got readr as a dependency and have been using readr::read_csv() readr::write_csv() in other functions so far. Not necessary to use these but might be more consistent if we do use throughout?

[amoeba]

Good catch! I'm fine with using readr everywhere.

[amoeba]

This is "in" as of #60. Thanks @aurielfournier and @annakrystalli. We might find things to improve now that all of this is in but I think we can use new issues for those.