Add Southern UT Fault Mapping data to hazards portal

[AHiscock]

Myself and Tyler K. have finished up our new southern UT fault mapping. Here is a list of the faultnums that need to be copied into the Hazards Portal within our study area boundary (located here - M:\Shared drives\UGS_Shared\Hazards\Fault Mapping\SUFM_Project Extent\SUFM_ProjectExtent.shp)

Data is on UGHP SDE in this feature class: UGHP.UGHPADMIN.QFault_SUFM FaultNums: 997a 997b 998a 998b 998c 1004b 2520 2522 2524 2527 2528 2529 2532 2533 2534 2535 2536 2537 2550 2558

I don't have the special-study zones associated with these faults quite ready yet (they are being reviewed by Steve, hopefully he'll have them done today or tomorrow, and then I can provide that data as well).

This is my first time startting a GitHub issue, so I hope I provided everything you need! Let me know if I missed anything. I will be on A/L starting this Wednesday (9/29) through 10/11, with some limited email access/checking going on.

[marthajensen]

@AHiscock

Just a few questions --

Has the SUFM data already been through the Hazards review process (including topology)? Is there a report reference for the data that needs to be included in the Hazards portal?

I doubt I'll get to this before you leave. Would Emily be the best person to ask questions to as they arise? Will she be the person who reviews the data before publishing it to the web?

[AHiscock]

@marthajensen

Yes, it has been through the Hazards review process. I ran topology on it last week, since we no longer have a Gordon. I haven't run topology in a long time, but I'm 99% sure I did it right. I set up a report reference link in GeoData, like we did for our last fault mapping project. Just a note - the link is set to private currently, and won't be "live" with the final report until we get it completed and through review. We've told the USGS we would have the FTR report submitted to them by the end of October. Here's the reference report link - https://geodata.geology.utah.gov/pages/view.php?ref=65953

No worries about getting to this before I leave. I just spoke with Emily, and she's ok with being the person for questions and such while I am gone.

Thanks Martha.

[AHiscock]

@marthajensen

OK - I have finished the special study zones that go with this fault mapping. They are all in a shapefile located here M:\Shared drives\UGS_Shared\Hazards\Fault Mapping\SUFM_SpecialStudyZones\SUFM_SSZ_Master.shp

Everything should be ready to go from me. As I mentioned, @emkleb should be available for any questions that may come up while I am gone.

Thanks Martha and Emily!

[marthajensen]

@emkleb The data is ready for review. Please review the following pieces of data:

Hazards Portal:

Study Areas "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Study_Areas

• I wasn't sure what to put in the "Name" field for the new data in the attribute table. Please have a look and tell me what to add or add something. It needs to match the name in the MappedHazardsTable (below). I also added the report reference above (https://geodata.geology.utah.gov/pages/view.php?ref=65953) to the Repor_ID and URL1 fields. However, @AHiscock indicated the report was set to Private in GeoData. When I click on the link, it appears the report is viewable.

Quaternary Faults "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Quaternary_Faults

• Check the new fault data

Special Study Zone "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Surface_Fault_Rupture_Hazard_Special_Study_Zone

• Check the new special study zones and the mapped scale. I think this data was mapped at 1:10,000 so I added that information

Reporting tool data

"G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Final_Report_Tables\HazardUnitTextTable.csv"

• the only thing that changed in the HazardUnitTextTable is the quaternary fault data at the end of the table

"G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Final_Report_Tables\MappedHazardsTable.csv"

• Please check the name of the study in Row 117 and 118. The name in these rows needs to match the name in the Study_Areas feature class.

UGRC data:

This is the undissolved version of the feature class that we provide to the UGRC "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Master_QfaultsData\Qfaults_AGRC.gdb\Qfaults

Once you give me the go-ahead, I will move the data to the LIVE version of our geodatabase.

[emkleb]

@marthajensen, here is my review. Please address a couple items listed below.

I apologize for my slightly delayed review. I didn't see the Github email, and I only checked on it today.

Hazards Portal: Study Areas "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Study_Areas

• Adam put a temporary file for the URL, so it works, but the final report isn't up yet.
• I added the name "Sevier and Hurricane faults" to the GDB above and the CSV

"G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Quaternary_Faults

• One thing I noticed, and this may be a legacy database thing, but in the non-domain fields (ie. fault_name), some field are while others are blank (no spaces). Why is that? I only ask because Arc sees a blank value not as , but as something else, even though it should technically be .
• Looks like, spatially, all of the fault data are there.
• Attributes look good for each fault number

Special Study Zone "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Surface_Fault_Rupture_Hazard_Special_Study_Zone

• It looks like the wrong data was added for this layer. It should be the "SUFM_SSZ_Master.shp" Adam listed. It's a polygon shapefile that very closely follows the fault mapping. Please take another look.
• 1:10k is correct. Thanks for updating.

This is the undissolved version of the feature class that we provide to the UGRC "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Master_QfaultsData\Qfaults_AGRC.gdb\Qfaults

• Looks good.

[AHiscock]

@marthajensen @emkleb Looks like you guys have made good progress on all of this while I was gone. Thanks so much! Let me know if I need to do anything.

[AHiscock]

@marthajensen and @emkleb

While reviewing and cleaning up the new SSZ's for our new data, I decided to take a quick look at the Quaternary_Faults feature class here: "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Quaternary_Faults I found a few issues, hopefully it's not that big of a deal:

• It seems that a bunch of the data for fault nums in the list I originally gave you is missing from the "Quaternary_Faults" feature class. For example, fault num 1004b (Washingon fault zone - Fort Pierce Section) is missing data OUTSIDE of our project area boundary. Here's a screen shot to illustrate: The straight black horizontal line is our study area boundary, and the shaded polygons are the SSZ's. The grey lines are the "Quaternary_Faults" feature class. The fault continues N of the study area boundary (those traces are currently in the haz portal), but wasn't remapped as part of this project.
• I looked around at some more of the data in the "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Quaternary_Faults" feature class, and I think I figured out what happened. We needed all the faultnum's I listed in the original post copied in, but only WITHIN the study area boundary.
• It's a little more complicated this time around, because Tyler re-mapped parts of different faults and fault sections (faultnum's), but not necessarily entire fault zone/section (or entire faultnum). It seems like the new faulttnum's I originally listed were copied in, without using the study area boundary as an extent for what to copy in. Does this make sense?
• I'm sorry if I didn't explain that well enough initially! Hopefully this isn't a big deal and we can fix it easily. I have time to help. If you need to re-do what you are copying in, I may need to tweak the study area boundary a bit to eliminate any weird fault terminations between the new and old data (if that makes sense). Sorry to create more work, but I'm glad I caught this.

I'm available all day tomorrow if you'd like to have a little meeting so I can explain this better. If @emkleb is available, maybe we should include her as well. Let me know. I'm also not so sure how this works on GitHub, hopefully you both get an email to let you know I posted all this in GitHub.

[marthajensen]

@AHiscock

ok - When you get the SUFM study area fixed, let me know.

I think I understand what needs to be done. In the qfaults master feature class, I need to select and erase all the faults with the faultnum's listed in this issue, but only within the new SUFM study area. I then need to copy in your new faults.

If you want to meet and discuss this in more detail, I am available

[AHiscock]

@marthajensen

Done making changes. Here's a summary of what I've done:

Study Areas "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Study_Areas

• All fixed. Trimmed the polygon for the "Sevier and Hurricane" fault mapping study area. One quick note - can we change the "Name" field to Washington/Hurricane/Sevier-Toroweap Fault Zones in the Study_Areas feature class?
• New polygons for both the WFZ and Bear Lake/Oquirrh projects are in the feature class

Special Study Zone "G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Surface_Fault_Rupture_Hazard_Special_Study_Zone

• Everything should be good to go here. I'll do another quick review once you re-do the lines.

I think thats it! Let me know when you are done and ready for me to review again. Thanks!

[marthajensen]

@AHiscock

I've rewrote parts of the workflow script and ran it again to encompass the study area issue that we ran into.

Please check the following datasets:

Hazards Portal

Study Areas

"G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Study_Areas

• "Name" field changed to Washington/Hurricane/Sevier-Toroweap Fault Zone

Quaternary Faults

"G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb\Quaternary_Faults

• Last dataset had 1599 faults - new dataset has 1690 faults

Reporting tool data

"G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Final_Report_Tables\HazardUnitTextTable.csv"

• the only thing that changed in the HazardUnitTextTable is the quaternary fault data at the end of the table

"G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Final_Report_Tables\MappedHazardsTable.csv"

• "Sevier and Hurricane faults" changed to "Washington/Hurricane/Sevier-Toroweap Fault Zone" (last 2 rows of the CSV)

Quaternary Faults for UGRC

"G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Master_QfaultsData\Qfaults_AGRC.gdb"

• Last dataset had 7865 faults - new dataset has 13298. One potential issue, which can't be solved easily (or maybe at all) by code, is the Summary field. For fault 1004b the Summary field has information outside the new study area, but not within it. I'm sure this same thing occurs across the Study Area in multiple places (I only checked one location). If this is problematic, we will need to edit the attribute table in GIS. This is also the case with the Hazards Portal faults.

[AHiscock]

@marthajensen

Everything looks good to me. All the faults that were previously missing are now there, so it seems like your new script worked perfectly.

For the "Summary" field issue, I noticed that as well, but I am not familiar what that field is even used for or where the information in it comes from? I also noticed that the new data doesn't have anything in the "USGS_Link" field. Our Bear Lake/Oquirrh data we pushed to the portal earlier this year has a link in the "USGS_Link" field but nothing in the "Summary" field. How crucial is it that we have info in the "Summary" field? Maybe @emkleb can chime in with some insight, since I don't know how important these fields are.

[emkleb]

The Summary field is not necessary to push outside of UGS. It is a legacy field used by USGS, but it's not maintained by them anymore. It might not hurt to keep it, because it contains a lot of good geologic information in addition to the other attributes.

option 1- keep the field, and just have some parts of the same fault number have a summary, and some without (ex. 1004b). Might be a little sloppy, but it preserves the information. This information can also be found on the USGS archived report pages (example for 1004b https://earthquake.usgs.gov/cfusion/qfault/show_report_AB_archive.cfm?fault_id=1004&section_id=b ). option 2- remove the field completely from the UGRC delivery.

I'm in favor of option 2, since we do have the URL for the USGS webpage, where users will be able to find the summary information that is in the summary field.

On Thu, Oct 21, 2021 at 9:50 AM Adam Hiscock @.***> wrote:

@marthajensen https://github.com/marthajensen

Everything looks good to me. All the faults that were previously missing are now there, so it seems like your new script worked perfectly.

For the "Summary" field issue, I noticed that as well, but I am not familiar what that field is even used for or where the information in it comes from? I also noticed that the new data doesn't have anything in the "USGS_Link" field. Our Bear Lake/Oquirrh data we pushed to the portal earlier this year has a link in the "USGS_Link" field but nothing in the "Summary" field. How crucial is it that we have info in the "Summary" field? Maybe @emkleb https://github.com/emkleb can chime in with some insight, since I don't know how important these fields are.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UGS-GIO/geohaz/issues/75#issuecomment-948746090, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHC3P2TAFMQZ7EUUJ5CWE2TUIAZEXANCNFSM5E26DYWA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[AHiscock]

@emkleb - Thanks for the response. I think option 2 sounds good. One question - Our new data has nothing in the USGS_Link URL field, I'm guessing we need to get that added?

@marthajensen is out until Monday, so we can just resolve this then.

The Summary field is not necessary to push outside of UGS. It is a legacy field used by USGS, but it's not maintained by them anymore. It might not hurt to keep it, because it contains a lot of good geologic information in addition to the other attributes. option 1- keep the field, and just have some parts of the same fault number have a summary, and some without (ex. 1004b). Might be a little sloppy, but it preserves the information. This information can also be found on the USGS archived report pages (example for 1004b https://earthquake.usgs.gov/cfusion/qfault/show_report_AB_archive.cfm?fault_id=1004&section_id=b ). option 2- remove the field completely from the UGRC delivery. I'm in favor of option 2, since we do have the URL for the USGS webpage, where users will be able to find the summary information that is in the summary field. … On Thu, Oct 21, 2021 at 9:50 AM Adam Hiscock @.***> wrote: @marthajensen https://github.com/marthajensen Everything looks good to me. All the faults that were previously missing are now there, so it seems like your new script worked perfectly. For the "Summary" field issue, I noticed that as well, but I am not familiar what that field is even used for or where the information in it comes from? I also noticed that the new data doesn't have anything in the "USGS_Link" field. Our Bear Lake/Oquirrh data we pushed to the portal earlier this year has a link in the "USGS_Link" field but nothing in the "Summary" field. How crucial is it that we have info in the "Summary" field? Maybe @emkleb https://github.com/emkleb can chime in with some insight, since I don't know how important these fields are. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHC3P2TAFMQZ7EUUJ5CWE2TUIAZEXANCNFSM5E26DYWA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[marthajensen]

@AHiscock What URL should I add to the USGS link field?

I was looking through the data we currently have and the USGS links are all slightly different

Should the citation field also be filled out to say "Hiscock and Knudsen, 2021"?

[AHiscock]

@marthajensen The citation field should be "Knudsen and others, 2021"

As far as the USGS link field - shouldn't each faultnum have the USGS link for that fault num? Like for example, all fault nums 1004b should have this link: https://earthquake.usgs.gov/cfusion/qfault/show_report_AB.cfm?fault_id=1004&section_id=b And all faultnum 997 should have this link: https://earthquake.usgs.gov/cfusion/qfault/show_report_AB.cfm?fault_id=997&section_id=b This may be a question for @emkleb

I can compile a list of links for each of the faultnum's we updated in this project if that would help. Then you can just plug them into the USGS_Link field.

[marthajensen]

@AHiscock

Hi Adam,

If you can provide me the list of USGS_links when you have time that would be great! Thanks!

[emkleb]

Yes, the USGS link should have those URLs. I see that in the version in the review version doesn't have all of them compiled: M:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Working and editing geodatabase\Geologic_Hazards_Geodatabase_Review_Version.gdb

This is a legacy issue from copying the SDE version of q-faults.

[marthajensen]

@JCastleton

Your turn! We have some new fault data ready for the web for the Washington/Hurricane/Sevier-Toroweap Fault Zones. Please review the following datasets:

Hazards Portal:

Study Areas "G:\Shared drives\UGS_Hazards_MapPortal\Hazards Portal\LIVE Geodatabase\Geologic_Hazards_Geodatabase_Final_LIVE_Version.gdb\Study_Areas"

Quaternary Faults "G:\Shared drives\UGS_Hazards_MapPortal\Hazards Portal\LIVE Geodatabase\Geologic_Hazards_Geodatabase_Final_LIVE_Version.gdb\Quaternary_Faults

Data was added or modified for fault numbers 997a, 997b, 998a, 998b, 998c, 1004b, 2520, 2522, 2524, 2527, 2528, 2529, 2532, 2533, 2534, 2535, 2536, 2537, 2550, 2558

Special Study Zone "G:\Shared drives\UGS_Hazards_MapPortal\Hazards Portal\LIVE Geodatabase\Geologic_Hazards_Geodatabase_Final_LIVE_Version.gdb\Surface_Fault_Rupture_Hazard_Special_Study_Zone

Reporting tool data

Hazard Unit Text Table

"G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Final_Report_Tables\HazardUnitTextTable.csv"

This data is also located in the final live gdb ("G:\Shared drives\UGS_Hazards_MapPortal\Hazards Portal\LIVE Geodatabase\Final_Report_Tables_LIVE.gdb") but its probably easier to review as a CSV in the folder above. The only thing that changed in the HazardUnitTextTable is the Quaternary Fault data at the bottom of the table

Mapped Hazards Table

"G:\Shared drives\UGS_Hazards_Geotech\Geologic Hazards Online Data\Final_Report_Tables\MappedHazardsTable.csv"

The only thing that changed in this table is last two rows, listing the new faults and their associated codes (Row 117 and 118). The name in these rows needs to match the name in the Study_Areas feature class. The MappedHazardsTable is also in the "G:\Shared drives\UGS_Hazards_MapPortal\Hazards Portal\LIVE Geodatabase\Final_Report_Tables_LIVE.gdb"

[AHiscock]

@JCastleton

Just to follow up - we'd like to have this data live by the end of the week to coincide with when we submit our FTR text to the USGS, so if you could review it today or early tomorrow that would be great. I apologize I didn't let you know sooner about our deadline.

[JCastleton]

I have reviewed the gdb and tables. Everything looks great!

[marthajensen]

@JCastleton

You are a rockstar! Thanks. I'll publish this in the morning :)

[emkleb]

@marthajensen @AHiscock Quick note- We also need to get this final data into the master Q-faults SDE feature class. I think Adam or I are capable of it, but it might be helpful if Martha does it so we can make sure we aren't missing any data, as well as see if any issues come up that may be relevant to our larger efforts to re-do Q-faults SDE.

[marthajensen]

@AHiscock @emkleb

@AHiscock I changed around the qfault symbology this morning to thinner lines when zoomed in. Have a look and let me know

@emkleb Let's take care of adding the new data to the SDE during our meeting on Wednesday.

[AHiscock]

@marthajensen That looks MUCH better. Thanks.