Latest Contributions by RonnieRichards

Reviewing the LocateXT documentation it appears the custom attribute function solely revolves around keyword searches. Due to variations of keywords or possible ocr issues it would be much more effective to have custom attributes to be able to be pulled out using regex expressions. This would be a powerful way to pull out specific values using single statements instead of multiple keyword definitions.  In addition to regex , the tool might also benefit being able to run a custom python function or arcade expression.  The same argument could be made for the use of regex or functions for locations. The location definition needs some work but ideally these locations would be defined by a set of regex functions. One example might be an expression to pull out zip codes or address strings and then potentially look up zip code features or geocode them against a service.  The use of out of the box templates could benefit because right now there are only default templates. Once functions or regex are allowed then this could actually help others get going much quicker by sharing other libraries of templates including functions for parsing strings, regex expressions, etc...  Thanks for the consideration!! Ronnie ... View more

Please create a standardize address method to an existing Geocoding Service or possibly as its own service. Look ups should support a single candidate or possibly batch candidates.There are needs to standardize address information outside of geocoding the address, sometimes when an incomplete address or only the street name has been provided. We'd like to use this to convert Next Gen 911 style street names to legacy or vise versa.  To make this work with a geocoding you must severely reducing the scoring which inherently creates other issues.  Ideally an address candidate could enter the standardize method and the output results includes the candidate as well as the result split into the addressing components as configured in the service.  The use of geoprocessing tasks is not a realistic option as the current standardize addresses tool takes in a dataset and requires an output dataset. This is overkill for simply standardizing a list of street names from Next Gen 911 style to the legacy style.  ... View more

For the new primary locator roles it would be really helpful to get the input search field values in the response. This way it can be checked to matched candidate. We are trying to use the new PointAddress and Streets Roles but getting invalid matches which did not occur in the SubAddress locator in 10.x. Due to these mismatches it would helpful to see what the input search address was so it can be compared to the result.  In this example below, we are entering and a single line input: 4791 PELL DR STE 1, SACRAMENTO, 95837 However the match comes back without the STE which is not correct and should not have the 100% match score. The 10.x SubAddress locator returned no matches which is a better result but realistically there should be a candidate match with a lower score than 100. If the search input was in the result we would easily be able to compare the search string with the match string to weed thru these mismatches.  ... View more