At the Washington Department of Fish and Wildlife (WDFW), I helped build an internal application that gives Wildlife Area managers the information they need to take care of the lands they are responsible for, and the assets on those lands, such as roads, buildings, shooting areas, signs and trails. It is an internal system, so this page describes the work rather than linking to it.
Why the Land Matters
WDFW manages more than 1 million acres of publicly owned land and about 475 water access areas across Washington. According to the department’s WDFW Lands page, the goal is a Washington where fish and wildlife thrive in healthy habitats and people can enjoy these places for generations. The department buys and manages land to protect habitat and natural and cultural heritage, and to provide access for hunting, fishing and wildlife-related recreation.
Doing that well starts with knowing exactly what land the department holds, where it is, and how that has changed. Wildlife Area managers then care for that land and everything on it, from roads and buildings to trails and signs. The data this system manages supports that whole range of work on WDFW lands, and it integrates with the systems that track those assets.
The Problem
The previous system could only show the land as it is today. It could not show what the land looked like on a past date. That made it hard to answer public data requests and to analyze how land use has changed, and it left less reliable information for the managers responsible for each area.
What I Built
- A new data model in SQL Server: every land transaction, such as a purchase or lease, is recorded as an addition to or subtraction from the land portfolio. T-SQL functions build and compile those transactions into parcels, which become the managed units of land, like Wildlife Areas. This lets us rebuild the portfolio for any date.
- Feature services: views over the compiled data are published as feature services for use in maps.
- Backend APIs: SvelteKit and TypeScript APIs that serve the database to the web application, which also uses the ArcGIS Maps SDK.
A Design Decision
I kept the geometry in SQL Server instead of in Esri’s geodatabase, so a single transaction could have several related geometries. That made it possible to publish one version of the land that the public can see and another internal version that shows all of it.
Scripting
I also wrote Python and T-SQL scripts for database work, and managed the enterprise geodatabase this data lives in.