Today’s blog post tackles the first geocoding issue outlined in our geocoding overview series: how to handle geocoding collisions at offset intersections. In the example below Collins St intersects with Reseda Blvd in two separate locations about 150 feet from each other:
Offset intersections can be a common occurrence in some cities or they may just be isolated to several corridors. Regardless of their frequency, they pose a challenge when attempting to geocode collisions and in many cases can leave some level of ambiguity in the location. This is especially true if one does not have access to the original crash report to investigate the actual location.
Let’s run through the geocoding scenarios for an example set of collision data at the Collins St & Reseda Blvd intersection. A typical set of data will include collisions occurring directly at an intersection as well as those offset a distance and direction from the intersection:
| ID | Primary Rd | Secondary Rd | Offset Distance | Offset Direction |
| 1 | Collins St | Reseda Blvd | 0 | |
| 2 | Collins St | Reseda Blvd | 25 | W |
| 3 | Collins St | Reseda Blvd | 37 | E |
To geocode these collisions it is a two step process; first you have to geocode to the nearest intersection and next you have to adjust the location for any offset distance/direction. Let’s take a look at the typical process for the first step, geocoding to the nearest intersection. In most cases the default intersection geocoding process will place all the collisions at the same location. The potential matching locations for the north and south junctions will be viewed as equally acceptable by the geocoding process, but it will default to one or the another. Which junction does the collision actually occur at? Using public data it is impossible to know, so there is no difference where the collision is located if it occurs directly at the intersection. In this example the collisions were all located at the southern junction. For record 1 without an offset that is an acceptable location and no further processing is needed.
However, what about the collisions that occur a stated distance and direction from the intersection (records 2 & 3)? These collisions can be geocoded more precisely since they lack the same ambiguity. If the collision occurs west of Reseda Blvd, it will be at the southern junction, while the collisions occurring east of Reseda Blvd will be on the northern junction. That is good news and it can add value to the geocoded dataset by having them in the correct location. The bad news is that by default only one direction can be offset properly. Since the collisions were all located at the southern junction, only the west offset can be located (record 2). Why is this? Well, we need to understand how the offset geocoding process works.
The offset geocoding process code attempts to move the collisions the proper distance and direction from the intersection. First the code searches for all segments within a small buffer distance of the default geocoded intersection. When it has found all the connecting road segments, it then tries to match the road names to the primary road name. If it finds a match for the road name, it then tries to match the direction of the road segment to the offset direction for the collision. If it finds a direction match the code will traverse the segment the given offset distance to locate the properly offset position. This process will work for record 2 since the point begins at the southern junction, but for record 3 it will be unable to find the east segment to match. What about just expanding the buffer search size to find the east segment of Collins St? Unfortunately, this will invalidate the offset geocoding code since it creates a long list of other exceptions that cannot be handled appropriately and is not a solution.
At this point, we need to find another way to offset record 3 in the eastbound direction. In order to do this it requires adjusting the original geocoded intersection in the first step to the northern junction for this record. Therefore we created an exception list of intersections and a corresponding XY coordinate that can override the default location. If the primary road, secondary road and offset direction match the list, the original geocoded location will be adjusted to the new XY coordinate.
| Primary Rd | Secondary Rd | Offset Direction | X | Y |
| Collins St | Reseda Blvd | E | -118.536001 | 34.17491 |
In this instance, the east offset records will all be located at the northern junction and can then be properly offset during step 2 of the code. The final result will appear as follows:
So what does it take to make this process work for an entire city? Well, once the code is in place it simply requires some GIS technician elbow grease to build a list of offset intersections and their corresponding XY coordinates to populate an exception list. It also requires reviewing geocoding results to determine which junction the initial geocoding process will use as the base intersection. Depending on the size of the city it can be a large task, but there may already be a list of existing offset intersections that can be used as a starting point. Regardless, it is never a bad idea to have an inventory of offset intersections and their XY coordinates, so it can be a useful exercise beyond geocoding collisions.
The ability to properly geocode collisions at offset intersections means a higher percentage of records can be geocoded with a higher degree of accuracy. At RoadSafe GIS, we recognize that value and have streamlined the process as part of the initial geocoding and data setup for new subscription clients.
Check back soon for more posts that tackle different ‘gotchas’ of the geocoding process.