|
IDEA
|
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
... View more
01-26-2024
09:26 AM
|
0
|
0
|
1706
|
|
IDEA
|
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
... View more
01-26-2024
08:30 AM
|
8
|
0
|
662
|
|
POST
|
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.
... View more
01-25-2024
10:44 AM
|
0
|
3
|
838
|
|
IDEA
|
Would an enhancement to include an output option for integer-based IDs instead of/in addition to the hexadecimal ID need to be an additional ArcGIS Ideas request?
... View more
01-25-2024
10:13 AM
|
0
|
0
|
1773
|
|
POST
|
Here's a bug if anyone wants to attach themselves to it: BUG-000163896 Synopsis: Creating a database view from ArcGIS Pro 3.2.x, converts the standard precision date field (in source table) to a high precision date field (in database view). Status : In review
... View more
12-20-2023
03:20 PM
|
1
|
0
|
3372
|
|
IDEA
|
As an additional confounding factor, if a user selects auto-assign IDs from within the sharing dialogue, those IDs are not permanently affixed to the APRX project file-- --I think that this contributes to the user errors, as a re-ordering of the layers that might otherwise not create new index IDs, would, if a user continually checks the "auto assign IDs" box within the sharing dialogue. layer_a (0) layer_b (1) layer_c (2) is not preserved within the APRX file even when a user saves after publishing a service. If those same layers are moved, and/or an additional layer added: layer_b (0) layer_a (1) layer_c (2) layer_d (3) If the auto-assign function was honored within the project, the above rearrange and layer addition would not affect a production publishing service: layer_b (1) layer_a (0) layer_c (2) layer_d (3) And I 100% agree with @stevegourley if a user was alerted to the fact that they might be pushing a bad change it could prevent some of those updates from happening. Obviously a centralized, RFC-controlled process is the most preferable option but those kind of strict controls are often not possible in geospatial programs of the following types: balanced, federated, hub and spoke, and decentralized. In my experience, most organizations fall outside of a fully centralized program and would benefit from this quality of life reminder. https://resources.esri.ca/news-and-updates/how-to-organize-your-geospatial-talent
... View more
12-19-2023
07:23 AM
|
0
|
0
|
6572
|
|
IDEA
|
As we're all aware, there's a thousand ways to skin the GIS cat. Having an ability to measure the resource consumption of a GeoEvent Service (ideally with a pre-programmed & repeatable feed) would allow users to better optimize their GeoEvent Services and pursue different implementation strategies. This can be encapsulated into the following thought; should you pre-program your geofences or create them ad-hoc within the service? Obviously the answer is, it depends. Which is kind of a non-answer. We can whiteboard and conceptualize different ways to accomplish a task and list likely considerations but most users will not have a great understanding of which operations are more performant. While there is an argument for, if it works, it works. There are plenty of shops what would like to minimize resource utilization, a tool to measure that would help them achieve that goal through better prototyping.
... View more
12-14-2023
10:47 AM
|
1
|
0
|
610
|
|
IDEA
|
The current service designer has extremely limited layout controls and are almost useless for organizing flows. This idea is to suggest some level of parity with the ArcGIS Pro Model builder in terms of Groups and Auto Layouts. Current State of GeoEvent Server: Current Layout Controls Proposed to have similar functionality as model builder: https://pro.arcgis.com/en/pro-app/3.1/help/analysis/geoprocessing/modelbuilder/grouping.htm
... View more
12-14-2023
10:40 AM
|
1
|
0
|
661
|
|
IDEA
|
The ability to split incoming data based on groups or geotags seems a fairly standard process-- --especially if you are trying to populate downstream applications with the ability to filter based on a single attribute. Since much of the data streams are outside of a user's control, these processors are invaluable to split up data into a way that is usable within the downstream apps (experience builder, dashboards, etc.) which are not well-designed to ingest multi-categorical data. Since this tool is already Esri supported, let's add it into the standard installation and allow users to utilize it without the need to install the GeoEvent SDK. https://www.arcgis.com/home/item.html?id=68238a93e5fd4043ad0bbb501b265566 https://github.com/Esri/field-splitter-for-geoevent https://github.com/Esri/multi-cardinal-field-splitter-for-geoevent
... View more
12-14-2023
10:35 AM
|
0
|
1
|
979
|
|
IDEA
|
Still needed. Would love even an "under consideration" flag. @AlbertSchelin saw your article on Dashboards in Enterprise, do you have any visibility on this?
... View more
12-14-2023
06:01 AM
|
0
|
0
|
1540
|
|
POST
|
I've found a SQL-based workaround, the date field by default (at least for editor tracking) is a datetime2(7); so you can run a CONVERT or CAST to appropriately downscale the precision. CONVERT(datetime2(0), yourschema.last_edited_date) AS last_edited_date
CAST(yourschema.last_edited_date AS datetime2(0)) AS last_edited_date
-- by default the datetime2(7) is generated within a geodatabase that has a precision of 7 EDIT Spoke way too soon. After registering the field is still reading as high precision even though the type is set to datetime2(0)
... View more
12-12-2023
09:27 AM
|
1
|
0
|
5416
|
|
POST
|
Our workflow has been as follows: Create a View using CREATE OR ALTER VIEW syntax (within the GP tool and also directly against the geodatabase in SSMS) Run Register with Geodatabase GP Tool, selecting the view from the appropriate SDE connection The view we are using combines a registered point feature class with three other registered tables within the same geodatabase. We are not utilizing query layers. I'm currently running trouble-shooting to prepare for a support ticket submission to see if I can force the conversion by dictating the date format within SSMS utilizing CAST and CONVERT.
... View more
12-12-2023
08:51 AM
|
0
|
1
|
5425
|
|
POST
|
Do you have a current support ticket with Esri; if so, is there a registered defect or enhancement that our organization can attach themselves to? We re-created a registered view and it automatically cast the date field (which is not high-precision in the feature class the view is based off of) as high precision. For anyone else that stumbles across this, the above workaround did not solve our view issue, we had to delete and re-register with an ArcGIS Pro below version 3.2.
... View more
12-11-2023
02:52 PM
|
0
|
3
|
5450
|
|
IDEA
|
TLDR: ArcPy Cursors do not universally respect Context Managers; Add Appropriate Methods to the Cursor Class to enable graceful exits (discard, disconnect, close) as part of the __exit__() call. Recently an Esri blog was published detailing a relatively common "gotcha" pertaining to cursors applied against a file geodatabase: https://www.esri.com/arcgis-blog/products/arcgis-pro/data-management/locked-by-another-application-using-arcpy-and-a-file-geodatabase/ The given solution was to embed a del call within a context manager (a with statement). This idea runs contrary to the syntactic sugar abstraction that is a context manager, or put otherwise, we use a context manager to not have to worry about some of the nitty-gritty of programming details like closing files and cursors. The suggested solution is problematic as it requires a user to have in-depth knowledge of what is likely an oversight due to the long-lived nature of the ArcPy library; further compounded by the lack of documentation outside of the blog's reference. https://realpython.com/python-with-statement/ This idea is to add in certain methods within the ArcPy Cursor Class to have it conform to the Python DBA Specification (https://peps.python.org/pep-0249/); while this sounds like a lot, in reality the additions would be fairly minimal and would be similar to the solution discussed in this blog post: https://dev.to/c_v_ya/sql-cursor-via-context-manager-2gc7 Having an implementation would make the ArcPy library more robust and allow the ArcPy Cursor to behave the same way regardless of the underlying data source-- --which would be the expectation for any other library, a function to behave the same way for all the inputs it is programmed to accept. This would benefit the users as they would not need to have an arcane understanding of a library that is possibly older than some of its users; they would be able to trust that ArcPy cursors comply with context managers which is a common usage pattern since Python 2.5.
... View more
10-03-2023
08:24 AM
|
23
|
1
|
1946
|
| Title | Kudos | Posted |
|---|---|---|
| 7 | 08-21-2025 02:14 PM | |
| 20 | 07-23-2024 09:30 AM | |
| 12 | 07-09-2024 10:58 AM | |
| 1 | 02-22-2024 10:51 AM | |
| 1 | 03-04-2024 02:59 PM |
| Online Status |
Offline
|
| Date Last Visited |
2 weeks ago
|