Latest Contributions by ShanaBritt

Kevin: Have you checked if any of the locators that are participating in the composite geocode service are running into the issue described in https://support.esri.com/en/technical-article/000011688? This is the first thing that comes to mind regarding your example when typing the street address with zip and municipality, but not getting candidates when only the street address is provided.  ... View more

Brian, Sorry for the delayed response, I've been busy with finishing up certifying the next release of ArcGIS Desktop and needed to mock up some of the data based on your screen shots to determine what was wrong and how to fix it. 1. The reason "1625 Jaywin Circle" didn't match was because of the fields you used for field mapping when building the address locator, which was based on the 'TYPE_SHORT' field. This field contained and abbreviation ('Cl') for "Circle" that was not part of the street suffix type aliases grammar in the address locator style.Aliases provide a mechanism to support word substitution beyond what is provided by spelling substitution. Whichever alias form is found in the reference or input data is treated as equivalent. Below is the alias section for Circle in the grammar for the address locator style which does not include 'Cl'. If you had used 'ROAD_TYPE_FULL' field when building the locator searching for "1625 Jaywin Circle" would have found a match in the Locate pane. Before: <def name="_ST_Circle" is_alias_list="true"> <alt>Circle</alt> <alt>Cir</alt> <alt>Ci</alt> <alt>Circulo</alt> <alt>Circ</alt> <alt>Circl</alt> <alt>Corcle</alt> <alt>Cr</alt> <alt>Crcl</alt> <alt>Crcle</alt> <alt>Crl</alt> </def> If you use this article as a guide, you can modify the address locator template to add the 'Cl' abbreviation to the Circle street suffix type to look like the following.How To: Add city aliases to the address locator style  At step 2 in the article search for "suf_type_ext" then scroll down or search for "Circle" until you get to the section I referenced above. After modifying the USAddress.lot.xml recreate the address locator and you should be able to get matches in the Locate pane and when geocoding the table if the street suffix type in the input address is 'Circle' or 'Cl'. After: <def name="_ST_Circle" is_alias_list="true"> <alt>Circle</alt> <alt>Cir</alt> <alt>Ci</alt> <alt>Circulo</alt> <alt>Circ</alt> <alt>Circl</alt> <alt>Cl</alt> <alt>Corcle</alt> <alt>Cr</alt> <alt>Crcl</alt> <alt>Crcle</alt> <alt>Crl</alt> </def> 2. Here are some screen shots to clarify my previous explanation about which fields in the reference data in your screenshots that could be used for building the locator. It is not required to map Full Street Name in order to get matches when geocoding, it is only used as an output field when batch geocoding. It's there to use for labeling if you did not had a field that could be used for labeling the geocoded point. Mock data: ---------------- Possible field mappings: --------------------------------- 3. To handle the house number suffix when using the US Address - Singlehouse Subaddress style to build a locator, concatenate the house number, house number suffix and/or house number prefix in a single field and use the new field to map to House Number when building the locator. See the difference in the mock data example for FULL_CIVIC_NUM and this example includes FULL_CIVIC_NUM. Results based on the locator field mappings above: ---------------------------------------------------------------------         ... View more

At this time there are no plans to bring back the functionality of the pre-10.5 Singlehouse Subaddress address locator style. The reason for the changes were for quality and performance and since 10.5 we have fixed issues that have been reported by customers at each release since then. The building type and unit components caused  confusion and slowed down the search. The 3 house number parts will need to be concatenated into a single field and the subaddress elements can be broken up between subaddress type and unit or all concatenated into just subaddress unit. More details can be found at http://pro.arcgis.com/en/pro-app/help/data/geocoding/commonly-used-locator-styles.htm#ESRI_SECTION1_7FC7CD744FDA4D379399C92D109FA67A ... View more

Which address locator style did you use to create the address locator? Do you have an example of the REST Suggest request you made that didn't return the expected results? -Shana ... View more

Here is some additional information related to this thread. This limitation is mentioned in the documentation here towards the bottom: Creating a composite address locator—Help | ArcGIS Desktop    Here is the Note: The suggest index does not store the house number for performance reasons, and so the best practice is to create a composite locator with at least a Street Address or Point Address locator and a Street Name locator. The reason for this is that if the house number doesn't exist in the Street Address or Point Address locator, you will still get a match to Street Name. You do not need different data to create the Street Name locator. A Street Name locator can be created from Street Address data because the Street Name style only uses a subset of the fields required by Point Address or Street Address.   We have also made fixes to our online service for this and plan on rolling these out to users when creating locators on their own data later in 2018. Shana ... View more

Anand: You would need to install 10.5.1 to get the fix. There is a workaround available for the issue, which is to use the Feature to Point tool in ArcToolbox > Data Management Tools > Features toolset to convert the polygons to points. Then use the points to build the address locator based on the US Zip 5 digit style. ... View more

Anand: Do you get the same results when you save the geocode result out to a shapefile? Is the status for all the records in the geocode result ‘U’ for unmatched? Do you get results returned when you search for a zip code in the Find tool or Gecoding toolbar using the same address locator that you geocoded the table with? ... View more

The issue you've described is addressed in a few other posts regarding suggestions with geocode services. See the following reply https://geonet.esri.com/message/716581-re-composite-locator-not-properly-locating-address-points?commentID=716581&et=wat…  ... View more

Is your geocode result in shapefile format or in a geodatabase? What geometry type is listed in the 'Shape' field of the "USA Zip Code Areas" layer when you open the attribute table? ... View more

Lee: What are your steps for the following statement in your original question? "Published to my 10.6 server and added it to Portal (federated and hosted on ArcGIS Data Store) via utility services." Are you publishing the composite locator from ArcMap to ArcGIS Server, then add the geocode service REST URL to the utility service section of the Enterprise Portal  organization settings for utility services? Does this mean that you published the locators by copying the data to the server or did you publish by reference where the locators were in a folder that was registered with the Data Store?   ... View more

What is the behavior when you use the composite geocode service in ArcMap to geocode the two tables? I'm trying to determine if the problem is with the geocode service or with Portal and the service as a utility service. ... View more

Lee: Do you experience the same behavior with the local composite in ArcMap or ArcGIS Pro? ... View more

I also noticed that in the Geocode Addresses tool you did not map a table field to "Full address" input field, it's set to none. So the result would be all unmatched records. Another option is to convert the building footprints to points using the Polygon to Point tool, then using the Reverse Geocode tool, then spatially join the reverse geocode result to the building foot prints feature class. ... View more

Kevin: At this time there is only a workaround of using the General - Gazetteer locator style when building the locator and publishing it as a geocode service. The Gazetteer style does not have the memory leak when used as a service with suggestions. It also has the logic to handle spelling sensitivity. Whatever field was used to map to the Keyfield in the Single Field style, map it to the Place Name field in the Gazetteer style. -Shana ... View more

Brian: I apologize for the delay, I've been working to meet some deadlines for Pro development and haven't been able to circle back to this issue. I have an idea I need to test out and will try to get a response to you this week. What I believe is happening is that the abbreviation you are using for 'Circle' in the reference data is not part of the logic in the locator style, so it doesn't know what to do with it. A quick note about the field mapping of the locator in your most recent screen shot... The 'Full Street Name' locator field is not used for address matching, so it is not necessary for it to be mapped to a field in your reference data. The content of the field when mapped is written to the geocode result for labeling if needed. You have a few options for field mapping based on the fields in your reference data. If the "ROAD_FULL" field in the reference data contains all of the street components, it can be mapped to the 'Street Name' field from the locator with no other components mapped (directions, prefix type, suffix type), then map the zone fields like city, state, zip code. If using the US Addresses - Single House Subaddress map "ROAD_FULL" to 'Street Name' and the "UNIT TYPE" and "UNIT NUMBER" fields to 'SubAddr Type' and 'SubAddr Unit'. In the existing locator properties, you could also use the "ROAD TYPE FULL" field to map to 'Suffix Type'. -Shana ... View more