Latest Contributions by LanceCole

Tristan,  There are several options available to prevent geometry modifications depending upon your workflow.  All of the solutions do require staging of your data to some degree.  For example, you could use AGOL to collect your raw field data then would need to pull that data into your enterprise environment for review and initial ending.  That data may need to be split into separate feature classes or tables for internal use or be republished to AGOL for external use. 1) The simplest solution is if you have an internal Portal hosted on a ArcGIS Server.  Feature services on ArcGIS servers have an option to “Allow Geometry Updates” which prevents geometry edits, if unchecked, but still allows other attribute edits.  Additional info is available at Editor permissions for feature services—Documentation | ArcGIS Enterprise .  You can still create new features but cannot move existing.  This would require a workflow where you would edit or approve your data in one process before migrating the data to this service as you cannot make changes.  There is a known bug with this option that is still under review by ESRI, BUG-000119726S  2) A similar option is available in AGOL for feature services.  In the feature service settings there are options as to what type of editing is allowed.  One of the options is to “Only update feature attributes”.  Unfortunately this prevents any editing of the feature geometry including adding new features. 3) Another option, which we are currently using, is to split your feature geometry and attribute data.  We create a feature class that contains the geometry and any attributes that we do not want users to modify.  We also create a table in the database that is connected to the feature using a relationship class.  The permissions for these two items can be set independently through your enterprise geodatabase permissions.  Our GIS editors can have full rights to both items, whereas, GIS users can be prevented from editing the feature class but allowed to edit the table. The down side to this is you cannot edit the table values from the feature class attribute table directly.  The table values will not even be displayed in the feature class attribute table.  To edit values you must use the attribute window and drill down to the related table record where they can be edited.  Note, you can have the table values displayed in the attribute table by also creating a join in ArcGIS linking the feature class to the underlying table.  However, these values will be read-only.  In Pro you can also use the view related data feature. I am traveling this morning so I borrowed a few screen shots from other posts.   ... View more

Malcolm Meyer, pGDB do have a MDB extension but they are a hybrid database for use in ESRI products.  You can open them in Access, but it is not supported and can corrupt the file if you are not careful when saving and making changes.  Not only is ESRI no longer developing and supporting pGDBs but Microsoft is no longer developing and supporting MDBs that the file is based upon.  It is a matter of time before these files will disappear or become unusable.  Furthermore and as previously stated, pGDB files absolutely do not support multi-user access.  Each user must have their own copy of the data.  We we have hundreds of fGDB files saved on network shares that about 30 users access for read-only purposes.  The network shares are flagged read only for all authorized users with the exception a few users that have full access for editing.  This prevents lock files from being created on the fGDB files by users only accessing to read the data.  It also prevents accidental editing, deleting, etc.  We have never had a fGDB become corrupted but have had orphaned lock files from ArcGIS crashes (like that ever happens) while an editor is working on the file.  A quick delete of the lock files fixes the issue. ... View more

Micah Babinski‌, I had to think about this question.  Do not consider of Nullable and Required as related to each other as they serve totally different functions.  Nullable and Non-Nullable pertains to when a value is not provided for a field the database will automatically populate the field with a <NULL> for Nullable or a zero (0) for numbers and an empty string ("") for text for Non-Nullable fields. Required pertains to the field (the column) in a table not the values stored in the field.  When you select Required you cannot delete or remove the field or column from the table.  The Delete Field option will be grayed out for this column in the table.  The values in the field still can contain NULLs if the field is also set to Nullable or will contain 0 and "" for Non-Nullable.  A good example of the use of Required would be to prevent a user from accidently deleting a field that is used by other functions or programs.  The image below shows a field in a table that is set to Required and Allow Nulls.  You can see there are Null values in the table but if I try to delete the field, the option is disabled. ... View more

Mark‌, The reason no transformation options are available is the combination of settings you have input do not have a transformation path. ProjectZ is intended to convert the Latitude, Longitude and Altitude values collected from a GPS back into 3D points and convert the Altitude (Height Above Ellipsoid) into Elevation values.  The Latitude, Longitude and Altitude values stored from Collector are in the raw GPS data format you are utilizing.  For example, I am using a State VRS system that utilizes NAD 1983 (2011) for both horizontal and vertical.  These are set in ProjectZ as follows for the Input Coordinate System: Click on the Globe next to the input box Click on the Current XY box then select:     Geographic coordinate system > North America > USA and territories > NAD 1983 (2011) Click on the Current Z box and select:     Vertical Coordinate System > Ellipsoidal-based > North America > NAD 1983 2011 Click OK You will need to determine your coordinate system being utilized by yout GPS and apply the same.  If you are using WGS84 I would guess you could try the following. Click on the Globe next to the input box Click on the Current XY box then select:     Geographic coordinate system > World > WGS 1984 Click on the Current Z box and select:     Vertical Coordinate System > Ellipsoidal-based > World > WGS 1984 Click OK Set your X, Y and Z fields and output Feature Class For you Output coordinate system it is the simular Click on the Globe next to the input box Click on the Current XY box then select:     Projected coordinate system > State Plane > Your system > Your state system Click on the Current Z box and select:     Vertical Coordinate System >  North America > NAVD 1988  -  Do not select NAVD88 (height) (ftUS) at this point.  Click OK Note: You cannot transform directly to NAVD88 (height) (ftUS). Run the ProjectZ Once this completes, you can run a Project on the new feature class to go from NAVD 1988 to NAVD88 (height) (ftUS) using the same XY coordinate system. This is explained in more detail in the post I noted previously. Is it possible to collect accurate Z coordinate values with Collector and Trimble R2? ... View more