Mueez Khan
Mueez Khan
Mueez Khan
Table of contents
Our Mission: To make finding water data simple.To help visualize some of the complexity and data flow required to fully integrate water data, this braided stream visual depicts the combination of “water data streams” from multiple regional, state, research, and federal data providers. These data providers, at the top of this figure, are the tributaries.
Each data provider can be considered an individual stream that is a tributary flowing toward a “confluence” of multiple data streams. Data providers with various internal data systems, such as databases or spreadsheets, can make data available in different ways, which are shown as channels on this figure...The goal is to bring all channels together at a confluence, shown as a beaver dam in this illustration, that integrates all of the data into a coherent whole.— New Mexico Water DataIn the publication 2025 Plan: New Mexico Water Data Initiative published in September 2025, user research revealed "inadequate geographic filtering" as one of the issues of the hub and a key suggestion of "enhancing geographic filtering". The geospatial features I'm developing directly contribute to this enhancement and build upon the geospatial features I've built for the Texas Water Data Hub. Many of the features of the new gazetteers for the New Mexico Water Data Catalog resemble those of the Texas Water Data Hub that I've written a post about before. Therefore in this post I intend to highlight new and/or improved features rather than demonstrate features I've built already for the Texas Water Data Hub.
This section in particular is a bit technical. Having web development experience can help.The first gazetteer work I focused on was for the Texas Water Data Hub by adding requested geospatial features to their custom CKAN extension. However, the extension had thousands of lines of JavaScript code and was not very maintainable especially if a developer did not have much experience with HTML, CSS, and JavaScript and may need to spend several weeks to months attempting to understand the codebase. The team for the New Mexico Water Data Catalog was also looking for the same geospatial functionality, however porting the entire codebase for New Mexico's specific use case (let alone making it a generic geospatial CKAN extension) was not feasible within a reasonable timeframe. Therefore I did something I've done multiple times before similar to what I did for the : a rewrite of the extension's codebase, in this case integrating React. CKAN does provide the Jinja2 templating engine and also HTMX in recent versions of CKAN. However with the rewritten extension's complexity and ease of integration with third-party libraries, I contemplated as to how I could integrate React into the CKAN extension. Considering how React projects and CKAN extensions are architectured, I thought perhaps I can "inject" a React app as a "widget" within the page by targeting a DOM element by its ID. The HTML element with that specific ID can be specified within a Jinja2 template file and also the bundled output of the React app (built as a single JavaScript file with Vite and Rolldown) can be imported as a web asset. Since I plan on using shadcn/ui with Tailwind CSS I need to prevent conflicts with classes from Bootstrap which CKAN provides, therefore I also included Tailwind's
prefix option. I also decided to replace Leaflet as the primary map provider with MapLibre GL JS (by using the react-maplibre library) as it is actively developed with the MapLibre Organization. Also I can focus on using TypeScript instead of JavaScript!
Note: The new ckanext-gztr CKAN extension now has a new architecture compared to when this blog post was made. Learn more at gztr.dathere.com!
This new architecture provides better potential for maintainability, customizability, and adding new features. Note that this is primarily for the widget-based architecture where specific React apps act as components initialized onto part of a web page rather than replacing the default architecture of a CKAN extension. For example we still use Jinja2 to inject the React app (which is bundled as a single JavaScript file by configuring Rolldown).
This architecture can definitely be improved. For example I think it may be useful to look into Vite's library mode to consolidate widgets and have multiple build outputs. Also consideration should be made as to how to import shared libraries in the case that multiple React widgets are on the same page. Perhaps even profiling for bundle size optimization.
Note: The UI in the new ckanext-gztr extension now uses a single combobox.
Note: The public search gazetteer has initially been made for desktop devices to view and is not responsive for mobile devices yet. In a future update the public search gazetteer should be either made responsive or optionally hidden from mobile view.
Submit a comment about this post that may be shared.
Receive updates during my career.
Technical writing on work experiences, projects, and tools you may find useful.