For some reason I am having trouble geocoding with ArcMap 10.4. I have a table of single-field addresses like this 123 1st st nw. For some reason after running the geocode, the output point file has ZM values in its geometry.
After running the geocoder, and opening the Interactive Rematch, I change the results to show unmatched results and click Rematch Automatically. This gives the error message "Couldn't rematch this table. The geometry has no Z values".
What's going on here?
I've tried disabling the M and Z value output in the geoprocessing environment settings, but the results are the same as described.
An aside question, when the Interactive Rematch window opens, there are about 200 matches and 300 unmatched, but the vast majority of them have a candidate with a score of 100. Why would a candidate with a score of 100 not be automatically matched?
I'm pretty much having this exact same problem. It may be something going on with 10.4, since I recently upgraded, and didn't have this problem before. I also thought of the Geoprocessing environment settings - and my change made no difference, just as you found.
Regarding your aside question, the only way I can think of that happening is if it were also tied with another candidate, and you chose NOT to match if candidates were tied.
Thanks for the response. I'm glad I'm not the only one having the issue. I still didn't have a great solution to the problem...basically I had to match each one individually which took quite some time.
OK, here's what I had to do to fix this issue - hopefully you have your locator source data to do the same. First, check to see if your locator source data (ie addressable streets, address points, parcels, etc) are stored with Z and M coordinates. If they are, get rid of those geometry elements by exporting from one feature class to another, but disabling Z and M values in your Geoprocessing Environment variables. Then, rebuild your locators on the new source data.
After doing that, I was able to geocode against my new locators and the outputs are just points - which work everywhere more consistently!
Thanks for this, I just upgraded to 10.4 and ran into that issue immediately.
I regularly use a compound data locator, which uses 4 different street layers;
I am so glad I have all of the source data on hand!
Will post my results
Upon further investigation into the behavior, it is the M values that is causing the problem and not the Z values. You should be able to run the feature class to feature class tool and just drop the M values, then create the locator based on the new feature class and maintain the Z values if you need them for display in 3D workspace. The default extent of the M values are out of range or are not valid ranges and is what is causing the output not to display on the map.