Latest Contributions by GIS_Spellblade

‎03-04-2024

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

‎02-22-2024

This blog walks through the process if you're using the not old Map Viewer: https://www.esri.com/arcgis-blog/products/arcgis-online/mapping/color-pop-ups/ You would likely want to restructure your arcade expression to return a WHEN statement against the unit and building not being null; and the default can be an empty string "". That would reproduce the same as it exists in ArcGIS Pro. https://developers.arcgis.com/arcade/function-reference/logical_functions/#when The other thing that I might do is to tidy up the HTML tags by wrapping them in a few variables since all of them are being reused in various ways. You can also use string literals to make it neater as well: https://www.esri.com/arcgis-blog/products/arcgis-online/mapping/manage-your-strings-quite-literally-with-arcade-1-11/

‎02-22-2024

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

‎02-22-2024

If you have access to an enterprise geodatabase (which it sounds like you do) then you have the ability to set up versioning which would include reconcile and post. That said, it sounds like the issue that you really have is a lack of QA/QC. If you set up traditional versioning or branch versioning you'll want to have an intermediate version where yourself or supervisors/power users are able to perform quality control on field work that has been performed. I think this blog might be useful for you: https://www.esri.com/arcgis-blog/products/arcgis-pro/data-management/qa-qc-workflow-with-branch-versioned-data/

‎02-22-2024

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.

‎02-22-2024

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.

‎02-22-2024

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

‎02-22-2024

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:

‎02-20-2024

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

‎02-17-2024

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

‎02-15-2024

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.

‎02-07-2024

Yes that's correct

‎01-26-2024

I'll just drop this here. Seems like it could solve this issue if these parameters were exposed. https://community.esri.com/t5/arcgis-pro-ideas/create-locator-additional-options-when-creating/idc-p/1192654#M20349

‎01-26-2024

This ArcGIS Idea is to allow an additional option, when utilizing the H3 spatial index, to output the integer-based ID in either a BigInt or String format. This functionality would be a huge quality of life improvement and create better interoperability for utilizing this open-source spatial index specification. While the new addition to utilizing the open-source H3 Spatial Index within the Generate Tessellation (basic, standard, advanced licenses) and Generate Grids and Hexagons (business analyst extension) is an excellent step forward; however, there currently exists a limitation that severely impacts interoperability with other platforms that utilize H3 which is that these hex tiles can be identified through their integer-based or hexadecimaI IDs. The current toolset in ArcGIS only outputs H3 tiles utilizing their hexadecimal IDs, this is an issue because the integer IDs require a somewhat complex formula for translating this into the integer ID-- --this is not a well-known piece of knowledge and a cursory search in a stack exchange will bring up results for a simple hexadecimal to integer conversion function. The easiest way to convert the two IDs (without looking up the formula spec on the H3 API documentation) is to utilize the Python library h3-py which can be downloaded utilizing the ArcGIS Pro GUI-based package manager (if a user knew that this is what was required). This significantly ups the requirement to interoperability with other H3 datasets (that may not have the hexadecimal ID included in favor of the integer-based ID) as a user will need to have in-depth knowledge that may not be required for what would otherwise be a simple data request/process. import h3 some_hex_id = "8826c20001fffff" print(h3.string_to_h3(some_hex_id)) #613171383972659199 This ArcGIS Idea is to allow an additional option when utilizing the H3 spatial index to optionally output the integer-based ID in either a BigInt or String format. This would be a huge quality of life improvement and create better interoperability for utilizing this open-source spatial index specification. https://www.esri.com/arcgis-blog/products/arcgis-pro/analytics/use-h3-to-create-multiresolution-hexagon-grids-in-arcgis-pro-3-1/ https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/generatetesellation.htm https://pro.arcgis.com/en/pro-app/latest/tool-reference/business-analyst/generate-grids-and-hexagons.htm @MargaretCrawford

‎01-25-2024

GeoEvent Version 11.1 - So I ran into what I think is an issue, but I don't have time to properly test, it looks like there is an issue with the Field Enricher (Feature Service) when you are working with a GeoEvent definition and spatiotemporal datastore that has been edited from its original creation. The results that I have seen are that when Target Fields are set to New Fields, the join works as expected and fields can be populated; however, when Target Fields is set to Existing Fields, the join does not work as expected and no fields are populated. The schema between the two GeoEvent definitions are the same and there shouldn't be any differences between them. I'm failing to understand how a difference in these options would affect a join which should match regardless of option selected. Based on preliminary testing with a fresh GeoEvent definition (created for purpose without additional added fields post-deployment) the Field Enricher (Feature Service) works when set to Existing Fields.

Online Status	Offline
Date Last Visited	2 weeks ago

My Ideas

Latest Contributions by GIS_Spellblade

Re: Service credits allotments for ArcGIS Enterprise deployments

Re: Arcade symbology expression working in Pro, but not in AGOL?

Re: ASK FOR ARCADE STATEMENTS TO AVOID DUPLICATION OF ELECTRIC METER NUMBER IN LV SERVICE

Re: Do I need workflow manager to reconcile and post?

Re: Repair Geometry Tool Unbearably Slow and Dysfunctional

Re: Enable local time formatting of UTC date/time data

Re: Disable World Geocoding Service for users on a license server?

Re: Portal for ArcGIS quotas

Re: Arcade Extension for Visual Studio Code

Re: High Precision Date Field Issue when Registering Tables

Re: Enable local time formatting of UTC date/time data

Re: Is this an issue with Field Enricher (Feature Service)?

Re: The Create Locator GP tool should output locators that follow esri tech support best practices

Add Option to Output Integer IDs for H3 Spatial Grin in Generate Tessellation GP Tool

Is this an issue with Field Enricher (Feature Service)?

Create CheckPrivileges GP Tool

Bifurcate Shared Services Pools into Schema Lockin...

Re: Do I need workflow manager to reconcile and po...

URISA Vanguard Cabinet Upcoming Webinars

Re: Disable World Geocoding Service for users on a...