Latest Contributions by BradNiemand

Michael, If the addresses have the same attributes and are from the same role then all of them will be returned.  The first one will just be the closest to the center of the map.  Even if the addresses have the same attributes but are from differnt roles and are not spatially near each other, all the candidates will be returned. The logic for deduplication of identical candidates happens when you have identical attributes across different roles where the locations are very close to each other.  Essentially we want to remove the StreetAddress match if we have a PointAddress match that represents the same address but with a more spatially precise location. Brad ... View more

Joe, Likely the limitations you are seeing are because of the older version of the software.  Please let me know once you have tried it against 10.7.1. Brad ... View more

Joe, Does your locator have any zones (city, state, postal) built into it and if you do, are you trying to search with no zones?  If not I think this might be what you are running into with 10.6.1.  10.6.1 was released prior to the Create Locator tool so the only locators that could be used with it at the time were the World locator and locators from StreetMap Premium.  The functionality to support locators with no zones was not added until after 10.6.1. The only way around this is to ensure that you are zoomed in past 1:500,000 so that location is passed in. Brad ... View more

Joe, Do you have the patch installed? ArcGIS Server 10.6.1 General Geocoding Patch  There is nothing specific to the behavior you mentioned above in this patch but it would be good to install anyway. Brad ... View more

Joe, What version of Server are you using?  The center of the map is always passed in if you are zoomed in to 1:500,000 or closer (~30 mile radius).  This would apply to both local and published locators. It is possible that 2.4.2 has additional logic that further reduces duplicates when PointAddress matches are found that isn't in the version of Server that you have installed.  We are constantly improving the geocoding results so it is very possible that if you are using a older version of Server, it doesn't contain this logic.  I don't recall any specific work we did related to this but like I said, we are constantly improving the matching logic. Brad ... View more

Joe, Without more information I am just going to guess that the center of the map is in a different location.  We use the center of the map to prefer locations that are closer to center of the map over locations that are further away.  I suspect that when you get the StreetAddress match above the PointAddress match, you have the center of the map closer to the StreetAddress location. As for why only the PointAddress match only shows one candidate without the StreetAddress match is because we do some logic under the covers to try to eliminate duplicate results when a PointAddress match is returned with a good score. If you have an ID that links the PointAddress and the StreetAddress, you can map the "Street Address Join ID" for both roles and it will eliminate the duplication of StreetAddress candidates.  The code tries to be smart about it but without this linkage, it isn't guaranteed. Brad ... View more

Kevin, I just created an app that points to online and captured the network traffic and it looks like location is getting passed in for me.  What web browser are you using?  If Chrome, can you hit F12 and tell me if the findAddressCandidates request has a location with it when just hitting the Enter button? Also, when you configured your app did you "Enable local search" on it? Brad ... View more

Kevin, Your locator is built with zones which is good.  We would also suggest including State when building the locator as well because we use the state values to enhance highways to account for variations for highways.  For example STHWY 101 would also accept GA 101 even if the alternate name wasn't in the data. Locators, by default, require at least one zone when performing geocoding.  A zone can be one of the following in the USA:  City, State, Zip or you can alternatively pass in the current location of the map.  The last option is to enable matching with no zones in the locator which is the optional property I described above.  Although we discourage using this property for large areas, I don't think your area is too large to consider it and the performance effects will likely be minimal. With regards to default behavior of searching by pressing Enter or using suggestions, they are both the same.  The problem here is the suggestions IS passing in the location as the center of the map and the Enter search IS NOT.  If they were both consistent, then they would provide similar results.  What I was mentioning as something that would need to be done in the Web App Builder is to change the underlying code to ALWAYS pass the same parameters to both methods. Are you saying if this patch is applied to Web App Builder; then both arrays (Suggest and Enter) will be the same?   The answer to your above question is yes.  If both operations passed in the location of the center of the map, the results would be the same. Brad ... View more

Kevin, That is great news!  I would still like to dig in on your final question though. If I type in '1 East Bay Street' or '1 East Bay' it comes up in Suggestion.  But... it does not come up, if I hit Enter. No Results Found. Can the Suggestions array be unified with the Enter key array? (I put forth Suggest array be used for both as it catches and returns more results as it is more forgiving with spelling) I think I know what is happening here.  The locator does not support searching without one zone (city, state, zip).  When you are retrieving suggestions, the application is passing in the location (center of the map) to resolve what location you are at but I assume during the findAddressCandidates call the location is not getting passed in as well which it should be.  When location is passed in, it acts as a zone for the locator and it should really be passed in as well if it was passed in to the suggest API.  This is why there is an inconsistency.  Whatever parameters get sent to the suggest API call should also get passed into the findAddressCandidates call.  Is this a default Web App Builder app with no custom code?  If so, it might be something I can see if we can get resolved going forward. I have a workaround for you though without having to write any code.  There is a property (which will be exposed in the UI for 2.5) that allows a locator to search with no zones. NOTE This property is not intended to be used with locators for large areas.  Typically we would suggest that it is used with cities that only have a single unique postal code because there is the potential for identical addresses across multiple postal code which could lead to false positive matches.  This will also affect performance with larger locators. In the UI it will be named "Match with no zones" and have a value of Yes or No.  You can manually add this property to your locator by opening the locator .loc file and adding the following property to the file. supportsOptionalZone = true I think this will solve your problem but just let me know. Brad ... View more

Kevin, What "Ghost" suggestions are you seeing with the new locators? Brad ... View more

Joe, What you are doing is a hack and really won't work in some situations.  You will have limitations with abbreviations not working as expected when using any non-address role for doing address geocoding. That being said, we have heard from you and others that suggestions for units is a requirement.  I can also say that has been prioritized and we are focused on getting this functionality to everyone as soon as we can. Brad ... View more

Kevin, You should really migrate over to new locators that are created with the Create Locator tool in ArcGIS Pro.  The classic locators have a limitation to them where the house number is not used as part of the lookup for the suggestion.  The new locators do not have this limitation. Using the Gazetteer locator with the classic locators for address suggestions will have the limitations to it.  As you can see by the output, it will prefer matches that have more exact matching components and which is the case you mentioned above is indeed "501 East Bay Street LLC".  The abbreviations and other parts of address matching are not done the same in the Gazetteer locator. I believe that the solution you are looking for is already available to you but it just requires migration over to the new locators created with the Create Locator tool in ArcGIS Pro. Brad ... View more

Joe, There are, I think, two questions here. 1. What format should the reference data be in to build the locator? 2. What format should the input address come in to the locator as?  Address in separate components like Address, City, State, Zip or all in a single field? For question 1, it is still preferred to have your street component data split up into its components like PreDir, PreType, StreetName, StreetType, SufDir.  We don't break unit values up into really fine components but we do suggest that the unit type and unit number are in separate fields.  That being said, we do still do a very good job of geocoding even if the data is all in a single field.  You would not map it to FullStreetName but just to StreetName or to both (unit information would still be better if it was separated out).  FullStreetName is used for display purposes only.  It is beneficial for countries where the street type can be concatenated to the streetname like in Germany. For question 2, you will get a bit better performance with multi field input than single field input but for interactive geocoding it is negligible so we generally say to stick with single field.  For batch geocoding you will get some benefits from your data being in multiple fields.  Quality is essentially the same between to both though so that shouldn't be considered as a factor. Brad ... View more

Joe, Is there something that I can assist you with in regards to publishing/sharing? Brad ... View more

Joe, There is a limitation with the old style locators where they would not verify the input house number during suggestions for performance reasons.  This was addressed with the new locators.  The only way around it is with the new locators. Brad ... View more