Latest Contributions by WrightKennedy

@JohnFix2 Hey John - I'm just now revisiting the thread after ESRI removed the legacy tool "Create Address Locator" from AGP 2.7.  I believe I've found the issue with reintegrating the edited json file (settings.json) into the locator package (.loz). By default, 7z compresses files even if they were originally stored in the archive. The screenshot shows my edited "settings.json" in 7z and highlights that 7z used Deflate when re-adding the file to the archive. To fix this, I unzipped the original archive (.loz), edited settings.json ("side-offset":0,), saved the json file, and used 7z to archive the files  (Archive format: "zip"; Compression level: "Store"). The file name needs to match the original file name exactly. Afterwards, edit the file extension from .zip to .loz. Here's a quick summary of how I've changed the offset settings in the new Locator format: Unzip .loz file Edit parameters in settings.json and save For my purposes, "side-offset" and "end-offset" You can also change the weighting parameters for the locator Use 7z to package all of the files and use file name identical to original .loz file name Archive format: zip Compression level: Store Change extension of .zip archive to .loz Geocode   NB During testing I found that setting the side-offset to 0 still left a small offset in the geocoded point. This may be caused by rounding errors in my reference dataset coordinate system or something along those lines. ... View more

I wanted to chime in to second George Brown's call for the previous locator options in the new Locator properties. My project is stuck between the older Create Address Locator tool and the newer Create Locator. The Address Locator allows for a user-specified side offset but consistently fails when the source dataset is a feature service layer. Additionally, it doesn’t have the new option (at least that I can find) to “Match out of range” (different from “Match without House Number”). The new Locator usually works on feature service layers but does not allow for easy customization in decision-making or geometry output (such as a user-specified side offset). For me, the important options locked in the new Locator properties are as follows: Side offset [e.g., we geocode houses marked as “rear” farther off the streets than main houses] End offset [e.g., we geocode differently for different street widths: Avenues vs. Streets] Spelling sensitivity [e.g., some addresses we geocode are from poorly OCR’d text, so this is useful] Match if best candidates tie [e.g., so we can identify ambiguity and be more confident in results] Intersection connectors [e.g., multiple types, sometimes unique, used in address listings] Bonus: Geocoding with the “Match with no zones” option turned off does not seem to work in the new Locator. This seems to fail to return matches more consistently when using numbers stored as text (e.g., FIPS) for zonal fields (i.e., city, state). The other options in the old Address Locator properties are convenient and sometimes save time, but we can work around them by preprocessing the event dataset (or making changes in the json settings file). Another, more general point about the new locator options in ArcGIS Pro: I’m frustrated with the move towards a “black box” locator. I see many of these settings are still in the Locator file (settings.json), but why remove accessibility in ArcGIS Pro? Professionals want transparency in and control of their methods. Turn-key solutions make sense for ArcGIS Online but not for the “Pro” version of ArcGIS. ... View more

Just a heads up: after upgrading to ArcGIS Pro 2.3.0, I have found that the issue I documented earlier in this thread (Jul 22, 2018 10:49 AM) still exists. When a user opens the calculate field geoprocessing tool by right-clicking on a field name in the attribute table and selecting "Calculate Field", the "Input Table" defaults to the first instance of the two identically-named feature layers. This happens regardless of the table used to open the field calculator tool (e.g., opening Calculate Field from Layer:2 attribute table still defaults to Layer:1 in the geoprocessing tool). It would help to have continuity between the geoprocessing input table name + suffix number and the layer name/attribute table name. So if two layers are named Example, the attribute table for Example layer 1 (by hierarchy in the Contents pane) would be named "Example:1" and the attribute table for copy 2 would be named "Example:2". ... View more

I'm surprised this is marked as "Answered." The "answer" (i.e., Disable/Enable Editor Tracking) does not work for Feature Service layers. We are having the same issue -- we cannot disable editor tracking on the hosted feature layer with ArcGIS Pro. While this can be done on the item's detail page in AGOL, the fields remain read only online and in ArcGIS Pro, which prevents edits to the tracking fields. ... View more

Thanks for the suggestion. Yes, this is specifically for the issue of limiting a field calculation to the selected features in a feature class (the OP's question) when multiple copies of the same feature class are in the map as different layers (my guess at the reason for the OP's issues). Using the file browser to select an absolute path for the Input Table ignores all selections (as expected, and as it worked in ArcMap when calculating a field from ArcToolbox). In ArcMap when you have multiple copies of the same feature class and you calculate a field from the Field Calculator (right click on a field name > Field Calculator), the field calculation only applies to the selected records in the table from which you opened the field calculator (regardless of duplicate layers). ArcGIS Pro is causing problems because when you follow the same steps (right click on field name > Calculate Field), the default Input Table is not necessarily the table and selected records from which the tool was opened, but instead the first instance of that layer name found in the Contents panel (former Table of Contents). The other very tricky thing I just found is that if you are working from the python line, if you use Send To Python Window (or Copy Python command) from Geoprocessing history, even if the Calculate field ran on the selected features from the correct Input Table (e.g., "StatesTest:2" from above screenshot), the field calculation runs on the first instance of the feature class in the Contents pane and whichever records are selected in that layer, since python doesn't include or allow (that I can tell) the ':2' notation that works in the Calculate Feature tool. tl;dr Don't have layers with the same names, but if you have to have them, put them in group layers with different names. (you can do even more damage without realizing it if you use Calculate Field when ToC includes different feature classes with the same layer/alias name) ... View more

I've finally had a chance to look at this again. I think the issue here is confusion about which table is which. The bug, from what I can tell, is that the Calculate Field tool always sets the Input Table default value to the first instance of the feature layer no matter the table used to open the tool. Rather than trusting the default value, if the Input Table value is set to the correct table, the field calculator works as expected on selected fields. When you switched to the "other table," you actually switched to the table from which you opened the tool. See screenshots below: Figure 1. Right click and open Calculate Field from StatesTest:1. The default Input Table is StatesTest:1. Figure 2. Right click and open Calculate Field from StatesTest:2. The default Input Table is still StatesTest:1 Kory, please let me know if there is a separate bug related to the Calculate Field tool and selected features, or if the Calculate Field - Input Table default value is the root of the trouble. ... View more

I haven't been able to reproduce the error or the issue you documented. I just updated to 2.1.3 in the past week, but I didn't see anything in the change log about this. Are you in 2.1.3? ... View more

It occurs when multiple copies of the same source feature class are in the map. Aliases don't seem to matter. ... View more

Recently, I had the same problem in AGP 2.1. Here's what I found: Calculate Field ignored the selection parameters when calculating a field in a feature class that was included multiple times in the map. Once I removed the copies of the feature class, Calculate Field worked as expected (calculated only the selected features). Hope this helps, and hope ESRI documents/fixes this! ... View more