|
BLOG
|
The code works in Python 2.7 32 bit, which ArcMap uses, and in Python 3.X 64 bit which ArcGIS Pro uses. The ArcGIS Pro Python requires that you maintain an active connection to ArcGIS Online through ArcGIS Pro to work, so whether or not you normally use ArcGIS Pro you have to periodically open it to maintain the AGOL connection for Python. The Python version you use makes no difference in how you code the dictionary Data Transfer portion of the script. You do have to enclose in parenthesis the outputs of all the print statements in Python 3.X to avoid an error. The advantage of using Python 3.X for this code is that it supports access to more than 2 GB of RAM and is much less likely to fail due to an out of memory error when you work with very large datasets.
... View more
09-03-2022
01:59 PM
|
0
|
0
|
5663
|
|
POST
|
I have a ProWindow dialog that has two buttons. One Button needs to just close the ProWindow and the other button needs to attempt to do an action and if it is successful it needs to close the ProWindow. I would use this.Close() if my buttons were implemented directly in the xaml class of the ProWindow, but I want to use MVVM and want to bind these buttons to the ViewModel and ICommand and RelayCommand. How do I set up the binding so that the button code within the ViewModel class will be able to close the ProWindow?.
... View more
09-01-2022
06:14 PM
|
0
|
2
|
1455
|
|
POST
|
I am using ArcGIS Pro 2.9.3 and have applied a rule package to a building footprint layer with almost 1 million footprint features using a modified version of the Standard Building cga in the Complete Streets example. I am trying to improve refresh performance and am looking for suggestions. I am not satisfied with the options I have tried so far. Prior versions of Pro gave Excessive Refresh Requests errors if I moved the camera in the scene before waiting for each refresh to complete using this layer. Fortunately Pro 2.9.3 seems to have fixed this behavior which at least allows the layer to complete the final refresh when I get the camera where I want it, but refresh performance is still slower than I like once I get to that point. The only suggestion I have seen in the Pro help is to limit the layer scale that will draw in the scene. I have limited the layer scale to 2 miles, which is probably the ideal scale limit for my needs. It works better than having no scale restriction, but it still takes a long time (3 to 5 minutes) for the rule to refresh whenever I pan to an area that forces the cache to reset. Even if I change the scale restriction to a significantly smaller value the refresh performance does not improve very much, and the level of improvement is not worth the limitation of what can be viewed in the scene. It seems that most of the refresh time is still being used to evaluate the vast set of features that ultimately are not displayed. I have 3D Analyst and considered converting the buildings into multipatch features, which does improve performance. If I exclude textures and colors when I build multipatches for the buildings the fgdb file is almost 2 GB, which is a reasonable size. However, I want the rule textures in the final symbology and I don't know of any way to apply the rule textures after generating multipatches it I didn't include the textures through the conversion tool. Unfortunately, if I include textures and colors when I generate multipatches the output file would be between 300 to 400 GB (I cancelled the tool when the file grew to 55 GB after about 15% of progress). That is too large to be justified. I haven't tried this option, but applying a definition query on the layer to limit the extent displayed by the layer using fields with an attribute index, like fields containing centroid coordinate values or community names, should improve performance. However, most of my users wouldn't know how to adjust the definition query when they moved beyond the initial query limits. I could setup separate scenes in advance that limit the amount the user can move, but I don't think my users would know which scene they needed to open to view a particular area given the large number of communities my jurisdiction covers. Setting up tiled layers could be done and placed in a scene, but I would think that performance would only be improved if the layers knew how to turn their visibility on or off in response to the camera position. It is unlikely my users could manually manage to adjust the layer visibility settings any better than they could manage separate pre-made scene files. I don't think there would be any improvement over using the original feature class if the user eventually ends up setting all of the tiled layers to being visible all the time. Is there something I am overlooking? I know how to program and am learning the Pro SDK, so a custom solution is possible. But I was hoping that applying some out of the box techniques would make going that route unnecessary.
... View more
08-04-2022
06:39 PM
|
0
|
0
|
547
|
|
IDEA
|
I voted for your idea and would have a use for this. Please also vote for my idea, which gives other examples of how it would be useful to be able to use Arcade for some of the parameters of other tools. Allow Arcade Expressions in Parameters of Geoprocessing Tools
... View more
07-27-2022
04:33 AM
|
0
|
0
|
3883
|
|
IDEA
|
One of the improvements introduced in ArcGIS Pro is the ability to use Arcade expressions not only as a replacement language where ArcMap used languages like Python or VB Script, such as Labels and Display Expressions, but in new places where ArcMap does not support custom expressions as inputs, such as the Symbology tab. In ArcMap, the Symbology tab only takes existing fields as valid inputs for the unique value category symbology options or the quantities symbology options, which does not allow the user to apply reclassified values or unit conversions to the values in a field without calculating over the values or adding and calculating a new field. However, in ArcGIS Pro the user can use an Arcade Expression instead of a field that can eliminate the need to create or calculate any field in the source data to accomplish symbology effects that present the data under classifications or in units of measure that are not directly stored in the source attributes. However, while applying an Arcade expression to the Symbology tab gives the appearance that the features have merged and dissolved together based on the user defined custom field values, the underlying features have not actually dissolved according to that Arcade expression and cannot be used in a geoprocessing workflow that needs an actual Dissolved feature class that is based on the case values the user custom defined using Arcade. To create the actual Dissolve feature class in ArcGIS Pro the user still needs to add a new field to the source data and calculate the values to be stored in the table prior to running the Dissolve tool. This becomes a real problem when the user has to make a copy of the source data in order to make changes to the schema and the source features class is very large and is only updated on a relatively small percentage of its features each day. The geoprocessing steps required simply to copy the source data, add the field and calculate its values are extremely time consuming and can take up the bulk of the time required to rerun many geoprocessing models if the user is trying to maintain outputs that approach anything resembling real time concurrency with the underlying large data sources. However, if I was able to use an Arcade Expression for the Summary fields or Case field in the geoprocessing tools that do aggregation, like the Dissolve tool, Summary Statistics tool, Frequency tool or Spatial Join tool, I could accomplish the same thing that an Arcade expression now can accomplish in the Symbology tab, but actually output a feature class rather than just the artificial appearance of that dissolve in a map that is only accessible in my project and not suited for further geoprocessing analysis. If Arcade was incorporated into those tools to extend the options available in the parameters that currently only accept fields as inputs, I would be able to eliminate all of the geoprocessing steps currently required to copy the source data and add fields calculated with custom field values to achieve the desired reclassified geoprocessing output. Although not all geoprocessing tool parameters may be suitable to be extended to allow Arcade expressions as alternatives to the standard validated parameter types and the introduction of Arcade into geoprocessing tools presents new challenges for validating the tool parameters, the value of the time saved by users would more than justify the effort in many cases, like the aggregation tools I mentioned. I am sure that many temporary files currently required to carry out most geoprocessing workflows could be eliminated if Arcade was introduced as an option for at least some of the existing geoprocessing tool parameters. Additionally, incorporating Arcade expressions as an option directly implemented for at least some of the geoprocessing parameters would make Arcade even more more portable and reusable across the platform and support the creation of a much larger array of outputs that not only can be used within ArcGIS Pro application itself, but can be used to create outputs that could be exported in formats that are suitable for external use in such things as Traffic Models.
... View more
07-15-2022
09:58 AM
|
7
|
2
|
1796
|
|
POST
|
The Search Forms layouts would have to undergo a huge redesign to fit in a single dockpane. A Button and combobox in the Quick Access Toolbar is working out great. The button launches the chosen search option as a modal ProWindow which has control over the application until the user either cancels the search dialog to close it or choses a valid feature or list of features and presses the Locate button, which closes the dialog and displays the features on the map. The forms do not cover valuable screen area when they are not explicitly requested by the user. My users are very familiar with how my forms behave in ArcMap and want the same experience in ArcGIS Pro. I also do not see a benefit of keeping the form available in a dockpane and having to monitor everything the user might do in the project that would force the search in progress to reset itself. The user is unlikely to know what would trigger a reset and do it without realizing why the search interface reset itself. In fact I don't know all of the possible things a user could do that should trigger a reset and don't want to try to imagine what they are or have to debug them all. While some of the forms are tall and narrow and would easily work in a dockable window, other forms have to be quite wide to be useful. I do not think redesigning those dialogs to fit in a single dockable window is really an option. I also don't want to have to control the width of the dockable window or worry that the user might resize it in a way that would make the form unusable. Anyway, here are the form designs I am trying to port which may give you a better idea of why I think using separate ProWindows is the best design. So far, all indications are that I can make that design work now that only one ProWindow is open at a time and I am no longer calling a ProWindow from within another ProWindow.
... View more
07-08-2022
09:02 PM
|
0
|
0
|
1894
|
|
POST
|
I made sure my code was fully consistent with the code you used and it worked when I launched the form directly. However, I think the issue arose due to the fact that I originally was launching the search case ProWindow from another ProWindow where the user chooses a search to launch from several search options using radio buttons. That was my original design for my ArcObjects Add-In using Windows Forms. The initial Form also did some map set up validation steps through the Search button prior to launching a given search form. However, I suspect that approach is creating too many complications in ArcGIS Pro, so I probably need to rethink the search selection part of the add-in. Would you recommend that I replace the initial ProWindow shown above with a toolbar that contains a dropdown menu of the search choices and a button that launches the appropriate ProWindow based on the kind of search chosen through the dropdown?
... View more
07-07-2022
11:10 AM
|
0
|
0
|
1915
|
|
POST
|
I am trying to run a query on a FeatureLayer in the Active Map through a button in a ProWindow, but either the code throws a Thread Exception if I try to perform a Search on the Layer outside of an async/await block or it skips over the code inside the await portion. Here is the code I have and I have tried it with and without the async/await code: private async void Locate_Click(object sender, RoutedEventArgs e)
{
String layerName = "Search PLUS Cases";
var fLayer = MapView.Active.Map.GetLayersAsFlattenedList().OfType<FeatureLayer>().FirstOrDefault(l => l.Name.Equals(layerName));
if (fLayer != null)
{
if (this.TbxPLUSCase.Text != null && this.TbxPLUSCase.Text != "")
{
Dictionary<long, string> RoadDict = new Dictionary<long, string>();
string whereClause = "CASE_ID = '" + this.TbxPLUSCase.Text.ToUpper() + "'";
QueryFilter qf = new QueryFilter();
qf.WhereClause = whereClause;
await ArcGIS.Desktop.Framework.Threading.Tasks.QueuedTask.Run(() =>
{
using (ArcGIS.Core.Data.Table PLUSTable = fLayer.GetTable())
{
using (RowCursor rowCursor = PLUSTable.Search(qf))
{
while (rowCursor.MoveNext())
{
using (ArcGIS.Core.Data.Row row = rowCursor.Current)
{
string dictvalue = row["CASE_ID"].ToString();
long v = Convert.ToInt64(row["objectid"].ToString());
RoadDict[v] = dictvalue;
};
}
}
}
});
}
}
this.Close();
}
... View more
07-06-2022
05:38 PM
|
0
|
5
|
1955
|
|
POST
|
Thanks. That is what I was looking for. Is this in the Documentation somewhere? Even if it is, I like having fundamental coding techniques like this posted in the community, since Google does a much better jobs of listing posts in response to searches than it does pages from the SDK documentation.
... View more
07-06-2022
11:59 AM
|
0
|
1
|
3052
|
|
POST
|
I am in the process of converting an Add-In from VB ArcObjects to an ArcGIS Pro Add-In written in C#. The original Add-In was designed using Windows Forms as modal Dialogs. The documentation for the Event Model and Properties of Windows Forms was easy to understand and implement for the adding and using controls on the form. The ProWindow UI template appears to be the closest equivalent to a Windows Form for the ArcGIS Pro Add-In. I have created a project with a ProWindow and added WPF controls that replicate my original Windows Form dialog, but I I don't know anything about what to do after that. The Microsoft documentation examples for WPF are causing errors and I don't understand how to connect the dots. For example, how do I add a button to a ProWindow and handle the button Click event to open a MessageBox saying the button was clicked as the stub code that I can eventually replace.
... View more
07-06-2022
11:17 AM
|
0
|
3
|
3065
|
|
BLOG
|
@LydiaRill I offer this blog and the transformations it can bring anyone's work flow completely free of charge. Our time is the most valuable thing we have and I'm just glad you took the time to share with me Your gratitude. With the time this has Blog has helped you regain, please share it with others that may benefit. If you ever go to the Esri UC conference (when it's no longer just virtual) it would be great to meet you. I'd love hear more about what this Blog has helped you to do and perhaps share more of what I've learned from the numerous ways I've used this technique in the years since I wrote this Blog. The conference is always such a great place for all of us to draw inspiration from others who love GIS.
... View more
12-09-2021
03:57 PM
|
2
|
0
|
5824
|
|
IDEA
|
As proof of the relevance of my comments, see this post: attribute-transfer-mapping-in-spatial-adjustment The esri community is the primary source of help on the real world requirements of the Attribute Transfer tool. That should be the job of the tool designers and the help authors.
... View more
11-30-2021
01:33 PM
|
0
|
0
|
3038
|
|
POST
|
Both layers have to be Selectable under the List By Selection button at the top of the Contents pane for the tool to work.
... View more
11-29-2021
04:52 PM
|
0
|
0
|
694
|
|
IDEA
|
Edit: I originally wrote that I withdrew my comments, but I am reversing that comment. I see this is about the Attribute Transfer Setup in Pro. I know my comments are relevant to ArcMap Desktop, and to the extent Pro behaves the same my comments apply. The tool won't work unless both layers are selectable in Desktop and the same is true in Pro. At least the Desktop help explains this relationship between the selectable state of the layers and the tool, but I just read the Pro help and there is no mention about it https://pro.arcgis.com/en/pro-app/latest/help/editing/transfer-attributes-between-features.htm. Since the tool simply won't work in Pro if either of the layers mapped are not selectable, the omission of this information in the Pro help for this tool is astounding to me. The restriction to only using selectable layers is frustrating to me, but I understand the behavior and can troubleshoot it. However, no one I have trained understands it and they just think the tool doesn't work as advertised and give up on it when they try to transfer feature attributes and the tool randomly (to them) works or doesn't work when they click on the source or target feature. At no point did the set up or the use of the tool explain that their layer selection settings are central to the way this tool behaves, and unless I am there to fix it for them, they give up. At minimum an additional comment at the bottom of the setup screen should be included that reads something like: "The Layers mapped should be selectable under the List By Selection Contents button" This would give my users a clue about why the tool doesn't work, since if they do try to do any troubleshooting, they usually check their field mapping settings and would see this essential comment about the tool's behavior and where they should look to fix it.
... View more
11-29-2021
12:40 PM
|
0
|
0
|
3086
|
|
POST
|
I reexamined your methodology and think there my be an alternative explanation of this behavior that still involves the difference in the behavior of a layer attribute join and the export of that join. The Attribute Join of a layer in Arcmap is in reality a one-to-one join that only considers the first record in the one-to-many relationship when it applies the definition query. So if the first record it encounters does not meet your query criteria the record is filtered out, even if the second record of the join would have met your criteria. However, an export examines all records in the joined table and will include matches that fail to meet your criteria on the first record, but succeed on the second record or any other records than the first. The export may also create duplicates of the Census Blocks if more than one record in the join table meets your query definition (if the inputs of the join came from the same file geodatabase this duplication of records would definitely occur). Both methods can produce incorrect results for what you want to achieve, which makes the use of ?-to many joins unreliable and unsuitable for this kind of analysis. The proper way to do this analysis to ensure all records that meet your criteria are included and no duplication happens is to do the following steps: Create a definition query in the broadband shapefile to show only Census blocks at 25/3 or greater. This reduces the size of the attribute table from 982,015 records to 654,582 records. Perform a Summary on the Census Blocks field of that shapefile to get a table that contains only one record for each unique Census Block value. You could include the first and last or min and max values in the 24/3 fields in the output, but that is optional. Then perform an attribute join of the Census Block shapefile as the target table to the Summary output as the join table, keeping only joined records. Both the Attribute Join and the export will show the same number of records that the Summary table contains (provided all of the Census Block shapefile features are in fact unique) since both will be the output of a true one-to-one join. This methodology will reliably and consistantly give the sum of households for all Census Blocks that actually meet your criteria. MS Access would also require you to do the same step of creating a Summary query first, and then using that summary output for creating a one-to-one relationship with the Census Blocks in order to get the sum of households you want, so this is the standard database methodology for solving this problem. MS Access is incapable of providing you with the sum of households you want directly from any ?-to-many relationship.
... View more
11-25-2021
12:35 AM
|
0
|
0
|
1257
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-31-2025 03:25 PM | |
| 1 | 03-28-2025 06:54 PM | |
| 1 | 03-16-2025 09:49 PM | |
| 1 | 03-03-2025 10:43 PM | |
| 1 | 02-27-2025 10:50 PM |
| Online Status |
Offline
|
| Date Last Visited |
Thursday
|