ethoms-usgs on master
cleaned typos and comments in F… Merge branch 'master' of github… (compare)
ethoms-usgs on v1.6.10
ethoms-usgs on master
new error messages in Fix Strin… (compare)
ethoms-usgs on v2.5.1
ethoms-usgs on master
more detailed error messages in… edits to error messages in Fix … (compare)
@cmrRose @stub0035 @awittner Yes! I think the schema documentation should be re-written to be more open-ended regarding software versions. I would not want anyone to feel locked in to using any particular version. As a reviewer, if I was given an AGP project, I would not ask for an mxd or style file. While it is true, at the USGS, that new versions go into a vetting period before they are officially cleared for general use, most of us are going to be at or very near the latest version (echoing Amber's point).
That said, if you are interested in using a GeMS toolbox tool that has not been edited to work with version-specific files, that's a problem. Log an issue at the appropriate github repo or propose a merge with new code as a collaborator.
Regarding symbology, one thing I look for that is sometimes missing is the text description of a symbol and/or the FGDC symbol name. You want users of your data who have no access to your ESRI-built symbol containers (style files, layer files, map/project files, carto reps) to be able to discover how a feature is meant to be symbolized. In the case of the AreaFillRGB field (which should probably be re-named to something like AreaFillValue because you should be allowed to use whatever color palette value you are working in), that might be all the recording of the symbol you need because ArcGIS Pro and QGIS can symbolize polygons based on the values in this field.
And if you didn't know, at ArcGIS Pro 2.5 you can once again Match Layer Symbology To A Style
Hi all, I'd like to make a recommendation for GeMS 2.1.
We are currently required to convert each feature class into a shapefile for the "open" publication. However, there are many well-known problems with Shapefiles that make them very ill-suited to serve as long-term, cross-platform archive. I would like to recommend that we replace the "open" version to something better suited to long-term archival like OGC Geopackages. It is a simple mater to import or export a geopackage to arc or comparable open-source platforms, it is a single file format so there is less chance of data loss (how many times have you lost the projection information for a shapefile!?), is a true FOSS format, and is much easier to transfer across the web. Even ESRI recommends it.
We can still keep the "simplified" shapefile version as is to continue serving the part of the community that is interested in simpler and more familiar data types.
Announcing some changes to the repos.
We decided that saving binary files and files that were not being versioned at gems-resources was not a good use of GitHub and was just another site to have to maintain, so I copied all files and links (and added more) to the Resources section of the NGMDB GeMS page and will, eventually, delete gems-resources.
There is now a badge called 'gems online documentation' at the top of each readme that links to an excellent HTML version of the GeMS standard document that was prepared by Megan James from the South Carolina Geological Survey. She will maintain this in the SCGS GitHub hive. Thank you, Megan!
Does anyone have standard values for the MapUnit field? Would it make sense to use standard map unit abbreviations to represent each geologic age (which each have its own special age symbol using the FGDCGeoAge font). When converting legacy data, its not always clear if a map unit abbreviation such as Trg is a Triassic or Tertiary unit. Map unit abbreviations starting with a P are also problematic – P can represent Paleogene, Paleozoic, Permian, Pennsylvanian, Precambrian, or Proterozoic. Yikes! Age information can often be inferred from the correlation chart or metadata for legacy data, and of course GeMS has age info in the DescriptionOfMapUnits.
I'd love to start a discussion on this. Anyone have interest?
Has anyone had issues with the USGS Metadata Wizard tool lately? When I run it in ArcMap or ArcCatalog, I get an error about not being able to find the right version of Python.
So then I try it in Pro and I get an error about missing parentheses. I just downloaded it again to see if something had changed, but no luck. Note, I'm running this after running the GeMS FGDC Metadata Step 1 tool. Thoughts are appreciated!
Here is the text of the error:
Errors and warnings
File "C:\Users\rfasselin\Desktop\Tickville_metadata\fort-pymdwizard-master\ArcToolbox\USGS_MetadataTool.py", line 683
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(message)?
Failed to execute (MetadataWizard).