For Attribute data, Data Currency and Data Consistency are very important concepts. When you’ve finished reading this post you’ll understand that you can’t just pick up an old dataset and blindly believe that it will meet your needs.
Data Currency
Out-of-date data might be pivotal to your project if you’re interested in analysing something from a long time ago. It can also be a major problem for your GIS project.
Let’s think for a moment about Google Maps. Do you think people would want to use Google maps to find businesses and places if the information that google returned was out-of-date?
For example, if a restaurant search returned a business that had closed 4 or 5 years ago, or an old menu.
Data currency is critical to Google Maps. Although some of their information is incorrect, google does a pretty good job of trying to keep the information current.
Data Currency also relates to common GIS tasks such as Land Use mapping. An out-of-date map might show a cadastral block as being in an industrial zone, where in fact, in the last few years, the zone may have changed to be residential. It’s sometimes important to know whether a residential area was once industrial, what sort of industries were there, and previous ownership – especially where environmental contamination issues are at stake.
Data Consistency
Many government databases are in poor standing because they’ve not resolved the data consistency issue. The idea behind data consistency is that you need to describe your data in a consistent way. For example, I was dealing with a Swimming Pool project for my state government some years back. The database I was using was from the Building Inspector’s department. A database search for “Pool” produced dwellings with “Swimming Pools”, “Pools”, “Pool Fences”, “Pool Tables”, and a number of other variations. The Department had no consistent way of describing anything in their database, meaning that it was near-useless for the project purpose.
Another example would be a search in a restaurant database for a Cantonese restaurant. Unless somebody is going to specifically be searching for a Cantonese Restaurant, its probably better to have it described as a Chinese Restaurant. Another mistake that’s commonly made in restaurant databases is to call a “restaurant” a “café”, to mis-spell it to be a “restrant”, or to abbreviate it somehow. If you have a consistent way of spelling and representing the same sort of thing in your database, that database is going to be far more powerful than it otherwise would have been.
Questions or comments, let us know below.