I am working on the geocoding of patient addresses for a public health organization.

We use the Normatim (OpenStreetMap) and Google APIs. With the Google service there is no problem so far, but it seems that Normatim, sometimes, has errors in the geolocation of some addresses, particularly with the numbers of the streets.

As you can see in the list, the street numbers are very different (from 2500 to 4300) and should be distributed along the entire street, but Normatim locates them at the same block (image below).

address list

enter image description here

I realize that these are errors in Normatim's data, and I do not intend a solution to this. I am looking for a way to identify these cases (when there is a 'suspicious' grouping of points) to re-process them through Google.

My first approach is to make a heat map, which allows me to visually identify these suspicious clusters and select cases manually.

But I'm looking for a way to avoid this manual selection, see if there is any way to perform this analysis in a more systematic way. Any ideas or advice?

Note: we must use the Normatim service since it is free and we do not have enough funds (yet) to pay Google (we can only use the 2000 free queries per day that Google offers, but our databases are larger, and growing).

enter image description here


Creating a unique ADDRESS_ID has been our key tool for evaluating geocoding.

Then, when you geocode from multiple sources, you can evaluate the distances between the different providers by joining the two tables back to each other on the ADDRESS_ID, and in our PostGIS system, use ST_DISTANCE() to calculate the distance between the various geocoded points.

When we do this, we look for addresses that after geocoding are more than 500' from the original. From there we can determine the cause of the error, or a pattern of why a particular set of points has ended up in a 'hotspot'.

Common sources of error that we have found using this method are:

  • 'N' prefixes are not picked up by Google, and have dumped dozens of points into a parking lot at Mile High Stadium in the 'N' lot (not good)
  • If a result isn't found, Google will dump the result to the Center of the City, thus creating a hotspot of points at Civic Center park in Denver
  • If a result can't be found on the street level, it will dump the point into the center of the Zip code instead

All of this is done using SQL, again in PostgreSQL / PostGIS, and processes can be created to do all of this automatically.

  • It seems a very interesting approach. But the problem that I find to apply to my case is that I don't have two datasets to compare. I understand that this method requires an 'original' dataset with 'good' data, and a series of data presented to it for comparison. I need a way to identify and extract badly geocoded addresses , but without resorting to Google. And yes, Google geocoding is a headache because of the inability to limit the search to certain parameters. Thanks! Jan 10 '20 at 18:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.