City and County of Denver GIS in the Rockies 2013

Conversion to a Linear Model In 2010 the City and County of Denver embarked on a

plan to convert our existing Feature Based transportation features into a linear model.

Part of the idea was to take advantage of the Roads and Highways application that was being developed.

Linear Referencing

2007 ESRI UC

Existing GIS Data We maintained a street layer that we published into

various editions primarily for Safety and for HUTF. We also maintained some event based layers such as

Pavement and Snow Routes. Resulted in a layer with 60 fields. Arc-Node model supported Intersections and Routes.

Deep Dive

Usual customers: Pavement management Traffic Engineering HUTF Safety

Parks (trails) City GIS users Permitting systems Addressing

As part of this we did a deep dive into as many agencies and their systems as we could.

Some new ones We also reached out to Networking for fiber routing … but this is not that story.

A lot of data One way we found to get our hands around all this

data was to dump all of the necessary data elements into a data dictionary.

Processing the results We began a process of model creation to try to

optimize the overall structure of transportation features as stored in the GIS.

Data Modeling It was a big job and we hired a professional. (as

you can see it was too big to fit on a slide)

Groups of tables We wound up with 3 main groups of tables:

Those specific to the ESRI ALRS model Those specific to our data The data dictionary

This presentation is about the data dictionary and how we used it to generate our schemas

Source Tables Documenting the existing system

Source Features

Bridges Traffic signals Parking meters City projects

Permits Traffic Counts BCycle Stations

Included things like:

All to be turned into Events

How do we examine all this? We documented every existing feature even remotely

connected to transportation For every feature we documented every attribute, data

type and every domain and their values

Problems with the data A by-product of this was that we found things like the

same data being stored under slightly different field names, redundant domains, names left over from coverages etc.

Crosswalk In the process we uncovered a need to be

thorough and to create a crosswalk table by which we mapped a source field to a target field.

Crosswalk (cont.) Having this as a table allowed us to quickly and easily

identify items with no match in either the source or the target.

Mismatches were part of an iterative process that forced us to think about why we needed certain data elements.

Creating a geodatabase Several times early on we would create a geodatabase

schema of parts of the model. Because it was so large, we would often just use parts

of it.

Schema Creation It occurred to me we could use this crosswalk table to

create a schema. Using what we had I wrote some python scripts to do

that.

Needed to be able to repeat this process We needed to be able to do this iteratively. The

process of writing the scripts helped us identify some inconsistencies between the data model and the physical implementation.

It also allowed us to keep up with the changing nature

of the Roads and Highways software which was very beta at this point.

Script I used Python and standard geoprocessing tools such

as Create Domain, Add Value to Domain, Create table, Add Field, etc.

That made the process independent of file geodatabase vs SDE

Process Steps SDE or File GeoDatabase? Determined the connections

Usage Table We had a Usage table that for each table listed the

fields to be created. There was a field for the order in which the field would

be added to the table.

FieldName tables Standardized field names listed data types and

domains

Process steps Created the domains first. Went through field names and found unique list. Used the CodedValue table to find the standardized

list of acceptable values for the domain.

Process Steps Created features using arcpy.CreateFeatureClass. Event tables were created using

arcpy.CreateTable_management Grabbed a set of records for the fields, put them in an

array so they could be sorted based on field order

(haven’t we all run into the irritation of trying to re-arrange the order of fields in an existing feature class?)

Process Steps Last came the

relationship classes.

Features have to exist

Load data Loading data was another problem, required several

other scripts and may be another presentation. Most of the attributes in the street centerline became

linear events Dissolved continuous events, eliminating existing

segmentation (though we preserved it as a separate event)

Dual purpose The beauty of it was we could run it, load data into it,

test it, determine the problems and then run it again. It allowed the data modeler to just add values to the

crosswalk table and those changes would be implemented.

We were still able to do our data dictionary comparison tasks.

Results It worked!!! It leveraged something we were doing anyway (the

data dictionary) and we didn’t have to learn anything new

It was flexible enough to allow us to keep up with changes in the Roads and Highways design

Provided a non technical way of changing the structure and to QA those changes

It wasn’t fast – in the future we would probably use something else like FME (which we didn’t have at the time)

Contact Information Bruce Reagan Associate GIS Developer City and County of Denver Bruce.reagan@denvergov.org (720) 913 - 5883