Latest Contributions by BradNiemand

Elizabeth, Somehow I missed that.  What you should do instead is use the Standardize Addresses tool to break the input dataset (VernonCountyMO_Addresses.shp) single field address (StreetName) into its components and then build a Single House locator off of that data. After that, you will have a Single House locator off of the new dataset.  You should then have "Street" and "City" as your input locator field names (the first name in the field mapping) and the second field in the field mapping would be the name of the field in your CSV file. You will notice that the geocoding will be much better as well because the Single House locator style allows for missing components, misspelled words, and other flexibility that the Singe Field style does not because it is an exact match locator.  The single field locator style is really for assets or something that has a unique value. I think the reason it is failing right now is because the Single Field locator only takes in a Single Field for input. Brad ... View more

Elizabeth, Are your locator fields StreetName and City?  StreetName doesn't sound like an out of the box locator field name.  You can run the table through the GeocodeAddresses GP tool in ArcMap and then look at the GP result to see what the field mapping was to confirm.  You may have done this already because you have the "VISIBLE NONE" as part of the string that isn't really needed but it part of the output from the tool. Is your locator just one USAddress - Single House locator or is it part of a composite or anything else that can give me some additional clues?  Just to confirm, were you able to geocode the CSV with the GeocodeAddresses GP tool in ArcMap with no issue? Brad ... View more

Elizabeth, Set that property to 1 or set it in the .loc file. Brad ... View more

Elizabeth, Look at it in the locator property dialog or in the locator .loc file. UseMultithreading Brad ... View more

Elizabeth, I can't guarantee this will work but try disabling multithreading in the locator and see if that helps. Brad ... View more

Elizabeth, Go to the Project references and make sure that the ESRI.ArcGIS.Geoprocessing assembly has the property "Embed Interop Types" set to false. Brad ... View more

Elizabeth, It will do everything that you did above but with a lot less code.  It will create a shapefile with all of the geocoding results in it as well as all of the original input data fields copied into the geocoded featureClass as well.  Essentially it is doing the exact thing that happens when using the GeocodeAddresses GP tool in ArcMap so you should get exactly the same output as you got in ArcMap. Brad ... View more

Elizabeth, Yeah that code is the hard way to do it .  All of that code can be replaced by this.  You just need to change the path to the table, locator and where you want the geocoded featureClass to go.  Also, the field mapping is "LocatorFieldName TableFieldName" with each field separated with a semicolon.  The 10.x locators have had the same field names for some time so I think Street,City,State,Zip should be the same for you too.  You will just need to put in the table field names to replace ADDRESS,CITY,STATE,ZIP below. You will also need the following using: using ESRI.ArcGIS.Geoprocessing; public void GeocodeAddressesTool() { String table = @"C:\geocoding\redlands\redlands_addr.csv"; String locator = @"C:\geocoding\redlands\redlands_points_locator";  String fieldMapping = "Street ADDRESS;" + "City CITY;" + "State STATE;" + "Zip ZIP"; String outputFC = @"C:\geocoding\redlands\redlands_addr_geocoded"; IVariantArray parameters = new VarArrayClass(); parameters.Add(table); parameters.Add(locator); parameters.Add(fieldMapping); parameters.Add(outputFC); IGeoProcessor GP = new GeoProcessorClass(); GP.OverwriteOutput = true; object Missing = System.Type.Missing; try { GP.Execute("GeocodeAddresses_geocoding", parameters, null); } catch (Exception e) { throw new Exception("Tool threw an exception: " + e.Message + " GP Messages: " + GP.GetMessages(ref Missing)); } } ... View more

Elizabeth, When you say created into a shape file do you mean that the CSV file is geocoded with the locator to create the shape file? I am not an ArcObjects expert but can get my way around the geocoding ArcObjects code.  If the CSV is getting geocoded, I would be curious as to how it is getting done right now because I might have an easier way to do it with geoprocessing in C#. Brad ... View more

Elizabeth, What are you trying to do with your code above?  I know you are trying to open a CSV file via ArcObjects but what will that be fed into?  Will you be geocoding it? The reason I ask is that there might be an easier way to do this with geoprocessing. Brad ... View more

Joe, Match out of range doesn't apply for your workflow but it does in many others.  It is there to provide a more spatially accurate result than a StreetName result.  Some workflows allow for StreetName results but if the StreetAddress range is 1-99 and you have a input of 101 or 111 it would be better to get a point at the end of the street segment with a type of StreetAdddressExt than it would be to get a point in the middle of the street segment with a type of StreetName.  This property is set to true by default but you can set it to false for your workflow. The invalid suggestions you mention was a limitation of the classic locators.  This is not longer an issue with the new locators created with the Create Locator tool.  I understand that many users had challenges with this limitation which is why we worked hard to ensure the new locators didn't have it as well. As mentioned in a previous comment, we are working to put together a Python API to support modifying properties of a locator after it is created.  Also, there is no way to modify the properties of a locator after it has been published as a service.  Any properties of the service are read-only. Once again thanks for the feedback and we are doing are best to integrate feedback back into the product each release and welcome continued feedback so we can continue to evolve our products to meet the needs or our users. Brad ... View more

Joe, Some follow up questions.  You state the following above: "Since that appears to be our only option with the new style locators, that's what we'll have to go with, but we aren't yet totally in love with the new styles. Don't get me wrong, they do show a lot of promise but they can put a strain on us with the little gotchas." What about the new locators are you not totally in love with at this time?  What can't you do with the new locators that you could with the previous ones?  You can still modify the properties such as score and you have even more flexibility to modify things like what categories to match to and what features should be supported for reverse geocoding to name a few.  Also, if needed you can still create a composite locator with participating locators that have adjusted scores if your workflow requires this. We appreciate any additional feedback you can provide. Brad ... View more

Joe, Thanks for the feedback.  We are looking into adding support for modifying properties via Python for an upcoming release so automation of this process will allow for this going forward. With regards to modifying the .loc file, it can be done but it is discouraged and not supported. As for adjusting the score for individual roles in a multirole locator, this is currently not supported.  I would like to understand your workflow in a bit more detail though to understand what you are trying to do. Is the score more important to batch geocoding? Why is it acceptable to have a score less than 95 for StreetAddress but not for PointAddress?  Is it because PointAddress is considered more spatially accurate so you want to ensure the result has a high confidence? If so, what is done with the lower confidence StreetAddress matches after geocoding?  Are they used at all? Can the minimum match score just be set to 95 for everything and then the confidence is high for all geocodes? Locators created with the Create Locator tool can still be added to a composite locator and each participating locator can have the score adjusted appropriately but I just want to make sure that it is really needed before we go down that path because you will lose out on some of the benefits of these new locators using this approach (size, deduplication of results, etc...). Brad ... View more

Kevin, Can you please help clarify the following statement? "There appears to be a bug introduced in the Oct AGOL update. The parameters such as min character and rooftop do not work. (when you click on a result from the Suggestion list ie without magickey) I tested with TS and they have it already as a known bug." Can you please provide an example address please?  The locationType parameter is working for the REST API and we have many tests that verify this at every release which are still passing right now.  Did you add the parameter to the WebAppViewer properties JSON manually?  I see it in the the JSON snippet above but I am unsure how it got there because I don't believe the WebAppViewer currently supports this parameter.  What you can do is create a Locator View, configure the preferred location type to be rooftop for that view, and then use that URL for the Locator View for your app instead. More information about Locator Views can be found here: Geocoding and geosearch—ArcGIS Online Help | Documentation  Another thing to note is that rooftop locations will only be returned if a rooftop location exists in the data for that address.  If the location does not exist in the data, the next best location will be returned instead such as the side of street or routing location. Also, what is the minCharacters property?  I don't know what that is used for.  It is not a geocoding property. With regards to searching without choosing a suggestion (no magicKey) versus searching with choosing a suggestion (with magicKey) returning different results, can you provide an example?  I would like to have some examples so that I can get a clearer understanding of the challenge you are having. Brad ... View more

Kevin, The Create Address Locator tool creates our "classic" locator where the Create Locator tool creates locator using newer technology.  The newer technology will not provide suggestions for non-existing addresses.  The classic locators had this limitation and we worked hard to ensure that this would not be the case for the newer technology.  You will be more successful migrating over and using the new tool (Create Locator in Pro 2.3 or newer). That being said, suggestions for subaddresses (addresses with units) are not yet supported for these new locators.  Entering the entire subaddress and just hitting the enter button will give the result, it just won't show as a suggestion.  All other address types work with suggestions though.  We hope to add this functionality in a future release but we don't have a target version at this time. Brad ... View more