•Model reality
•Use ArcGIS® Pro
Introduction
The goal of designing a geodatabase is to model the reality it is intended to represent. There are many characteristics, or behaviors, of the data that can be included in a geodatabase using various techniques. As the data modeler, it is your job to explore the capabilities of ArcGIS to make the most efficient and flexible database possible. The time spent at the start of a project designing the geodatabase will reap rewards later by making the data easier to use and edit and presenting a better representation of reality.
The first step is to study the reality that is about to be modeled. Look carefully and determine what features must be included in the geodatabase. In ArcGIS, everything is modeled as points, lines, and polygons, so realistic characteristics will need to be assigned to these pieces.
Next, look at how the data will be created. Will it be imported from another source, collected with field equipment, traced from aerial photos, drawn from survey data, or derived from some other process?
Finally, consider how this data will be used. Who will perform the edits, and what queries might it be expected to support in the future? Knowing many of the questions that the data will be used to answer will shape the geodatabase design.
With these things in mind, you can start to construct a logical data model. The model will diagram your process and allow for updates and changes before the final design is committed to a geodatabase. The design process uses a spreadsheet-based form to enter all the characteristics of the geodatabase, the feature datasets, the feature classes, and the data integrity rules of the feature classes such as domains and subtypes. Microsoft Excel® spreadsheet files included with the exercise data follow the creation process in ArcGIS Pro that will be used for basic diagramming.
The logical model is used to show what data types you will have (points, lines, or polygons), what tabular data will be included in the dataset, and the relationships between the tabular data and feature classes (if any). The model is also easily shared among your colleagues, so you can get several opinions on the design you are attempting.
Once a preliminary logical model is completed, it can be checked against many of the advanced features of the geodatabase, such as domains, subtypes, and relationships. Have the best tools been employed to ensure data integrity, ease of editing, and future expansion? You will also check the geodatabase against your idea of how the data should behave.
The result should be a well-thought-out geodatabase that is both efficient and a good representation of reality . . . well, at least as close as you can get using points, lines, and polygons.
You will start with a simple geodatabase, and then examine several advanced geodatabase options to see if better efficiency and more realistic behaviors can be achieved. The good news about any geodatabase design is that if it works, it’s a success. Ten different people could design 10 different geodatabases for the same project, and they all could work quite well. The true test is how efficient a geodatabase is, how well it models reality, how well it maintains data integrity, how flexible it remains for future projects, and how easy it is to work with in editing and extracting information.
Designing the data
Scenario
The City of Oleander, Texas, population 60,000, has hired you as the top-gun geodatabase designer and wants an all-new database design for its parcel data. The new geodatabase will be used to designate each piece of property in the city—who owns it, its legal description, address, and more. You’ll get information from the city planner to get the full idea of what’s needed, and then create a diagram of your proposal. At this point, the geodatabase will not be constructed, only designed.
The city planner describes a dataset that would have a polygon for each piece of property in the city, whether it is platted or unplatted. It should have information about the legal description, the street address, and the current usage of each property.
Data
Because you are creating this geodatabase from scratch, there is no data to start with. You will need to print the geodatabase design forms from the exercise materials you download from ArcGIS® Online and use them to document the design process.
Tools used
•Geodatabase design forms
Begin the logical design for the geodatabase
The main component of this geodatabase will be polygons representing every piece of property in the city. Each piece of property is assigned certain data by the city. This data includes the subdivision name, block designation, lot designation, street address, and a land-use code, which shows how the land is being used.
As you know, the geodatabase is the framework in which other components are built. It may contain feature classes, tables, relationship classes, feature datasets, and many other components. You will design the geodatabase and its components using the geodatabase design forms provided in the files you download for this book.
Access the data
The data is stored in a book group named Focus on GDBs in ArcGIS Pro (Esri Press) in the Learn ArcGIS organization. You will log in and access the files for this tutorial, as well as for all the tutorials and corresponding exercises in this book as you need them.
1.Go to https://www.ArcGIS.com, and log in with an ArcGIS Online account.
2.On the Home tab, type Focus on GDBs in ArcGIS Pro in the Search box, and then click the Search for Groups entry in the drop-down list. (If no groups were found, turn off the option to “Only search in your organization.”)
3.Click the link to open the Focus on GDBs in ArcGIS Pro (Esri Press) group and find the data, named FocusGDB. It consists of a zip file for each tutorial in the book.
4.Create a folder named EsriPress in a location where you want to store all the files, preferably on your drive C. Click the thumbnail and download the data for the first tutorial, saving it to your new folder (e.g., C:\EsriPress), rather than in the Documents library or on the desktop.
5.Extract the zip file. It will create a folder named Tutorial 1-1.
6.You can download and access these files as you need them for the other tutorials in this book.
Start building the model
1.Open a file explorer window and navigate to the location where you downloaded the tutorial 1-1 materials. Open the file GDB design forms.xlsx. Note: There is also a PDF version of this file in the same location.
2.Print all six pages of the geodatabase design forms (GDB feature classes, tables, domains, domains 2, subtypes, and relationships).
You will write out all your designs on these printed sheets, and you can print more sheets for corrections or expanded designs. Pages 1 and 2 will be used for these first few steps, but the other pages will be used in the other steps of this tutorial.
The geodatabase will need a name. It should reflect in general terms what will be stored in it.
3.On the first line of page 1 (GDB feature classes), write the name LandRecords for the geodatabase name.
The next line asks for a feature dataset name. A feature dataset is used to separate data into smaller subsets but is also important in grouping data for use in topology and various other advanced features. For now, leave the feature dataset name blank.
The next step is to start filling in the feature classes. So far, the city planner has described only one feature class, which will contain the polygons representing parcels and will include the fields he described.
4.On the feature class portion of the worksheet, add a new feature class named Parcels. Note its type as POLY (for Polygon), and give it an alias