Translate a Digital Map With GeMS, Part C2

Video Transcript
Download Video
Right-click and save to download

Detailed Description

Translate a Digital Map With GeMS, Part C2 - How to translate point features and non-spatial information from another schema to GeMS

The Geologic Map Schema (GeMS) defines a standard database schema — a database design — for digital publication of geologic maps. This tutorial is one of six originally presented as part of a short course at the 2021 Northeastern Section Meeting of the Geological Society of America by Ralph Haugerud, USGS, on how to use ArcMap and custom tools to create GeMS-compliant ArcGIS file geodatabases.

GeMS Trainings

  1. Getting Started With GeMS, Part A
  2. Digitizing an Analog Map With GeMS, Part B1
  3. Digitizing an Analog Map With GeMS, Part B2
  4. Digitizing an Analog Map With GeMS, Part B3
  5. Translating a Digital Map With GeMS, Part C1
  6. Translating a Digital Map With GeMS, Part C2

Details

Date Taken:

Length: 00:10:57

Location Taken: US

Video Credits

Video editing, Evan Thoms, USGS, Geologist, ethoms@usgs.gov

Caption editing, Megan James, South Carolina DNR Geological Survey, Geologist, jamesm@dnr.sc.gov
 

Transcript

Let's talk about point features and nonspatial tables. First, point features. The main database is fully normalized and optimized for cartography. Point attributes are spread across 3 tables, observation symbols, locations and inclination values. This is because, in some cases, there's more than one observation at a location thus separate tables and a many observation to one location relation is the best way to store these data. It allows for the most precise editing with the least possibility for error. The schema also allows for exact positioning of symbols for observations of foliations, joints, etc. And in the database, the oriented feature, point features, foliations attitudes, and non- oriented features like pegmatite outcrops, observations, are in the same set of tables. GeMS is not fully normalized. Each observation of a joint foliation or bedding carries its location. And if you had made more than one observation at a station, the locations are repeated. To translate the main database into GeMS was complicated. And I will not take you through all of it, but here's the recipe I used. Basically, I took the observations feature class and added the fields from the other feature classes to it. I added XY values to that location feature class. I joined the observation feature class location feature class and transferred the field values, including the XY locations. Same thing for the feature class, C. I loaded the, then the, the feature Class A that's been modified as XY data using the point X and point Y from the add XY tool and then exported that as point feature class D, a new point feature class. And this had the virtue of basically turning one observation location into many instances of the same thing. I could then load feature class D into orientation points. I ran attribute by key values to translate the main types to GeMS types, data source IDs and confidence values. I ran set symbol values to calculate symbols, and I set ID values. Then I selected and copied the non-oriented features from orientation points to outcrop points and deleted them and then I validate the database and fixed a bunch of stuff. Enough. Nonspatial tables we still gotta fill out data sources to Glossary, miscellaneous map information in the DMU. And the basic problem here, as most of you know, is that editing tabular text in ArcMap is awful. It works a little better to edit your tabular text in Excel and load the Excel tables in Arcmap. It's very smooth process, but Excel balks at large fields. And here the description field is not transferred, it's come across as blob and you can't look into that. The solution is pretty straightforward. I build tables in Word, I copy paste them into Excel. I save them as CSV and the CSV file loads directly into an arc table with no problems. Glossary, miscellaneous map information and data sources are pretty easy to do that away. Description of map units needs a little more discussion. Let's start with the published map, which has an explanation of map units in the legend. Such an explanation is an essential part of any geologic map. It's rare that a map user can, be expected to understand without some sort of guide, what PG or CDG is. These explanations are fairly formalized. Each element description has a name, a description, distributed text, a label, some sort of text, formatted text, that, that gets plotted on top of the polygon on the map, and a symbol, which here in this case is a salmon color with random gray dashes. When these things go into the DMU table, we need a key to tie these elements back to Map Unit Polys. Name doesn't work as the key because it may not be unique. There are two names of granite in this table. It's hard to enter a color fill, the color salmon in a keyboard into the map unit polys table, so symbol doesn't work. Label is a poor choice. Here, it would work fine, but in many cases we use special characters. For example an up carrot for the run together TR, and formatting instructions like make this lower case to drive the labeling that are hard to type and hard to read. So we invent another field which we call map unit, so short plain ASCII token, in this case CDG and use that to label the map unit polys and tie them to the relevant row in the description of map units table that describes what those polys are. The explanations on our maps are typically strongly hierarchical. In this case we have stratified rocks in a first order heading. Underneath that this is a first child, is a parent, as a child is, is the Vassalboro group, bracket, which is parent to Slurian Ordovician question mark, which is parent to Vassalboro group, undifferentiated. So this is a heading, this is a heading of a kind, a heading. This is a description of the map unit, paragraph style and it's on the 1st order and its parent to four, Description of Map unit paragraph styles, the 2nd order shown by their indentation. Hierarchy in this explanation is shown by font and by indentation, and not all maps use the same set of fonts and notation brackets, appendix three in the GeMS specification has several examples that might make it a little bit clearer how to read hierarchy or how we do read hierarchy from these explanations. Well, in GeMS we describe the hierarchy with two fields, two attributes. One is the hierarchy or H key, which is a, a text string of numbers and separators, and the other is a paragraph style which is also a text string. And let's go through this. In the DMU table headings get their own rows, so the first row is intrusive rocks and 2nd row is Permian. The 3rd row is granite. Permian is a child of intrusive rocks and granite's a child of Permian. So this is 1, this is 1 Dash 1, 1 Dash 1 Dash 1. And I've gone through here and assigned H key values to every feature. Note that in stratified rocks this bracket here is the first child of stratified rocks. This bracket's the second child. If we were to take our DMU table and sort it for example on name, Vassalboro Group, or on map unit SOvu, we would get an order that wouldn't look like this at all. If we re-sort on the hierarchy key. Things go back in order in some DMU's, there are ambiguities about whether a, a row is meant to be treated as a heading or as a map unit, some maps use map units as headings, and so this is uncertain. So we reinforce the hierarchy and resolve these ambiguities by recording paragraph style, and these are example values. Paragraph style values need to be defined in the Glossary. So let's go look at the explanation of units on the Lisbon Falls South map. This is a close up. We can go in here and grab the description text. And copy it and bring in a Word document and copy and paste that description text. And we get this. And with a little bit of hand editing, we can translate that into this, which is our map unit description. We can take this, text here, and paste it into a table we built in Word. And here is that same text and add the other elements, that makes your DMU, to this and I need to make this a little smaller so you can see. And I've done this for every unit, every heading, and every bracket, in the explanation of units. The color values I read off of the bedrock units table in the map database Chris Halstead kindly supplied the main style to me. From that, I was able to go into the Windows File Manager and read out the RGB values for each of those colors and enter those, and I wrote in a verbal description of the patterns on some of the units. Building this table, here, took about an hour. All told, not too bad. At that point, I can copy the table. Control C. Then go to, Excel, control V. There's a table with long text descriptions and I can file save as, and I don't want to say this is Glossary. I want to save this as the DMU. And actually already done this already. Lisbon DMU UTF 8 and save. I can replace it, OK. Then I want just the only  active sheet only, that's fine. Close word, close this, save. And I can go back to Map Composition, open catalog. And open my database. I've been building, go to the DMU and load, load data. Next, navigate to,  find my CSV file, open. Add, next, next. All the fields map appropriately, next. And if I open this up, there's my DMU and it has the long descriptions in it. At this point we have nearly all the substance of the main database. Lisbon Falls South quadrangle in GeMS there's still clean up work to do. I need to run validate database and fixed odds and ends, a few fields need renaming and so on. I've also failed to transfer or build feature classes for photo points and for geocon points and when I did this I didn't add Glossary definitions for the oriented endpoint feature types to the main database, but I got a nearly complete database.