|
IDEA
|
@Bud the condition with duplicate OIDs caused by a 1:M join cannot be known until the data is completely read, so this is not possible to "disallow" such layers from being used as input. We have found that some tools error under this condition, while others use the first record in the set of duplicate OIDs, while others do other things. All of these specific behaviors based on different tool implementations cannot be explained in full detail in a documentation topic like you highlighted from Add Join, thus the generic "can produce unexpected results". We have internal development enhancement issues logged to support dynamically generating unique OIDs for the case of 1:M joins, which will work around any limitations there may be for geoprocessing tool algorithms that require unique OIDs. This idea in the current state is not actionable, but if you want to change the idea or enter a new idea for some tools that you have used to support 1:M join layers as input without duplicating the OIDs, we can make a match to our internal development issue.
... View more
05-22-2024
03:48 PM
|
0
|
0
|
1220
|
|
IDEA
|
@rgeorge9935 all geoprocessing tools, including XY Table To Point, leverage a system in ArcGIS Pro called the text file workspace for reading CSV, TXT, and other delimited files as a table. The same text file workspace is used when you open the attribute table in ArcGIS Pro for a standalone table with the same delimited file source. If you were to add the same delimited files to Pro, the attribute table would not recognize that the column headers are located in a different row. For consistency and code maintainability, we will not introduce tool-specific changes as you described to a tool like XY Table To Point. Depending how you want to move forward there are two options for managing the feedback you raised in this idea: 1. Edit the idea title and label so that the requirement is more generally that Pro's delimited file/table handling should allow the user to specify the row header, and not specific to the XY Table To Point geoprocessing tool. 2. If you prefer, this specific Idea can be closed, since as-written it cannot be implemented, and you can raise a new Idea with a similar theme about Pro generally supporting delimited files where the column header is not in the first row.
... View more
05-17-2024
02:04 PM
|
0
|
0
|
1242
|
|
IDEA
|
05-17-2024
01:49 PM
|
0
|
0
|
1059
|
|
IDEA
|
The Copy tool can copy data elements between workspaces of the same type, for example copying a valid annotation feature class from one file geodatabase to another. The documentation for Copy will be clarified.
... View more
05-17-2024
01:32 PM
|
0
|
0
|
2612
|
|
IDEA
|
@Bud Sweeping ideas that cover multiple functional areas like this cannot be tracked or implemented. It takes specific effort per tool to support a processing extent. I suggest you update the idea to be specifically about the tool Register with Geodatabase, which will be assigned a Geodatabase label and can be left open. If you prefer to enter a new idea to cover that, this idea will be closed.
... View more
05-17-2024
01:29 PM
|
0
|
0
|
1073
|
|
IDEA
|
05-17-2024
01:23 PM
|
0
|
0
|
1541
|
|
IDEA
|
@MErikReedAugusta as others indicated, using SQL as the expression type for Calculate Field is the only way to improve the performance of calculations done with hosted feature services. Either the Python or Arcade options require Pro client-side calculation, which as you indicated is slower to read and write the updates to the hosted data source, compared to local geodatabase data. The Calculate Fields (Multiple) tool also can use SQL expressions for batches of calculation, which will be even faster than running several sequential Calculate Field tools in a script.
... View more
05-17-2024
01:19 PM
|
0
|
0
|
1371
|
|
IDEA
|
05-17-2024
01:15 PM
|
0
|
0
|
740
|
|
IDEA
|
The idea was marked as Already Offered based on the arcpy.metadata command to delete geoprocessing history, which has been available for several releases. The enhancement in Pro 3.3 supports a UI to accomplish the same goal through the metadata editor.
... View more
05-13-2024
05:30 PM
|
0
|
0
|
2991
|
|
IDEA
|
I want to bring up that the default output location for geoprocessing tools is by default set to the project's default geodatabase, but this can be configured to any location by setting the Geoprocessing Environments workspaces. A few folks that described what they want in this thread could benefit from setting their scratch workspace to their preferred location, which will make the default output paths generated in that location rather than the project geodatabase. https://pro.arcgis.com/en/pro-app/latest/tool-reference/environment-settings/scratch-workspace.htm
... View more
05-08-2024
11:45 AM
|
0
|
0
|
2624
|
|
IDEA
|
@Zameskalo @SteveCole the new idea you submitted and commented on has been merged with this existing idea, and like @SSWoodward points out it was implemented in ArcGIS Pro 3.1.
... View more
05-02-2024
12:10 PM
|
0
|
0
|
3625
|
|
IDEA
|
New options are being added to the Package Map and Consolidate Map geoprocessing tools in ArcGIS Pro 3.4.
... View more
04-23-2024
05:10 PM
|
0
|
0
|
3950
|
|
IDEA
|
A direction field is provided in the output feature class created by the Geotagged Photos To Points tool. https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/geotagged-photos-to-points.htm If there are additional photo properties that are desired to be maintained in the output feature class's attribute fields, please log them as additional Ideas.
... View more
04-22-2024
11:21 AM
|
0
|
0
|
1682
|
|
IDEA
|
@Michele_Hosking thanks for your feedback. I observed the same error you described when one of the fields in the template table already exists in the input table. This is a defect, which has been logged with Esri Support as BUG-000166581. This bug does not cover your feedback that you'd like to selectively choose which fields to add. If you are looking for that capability I think it might be better to use scripting. For example, you can specify the a list of fields to exclude (my list is Name and Type), while adding the remainder of fields to the input based on fields from the target. exclusion_list = ["Name", "Type"] #Update with your field names to exclude
field_list = []
for field in arcpy.ListFields('Template_Table'): #Update with your template table name or path
if not field.required:
if not field.name in exclusion_list:
if field.type=="String":
field_type = "TEXT"
elif field.type=="Integer":
field_type = "LONG"
elif field.type=="SmallInteger":
field_type = "SHORT"
elif field.type=="Single":
field_type = "FLOAT"
else:
field_type = field.type
field_list.append([field.name, field_type, field.aliasName, field.length, field.defaultValue, field.domain])
arcpy.management.AddFields('Input_Table', field_list) #Update with your Input Table name or path
... View more
04-08-2024
04:12 PM
|
0
|
0
|
4162
|
| Title | Kudos | Posted |
|---|---|---|
| 3 | 03-22-2024 09:27 AM | |
| 2 | 03-08-2024 01:56 PM | |
| 3 | 02-21-2024 11:58 AM | |
| 1 | 05-09-2023 02:24 PM | |
| 3 | 02-27-2023 05:23 PM |
| Online Status |
Offline
|
| Date Last Visited |
Wednesday
|