The folks working on the ICE-D project have released version 2 of the database (ICE-D Version 2) and are ready to start getting community contributions again!

We are scheduling this workshop to debut the new database, show the contributors at the University at Buffalo how to connect with and view the new database on their own personal computers, and then teach contributors how to use the new, sleek admin page on the version 2 website to add data!

There will also be opportunities to discuss and brainstorm useful and impactful applications using the ever-growing ICE-D (e.g. data manipulation, visualization and analysis in Matlab, and geospatial analysis in GIS software).

The workshop is planned to take place April 11-13 (Mon - Wed) depending on availability of UB Students and ICE-D workshop organizers. exact timing of events TBD.

1) Get connected to the new database through SQL clients and Matlab

2) Get contributors set up with add/edit/remove privileges for relevant tables on the ICE-D version 2 admin page

3) Applications demonstrations (Matlab and GIS) and brainstorming of new applications, community feedback, etc.

Please don't hesitate to email any of the workshop organizers if you have any questions (Joe Tulenko, Greg Balco, and/or Ben Laabs).

users successfully added as standard_editors. However users can't view tables that have import/export options but they can still add individual entries one at a time. I also did not figure out how to do bulk uploads so for now we are going to stick with individual entries for now.

After the workshop, I was able to successfully do a bulk upload for the sites table, but using the same “csv file open in a text editor” method for the samples table, I noticed that you do NOT need to include the id column. The web app generates unique ids for samples without the user needing to acknowledge the id column

Somewhat related, I noticed that in the samples page, the samples are listed by their name but their unique ids are not listed anywhere. Unlike the sites and regions table where unique ids are listed.

This could/should be an item for the ICE-D team to discuss offline.

The general consensus from the group was that it would be nice to have a tutorial written for adding data to the database through the web app and perhaps a csv template that editors can use to organize the data they plan on editing.

The amount of information that can be added to ICE-D for any one sample (all of the various attributes in the various tables that exist in ICE-D) can seem a bit overwhelming so it might be beneficial - especially in terms of accessibility and getting new users involved - to somehow highlight and direct editors toward the most vital information that needs to be added in order to make a entry with enough metadata to show up in the web app and calculate an age.

Today's focus was on two things:

All attendees were able to connect to the database either on Heidi SQL for PC users or tablesplus (free version) for Mac users.

Mac users were not able to connect to the database through Matlab. There were issues using the JDBC connector and/or issues with non updated versions of Matlab. We will need to make a tutorial for connecting through Matlab on a Mac similar to the tutorial written for PC.

Those that were able to connect though were able to run the scripts that we have written so far (e.g., Greenland deglaciation, measurement precision over time, etc.)

good discussions today about what needs to happen with ICE-D to allow users (at multiple levels of involvement in cosmogenic nuclide geochemistry/applications) to visualize the data both on the web app and from their own personal desktops.

Making a user interface on ICE-D that can hopefully give more context to what the samples shown in the database actually mean.

This would entail adding other geospatial information that can be overlain on a leaflet or google mutant web map that can be toggled on and off. Discussions included adding mapped glacier polygons from various publicly available sources like the Alaska PaleoGlacier Atlas, and hopefully glacier surface reconstruction projects like what Larkin is doing for the Great Basin and what Caleb is doing for Alaska.

Additionally, it would be interesting to add similar information to the Greenland page, such as ice margin limit information.

We also explored other websites that make special visualizations with some of the layers they display - see the example of polar sea ice found in the following webpage: https://storymaps.arcgis.com/collections/90bbfc79f4c947f4b6e34e1321ce0c77?item=5

This example is very ambitious but perhaps we could try to incorporate some visualizations of ICE-D and other geospatial layers in some interactive way in the wiki (i.e., a gif of a Greenland map with ice margin info displayed and all of the ages collected that date those ice margins at different times of the past).

We also thought that it would be nice to link sites to glacier polygons and ELA values if they exist (like in the Great Basin where Larkin is working, there are likely moraines with cosmo ages that now have a reconstructed glacier surface and ELAs and they could be linked). We would need to brainstorm further if it is possible to store geospatial information in the ICE-D database though. Like if there were some way to perhaps store all of the individual polygons as geojson files somewhere in the ICE-D project and a column perhaps in the sites table could be a place to store hyperlinks to respective geojson files?

updated note that perhaps instead of these geospatial things existing in ICE-D, perhaps ICE-D data should be incorporated into other geospatial online applications (like the APG Atlas see day 3 notes below).

The point was made that down the road, there could be things like these examples that give a little more geologic context to the sample info stored in ICE-D.

providing a means for the community to connect with a live and continuously updated version of the database from their own personal GIS applications (similar to how we connect to the live and up-to-date database through Matlab)

Users will more than likely be at various stages of familiarity with GIS software, so we should strive to make the data as accessible as possible. To that end, we are discovering that Web Feature Services (WFS) are quite universal; they can be opened in all GIS-based applications that I (Joe) currently know of. This includes ArcGIS, QGIS and even Google Earth (which was a pleasant surprise and something I learned through this workshop).

And then of course the Web Feature Service achieves the goal of providing users with constant access to the latest and most up-to-date version of the database without having to re-download datasets. Sounds like a win win.

Other discussions on this front focused primarily on what attributes would need to be included in a WFS, the possibility that file size might be an issue, and ways that that might be circumvented.

In short, it would be excellent if we were able to create multiple WFS's and give users the opportunity to select the specific data they need. Maddy suggested that we could organize the samples by geography; perhaps by continent, range, etc. Depending on how easy it would be to make multiple WFS's. This would also be extended to applications (i.e., a unique WFS for ICE-D Greenland, one for ICE-D Alpine, etc.)

Additionally, we could possibly break WFS's up by attribute; users could have the option to get samples with all of the attributes necessary to calculate ages, or other various attributes that we might want to define.

And then of course, depending on file size and how sluggish it would make people's personal desktops when the WFS is on, we could have a mega WFS with all of the samples in the database and some defined amount of attributes (perhaps unrealistic to expect that we could include every single column of all the tables in ICE-D? Maybe not?)

It would be interesting to learn more about how specifically we can create WFS's; if the web developers are the only ones who can do it of if I (Joe) might be able to figure it out.

And finally, in terms of organization, attendees agreed that it might be most valuable to make it obvious on the home page where to find these WFS links. As in, on the main page (https://version2.ice-d.org/) create another image/link entry like all of the ICE-D applications that opens to a new page that has WFS links and descriptions of what the WFS links are, and perhaps a link to a tutorial on the Wiki that describes how to open the links in various GIS applications (ArcGIS, QGIS and Google Earth).

notes from the post-wokrshop discussion.

- Jason suggests that it's okay if workshops are sometimes chaotic and Joe is running around troubleshooting computer issues. Workshops can/should be treated as a 'hack-a-thon' since there will likely always be computer issues.

-That said, better notice of what to prepare for ahead of time, tutorials that cover all topics covered at the workshop (i.e., currently missing tutorial for uploading data to the web app and missing a tutorial for connecting to Matlab using a Mac).

- Prioritize getting the APG Atlas up-to-date (i.e., incorporating Joe's sandbox map into the APG Atlas) and then figuring out how to make a WFS for Alaska samples that can be displayed on the leaflet map. Would be sweet for Joe to learn how to make a WFS.

- Jason made a good point that the purpose of ICE-D might best be served if it is strictly a database to house cosmogenic nuclide measurements and perhaps not other mapping/geologic info. Then, when others want to use ICE-D for their own purposes - such as showing the cosmo data compared to mapping efforts in Alaska ala the Alaska PaleoGlacier Atlas, or complimenting a housed and displayed multitude of glacier surface/ELA reconstructions - we can provide them a specially tailored WFS for their purposes.

- All this said, we could make the APG Atlas an example of what community users can do with ICE-D and I can show it off at workshops.