Is there an industry standard or best practices for a database of Addresses? I've searched for examples of Address models, and all I've found are very barbaric models that have something like address lines 1-3, postal code, and maybe latitude and longitude float fields. This wouldn't facilitate searching by city.

I've been thinking about the model that Google Maps uses, and initially I thought they used nested tables, so for example a route would belong to a locality, which would belong to a state, which would belong to a country. But then there are countries that don't use localities, for example they might use counties, and Google Maps presents their address components in the API side-by-side instead of nested, so I'm inclined to believe that Google Maps uses a "thing-and-data" model. Is this kind of model the industry standard for storing addresses?

I wasn't able to find any examples of recreating the Google Maps model, but I only found a list of all the types of "thing"'s they currently have thus far: https://developers.google.com/maps/documentation/geocoding/intro?csw=1#Types

If this type of model is recommended by the GIS industry, what is it called and where can I find examples of its implementation in code? If it's not the industry standard, what is the recommended model?


2 Answers 2


Well, first off, let me say if you are looking for a single, official, industry standard geodata model that works perfectly for all addresses across the globe, good luck and let us all know if you find one. However, that said, at least for the USA, there are some applicable geodata models for addressing data that may work as a good starting point for you.

First, a very detailed and extensively parsed out data model is available from the FGDC at https://www.fgdc.gov/standards/projects/FGDC-standards-projects/street-address/index_html (with links on that page to standards documentation/descriptions and schema files). This schema was designed to enable presumably almost any addressing data, including unique exception type situations, to be handled and accounted for within a single data model. Therefore, it is in theory a comprehensive data model, but that comes at the cost of increased complexity, making it potentially more work to build and/or maintain the data in this model.

Second, while I know your tags suggest you are not working strictly within the ESRI platform, the company still has some useful tools and data models. Including their Local Government Data Model, which you could download at http://solutions.arcgis.com/local-government/help/address-management/ as part of their address maintenance tool set. This model, unlike the FGDC one, was built in theory to best suit the most common needs of the majority of ESRI software users. It is likely to be a bit easier to use in terms of complexity in parsing out data, though it relies more on storing pieces of data in multiple different datasets (ex: there is a road, a site, an entry point to the site, a structure assigned an address, and other related tables that help maintain and QA/QC the data). However, if you were to use the ESRI platform, there are tools they have built to minimize the hastle of this complexity. Of course, if you're using it just as a database model though, of course you're going to have to deal with the data redundancy/synchronization/cross-table validation complexities yourself.

And again, those are just 2 of the more formalized ones. There is also Geodatabase models for specific industries, like the 911 industry, but that is currently undergoing an over-haul of data-models and associated standards, data maintenance recommendations, and such, so...

Sorry if that's about as clear as mud. Feel free to ask if you still have questions as I may be able to clarify.


PostGIS 2.2.0 includes the "address_standardizer" extension, which is derived from/similar to the PAGC address parser. The gazetter-and-rules approach to parsing may work better for you. I deal with property data, which in the case of undeveloped lots, may not have street numbers or otherwise "odd" addresses. You could (using the address_standardizer_data_us extension as a start) build a list of rules to more easily parse out the names of cities and places you desire.

  • From what I understood, this looks like it accomplishes the same as the searchbox on Google Maps. What if I have the data parsed, and I want to store it in a database? What model should the database use, in terms of fields/relations/tables?
    – davidtgq
    Commented Jan 22, 2016 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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