Latest Contributions by BradNiemand

Joe, Technically the house number is also require but only one of the two sets of options is required.  Either House Number, OR House Number To and House Number From.  We do give an error before execution if one of either of the two is not populated.  It would be equally as confusing if all 3 were required so we went with none of them showing as required with an asterisk in the UI. Brad ... View more

Joe, Just trying to make sure I understand.  The second time when you mapped the building field to the building unit field you got correct results?  If so, the results you were getting the first time were because the data that you have really didn't fit the field mapping that you used which caused unexpected behavior. If the above it not the case, I might not understand and may need some additional information. Brad ... View more

Joe, Building name is not typically used in the USA but some datasets have it modeled in this way.  Typically a building name would be a POI that is linked to the PointAddress record like Esri is linked to 380 New York St, Redlands ca... I am not 100% sure without seeing the reference data but I think you have some units that are actually just building names such as building A or building B.  In this case you should map the Building value to the "Building Unit" instead.  For your data I would imagine it would be Unit and Building Unit that are mapped.  See the highlighted below. We allow searching on just the building name so likely those are all pretty low scored candidates that matches the "W" as the building name.  Likely this is because one of your buildings has the name "W". Hope this makes sense. Brad ... View more

Lucas, Shana and I discussed this and i wanted to provides some additional information for you. There are many benefits to the locators created with the Create Locator tool over the Create Address Locator tool and I will outline some of these benefits below. 1. These locators support Address, Address2, Address3 inputs right out of the box so there is no need to create a composite locator for what you are trying to do. 2..They are faster and smaller 3. They have improved match quality and the ability to handle extra information in the text much better.  For instance, if you have "Attn: Joe" in the input string, this will be handled much better in these locators. 4. Improved suggestions for interactive geocoding such as suggestions for intersections and verifying the house number when showing suggestions.  Other improvements are the ability to get suggestions with a locator in Pro without publishing it to Enterprise. 5. Create one unified locator instead of a composite locator.  You can now create a multirole locator that combines many datasets into a single locator.  This allows user to combine Rooftop, street centerline, postal, city, etc... into a single locator instead of creating separate locators and combining them into a composite.  This allows the locator to be smaller and not duplicate information across multiple locators.  A mutlirole locator will also be much faster than a composite locator. These are the highlights but there are more and we continue to improve these locators each release. With regards to the standard set up input fields, yes, all fields will be displayed if you build a locator with only a city role because we have a unified set of input fields.  Typically users build a city locator only to include in a composite as fallback so there is really no need to do that going forward because it will just be part of a multirole locator.  In addition to that, the "SingleLine" input field can always be used simplified input for the locator, there is no need to use the multiple input fields. Lastly, you mention " The only downside I saw with that is it requires 2 copies of the same locator, doubling the storage size. " in the first paragraph above.  Are your locators quite large?  If your organization can't currently migrate over to the create locator tool, the workarounds above are probably your best bet. Brad ... View more

Julie, I would need to know more information about your environment. 1. What is the size of the locator?  What type of locator is it (Created with Create Address Locator Tool or Create Locator tool)?  Is it a composite with many locators in it? 2. What client are you using to geocode?  Pro, ArcMap, etc... 2b. What version is the client? 3. Where does the locator exist?  Is it hosted on a Server (if so, what version), local on the machine, is it on an SSD or HDD? 4. What is the machine configuration?  Memory, #CPUs, #cores per CPU, disk types SSD or HDD. 5. Where are you reading the table from (FDGB, Enterprise GDB, other) and where are you writing the results to? 6. How is the locator configured?  Is it configured to use multiple threads? I may have more questions after you answer but there are many variables that could cause a performance problem but typically the answer to your problem will not be that you have to split the table into smaller chunks. Brad ... View more

Tim, What version of Pro are you using?  I did a very simple test on my side to create a locator with Place Name, Place Category and Place Subcategory mapped and everything works for me in Pro. Brad ... View more

Tim, Another question that I am not sure I have a clear understanding of right now.  Does searching for something without category work right now? Brad ... View more

Tim, You have not been forgotten, sorry for the delay between responses. 1. Does your locator work as expected in Pro? 2. Just want to also confirm that you are using the "Create Locator" tool with the POI role and not "Create Address Locator" tool with the Gazetteer style correct? 3. Are you compiling the app to be x64? Brad ... View more

Tim, So you don't get suggestions for anything?  That is odd.  That documentation is actually outdated and only refers to the classic locators not these new locators.  Do you get geocoding results back? Brad ... View more