Latest Contributions by GIS_Spellblade

Just a minor follow-up on this; depending on the complexity of your feature (especially dense, un-simplified multipolygons), reducing the precision of the WKT could cause some vertices to become coincident, break topology, or otherwise create invalid geometries that will make your table un-selectable within the ArcGIS Pro GUI. I was dealing with some coastal polygons and this issue tripped me up and I ended up needing to move up to a precision 7 to negate the issue. Also, relevant XKCD:  https://xkcd.com/2170/ ... View more

@TanuHoque, is there an Idea open for collecting Editor Tracking Information with the new UTC + TimeZone Enabled field instead of the UTC or database time? ... View more

And here's the recording from yesterday is anyone is interested! https://www.youtube.com/watch?v=_E5Ox1e3d_I ... View more

There is a similar idea here: https://community.esri.com/t5/arcgis-enterprise-ideas/portal-for-arcgis-quotas/idc-p/1385556#M3641 Additionally, there is an ENH (ENH-000120963) that mimics this request that you could ask your account manager to attach your organization to for more traction. https://community.esri.com/t5/arcgis-pro-questions/disable-world-geocoding-service-for-users-on-a/m-p/1385560/highlight/true#M79168 ... View more

You could use some logic similar to this: var search_duplicate = $feature.FACILITYID var features = FEATURESETBYNAME($datastore, "Featureclass Name Here") var sqlExpression = "A_FIELD_NAME_HERE = @search_duplicate" var result = FILTER(features, sqlExpression) WHEN( COUNT(result) > 1, `Duplicate Value, choose another ID`, $feature.FACILITYID ) Or you could use a sequence: https://support.esri.com/en-us/knowledge-base/how-to-add-auto-sequential-values-using-attribute-rules-000024533 Also, this post has a great solution to what you're asking for: https://community.esri.com/t5/arcgis-field-maps-questions/arcgis-fieldmaps-form-calculate-expression-to/m-p/1159183 ... View more

That's kind of big for a shapefile; I would export it to something a bit more performant like a geopackage, mobile geodatabase, or file geodatabase and the repair geometry tool should run faster. Then export it back to shapefile (if you absolutely have to have a shapefile); otherwise I'd stop using shapefiles altogether. ... View more

I'm not sure that this solves the use-case for us. We're noticing discrepancies between the time as provided in the Editor Tracking fields vs. the manually entered fields. It is possible for us to update all of our manually entered fields but that's a bit of a lift across our entire infrastructure. Additionally, when we're serving this data out in a web application, it seems the pop-ups are aware of the client's local time and automatically casting our UTC dates to those times (even though the service settings are set to UTC and display in UTC) which is throwing everything off. Our expectation here is that the web pop-ups would display the time as recorded within our database. ... View more

There is not one out of the box; you would need to either disable Utility Services or create a custom role to restrict access to it. You can ask your account manager to sign up for this enhancement that is requesting exactly this functionality within ArcGIS Enterprise. ENH-000120963   ... View more

For anyone else that stumbles across this; the inability to allocate credits to a Named User within ArcGIS Enterprise is still an issue. There is an enhancement (ENH-000120963 opened in 2019) that you can add your organization to (with the help of your account manager) that would address this problem:   ... View more

This would make development so much better. I only loathe writing Arcade because of how I have to do it. VS Code is life. ... View more

After a bit of back and forth, this behavior is "expected"; therefore the previous BUG was closed and has been replaced with this ENH request. If you're interested in seeing this resolved feel free to add your organization to the enhancement request. ENH-000163896 When they create a feature class, they create a date time field in standard precision. Using an automated python workflow, they aim to create a database view from the feature class and register it with the geodatabase. However, when the date time field is created in the database view, it is created in high precision by default, and they are unable to change it to standard precision. Even after changing ArcGIS Pro option to opt out of using new field types for query layers and text files (check the Use field types that are compatible with ArcGIS Pro 3.1 and earlier releases when adding query layers and text files option under Map and Scenes option) the same behavior is reproduced. They aim to create the fields in standard precision since, having high precision fields in database view breaks their workflow. In ArcGIS Pro 3.2 and later, new field types to support date, time, and big integer values are available. When query layers on unregistered datasets or text files are added to a map in ArcGIS Pro 3.2, these fields may be assigned to the new field types, which are unavailable in earlier releases. By design, when a query layer or database view is created in ArcGIS Pro, it is created in high precision.  It is an expected behavior in ArcGIS Pro 3.2 and higher in which high precision fields are created. However, in scenarios where users need to work with standard precision, currently there is no way of attaining this. Hence, adding a functionality in the Register with Geodatabase GP Tool to format date time fields in standard precision will let customers achieve this.    Documentation Url : https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/arcgis-field-data-types.htm#:~:text=The%20new%20date%20time%20fields,table%20in%20the%20fields%20view. https://pro.arcgis.com/en/pro-app/latest/help/mapping/properties/default-settings-for-new-maps-and-scenes.htm#ESRI_SECTION1_856A5CFA37884F889D2BBC0FC31315A2 ... View more

I'd like to hop onto this idea as well. We have a similar business use-case; we keep our primary data is in UTC, per company policy, but when users input dates into our data they are not expecting to have to compensate for the UTC conversion. This crops up in the following ways, a user will input the date an asset was created (yyyy/mm/dd) and due to their timezone differential, the asset appears to be created the previous day. This is relatively easy to compensate for in a web application through utilizing Arcade and the ToLocal() function for display. On desktop the workaround is a bit more cumbersome and would require one of the following: a field calculate snippet for desktop users an attribute rule per featureclass with manually entered dates a constant sticky-note to remind them of their time difference All of the above options are unsavory and require varying amounts of overhead to create and maintain; hence, a software setting that abstracts this away from the user (and the program administrators) would be ideal. This would be a huge quality of life improvement for those in our organization that are responsible for data entry who are normally not the same individuals who are proficient in programming datetime conversions. ... View more