Executives and other mere mortals really get the short stick when it comes to the lingo of GIS. It’s kind of like slang in that it evolves at a much faster rate than anyone can really keep up with, and the meanings of these words can vary significantly depending who says them. My blog is dedicated to those professionals (GIS and otherwise) who get blindsided by the GIS jargon of the day. Every time I hear a new word, I promise to post my working definition so that those who have better things to do than decode GIS jargon can move on with their lives.

For my starter blog, I’m going to begin with an old favorite.

GIS Data Model

Back in 1985, a GIS data model referred to the method used for encoding spatial data on disk… i.e. raster vs. vector. The unsaid assumption was that the data were organized in simple flat files such as coverages or DEMs (Digital Elevation Models). However, in the last 10 or more years, enterprise relational database technology such as Oracle, Postgres, and SQL Server has advanced to the point where spatial data can be housed directly in a normalized relational database just like the rest of an organization’s business data.

Therefore, when somebody talks to me about a data model (GIS or otherwise) in 2011, I assume that they mean the series of database objects (tables, views, primary/foreign key constraints, and triggers) that define both the container for the relevant data and the business rules within the database that enforce data validity. A data model is the container that you put the data into in a modern database.