POST
|
Thank you for the information. This helped me get on the right track of knowing what I'm looking for and where to look. And as a note for anyone else who may stumble across this, Josh Carlson's post helped me then find the post https://community.esri.com/t5/arcgis-api-for-python-blog/using-the-arcgis-api-for-python-to-create-a-view/ba-p/902966 which ended up getting me what is a starting point for the solution I'm likely to end up using for this (essentially, creating the view layers from the ArcGIS Python API directly instead of trying to manually create the first one in the UI and then find a way to copy and alter the view layers).
... View more
05-12-2023
02:57 PM
|
0
|
0
|
364
|
POST
|
I've published Feature layer (hosted) to ArcGIS Online from ArcGIS Pro (3.1.1). The feature layer contains a number of individual data layers for a large region. I'd like to create individual Feature layer (hosted, view) for some of the layers for each individual county within the region where the data is queried by county name. What I'm hoping is that someone can help me with a more efficient workflow than manually creating these view layers for each individual county. All of the view layers will end up being the same except in the attribute filter on the view layer the county name will be different. I've seen in the ArcGIS Python API that you can copy various items from one organization to another for staging/production migrations and such, but I've not seen anything specifically for doing what I'm talking about with duplicating a view layer within an organization that keeps a reference to the same source hosted layer. I may just have been using the wrong search terms though. I'm ok manually updating the specific county name in the attribute queries if I need to, but I'd prefer to not have to manually duplicate the entire process including field settings, description, and other view layer customizations for every county if someone has an alternative. Any suggestions would be appreciated.
... View more
05-12-2023
09:35 AM
|
0
|
2
|
416
|
POST
|
As an update, regarding the auto-field mapping of the editor tracking fields specifically, ESRI has officially logged a bug. BUG-000157802 Synopsis: The Field Map in the Append tool do not recognize the matching fields of a layer with Editor Tracking Enabled in ArcGIS Pro
... View more
04-26-2023
01:33 PM
|
0
|
0
|
566
|
POST
|
Thank you very much for getting this fixed! I updated and it appears to be working! Also, as an FYI, I did happen across another slight difference that has an easy work-around, so it's not a problem, but I figured I'd pass along anyway in case it's helpful. In 2.9.5, I had a DataLoadingWorkspace with some target dataset mappings having text fields configured with an expression like: !SourceTextField![:50] in order to trim a longer source field down to the target field's field length. For those fields, when the source dataset's value was Null, it would simply set those fields for those features to Null as well. However, when moving to 3.1.2 (I didn't check specifically at 3.1.1) it ended up erroring out. I was able to isolate it to this particular issue since only changing all occurrences of those expressions instead to: !SourceTextField![:50] if !SourceTextField! else None appears to have fixed the problem and it's running without errors again. Like I said, this isn't really a problem as it has an easy fix that makes it a better Python expression anyway, but, I found it an interesting difference in how 2.9.5 vs 3.1.2 DLT appears to be handling Null values or Python Expression type errors or whatever specifically is going on behind the scenes in DLT, so I'm just passing it along. Anyway, thank you again very much for the expedient help getting this issue resolved! I have made a lot of use of the DLT solution throughout a number of my workflows, so, having this operating correctly again in the updated version is great! Thanks!
... View more
04-19-2023
08:39 AM
|
0
|
0
|
485
|
POST
|
Thank you, I appreciate the information and look forward to the update!
... View more
04-17-2023
10:14 AM
|
0
|
1
|
514
|
POST
|
After upgrading from ArcGIS Pro 2.9 to 3.1.1 I am experiencing some issues with the Append GP Tool that appear to be undocumented and are causing problems for a number of existing geoprocessing workflows, including various scripted workflows. So, I'm trying to find out if this is a bug that is planning to be corrected, was an intentional change, or otherwise get more information so I can plan accordingly. In the past, both in ArcMap and in ArcGIS Pro through at least v2.9 (I jumped right to 3.1.1, so I do not know at intermediary versions like 3.0 what the behavior is), if you opened the Append GP tool interactively, and set the "Field Matching Type" to "Use the field map to reconcile field differences", the auto-populated field map, in my experience, would auto map any source dataset fields to a target dataset field with an exactly matching field name. However, now in ArcGIS Pro 3.1.1, some fields where there is an exact match in the field name, type, and length between the source and target datasets aren't auto-matching any more. I can confirm from personal testing that any fields in the source dataset that are configured as Editor Tracking fields but the corresponding field in the target dataset is not, are not auto-matched any more, where they were previously. The post at https://community.esri.com/t5/data-management-questions/append-data-management-gp-tool-field-mappin-fiald/m-p/1267945 suggests that this is also affecting fields with Attribute Rules configured in the source dataset but not in the target dataset, again even when the name and properties all match. Now, I know, when running the tool interactively, you can visually identify these with the "(0)" next to the field and then manually configure a field match; but frankly, that's a degradation in ease of use in the newer version of the software, which seems a poor choice by itself. However, the issue really comes in where the Append tool is used in existing scripted workflows, such as automated tasks to take data from a number of local source datasets and append them into a single regional dataset for example. In my case for example, the source and target datasets contain overlapping sets of fields with the same name, type, length, etc... (each may have additional fields not found in the other, but they contain a core set of fields that are the same). However, since the source datasets are directly edited by users and the regional (target) dataset is not, editor tracking is enabled on source datasets but not on target dataset, so the editor tracking data from source datasets can be preserved in the target database; though now these fields in my target dataset are Null after the 3.1.1 upgrade. In the past, based on how the Append tool worked, if in the script you passed sources and the target with the "schema_type" property set to "NO_TEST", it would automatically append all data from the source fields into the identically named target dataset fields where there were identically named fields, without any explicit creation of or customization of a FieldMappings (and any fields without identical field names in both would simply be ignored). In v3.1.1 however, this no longer is the case, and some fields, as noted above, even though they are identically named and with the same properties, no longer auto match. So, since ESRI is typically pretty good about maintaining backwards compatibility through changes to GP tools and there is no documentation I've been able to find specifying this functionality was intentionally removed, I'm left wondering if this is a bug or if I'm missing something or what. However, since this is breaking existing workflows, is causing errors in other ESRI solutions (see https://community.esri.com/t5/data-loading-tools-questions/issue-copying-from-editor-tracking-fields/m-p/1278849), and there is no documentation related to it, I was hoping someone could chime in with a bit more information about this issue so I can downgrade my software for now, rewrite my scripts, or otherwise plan accordingly?
... View more
04-17-2023
09:43 AM
|
1
|
2
|
636
|
POST
|
So, after playing around with it a bit more, it appears it is in fact still having the same issue, even with the AppendWithTransformation tool. However, I've narrowed it down a little. When I do a very simple run, where every target field has a source expression of !SourceFieldName! there's no issues. However, if there's a more complex expression in one of the fields ex: !SourceFieldName!.split('-')[0].strip() if !SourceFieldName! else None then the other field map for fields in source dataset that are editor tracking fields ex: TargetField: CreationUser | Expression: !CreationUser! don't copy values into those fields (in above example: CreationUser field in target dataset is empty, even though source dataset has values. Not sure if this helps, but hopefully. Please let me know if there's anything else I can provide to help get this fixed!
... View more
04-14-2023
02:59 PM
|
0
|
0
|
533
|
POST
|
I sent a direct message with Data Loading Workspace for testing. As an update, for now, as a work-around, the current project is pretty simple field mappings, so I've migrated them to use the AppendWithTransformation with the same mappings copied over.
... View more
04-14-2023
10:42 AM
|
0
|
0
|
540
|
POST
|
I upgraded from ArcGIS Pro 2.9 to 3.1.1 and at the same time updated dltsolutions to the 3.1.1 version in Package Manager. After the update however, some fields are not copying data over. In a Data Loading Workspace, where there are fields in the source dataset that have Editor Tracking enabled on them, and they are added in the data loading workspace for a particular target dataset as an expression (ex: TargetField: CreationUser | Expression: !CreationUser!) it fails to copy any data over into those fields in the target dataset now after the update. To clarify some details: It was copying over all data correctly until the version updates. All other fields are copying over correctly, it's only where the source field is used for editor tracking that it's not copying the field value The corresponding field in the target dataset is NOT configured for editor tracking (Editor Tracking is only enabled in the Source Dataset) From limited testing, this same error behavior does NOT occur via the Append with Transformation tool, only via a Data Loading Workspace. Am I missing something or has anyone else encountered this and found a work-around?
... View more
04-14-2023
07:11 AM
|
0
|
7
|
577
|
POST
|
I'm not familiar enough to know personally if there is a solution exactly as you are asking for. I do wonder however, as a work around, if it would be sufficient to add an optional input parameter of a text file. You could have the text input as-is they can use if the text is short enough or allow them to input a basic *.txt file as an input otherwise for longer/multi-line text. Not sure if that would really meet your needs or not, but, figured I'd at least throw it out there in case it helps.
... View more
01-06-2023
02:53 PM
|
0
|
0
|
650
|
POST
|
Thank you for the update. I appreciate and will be on the lookout for the July update then!
... View more
06-27-2022
06:11 AM
|
0
|
0
|
791
|
POST
|
I was just wondering if anyone knows if DLT is already compatible with or will be upgraded to be compatible with ArcGIS Pro 3.0? From reading the release info on Pro 3.0 and 2.X to 3.0 migration documentation, it makes me wonder how compatible DLT is with the changes. Any insight on if this has been tested, is planned for update, etc... would be helpful in making plans for any changes to our workflows and changes to our software versions.
... View more
06-24-2022
02:48 PM
|
1
|
5
|
830
|
POST
|
I'm not in a position to test out your specific code at the moment and I'm not personally that familiar with the CreateFishnet tool, but just from a brief review, it looks like CreateFishnet outputs a feature class. You are then trying to use that feature class as the input to SelectLayerByLocation. However, SelectLayerByLocation does not actually allow feature classes as an input, only layers (of feature classes). So, while there may or may not be other problems causing the issue, at the very least you should consider adding Make Feature Layer tool (https://pro.arcgis.com/en/pro-app/2.8/tool-reference/data-management/make-feature-layer.htm) before SelectLayerByLocation. And use that newly created layer as the input to SelectLayerByLocation and DeleteRows. Then, to keep from having a bunch of temporary layers in memory (which can cause issues if you have multiple layers with the same exact name), I would add Delete tool (https://pro.arcgis.com/en/pro-app/2.8/tool-reference/data-management/delete.htm) after DeleteRows to delete the temporarily created layer.
... View more
05-18-2022
03:00 PM
|
1
|
1
|
738
|
POST
|
I'm looking to set up some single machine ArcGIS Enterprise implementations and was hoping to be able to get away with using Enterprise Builder for a pretty standard base deployment. We were also looking at using gMSA (Group Managed Service Account) for the service account. I'm wondering if anyone knows if I can use this kind of an account upon initial install of Enterprise Builder or not. And, if I can't use a gMSA during install and have to change it manually to a gMSA later, will that cause any issues when running Enterprise Builder in the future to update to later versions (as I understand you can just run a new version of Enterprise Builder to upgrade all components to a new version). We'd be initially installing at 10.8.1, but want to plan for an upgrade path for when such becomes available. Any feedback regarding gMSA w/ Enterprise Builder would be great, thanks!
... View more
05-03-2021
12:08 PM
|
0
|
1
|
468
|
Title | Kudos | Posted |
---|---|---|
1 | 04-17-2023 09:43 AM | |
1 | 06-24-2022 02:48 PM | |
1 | 05-18-2022 03:00 PM | |
1 | 03-29-2018 09:18 AM | |
3 | 05-23-2019 12:20 PM |
Online Status |
Offline
|
Date Last Visited |
05-12-2023
10:57 PM
|