Mapping Center

One of the things we end up explaining on a fairly frequent basis is why we've been spending time working on data modeling, the base map data model, cartographic data modeling, or adding cartography to the ArcGIS data models. This is as good a time and place as any to put forth what we think a cartographic data model is and share some of our reasons for working in this area.

A cartographic data model is the codification of the geographic features, attributes and processes that produce a desired map or products through specified software. This includes specification of all geographic features and labels that will appear on the maps, and their symbology. It includes allowances for the software to handle or process the data appropriately and efficiently in order to make the maps.

While data models can be articulated in a variety of ways, through books of specifications, UML diagrams, organizational charts, etc., cartographic data models are best expressed when the maps themselves are what organizes the information in the data model. It's back to the old adage, "a picture is worth a thousand words". In the Map Specification diagram information related to the data model through annotated notes next to the features they pertain to. Click on that diagram to download the full size PDF version [11.0 Mb].

An advantage of cartographic data modeling is that it requires us to think analytically about map design and the map making process. In many cases we know that it's easy to find ourselves allowing the software to drive our map's design rather than harnessing the power of the software to effectively and efficiently execute a pre-conceived design.
Cartographic data models that reflect both map design and software capabilities can and should influence the primary data capture and initial database compilation as well as subsequent update by assuring that the requirements for making all maps and data products are embedded in the database design. For example in the image below which shows a portion of a topographic map of Southern California with the names for physiographic features e.g., mountain ranges and valleys, which were part of the map's specification.

These features are not normally captured in GIS databases, but we knew that Maplex could automatically label the features as required if the features were stored as polygons. Knowing this mapping requirement and the software functionality at the outset allowed us to design the initial database so that these date were included.

Perhaps the hardest information to get into the data model are the processes that the map maker uses to produce the final map design and product. In some cases, it is possible to translate the cartographer’s thinking directly into GIS data and sequences of software functions; other times the requirements are more elusive because it is difficult to formalize how a cartographer completes certain tasks. There are a number of reasons for this elusiveness, including the iterative and inexact nature of some map making tasks, the lack of attention historically given to codification of some map making tasks, difficulties in translating the tasks to their expression in a digital environment, and incomplete knowledge of the data and/or software required to complete the tasks. However, each of these circumstances can be added to the specification to qualify the nature of such mapmaking tasks.

For more information see the Basemap Data Model website and Chapter 8 of Designing Geodatabases.

CF