Dave Soller described the new push for the National Geologic Map Database's Phase 3 and possible funding opportunities to help the effort. Please contact Dave at drsoller@usgs.gov if you have ideas about how your state could contribute. Recording: https://dggs.alaska.gov/gemswiki/lib/exe/fetch.php?media=start:CDEFG_NGMDB’s_Phase_Three_and_related_upcoming_opportunities-20200309_1809-1.mp4

At this meeting, DGGS gave a brief update presentation of recent GeMS database work, and we discussed a few tools for diagramming geodatabases in Esri products. We also went “round robin” around the various attendees and folks described where they are in GeMS implementation, current projects, and related needs and concerns. Recording: https://dggs.alaska.gov/gemswiki/lib/exe/fetch.php?media=start:cdefg_diagramming_arcgis_databases_and_more-20200210_1907-1.mp4

Folks implementing GeMS posed questions about the best way to create a Glossary with minimal effort. Some states are interested in creating a Glossary resource that we can all pull from. Jen Athey volunteered to compile GeMS Glossaries and make the definitions available. Please feel free to send what you have so far to jennifer.athey@alaska.gov to be added to this resource. Recording: https://dggs.alaska.gov/gemswiki/lib/exe/fetch.php?media=start:cdefg_the_gems_glossary-20200113_1913-1.mp4

Discussion topic was where to put different kinds of geologic information in GeMS. We really just scratched the surface of this topic. Trish Ekberg from Alaska DGGS gave a presentation on how DGGS has tweaked the schema, which we feel still honors the ideals of data organization in GeMS. Then we walked through some examples of where to put different kinds of data in the schema. There was a fair amount of consensus. Recording: https://dggs.alaska.gov/gemswiki/lib/exe/fetch.php?media=start:CDEFG_Finding_homes_for_geologic_features_in_GeMS-20191209_1906-1.mp4

GeMS stakeholders would like to see an increase in communication in the geologic community to help with issues and questions as GeMS gets implemented. Since this meeting, some new tools were implemented. Following is from an email to the DMT listserv from Evan Thoms, USGS:

For those working with GeMS data in ArcGIS, I wanted to make sure you all knew that there are now two versions, one for ArcMap and one for ArcGIS Pro. They are available from GitHub:

• https://github.com/usgs/gems-tools-arcmap (formerly https://github.com/usgs/GeMS_Tools/)
• https://github.com/usgs/gems-tools-pro

The two versions have been developed separately because ArcMap uses Python 2.7.x and ArcGIS Pro uses Python 3.x and there are syntax and arcpy differences between the two. For instance, note that with ArcGIS Pro, ESRI has not (yet!) ported over the entire Metadata toolset of geoprocessing tools. If you want to use the Purge Metadata or FGDC CSDGM2 Metadata tools from the GeMS toolbox, you will have to do that in ArcMap.

As before, downloading the tools does not require a GitHub account, but if you want to create an issue there to report a bug or request an enhancement or new feature, you will have to log in.

Now linked from both repositories (look for the badge that says 'chat on gitter' below the title in the readme section) is a newly created Gitter room at https://gitter.im/gems-schema/community. Gitter is a free and open-source chat platform for developers and users of GitHub and GitLab repositories. Go there for non-code specific questions about the use of tools in either toolbox as well as questions about working with the GeMS schema in general. Feel free to post news about workflow documentation, the publication of GeMS databases, or other resources that your group has available if you think they could be useful to the community. Log in to Gitter using a GitHub, GitLab, or Twitter account.

Finally, as always, you are invited to collaborate on the development of the tools. See the suggestions in the readme section of either repository.

Thank you! Evan

Alaska DGGS presented an overview of work to date on the enterprise multi-map database and system. Recording: https://dggs.alaska.gov/gemswiki/lib/exe/fetch.php?media=start:CDEFG_GeMS_multi-map_project_and_documentation_update-20191007_1804-1.mp4

Joe Colgan, USGS and team members presented their FEDMAP project and geologic map database, “Geologic Framework of the Intermountain West.” Recording: https://dggs.alaska.gov/gemswiki/lib/exe/fetch.php?media=start:cdefg_fedmap_project_presentation-20190903_1802-1.mp4

DGGS staff presented a project update and future work.

Jen Athey, AK DGGS presented a preview of her 2019 Digital Mapping Techniques talk and showed a demo of DGGS' multi-map database implementation.

AK DGGS presentation included general CDEFG project update, topological lessons learned, and information on geological surfaces (surficial, bedrock, basement, other), responses from geological surveys about how they handle bedrock and surficial units on maps, possible database solutions, and tweaks to the draft database model.

Minutes for March 11, 2pm ET
1. Roll call: Tracey, Andy Cyr, Jen, Chris H, Chris W, Etienne, Amber, Charlie, AGS Andrew and Laura, Lina
2. General CDEFG project update: From Nov 2018 - Feb 2019 we converted four geologic maps to the GeMS format, concentrating on parsing the data and filling out the attributes correctly. Conversion appears to take about 4 weeks for a data-rich 1:63,360 map. We'll share some of what we've learned next. From March - June 2019, we'll be testing the multi-map database by creating three maps in GeMS format and creating a compilation map from them.
3. Topological lessons learned

• Sub-millimeter-scale dangles and gaps. We discovered in an ArcInfo-era dataset we were converting that there were many tiny dangles and gaps in multipart features and other multipart feature oddities. We are not sure if the topological errors were introduced later or if it was a problem from the original dataset. Aside from manually fixing the errors, we experimented with other Esri solutions, particularly changing the topology cluster tolerance, which actually moves and fixes the topological errors. With topological errors this small, we were wondering how the community feels about fixing them versus leaving them. More information at topology lessons learned.pdf.
• Amber said that creating data in ArcPro using Network Analyst might have advantages with topology. Other folks on the line said they haven't used anything other than the default topology cluster tolerance. They would rather have the dataset be manually cleaned up, particularly if any analysis will be run on the data layers. The data should be meaningful, which wouldn't be the case for random sub-millimeter arcs. It was suggested to draw lines first and then build polygons from them, which might result in fewer topological errors.

4. Geological surfaces (surficial, bedrock, basement, other)

• Responses from geological surveys about how they handle bedrock and surficial units on maps. Eastern US states and Canada are more likely to keep mapping, map presentation, and GIS files separate for bedrock and surficial data. Some factors that may influence this could be that East Coast geology is already complicated and having surficial on top gets too complicated for a 2D map, and the mid-continent geology is often only surficial units. Another factor for the western states could be the cost-savings of putting surficial and bedrock together to cover large areas. (http://137.229.113.30/jamwiki/en/File:Mapping_bedrock_and_surficial_%281%29.png, http://137.229.113.30/jamwiki/en/File:Bedrock_and_surficial_presentation.png, http://137.229.113.30/jamwiki/en/File:Bedrock_and_surficial_GIS.png)
• Possible database solutions. DGGS is strongly considering separating bedrock and surficial GIS to minimize data loss and allow for more rapidly changing surficial data. (GeMS Bedrock Surficial Topological Considerations.pptx) Andrew suggested another method would be to have a single table for the polygons that references another table with cartographic, unit, stratigraphic, and other information. Although this might be more complicated, it is not unusual to have a middle step negotiating between the database and webGIS data, for example. Amber said it will be important to get this right since it has implications for data curation. In Andy Cyr's surficial database, they keep track of what bedrock units are under the surficial and subordinate units, but they don't keep track of contacts under the surficial. Amber is working with Andy and Kevin Schmidt to format their data into GeMS.

5. Tweaks to the draft database model: (draft db model.pdf) DGGS is considering accepting additional database formats in the psdb Geologic Maps “Quarantine” step prior to the psdb Geologic Data “multi-map” database. There's not enough DGGS database administrator time available to correctly manage and train all of the geologists in using a Postgres database from the get-go. For projects that don't require multi-user editing and other enterprise database functionality, it might be acceptable to use file geodatabases instead. We see this part of the enterprise GeMS database conforming to the needs and resources of the particular organization. Maps would still need to be migrated to Postgres to be entered into the psdb Geologic Data “multi-map” database.