The highlight of this release is our CoreSpatial Portal release based on MapStore2 v2025.02.02. This is a large rollup that advances through multiple upstream MapStore2 releases. See full details below.

We also look forward to continued development in the following areas:

• Bulk tile collection projects via Map Manager UI
• Expanded image handling capabilities in Map Manager – georectification of commercial drone imagery using JPEG EXIF
• Desktop GIS integration via QGIS

CoreSpatial Server and Basemaps Release Notes

2026.1.7 (03/31/2026)

• Update GeoServer to 2.28.3
• Update PostgreSQL JDBC jar to 42.7.10
• Update C3P0 Connection Pooling lib 0.12.0
• Improve SBOM/CVE diff automation (new scripts, live image scans, and previous-release SBOM comparisons)

2026.1.6 (03/03/2026)

• Patch five High/Medium CVEs in bundled JARs
• Add support for multiple SBOM formats: SPDX, CycloneDX, and Syft

2026.1.5 (01/21/2026)

• Patch vulnerabilities discovered in UBI 9 base image

2026.1.4 (01/30/2026)

• Patch vulnerabilities discovered in UBI 9 base image

2026.1.3 (01/26/2026)

• Patch vulnerabilities discovered in UBI 9 base image

2026.1.2 (01/21/2026)

• Patch gnupg2 High severity vulnerability affecting the Docker container base image

2026.1.1 (01/14/2026)

• Patch libpng to remediate High severity vulnerability affecting the Docker container base image

CoreSpatial Map Manager Release Notes

2026.1.9 (03/30/2026)

• Refresh runtime container packages in the final Docker image to clear fixed vulnerabilities in the release container

2026.1.8 (03/25/2026)

• Bump Spring Boot to 3.5.12 to remediate JAR vulnerabilities affecting Tomcat and Spring Web MVC
• Update PostgreSQL JDBC to 42.7.10, Logback to 1.5.32, commons-io to 2.18.0, commons-lang3 to 3.19.0, and commons-compress to 1.27.1
• Separate WMS Scraper into its own versioned release flow

2026.1.7 (03/06/2026)

• Bump Jackson to 2.18.6 to remediate a JAR vulnerability

2026.1.6 (03/03/2026)

• This release was cut to patch vulnerabilities discovered in the base container image

2026.1.5 (02/02/2026)

• Bump react-router and react-router-dom to 6.30.3 and @remix-run/router to 1.23.2
• Bump lodash to 4.17.23

2026.1.4 (01/30/2026)

• Remove Python from the runtime image so it remains build-time only for GDAL
• Pin Logback to 1.5.25 for vulnerability remediation
• Set Flyway baselineVersion to 0 in application and test configuration

2026.1.3 (01/26/2026)

• This release was cut to patch vulnerabilities discovered in the base container image

2026.1.2 (01/21/2026)

• Patch gnupg2 and jaraco-context High severity vulnerabilities affecting the Docker container base image

2026.1.1 (01/14/2026)

• Patch libpng to remediate High severity vulnerability affecting the Docker container base image

CoreSpatial Portal Release Notes

2026.1.1 (3/30/2026)

This release is a large rollup that advances the MapStore2 submodule through multiple upstream releases. The full details of upstream changes can be found in the MapStore2 release notes on GitHub:

• MapStore2 v2025.01.00
• MapStore2 v2025.02.00
• MapStore2 v2025.02.01
• MapStore2 v2025.02.02

New Features & Enhancements

• Cesium Ion World Terrain — Added Cesium Ion World Terrain support for 3D map view; reads ionAccessToken and terrainProvider from localConfig.json with graceful fallback to default ellipsoid when no token is configured
• Manager Page Plugins — Fixed blank manager page by adding UserManager, GroupManager, TagsManager, IPManager, and Footer plugins to the manager configuration; added missing translation keys throughout

Bug Fixes

• Fixed duplicate file upload attempt that could trigger two concurrent upload requests
• Fixed OSM background layer CORS errors by using explicit HTTPS tile URLs in base configuration

Security & Infrastructure

• Switch to Iron Bank ubi9 base image for the container
• Bump Tomcat to 9.0.108 (from 9.0.90) in RPM and container builds, addressing multiple CVEs across the 9.0.x series
• Bump org.apache.commons:commons-lang3 from 3.17.0 to 3.18.0
• Bump org.apache.cxf:cxf-core from 3.5.10 to 3.5.11
• Multi-format SBOM generation (syft-json, cyclonedx-json, spdx-json, table) now included with all releases
• CVE diff reporting added to release pipeline for tracking vulnerability changes between releases

Database Migrations

• Migration 005 — Adds gs_ip_range and gs_security_ip_range tables required by GeoStore 2.4.0 for IP-based access control. Deployments upgrading from older GeoStore versions will have schema validation errors fixed by this migration.

Testing

• Added Playwright end-to-end regression test suite

The post CoreSpatial 2026-Q1 Release Announcement first appeared on .

We anticipate the release of Portal in the upcoming weeks based on MapStore2 v2025.01.01, as well as promoting FIPS compliance for GeoServer to a generally available release.

Other exciting features on our roadmap include:

• Expanded deployment options with Docker Compose
• AI Enablement via MCP API
• Expanded FIPS 140 compliance across all CoreSpatial modules

CoreSpatial Server and Basemaps Release Notes

2025.3.5 (9/24/2025)

• Docker setup scripts hardened and simplified:
  • Unified permission / ownership helpers (fix_dir, fix_file) across data load steps
  • More robust curl version / SigV4 capability detection and consolidated S3 / MinIO download logic
  • Non‑root friendly: scripts no longer require running as root
• Default basemap data storage now points to Cloudflare R2 (via BUCKET_HOST)

2025.3.4 (8/29/2025)

• Update GeoServer to 2.27.2
• Docker build now uses Iron Bank ubi9 base image
• Minor improvements to docker setup script

2025.3.3 (8/14/2025)

• Patch vulnerabilities in OpenJDK 17

2025.3.1 (7/2/2024)

• Update PostgreSQL JDBC jar to 42.7.7 – patches CVE-2025-49146
• Update commons-beanutils to 1.11.0 – patches CVE-2025-48734

2025.2.4 (7/1/2025)

• Add logic for catalog manifest to allow for updates to catalog

CoreSpatial Map Manager Release Notes

2025.3.3 (9/22/2025)

• Bump Spring Boot to 3.5.6 to clear 1 High severity CVE

2025.3.2 (8/27/2025)

• Bump Spring Boot to 3.5.5 to clear 1 High and 1 Medium severity CVEs

2025.3.1 (7/7/2025)

• Bump Postgres JDBC Jar to 42.7.7
• Bump Spring Boot to 3.5.3 to clear 1 High and 2 Medium severity CVEs

The post CoreSpatial 2025-Q3 Release Announcement first appeared on .

What Is FIPS Compliance and Why Does It Matter?

FIPS stands for Federal Information Processing Standards, a set of publicly announced standards developed by the National Institute of Standards and Technology (NIST) for use in computer systems by non-military government agencies and contractors. Specifically, FIPS 140-2 and 140-3 relate to cryptographic module validation. They define the security requirements for cryptographic operations like encryption, hashing, and signing.

• Learn more about FIPS 140-2
  
• Explore the latest FIPS 140-3 standard
  
• NIST’s full FIPS series can be found at csrc.nist.gov
  

Many U.S. federal systems (and an increasing number of enterprise platforms handling sensitive or regulated data) are required to run only FIPS-validated cryptographic modules. Without this validation, software components like web services, authentication providers, or spatial data servers will be deemed unsuitable for use in secure environments, particularly those that handle Controlled Unclassified Information (CUI), Protected Health Information (PHI), or mission-critical defense data.

Why This Is a Big Deal for CoreSpatial and GeoServer Users

GeoServer, a cornerstone of open-source geospatial services, is widely adopted across both public and private sectors. However, until now, deploying GeoServer in a FIPS-validated environment was not possible due to compatibility issues related to the use of older style JCEKS keystores for secret management, among other password handling issues. 

With this new release of CoreSpatial Server, we’ve resolved those limitations by:

• Configuring the Java runtime environment to use Bouncy Castle FIPS 140-2 validated cryptographic providers
  
• Hardening container images and RPM-based installations to ensure strict FIPS mode enforcement
  
• Providing turnkey compatibility with RHEL FIPS-enabled operating systems
  
• Validating compatibility with secure ingress and TLS termination using approved ciphers and key lengths
  
• Ensuring continued compatibility with key plugins and extensions, such as WMS/WFS/WCS services, PostGIS integration, and security modules
  

This means CoreSpatial Server customers can now deploy GeoServer in environments where FIPS 140-2 compliance is not optional – including DoD, DHS, and state-level emergency management systems.

Deployment Scenarios Supported

The FIPS-compliant CoreSpatial Server supports:

• Bare metal or VM installations on RHEL 8 and 9 with FIPS mode enabled
  
• Containerized deployments using Podman, Docker, or Kubernetes where the underlying host supports FIPS 140-2 compliant cryptography
  

Whether you’re deploying in a SCIF, in a hybrid cloud with strict compliance policies, or inside an accredited container security boundary, CoreSpatial Server now enables you to take full advantage of GeoServer’s spatial publishing power without compromising on compliance.

Get Started Today

To explore FIPS-ready deployment options or see a demo, contact us at sales@newmoyergeospatial.com or visit our CoreSpatial overview.

For federal agencies and contractors already navigating FedRAMP, CMMC, or NIST 800-171 compliance landscapes, this enhancement brings CoreSpatial one step closer to being your go-to open-source alternative for secure geospatial systems.

The post CoreSpatial Server Adds FIPS 140-2 Compliance to GeoServer first appeared on .

This release includes major security and performance updates across the stack. We are hard at work to bring a new release of Portal based on the recently dropped MapStore2 v2025.01.00, as well as FIPS compliance for GeoServer (CS Server).

CoreSpatial Server and Basemaps Release Notes

2025.2.3 (6/10/2025)

• Update GeoServer to 2.27.1
• Update Jetty to 9.4.57.v20241219
• Update PostgreSQL JDBC jar to 42.7.6
• Update C3P0 Connection Pooling lib 0.11.1
• Update Marlin Jar to v0_9_4_8_jdk17

2025.2.2 (5/12/2025)

• Add ability to map data from mounted volume in Kubernetes environment

2025.2.1 (5/2/2025)

• Improvements to container initialization scripts
• Multiple High and Medium severity security patches in OpenJDK, libexpat, c-ares, and giflib
• Update OSM database to 3/31/2025 build

CoreSpatial Map Manager Release Notes

2025.2.2 (6/10/2025)

• Bump Spring Boot to 3.5.0 to clear 2 Low severity CVEs
• Bump Python to 3.12.11 to clear multiple CVEs (Medium, High, and Critical severity)
• Bump Postgres JDBC Jar to 42.7.6

2025.2.1 (5/2/2025)

• Bump Spring Boot to 3.4.5 to clear multiple CVEs

The post CoreSpatial 2025-Q2 Release Announcement first appeared on .

At NGS, we’ve seen this shift firsthand through CoreSpatial – our secure, customizable, open-source GIS stack designed specifically for federal use cases. Here’s why open-source GIS is now a viable, and often superior, option for government agencies.

Reason #1: Security and Compliance Have Caught Up

Modern open-source GIS tools like GeoServer, PostGIS, OpenLayers, and CesiumJS now meet many of the same cybersecurity standards as commercial platforms. They benefit from active community and vendor-backed development cycles that rapidly address CVEs and harden default configurations.

With platforms like CoreSpatial, NGS overlays strict DoD and FedRAMP-informed security architectures on top of these tools. Role-based access control, encrypted transport and storage, centralized logging, and auditing can all be configured from the start – without black-box components.

Reason #2: Deployment Flexibility for Tactical and Enterprise Environments

One of the most powerful advantages of open-source GIS is deployment flexibility. CoreSpatial can run:

• On fully air-gapped networks
• Inside cloud-native environments (AWS GovCloud, Azure IL5)
• On portable edge devices for field operations

This is possible because you’re not locked into a vendor-controlled SaaS model or restrictive license agreement. Government teams have full control over how and where they operate their systems.

Reason #3 Avoiding Lock-In While Enabling Innovation

Many federal agencies are trapped in decades-old licensing cycles with proprietary vendors. This creates two problems:

• High costs for marginal capability improvements
• Little ability to customize or extend platforms to meet modern mission needs

Open-source GIS flips this model. You own the code. You can customize it. And you can collaborate with an ecosystem of innovators – whether they’re internal developers, contractors, or commercial integrators.

Reason #4 Interoperability and Open Standards

Interoperability is essential in environments where multiple agencies, systems, and coalitions must work together. CoreSpatial adheres to OGC standards out of the box, ensuring smooth data sharing across platforms, whether you’re integrating with NATO allies, municipal systems, or intelligence feeds.

Rather than relying on translation layers or costly middleware, open standards are native to the architecture.

Reason #5 Real-World Use Cases Are Already Here

Open-source GIS isn’t theoretical – it’s operational. CoreSpatial and its component parts are already supporting use cases including:

• Command and control and situational awareness platforms using OpenLayers, Cesium, and GeoServer
• Imagery processing and dissemination using GDAL, PostGIS, and GeoServer
• Multi-domain targeting and air mission planning using PostGIS, GeoServer, OpenLayers,  and CesiumJS
  

These systems deliver real value today – and do so at a fraction of the traditional cost.

By the way, we are compiling a list of government programs and agencies that use open source GIS solutions today. We look forward to sharing those in the upcoming weeks ahead. 

Feel free to drop us a line if you’d like to contribute! info@newmoyergeospatial.com

Conclusion: Time to Rethink the Stack

Open-source GIS is no longer a fringe solution. It’s a strategic asset for agencies looking to modernize geospatial capabilities, reduce risk, and stretch every budget dollar further.

If you’re evaluating your next geospatial procurement or modernization effort, it may be time to rethink what’s possible – with open source.

Want to see how CoreSpatial could fit your mission? Contact us for a live demo.

The post Why Open Source GIS Is Ready for Mission-Critical Government Use first appeared on .

Gary Rosenberry, Senior Software Developer, NGS

Gary is an experienced Software Engineer with a demonstrated history of working in the computer software industry. Skilled in GO, Java, JavaScript, Spring, React/Redux, SQL, Government, Management. Strong engineering professional with a Bachelor’s degree focused in Computer Science and Programming from Shippensburg University of Pennsylvania.

• LinkedIn

Introduction

As a full-stack developer since November 2016, I’ve had the opportunity to work on a variety of custom web application solutions across different tech stacks. In recent years, I’ve shifted my focus toward leading front-end development efforts, primarily working with React. My experience spans Java, Go, and JavaScript, but my main expertise lies in building and maintaining React-based projects.

For the past four years, Redux has been my go-to tool for managing and organizing application state, and more recently, Redux Toolkit has become an essential part of my workflow. One of the most overlooked yet crucial aspects of working with these technologies is establishing a scalable and maintainable folder structure. A well-organized project can make a significant difference in code maintainability, collaboration, and long-term scalability.

In this article, I’ll share an example of structuring a React application using Redux Toolkit effectively. While this is not the only way to organize a project, it provides a solid foundation that can be adapted to different needs. Whether you’re starting a new project or refactoring an existing one, having a structured approach will save you and your team countless hours down the line.

Why Folder Structure Matters

The Downside of Poor Organization

A poorly designed or inconsistent folder structure leads to wasted time and unnecessary confusion. Without clear guidelines, developers might struggle to find files, leading to delays and inefficiencies. More importantly, a lack of organization can make it difficult to understand how different parts of the application interact, increasing the risk of introducing bugs and technical debt.

The Benefits of a Well-Organized Project

Core Principles of a Good Folder Structure

A well-structured project should be logical, scalable, and easy to navigate. Here are the key principles to follow:

src/
  app/
    App.tsx
    store.ts
  features/
    auth/
      components/
        AuthForm.tsx
      authSlice.ts
    dashboard/
      components/
        Dashboard.tsx
      dashboardSlice.ts

Feature-Based Organization

Instead of organizing files solely by type (e.g., a global components/ or redux/ folder), structure them around distinct features.

This method ensures that each feature is self-contained, making it easier to update or remove functionality without affecting unrelated parts of the application.

API Folder with RTK Query

To manage API interactions efficiently, we separate API logic into its own folder. This is a personal choice, but I prefer abstracting my API into its own folder. This allows me to code-split the API and re-use these pieces across features.

src/
  api/
    api.ts
    authApi.ts
    dashboardApi.ts

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

export const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  endpoints: () => ({}), // Additional endpoints are injected separately
});

import { api } from './api';

export const authApi = api.injectEndpoints({
  endpoints: (builder) => ({
    login: builder.mutation({
      query: (credentials) => ({
        url: '/auth/login',
        method: 'POST',
        body: credentials,
      }),
    }),
  }),
});

export const { useLoginMutation } = authApi;

This approach allows us to add API endpoints dynamically, keeping the code modular and easier to manage.

Common Folder for Shared Logic

src/
  common/
    hooks/
      useAuth.ts
      useDebounce.ts
    utils/
      dateFormatter.ts
      apiHelper.ts
    components/
      Button.tsx
      Modal.tsx

import { useGetUserQuery } from '../api/authApi';

export const useAuth = () => {
  const { data: user, isLoading } = useGetUserQuery();
  return { user, isLoading, isAuthenticated: !!user };
};

export const formatDate = (date: string) => {
  return new Date(date).toLocaleDateString();
};

export const Button: React.FC<{ text: string; onClick: () => void }> = ({ text, onClick }) => {
  return <button className="px-4 py-2 bg-blue-500 text-white rounded" onClick={onClick}>{text}</button>;
};

Caution When Editing common/

Since shared logic affects multiple parts of the application, updates should be handled carefully:

Final Thoughts

A good folder structure isn’t about following rigid rules—it’s about creating a setup that makes your project scalable, maintainable, and easy to navigate. While this isn’t the only way to structure a React project, it provides a strong foundation that can be adapted to different team preferences and project requirements. By adopting a feature-based organization, a modular API layer, and a structured common folder, you can reduce technical debt, improve collaboration, and boost development efficiency.

The post The Importance of a Good Folder Structure in React & Redux Toolkit Projects first appeared on .