Town of Braintree GIS
View my GIS website for Braintree
View in-depth project descriptions on Github
Managing a Drone Program
In 2025-2026, I built out a municipal drone program for the Town of Braintree Engineering Department - earning my FAA Part 107 certification through Bridgewater State University's sUAS program and standing up operations around an RTK-enabled DJI Matrice 4E capable of sub-centimeter positional accuracy. I use it to capture 2D orthomosaics and 3D models for site development monitoring, pre/post-paving documentation, and locating buried infrastructure before it's paved over, publishing results through ArcGIS Online for the rest of the organization.
I've also documented the program's SOPs - file structure, pre-flight checklists, mission reporting, 7-year FOIA-driven data retention, and LAANC airspace approval - so operations are scalable to future remote pilots rather than tied to one person's workflow.
Automating Workorders
Like many municipalities, Braintree tracks workorders, permits, and billing across separate databases that don't talk to each other, and workorders themselves have historically moved on paper - multiple trips to the office to collect, process, and return information about work done by field staff. It's an awkward process with a single point of failure, since paper copies get lost or damaged along the way. In 2025 I began replacing that loop with an ArcGIS Online web map and Experience Builder app that field staff use to record the jobs they do each day.
The solution is built on a hosted feature layer with attachments enabled, so a worker can drop a point where the work was done and photograph the job or the paper workorder itself - the same way they already edit our GIS utility data in the field. A GitHub-based automation checks the layer for new records several times per day, pulls the details from them (work start/end, description, worker names, attachments) into an email, and sends it back to the office, where staff can read each job and click through to view its point on the map. That gives office staff a digital source to reference when entering work into the relevant database, removes the need to carry paper back and forth, and preserves the work on a map for future reference.
Analyzing Utility Data
EPA's MS4 permit requires municipalities to report volumes of material cleaned from drainage system catchbasins as part of annual reporting. Stormwater field staff record cleaning events in ArcGIS Field Maps, taking three measurements at each basin - clean basin depth (rim to floor, no material), depth to deepest sump (rim to the bottom rim of the deepest outflow pipe), and depth to material (rim to top of sediment) - which together allow us to estimate the volume of material cleaned per basin over time.
I developed a Python-based tool using the arcpy and arcgis modules to summarize those cleaning events on demand. It's a standalone Tkinter GUI program with buttons for 'catchbasin cleaning analysis' and 'sump depth analysis', reporting the number of catchbasins cleaned, estimated total sediment volume over a specified time interval, and other summaries of the stormwater infrastructure we maintain in ArcGIS Online. It runs on any machine with ArcGIS Pro installed and signed in to Braintree's ArcGIS organization, as long as the member has the required layers shared with them, and the Stormwater department uses it to pull reportable sediment volumes directly.
Processing Utility Documents
As new water and sewer services are connected, documents are produced showing a diagram of the lateral running from the main in the street to the house - these documents are commonly referred to as water or sewer 'tie cards'. Historically they were created and stored in filing cabinets, and copies ended up filed in several places at once, so when someone updated a card the other copies quietly went out of sync. In 2025 I consolidated them into a single authoritative digital archive on Microsoft SharePoint, reorganizing the original water and sewer PDFs into a standard folder scheme: a folder per street, address sub-folders within each, and water, sewer, and sump-pump connection cards filed at the address level, with 'main gate' cards and other street-level records kept at the street level. Field workers, who previously had no way to reach these files from a phone or iPad, now have direct access to view and update them in the field. The archive also served as the source a contractor used to build our EPA lead-removal inventory of water service connections - pipe material, diameter, install date, and whether a service was previously lead - which we now maintain in GIS as our authoritative lead list.
Merging newly scanned cards into that archive is its own workflow, and with a backlog of several thousand cards to process it was worth automating. I created a Tkinter-based Python program that takes a folder of fresh scans (still carrying whatever random filenames the Xerox assigned), previews them one at a time, and lets the user rename each to our standard convention - 100 MAIN ST - WATER CARD, 100 MAIN ST - SEWER CARD, and so on. The program then locates the existing SharePoint file by that name and displays both side by side for cropping, page reordering or deletion, and merging, with undo/redo and a preview of the final PDF before committing the save. If no match is found, the user can search manually for a mis-named or misspelled counterpart, or choose 'create' to generate the correct folder, sub-folder, and file in place. That replaced a per-card routine of opening each PDF in Adobe or Bluebeam, cropping, renaming, and hunting down its SharePoint counterpart by hand. These days the cards trickle in a handful at a time and I handle them manually in Bluebeam, but this program is what made the original ~10,000 file backlog manageable.
Automating Address and Parcel Updates
As GIS Coordinator, I maintain Braintree's tax parcel data to the MassGIS standard, keeping it in sync with the Assessor's office and the Registry of Deeds as properties split, merge, or get reassessed. That work includes managing a master geodatabase of parcels, assessment records, and lookup tables, publishing to ArcGIS Online through a custom delete-and-reload Python script, and generating standardized tax maps with a script tool I built for the purpose.
I also assign and manage address numbers in GIS and maintain Braintree's Master Address Database, which was built from the MassGIS NextGen 9-1-1 format and stays linked to assessor records through a unique GIS_ID. It integrates with PermitEyes to enforce official address assignment before a permit can be issued, which keeps addressing authoritative at the exact point where bad addresses would otherwise enter the system.
Using a Survey-grade GPS
In 2025, the Engineering Department purchased an Emlid Reach RX RTK-enabled GPS unit to support GIS data collection workflows. It connects to the MaCORS RTK network over NTRIP to improve positional accuracy to sub-centimeter, and pairs with ArcGIS Field Maps as an external receiver in place of the significantly less capable GPS built into a mobile device.
Using maps I've produced, staff reposition existing features like fire hydrants and manholes - or add new ones - almost exactly where they sit in real life, which pays off for anyone later looking for an asset buried by ground or snow. We started with one unit to see how easy it was to use and how much use we'd get from it; it was successful enough that we bought a second. The Water & Sewer department uses the original day-to-day, and the Stormwater department uses the other to update our drainage system data, slowly improving the accuracy of our utility datasets over time.
Analyzing Impervious Surfaces
The Stormwater department bills a utility fee on residential and non-residential properties, and while residential parcels pay a fixed fee, non-residential parcels are billed on how much impervious surface exists on them. As properties are developed or boundaries change, that number changes too, so it has to be routinely recalculated and compared against historical data to keep our billing database accurate. I produced an automated, parcel-level comparison of impervious surface change using ArcPy geoprocessing workflows and custom scripts, calculating the impervious area that actually exists on each non-residential parcel and comparing it to the value being billed and to prior years.
Most of the time those numbers align closely, but the analysis surfaces parcels that appear to be over- or under-billed. Often that's an artifact of an imperfect impervious surface dataset, but in some cases it's a genuine billing discrepancy worth investigating. The analysis runs in ArcGIS Pro and exports cleanly to an Excel table that the Stormwater department can use to check parcels against the billing system and update it accordingly.
Monitoring Hydrant Flushing
In 2024 I began developing an ArcGIS Online solution for monitoring fire hydrant flushing operations. Field workers in the Water and Sewer department needed a way to visualize and track flushing on a map, store multiple records per hydrant, and see at a glance which hydrants had been flushed and which hadn't. I worked closely with field staff to understand their needs before architecting a solution that would benefit them in the field as well as office staff.
The result lets staff view hydrants by flush status, condition, service (i.e. out of order), pressure (i.e. high / low), manufacturer, and other properties. That same information is useful to the Fire Department, which can check current hydrant operation status and pressure to respond to emergencies more effectively.
Creating a Map Grid and Street Name Index
Many of the maps I produce share the same standard layout: a map area with the usual elements (title, legend, scale bar, north arrow, description) and a sidebar street list keyed to a grid on the map (A1, B1, A2, B2, and so on), broken up alphabetically so someone can find a street name and go straight to the right cell. That requires the grid to exist as a feature class, with each cell as a feature, so cell values can be spatially joined to the streets - and it requires every map using it to share the same extent, which I enforce by adding the town boundary polygon to each map (toggled off if necessary) and using ArcGIS Pro's 'fit extent' (Alt + click layer). I drew the initial rectangle from inside an activated map layout so it sized closely to the actual map window element, then used a Python script to divide it into a reasonable grid and enrich it with the correct cell values.
The street list needed its own cleanup, since our master MassDOT roads dataset often carries multiple features per road (different segments, non-continuous roads). I dissolved a copy of the roads layer on road name to create a single feature per unique name, split that by the grid, then de-duplicated again keeping only the longest segment per name - so each road is labeled in the cell it overlaps most, rather than in every cell it touches. Spatially joining that result back to the grid produces a list of unique street names each tied to a single grid cell value, and a custom Arcade script drives a Text (distinctValues list) layout element that draws the list in the sidebar.