Latest Contributions by BradNiemand

In addition to the countries mentioned above by Shana, additional countries have been added as well at Pro 2.6.   Belgium Switzerland Netherlands   Brad ... View more

URL above is correct but the display of the URL gets cut off.   Brad ... View more

Joe,   I am trying to reproduce your issue via REST and can't.  Am I missing something?   https://geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer/findAddressCandidates?Address=375+North+Shore+Dr&Region=PA&outFields=*&searchExtent=%7B%22xmin%22%3A1011246,%22ymin%22%3A13425000,%22xmax%22%3A2487548,%22ymax%22%3A15124138,%22spatialReference%22%3A%7B%22wkid%22%3A32167%7D%7D&f=pjson   Brad ... View more

Joe,   Can you give an example of what the input was that worked before but doesn't now?   Brad ... View more

I am almost positive that 10.7.1 supports this property but I can't seem to track down the exact date/release it was installed to truly verify.   Brad ... View more

10.6.1 ArcGIS Server had limited support for the new locators and this property was not yet supported at that version of ArcGIS Server.  In order to have support for the "Match with no zones" property, you will need to move to a newer version of ArcGIS Server.   Brad ... View more

Joe,   This is not currently supported for arcpy.  We have an issue in our backlog to get it added in an upcoming release.   Brad ... View more

Joe, At this point in time the Locate Pane will always return all of the output fields when choosing "Show Details".  Another option is the "Detailed View" by selecting the burger menu on the top right but when it is enabled it will also show all of the fields. It is a good requirement for a future enhancement to only show the enabled fields in the locator when in "Detailed View".  I think we would continue to show everything in the "Show details" dialog though.  I will add something to the backlog for the "Detailed View" though. Brad ... View more

Joe, You need to call arcpy.SignInToPortal(“https://machinename.domainname.com/portal”, “username”, “password”) and then using services as data sources should work just fine for CreateLocator using Python. The data sources need to be on the server federated with the Portal you are signing into.   If your data sources are shared with everyone (public) you don’t need to call SignInToPortal() first.   Brad ... View more

Stephanie, Sorry, I have been super busy. What issue are you having when using multiple alternate city names? Each alternate city name for a specific city (ex North Redlands, South Redlands) should have the same JoinID (ex 12345) in the alternate city names table.  If you primary reference data (the one with geometry) already has a city name (ex Redlands), this will be the primary city name.  All streets in the data that are in Redlands should have a city JoinID (ex. 12345).  This allows you to link in multiple alternate city names for Redlands. If you use a fully normalized dataset where city isn't in the primary reference data, then the primary city name can be in the alternate city name table but with an extra field that indicates which city is the primary (determined by the "Primary Name Indicator" field in the alternate name table field mapping). Hope this helps but let me know if you have any additional questions or issues. Brad ... View more

Stephanie, Yes, that is correct.  Instead of having a bunch of duplicated IDs for streets, you can use the same ID for each street in that city. Brad ... View more

Stephanie, See the following doc topic all the way at the bottom. Fundamentals of alternate name tables—ArcGIS Pro | Documentation  The image at the bottom shows a fully normalized reference dataset where all cities are in the alternate city name table but the logic still applies.  You can keep the city in the primary featureClass but have all alternate city names for the primary city in the alternate city name table with the same CityID value.  You also wouldn't need a "Primary Name Indicator" fields either because the value from the primary featureClass is used as the primary. At a basic level it would look something like this (obviously the Primary table would have many more fields). Primary reference data: City         | City JoinID My City    | 1 My City 2 | 2 Alt Name Table: Alt City              | Alt City JoinID My City Alt1      | 1 My City Alt2      | 1 My City Alt3      | 1 My City 2 Alt1   | 2 My City 2 Alt2   | 2 My City 2 Alt3   | 2 ... View more

Stephanie, As for the duplicate results and different scores, yes it is because there is no postal code for the PointAddress record so it is returned with a lower score.  The best way to fix this is to have both datasets have the same fields.  That would be by either enhancing the PointAddress dataset to include the postal code with the data (this can be done by overlaying postal polygons to apply postal codes to different points that fall within the postal polygons).  Another option is to not map the postal code for the StreetAddress locator when building it.  This is not ideal but would give back better ordering of the results because the scores would be the same.  I would stick to option 1 if that is possible. As for the joining of alternate city names, it is better to associate an ID with all cities with the same alternate city name and then the alternate city name table would have a single record for that alternate city name and would get linked with all of the records that had that ID.  This is more optimal and will make the locator smaller and faster. Brad ... View more