Dear GeoServer Developers,
I’m reaching out on behalf of a customer request we’ve received regarding alias-like functionality for workspaces and layers in GeoServer. After reviewing the use case and discussing internally, I’d like to present a problem statement and a proposed approach for feedback from the community—specifically on its feasibility and potential interest for inclusion in the project.
Problem Statement
Our customer manages geospatial data through GeoServer and frequently encounters situations where workspace and layer names become obsolete due to organizational or system name changes (e.g., legacy system names being replaced by a new organizational identity). They need a way to:
Rename workspaces (both human-readable and technical names in URLs/URIs) while keeping old names operational for a transition period.
Ensure client applications relying on old names continue to function without immediate reconfiguration.
Eventually phase out old names without disrupting access via new names.
A similar need exists for layers, though the “publish again” feature partially addresses this. The core challenge is at the workspace level, where manual duplication and reconfiguration of workspaces, stores, layers, and styles is time-consuming and error-prone. The customer also expressed interest in avoiding data source duplication and potentially signaling obsolescence of old names (e.g., via watermarks), though this is secondary.
Their initial framing was around “aliases” (akin to symlinks), but they’ve noted this term may not fully capture the requirement. A key sticking point is their desire to eventually delete an original workspace while keeping the “aliased” version functional, which could complicate an alias-based approach.
Proposed Approach
Rather than implementing aliases as symlinks (which could introduce issues like dangling references if the original is deleted), we’re considering a “workspace cloning and synchronization” feature:
Clone Workspace: A new function to create a 1:1 duplicate of a workspace, including stores, resources, layers, layer groups, and styles. This would allow immediate use of a new workspace name while preserving the old one
.
Synchronization Mechanism: Designate one workspace as the “master” and another as a “synchronized copy.” A catalog listener would detect changes in the master (e.g., layer additions, style updates) and replicate them to the synchronized copy. This ensures consistency during the transition period.
Phase-Out: Once the transition is complete, the old workspace could be decommissioned without affecting the new one, as the clone would operate independently after synchronization ends.
For layers, the existing “publish again” functionality seems sufficient, so the focus would be on workspaces. Integration with GeoFence and the REST API could be considered later, but we’d likely start with a simpler scope to limit complexity.
Questions for the Community
Does this cloning and synchronization approach align with GeoServer’s architecture and catalog system? Are there potential pitfalls we should anticipate?
Is there existing interest in such a feature within the community, or overlap with past discussions/GSIPs?
Would this be a valuable addition to GeoServer, and if so, what would be the best path forward (e.g., GSIP, prototyping)?
We’re in the estimation phase for our customer and haven’t received a green light for development yet, but we’d greatly appreciate your insights to refine the proposal and gauge its fit for the project. I’m happy to provide more details or join a discussion if needed.
Looking forward to your thoughts!
Best regards,
Gabriel Roldan