Latest Contributions by ShanaBritt

I would also suggest a composite locator, but comprised of locators created with the General - Gazetteer locator style and General - City State Country style where you map Name, Category, and Sub_Cat to City, State, Country. The Single Field style has a memory leak bug when published as a service, which does not exist in the Gazetteer locator style. If the data you have has address components, use the US Address - Single House locator style and include the locator in the composite. ... View more

It sounds like you are running into BUG-000116323. ... View more

Michael: The link I copied from my post worked for me. The script is checking for functionality that is not supported in ArcGIS Pro, but the topic does include links related to converting from Python 2 to 3 such as https://docs.python.org/3/library/2to3.html and tips for migrating from 10.x to Pro. Python migration from 10.x to ArcGIS Pro—ArcPy Get Started | ArcGIS Desktop. the GeocodeAddresses gp tool has no parameters regarding the fields in the output feature class, so modifying the feature class related fields would have to be manual. ... View more

Michael, The difference in the output schema between ArcMap and Pro is not caused by the style, it is a difference in the underlying code for when the output feature class is created between ArcMap and Pro regardless of the version of the desktop application. When you geocode with ArcMap regardless of the version of the locator style you will get "Arc_" fields and with Pro you will get "IN_" & "USER_" fields in the output feature class. You may want to check out this topic for converting your 10.x scripts to ArcGIS Pro.  http://pro.arcgis.com/en/pro-app/tool-reference/data-management/analyzetoolsforpro.htm ... View more

If you are using the same 10.3 locator in ArcMap 10.5.1 and Pro 2.2.1 you should be getting the same results, the output fields will be slightly different where ArcMap will have "Arc_" fields, which are used during the geocoding and rematching process. Pro will have "IN_" fields, which are equivalent to the ArcMap "Arc_" fields and "USER_" fields, which are the original fields from the input address table. See the first paragraph under the image in this Pro topic About geocoding a table of addresses—ArcGIS Pro | ArcGIS Desktop and in the ArcMap topic About geocoding a table of addresses—Help | ArcGIS Desktop  ... View more

Kimberly: 1. You did everything correct by mapping the municipality to the additional user field when building the locator. You are probably missing the step where you turn on that additional field in the output. You want the additional field and any other output settings turned on before you publish the locator as a service. When the locator is added to the project in ArcGIS Pro, right-click the locator and select Locator Properties. You will want to change the 'Write user-specified additional output fields" property to yes. About modifying a locator's settings—ArcGIS Pro | ArcGIS Desktop  2.The spelling sensitivity is located on the Geocoding options page of the Locator Properties, but I would not adjust it just to get those 4 addresses to match. I would do one of two things: a. Launch the Rematch Addresses pane to see if candidates are available and if not, just modify the street type value and select the highest scoring candidate returned. Rematch geocoding results—ArcGIS Pro | ArcGIS Desktop  b. Open the attribute table of the geocoded result and change the 'La' to 'Ln' in the field named In_Address for the 4 records. It's the field that starts with IN_ and contains the input address, this is the field that is used during the geocoding process. Then launch the Rematch Addresses geoprocessing tool and specify a query that would select those 4 records that were modified and run the tool. The tool would rematch only those four records that were modified. ... View more

Our current plans do not include a hotfix or patch for Server 10.5.1 for the General - Single  Field style based locator with the memory leak as there is a workaround of using the Gazetteer locator style that has better logic than the Single Field style. ... View more

Michael: Any locator with a style release prior to 10.5 will have less (different) output fields than a locator created with style release 10.5+. Style release 10.5 is when there was a major change in the styles, especially the Single House Subaddress style. The change at the time was to add the improvements that had been made to the online World service to the out of the box styles and fix performance issues with the Single House Subaddress style. The locator styles included with ArcMap and Pro have the same style release. ... View more

Michael: Which version of ArcMap were the locators originally created in? Which version of Pro are you using? ArcMap 10.5 / ArcGIS Pro 1.4 was the release where the address locator styles changed, which included additional output fields. Some of the Python changes are described in the following blog. Geocoding Improvements and Deprecations in ArcGIS Desktop 10.5 and ArcGIS Pro 1.4  The address locator styles included with ArcMap and ArcGIS Pro are the same and the expectation is that a locator created in ArcMap will work in ArcGIS Pro and a locator created in ArcGIS Pro with the Create Address Locator tool will work in ArcMap. There may be times where the locator style included with ArcGIS Pro is more current than the one installed with ArcMap because the two applications are on different development cycles. A problem might be found in ArcMap after its cycle ends, but we are able to get the fix in the Pro. Then the following ArcMap release will include the fix. At version ArcMap 10.6.1 and Pro 2.2 the styles are the same. ... View more

Kevin: I'll need to search for the bug report to see which version the zooming behavior was addressed for the locators, it might have been specific to the Single House Subaddress style, but will double check. I would definitely move away from using the General - Single Field locator style as it acts as a lookup of exact matches and doesn't use the same indexing, parsing, and spelling sensitivity logic as the US Address locator styles. Also, the Single Field locator when built with suggestions causes a memory leak on server and would suggest using the General—Gazetteer locator style for searching for place names, points of interest, well IDs, parcel numbers, etc... that are not address house numbers or street intersections. See the 'Applications' column in the table of the commonly used locator styles in the following topic http://desktop.arcgis.com/en/arcmap/latest/manage-data/geocoding/commonly-used-address-locator-styles.htm -Shana ... View more

Kevin: The new locators that you will be able to create will not have what you described as a "ghost address" when typing and suggestions are returned. I'm not sure if they will address the problem in WebApp Builder or if WebApp Builder is a separate issue. What is happening in the current locators is that when you create the locator with suggestions enabled the street name is indexed, but house numbers and subaddress units are not indexed, so there is no correlation between the street name and the house number or subaddress unit. So when you type a house number that does not exist for that street segment, the locator returns an invalid suggestion candidate from a line segment in the reference data that does have a house number of 149. I believe we fixed that part where you click on the invalid suggestion and it zooming to a different location at either version 10.5.1 or 10.6. What is the reason you use the Single Field locator style for address points vs US Address—Single House and Single Field locator style for centerlines vs US Address—Dual Ranges ? ... View more

Gelcys ArcMap 10.5 includes the US Address - Single House Subaddress locator style that will allow you to create a locator using points or polygons as the reference data and can reference subunits in a single field or two fields for unit type & unit number. At version 10.1, there was a customized locator style floating around on the forums that supported units, but it was not one that was out of the box. An out of the box style for geocoding subaddresses was introduced at version 10.3 and since that version improvements have been made to the style that affect performance and standardization. ... View more

You could have the full street name in a single field in the reference data and map that field to Street Name when you build the address locator. When the address locator is built parsing occurs and that is what is indexed in the .lox file. When you geocode the address it should match, but you may see that the parsing might be different. You would be able to see this if using the Find tool. ... View more

It is possible to geocode a table of addresses using a single field that contains the full address/location or multiple fields with the components of the full address split across multiple fields when using a locator based on the US Address - Singlehouse locator style as well as other street address level locator styles (Dual Ranges, One Range, Singlehouse Subaddress, Street Name) . The table should be formatted as follows if you are going to use multiple fields, where the house number and street name are in a single field and city, state, zip code are in separate fields. If your existing table only has one field in it that contains the full address "380 South Valley Drive, Laguna, CA 92112" and no other fields and the address locator was created without city, state, zip mapped, this is the reason you only see one field when you select the Multiple Field radio button. If you create your locator with city, state, zip mapped, then you will see those zones listed in the Input address fields section of the locator properties. Locator input address fields properties—Help | ArcGIS Desktop  Is the address on "South Valley Drive" getting matched to the correct location when geocoded? ... View more