# How to maintain integrity between changing street network and geocoded points?

We maintain hundreds of thousands of points geocoded against a dual-centerline Navteq street network. We are faced with the challenge of maintaining referential integrity between our points and the street network, which changes with each Navteq update. A high percentage of our points are geocoded manually, so we can't just run them again through an automated geocode process.

Some points are geocoded by street address, others by distance and direction from an intersection, still others by GPS coordinates. In each case we need to retain the closest possible match on the updated street network.

I solved this problem once before on a single-centerline network, using linear referencing, geocoding, and snapping techniques, but the process was very rigid and brittle. (See http://thewyvern.co/Thesis.final.pdf for details.)

Has anyone else confronted this problem? Do you have any suggestions? Can you point to any research out there that could help us develop a robust solution?

For context: we are using a custom geocoding algorithm coded in ArcObjects, which relies only partly on ESRI's Locator class. Our system is based on ArcGIS Server 9.3.1, with data stored in ArcSDE 9.3.1 on Oracle. Navteq data is delivered in shapefile format.

• Can you add more information to your question such as what software you are using to geocode, data formats, available software, etc. If you are using ArcGIS, have you considered using a geometric network? If you have FME you might be interested in this presentation by San Antonio Water System. Commented Oct 6, 2011 at 18:30
• "Topological integrity" is a very broad term, and I am curious as to exactly what you mean by it. Do you want the nodes that you geocoded to be part of the street edges? Because using parcel-level geocoding with corrections can easily put the geocoded points on some part of the parcels and still be "topologically correct" Commented Oct 10, 2011 at 21:25
• @Ragi: It is a topological problem (I think) in the sense that points are positioned in network space relative to other features. But perhaps the term is unhelpful here.
– nw1
Commented Oct 11, 2011 at 15:53
• Is there an attribute relationship (PK/FK) between the node and centerline, or could one be added to the nodes before updating the centerlines? I'm pretty sure NAVTEQ keeps a semi-permanent ID that should stay the same even if the geometry changes. Would a centerline ID and a percentage down the line be enough to locate your nodes appropriately after centerline updates? Commented Oct 11, 2011 at 18:17
• In my experience, the ID only changes when the geometry is split, usually because of a new intersection with another road or pedestrian geometry, not simply adjusted. Are you seeing otherwise? I guess I'm trying to determine the scope of the cases this solution must handle. Commented Oct 11, 2011 at 20:52

I am looking at a problem for my agency right now that hints at that same scenario or atleast a very similar one.

What I am targeting is this; all address points have a ID to the street they match to; as well as the USPS Range from AIS. We need to run a check for change detection with each vendor street update, for the street-segment IDs that have a change we then isolate the points that reference that ID; we will then loop through each one of these doing a buffer to select the nearest street-segment ID so we are able to keep these related properly.

This will be a time-consuming process but you can script a fair amount of it(this I am modeling out now) and it only needs to happen when you update your vendor data. We will be getting updates for our addresses from a number of sources, so we will take the points and merge them in and then update them each time our vendor data updates, I might even add refernce to the TIGER/Edge but that would just be for future demographic modeling uses.

We are working to bridge ranged addresses with parcel level data that will support a statewide addressing and routing source.