Latest Contributions by JoeBorgione

These look a lot like Utah addresses.  Some counties like Salt Lake have rules about numbered streets; they end in 0 or 5.  I suppose you could parse out your address string and then examine the second numeric string to see if it's divisible by 5 (modulus function) and make an assumption that if it is, then it is the street, whereas if it is not, then you'd want to swap the the two elements before you stick them back together as the address string.  There is always a certain risk in making assumptions however... ... View more

My response(s) in bold Thank you for the quick response Joe.  I just wanted to make sure I understand correctly what you are recommending that I could do to address this issue.  For the ones which are 100 percent matched, but tied, I could take a sample and verify that they do in fact lie within the same tract.  However, I understand that the partial matches may be much more of a problem, if the two candidates are matched at 78 it is more likely that they are in very different locations.  Look at two addresses: 1234 S Main ST and 1234 N Main St.  Toss out the pre-directions and they are an exact match. That's why partial hits can be problematic. Is it possible then to have Arc count them as matched if there score is 100 but unmatched if it is any less (if I find that I am comfortable with the 100 percent matches)? Absolutely; when you create your locator you can adjust what scores can be a match or a miss.  You can also score ties as a miss if you like. Secondly, is there anything known about how Arc chooses 1 of the tied candidates as the match address? Is this process random? Or is it determined by the layout of the line file? It occurred to me if it were random, it is likely to be less of an issue, however if it just chooses the first one it comes across it may be biased in some way. Any insight into this process would be greatly appreciated. I've never really thought about that way; typically I view ties as a problem in the data I'm matching against and go in and fix the problem.  If two addresses match against two separate streets, that means the ranges overlap, and I like to fix those. Thanks again for all the help!  Cheers. Good luck ... View more

I don't know of any literature cititations to reccomend, however, just for fun you maight make some random checks on your ties and see if the tied addresses are not in different tracts.  You'll need to decide what a significant sample of that would be. Also, I think your partial hits might be more of a problem.  Let's say you have an incident logged as 1234 S Main St  and you get a partial match at 1234 N Main ST because S Main ST is now called  S Old Main St but the LEO still calls it S MAIN ST.  You may want to take a look at your partial hits; working in 9-1-1, I always look carefully at those that match but less than 100%.  Obviously that's not a practical standard for the numbers of records you are dealing with. Hope this helps- ... View more

Three words: Network Analyst Extension. Online help:  10.x   9.3.x ... View more

I can attach the data, but it won't let me attach the address locator.  Help? How about a point shapefile of the ones that should be hitting?  And a screen shot of your locator properties? I'll do my best to get to this a little later today... ... View more

Search on Add xy: ArcGIS 10.x online help ArcGIS 9.3 online help ... View more

I have built an single field address locator from an address point shapefile, and am now trying to geocode a voter file.  Most of the addresses plot out correctly, however every once in a while it matches ie) 8418 Long Grove Rd with 8144 Long Grove Rd.  Why is it doing this?  How can I fix it? Thank you! What version of ArcGIS are you using?  Tough to even make a guess without seeing your data; perhaps you could post a snippet of your points and the address file you are matching and see if anyone can replicate the problem you are having... ... View more

I figured out that the issue was my Google toolbar. I disabled the toolbar and all of the geocoding functions are working correctly. That definitely tops this list of "who would have guessed". ... View more

Just a guess; you'll need to get rid of the attributes that the geocoding process creates and adds to the features. ... View more

I have to ask: So you have a geocoding service added to your session in some form? ... View more

I perform a similar analysis on a monthly basis, and while there may be a more elegant way to do it, here is my method: I have a 'master' point feature class that is essentially a compilation of everything I geocode; it does not have all the geocoding attributes you get after geocoding.  It sits off by itself, and is made available for those who need it. Each month I geocode incoming records to its own stand alone feature class; I then use the simple data loader to fold them into the master feature class, mapping over the appropriate attributes. You can add a geocoding process into a model builder application (I think) but I'm pretty sure you can not add the simple data loader into a model builder.  I don't mind doing it manually as it gives me better control over the quality of the results.  I archive the individual monthly results just in case I need to get back at them. Hope this helps- ... View more

Brad- take a look a couple of threads down in the list; Dan had posted a question regarding Tiger Line data that I responded to. I'm all ears on this as I haven't taken the plunge into the 10.x pool nor do I use Tiger data. ... View more

I saw your post earlier, and just now tried creating a locator in a directory.  It works for me.  Typically I create my locators as an object in a geodatabase, but I just created a folder and then a locator within it.  Using windows explorer I can see .loc, .lox and .loc.xml files all named for the locator. I used a US streets locator based on my sde centerlines file, and then added the locator no problem in ArcMap; interactivley I entered my address and got a hit.  So I'm not sure what's going on with yours. Maybe, try it again and see what happens? ... View more

BTW- Using parcels (X,Y centroids - containing situs attributes) will work in postage stamp blocks. One will run into problem if there are shared easements or if access to the road for a specific parcel is not where the mailbox should be. This causes havock with emergency responders in non-rural areas. I've got a nifty little tool that looks at a parcel's situs address, and then moves the centroid of that polygon to front the parcel at the street that matches the situs address. So far it's worked pretty well for me, and I  work primarily in urban sub-urban settings.  All the best- ... View more

I think you guys are missing the point (no puns intended) on how to use streets as a reference when geocoding.  I make a handsome living geocoding against street centerlines because A) they are readily accessible, B) they are pretty accurate, and C) they are easy to work with as far as setting up a locator. But think about it; when it comes to geocoding and spatial precision, streets are only a generalized representation what we expect to find along a given segment.  Let's say you have a segment that is ranged from 100 -198 on the even side and 101-199 on the odd side.  If you geocode house number 150, it's going to interpolate the point right about the middle of the block on the even side, right?  Accurate, but probably not precise.  There may not be a house with the number 150 painted on the mailbox, and even if there is, I'd bet my last dollar it's not smack dab in the middle of the block. For that matter, are there really 198 addresses on that street?  Probably not! Here is another example; lets say you have an intersection of 13th & Main;  Depending on your grid system, it may geocode as such, or 1300 Main St may hit as well.  So, which segment of Main does that point reference? The begin node of one or the end node of the other? Does it much matter?  If Main ST t-bones into 13th, and the range on Main stops at 1298 and 1299, 1300 won't hit.  Clearly there is no house there, but in the 9-1-1 business there is always a lot of action in intersections. The trend I'm pursuing is to use point data derived from actual parcel addresses along the streets.  That way I know precisely where house number 150 is, and I'll composite the streets to the parcel points as a back up to find those 'generalized' addresses.  In fact, I just took a question a few moments ago about intersections from one of my clients; cops are famous for simply calling in two named streets like 13th & Main for traffic stops. Long story short; centerlines are for accuracy, not precision.  If you want to know the true range of a street, look at the parcels. Hope this helps (and everybody stayed awake to the end...) ... View more