When organizing geospatial data collections it is important to associate data with names that facilitate discovery. This applies to the names your users see and how you name features at the root level (think SDE Feature Names).
In 1997, I was appointed GIS Coordinator to the City of Bakersfield and while searching the internet for standards that I could use to organize the City’s data I came across the Tri-Services Spatial Data Standards (TSSDS) later renamed the Spatial Data Standards for Facilities, Infrastructure, and the Environment (SDSFIE). You can download the old standards here.
The TSSDS was developed in 1992 by the Tri-Services CADD/GIS Technology Center at the US Army Engineer Waterways Experiment Station in Vicksburg, MISS. The Center’s primary mission was to serve as a multi-service (Army, Navy, Air Force, Marine Corps) vehicle to set CADD and GIS standards, coordinate CADD/GIS facilities systems within DoD, and promote CADD/GIS system integration.
I was particularly interested in the hierarchical classification that assigned geospatial features to Entity Sets, Entity Classes, and Entity Types.
- Entity Sets were a broad classification like boundaries, cadastre, fauna, flora, hydrography, transportation, and others.
- Entity Classes were more narrow focused groups such as: transportation air, transportation marine, transportation vehicle, and others.
- Entity Types represented the actual geographic features.
Transportation – Vehicle – Road Centerline
Cadastre – Real-estate – Parcels
Hydrography – Surface – Canal Centerline
In 1997, shapefiles were new and most of us were still using covers so most geospatial data was organized in folders and this standard worked pretty well.
In 2001, at SFWMD we implemented the same standard in SDE:
Transportation – Vehicle – Road Centerline (TRVEH_ROAD_CENTERLINES)
Cadastre – Real-estate – Parcels (CDREL_PARCELS)
Hydrography – Surface – Canal Centerline (HYSUR_CANAL_CENTERLINES)
This system also worked pretty well but by 2001 there were many more non-geospatial professionals using the system, and the need for something more user-friendly.
The solution was a look-up table that takes terse SDE names and renders them in a simpler to read style. In principal, such a system would consist of a parent table containing source information (SDE, services, layers, shapes, covers, etc…) and a daughter table containing your classification schema. The parent table would be populated automatically through ETL scripts but the daughter table would be crafted manually by a data steward. A graphical user interface would then provide users with access to the information in the daughter table while a backend uses the parent table to retrieve the data.
Some of you may be asking why create a library from scratch when GIS packages can automatically index data for you. The answer is that these automated systems are good but still not as effective as a hand crafted system. Automated systems perform only as well as their metadata is written. Now let me ask you, how well is your organization’s metadata written? In most sizable governmental agencies data is incoming from both internal and external sources and unless you have a robust procedure for vetting the metadata a lot of garbage will get in. Vetting not only means automatically verifying that required metadata elements are filled in but also verifying that they make semantic sense and that titles are standardized. Looked at from this perspective it is much easier to standardize a feature class name in a lookup table than feature class metadata.
Juan Tobar, Supervisor – Geographers, Regulation GIS, SFWMD