rhaugerud on master
Update GeMS_utilityFunctions.py… (compare)
ethoms-usgs on v1.5.2
ethoms-usgs on v2.4.3
ethoms-usgs on master
writes topology db to output di… update versionString fixed comment typo (compare)
ethoms-usgs on master
writes topology db to output di… (compare)
rhaugerud on master
Update mapOutline_Arc10.py imp… (compare)
ethoms-usgs on v1.5.1
ethoms-usgs on master
fixed versionCheck (compare)
ethoms-usgs on v2.4.2
ethoms-usgs on master
changed versionString (compare)
ethoms-usgs on master
import utility functions (compare)
ethoms-usgs on master
removed debugging message (compare)
ethoms-usgs on master
new version string and removed … (compare)
Welcome to the GeMS Gitter room. This is the place to discuss questions about using the GeMS schema for organizing data in a geologic map database.
If you are here to report a specific problem with a tool in either the ArcMap or the ArcGIS Pro GeMS Tools toolboxes, please go to the appropriate GitHub repository and open an issue there.
During today's webinar, we discussed the issue of trying to find GeMS tools, documentation, and other resources that are shared by individual surveys (aside from the USGS tools)... We are sharing documentation and tools developed here at the Wisconsin survey through this repo: https://github.com/wgnhs/gems
If you know of other collections of documents or tools, please post them!
@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.
NOT NULL
fields