Latest Contributions by BradNiemand

Search for the following: <mapping_schema name="SingleAddress" geom_type="point"> Under this section you will see a field defined for "House"  It will look like this:           <field name="House" grammar_ref="House">             <desc>House number</desc>             <preferred_name>HN</preferred_name>             <preferred_name>ADDRESS</preferred_name>           </field> Replace it with this and you will get the functionality you want:           <field name="House" grammar_ref="House">             <desc>House number</desc>             <preferred_name>HN</preferred_name>             <preferred_name>ADDRESS</preferred_name>             <scoring_method ref="match_house_to_range">               <init_properties>                 <prop name="MatchHouseToRange:DistanceScoring:Method">Linear</prop>               </init_properties>               <parameter>                 <input_value/>               </parameter>               <parameter>                 <field_value ref="House"/>               </parameter>               <parameter>                 <field_value ref="House"/>               </parameter>               <parameter>                 <value>B</value>               </parameter>             </scoring_method>           </field> Brad ... View more

You might need to reduce the MinimumMatchScore and/or MinimumCandidateScore for the locator. Brad ... View more

Peter, The reason we don't allow incorrect house number is because this locator type is supposed to be the most accurate type of match that you can obtain.  Generally we would suggest that you create a Dual Ranges locator as well and add the 2 locators to a composite locator instead. If you don't have this data, there is a way to customize the locator style template file to build a locator without requiring the house number to be correct. What you would do is the following. 1. Open the USAddress.lot.xml file with a XML editor or text editor like Notpad++. 2. Search for "<mapping_schema ref="SingleAddressSearch" />" 3. Replace with "<mapping_schema ref="SingleAddressPolygonCentroid" />". 4. Build the locator again. Let me know if you have any questions. Brad ... View more

Jian, It is much lower than I would expect even for an HDD.  On HDD I would expect to see something closer to 250,000. Brad ... View more

Jian, Everything looks good with the specs and I am glad to see you using Multiple fileds, it is much faster. Virtual machines can have some issues depending on how the environment is set up.  Physical hardware is always preferred because you know what you are really getting. As for performance difference between HDD and SSD, it can be significant when doing Desktop geocoding because nothing is hot in RAM.  The initial overhead reading the indexes from disk is a real bottleneck (which is why we use a cache to store recently searched features in RAM which is what the RuntimeMemoryLimit controls). One more thing, if it is possible for you to do, is sorting the input table by state, then city, and then postal.  This will make the reads from the disk more efficient because it is reading from the same physical area. Hope this helps you some more. Brad ... View more

Jian, A couple questions for you. 1. What are the specs of your computer? 2. Are you using Single Field geocoding or Multiple Fields geocoding? 3. Are you running off of a HDD or SSD? Brad ... View more

Jian, Although we do handle the removal of confusing or redundant components while matching you may see a slightly better (1-2%) geocoding result if you use the standardization and "cleansing" process before.  It really depends on how bad the input address data is first and how good the standardization and "cleansing" tools are.  If I were you, I might give it a try with and without and see what the difference is.  You might see that you get little or even no better results. Brad ... View more

Jian, 1. The online service isn't a "True" composite locator.  It works differently and has additional functionality in it that can work this way. 2. We are actually changing the Minimum Match Score for the online service to be 93 as well for the USA and because your just using batch and Minimum Candidate Score is only used in FindAddressCandidates this is a pretty safe change that will actually reduce potential false positive matches. 3. This option is much higher risk than #2 above. Brad ... View more

Jian, There are a couple questions here but I will try to explain. 1. The online service has some additional sorting of candidates after the fact to make sure the best candidate is always first.  This is why you see the correct first result as a StreetAddress match as opposed to a PointAddress match. 2. What you can do is update the Minimum Candidate and Minimum Match Scores for the PointAddress locator to something a bit higher (I suggest 93).  This will allow for only high score candidates to get associated with the PointAddress locator. Let me know if you have any additional questions. Brad ... View more

Maybe contact tech support to try to reproduce it because I can't reproduce it on my side. Brad ... View more

Do you have the geocoded featureClass added to the map?  If so, the point will show up, if not, the point will not show up until you add the geocoded featureClass to the map. Brad ... View more

Jay, You need to update the lot.xml file for which you built the locator (General -   or US Address - tells you which locator you used). You need to updated the .lot.xml file prior to building the locator in order for this to work.  You can always revert the changes once you are done. Brad ... View more

Jay, Try editing the *.lot.xml file in the "%ArcGIS_Install%\Locators" folder before creating the locator and then re-create your locator. Brad ... View more