# core-geonetwork: a metadata catalogue and web map viewer for spatial data

> GeoNetwork is a Java catalogue application for spatially referenced resources, with metadata editing driven by templates, a web map viewer that combines services from other servers, harvesting between distributed catalogues and support for CSW, ISO 1911x, DCAT-AP and OAI-PMH. It is infrastructure for a spatial data infrastructure, not a general purpose data platform.

**geonetwork/core-geonetwork** — GeoNetwork is a catalog application to manage spatially referenced resources. It provides powerful metadata editing and search functions as well as an interactive web map viewer. It is currently used in numerous Spatial Data Infrastructure initiatives across the world.

- Repository: https://github.com/geonetwork/core-geonetwork
- Website: http://geonetwork-opensource.org/
- Stars: 524 · Forks: 518
- Language: Java
- License: GPL-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/geonetwork-core-geonetwork

## A catalogue for spatial data, and the standards it speaks

GeoNetwork is a catalog application to manage spatially referenced resources. It provides metadata editing and search functions plus an interactive web map viewer, and the README says it is currently used in numerous Spatial Data Infrastructure initiatives across the world. That last sentence is the reason this kind of software exists. A spatial data infrastructure is a shared arrangement where an organisation, a ministry or a research consortium publishes a catalogue of its datasets, and the catalogue has to be searchable by people who did not create it and often do not speak the same language. The standards list in the features section makes the scope clear: support for OGC-CSW 2.0.2, ISO 1911x and DCAT-AP metadata profiles, and OAI-PMH protocols, with the topic list naming the specific metadata schemas the codebase deals with, ISO19110, ISO19115, ISO19119 and ISO19139, alongside CSW, OGCAPI, INSPIRE, OpenSearch and Dublin Core. The audience is a catalogue operator in an institution that has to publish and serve metadata to other institutions.

## Search across local and distributed catalogues is the first feature

The features list opens with immediate search access to local and distributed geospatial catalogues, and that word distributed is doing the work. A GeoNetwork installation is rarely the only one. A national portal may hold its own records while also federating a ministry catalogue, a regional one and a set of university repositories, and the search needs to span all of them without the operator manually copying anything. The other features build on that. Scheduled harvesting and synchronization of metadata between distributed catalogs covers the ingestion side, so records appear without a person re-entering them, and the online editing of metadata with a powerful template system covers the local side, so a cataloger can create a record that matches the profile their infrastructure expects. The template system is the piece that makes the standards support usable in practice, because the alternative to a form that enforces ISO 19115 is a free-text field that nobody downstream can parse.

## The web map viewer, access control and a multilingual interface

The third feature is an interactive Web Map Viewer to combine Web Map Services from distributed servers around the world. This is where the catalogue becomes a map rather than a list. A user searching the catalogue can display the spatial extent of a record and then overlay it with the map services of other organisations in the same view, which is the practical point of publishing metadata in the first place. The web services directory in the repository, `services/`, sits alongside `csw-server/` for the Catalogue Service for the Web implementation and `oaipmh/` for harvesting over OAI-PMH. There is also an `inspire-atom/` directory and an `index/` directory, which is the Lucene index used for the search functions, and `events/` and `listeners/` for the event and listener layer. The repository also carries `healthmonitor/`, `monitoring/` and `jmeter/`, so the operational side of a service that other institutions depend on is part of the codebase rather than an afterthought.

Fine-grained access control with group and user management is listed as a feature, and for a shared catalogue it is not optional. A GeoNetwork instance in a real deployment is multi-tenant in practice: internal editors, partner organisations contributing records, and the public all see different things, and some records are restricted entirely. The topic list and the repository layout show the machinery for this, with `common/` holding shared code and the `auditable/` directory indicating that actions are recorded. A multi-lingual user interface is a separate feature, which for a European infrastructure is a requirement rather than a nicety, and the `translationproviders/` directory and `transifex-localization-files.json` at the repository root show that translations are managed through Transifex rather than edited in place. The features also cover uploading and downloading of data, graphics, documents, PDF files and any other content type, which is the difference between a metadata catalogue and a metadata catalogue that also holds the data.

## A Java monorepo with a plugin and schema structure

The repository layout is a large multi-module Maven project, and the `pom.xml` at the root is the aggregator. The `core/` directory holds the main application, `web/` is not present but the `domain/` directory holds the domain model, and there is a `web` equivalent in the form of the `es/` directory for the JavaScript search interface, which is the Elasticsearch-based search frontend. The plugin architecture is visible in `plugins/`, and the `schemas/` directory holds the metadata schema definitions that the template system is built on, with `schemas-test/` for their tests and an `add-schema.sh` script at the root for registering a schema. There are also `datastorages/` for the storage backends, `harvesters/` for the harvesting jobs, `cachingxslt/` for the XSLT caching used when transforming between metadata profiles, and `doi/` for DOI handling, which is how a catalogue assigns persistent identifiers to its records. Alongside that sit the standard directories for tests (`estest/`, `cswtest/`, `integration-test/`), for code quality (`code_quality/`), for auditing (`auditable/`) and for localisation.

## Documentation is compiled into the release, not just the website

The documentation arrangement is worth noting because it explains how a project of this size keeps help in step with the code. The GeoNetwork Manual and Online Help are included in the `docs/manual` folder, and that content is compiled into HTML pages during a release for publishing on the docs.geonetwork-opensource.org website. The online help is separately compiled into HTML pages during a release and is included in the `war` web archive, so a deployed instance ships with its own help. That is a deliberate choice for software used in environments where the operator may not have internet access, and it is a real difference from a project that only documents itself on a website. The developer documentation lives in README.md files in the code base, with the general project documentation in the root README.md, a Software Development Documentation section covering how to set up a development environment, build GeoNetwork, compile the user documentation and make a release, and module specific documentation in each module.

## The release process is a set of scripts in the repository root

The top-level entries show how a release is assembled, and the scripts are named for their purpose. There is `release-build.sh`, `release-notes.sh`, `release-publish.sh`, `release-restore.sh` and `release-test.sh`, along with `update-version.sh`, `updateBranchVersions.sh`, `updateReleaseVersions.sh` and `resetReleaseVersions.sh`. The naming pattern of the update scripts suggests that version numbers are maintained in several places and have to be moved in step, which is a normal consequence of a multi-module Maven build where each module carries its own version. The `release/` directory holds the release configuration, `CITATION.cff` is the citation metadata for the project, and the presence of a `PROCESS_FOR_DEPRECATION.md` at the root says something about how the project handles the deprecation of a public API. The `docker/` directory is there for containerised deployment, and the build badge in the README points at a Linux workflow, so continuous integration runs on Linux.

## Where GeoNetwork is the wrong tool

Three limits are concrete. The first is that this is a catalogue, not a data platform. GeoNetwork stores and describes spatial resources and serves map services; it is not a warehouse, a processing engine or a general object store, and a deployment that needs to run analytics over its holdings needs something else alongside it. The second is the operational weight. A Java application with a Lucene index, a relational database, an Elasticsearch interface, harvesting jobs and a plugin architecture is a substantial system to install, upgrade and back up, and the version lines in the release list show parallel maintenance, with 4.4.12 and 4.2.17 both released on the same day in July 2026, which is what supporting several production branches looks like. The third is the standards surface. Supporting OGC-CSW 2.0.2, the ISO 1911x family, DCAT-AP and OAI-PMH means the catalogue is tied to those specifications, and an organisation whose metadata needs are narrow may find that a much smaller tool, or a plain spatial database with a search interface, does the job.

## The alternative is a plain spatial database with its own search, and the difference is the standards

The realistic alternative is to store your metadata in a spatial database with a web map front end and no catalogue layer, which is what many smaller deployments actually do. The difference in approach is what the catalogue adds. A plain database gives you records you wrote, searchable by the fields you chose, with no obligation to be readable by anything else. GeoNetwork gives you records conforming to a metadata profile, exposed over CSW and OAI-PMH, which is what makes it usable as the catalogue for a spatial data infrastructure where the consumers are other institutions' software rather than your own staff. The cost of that is the profile work, the plugin and schema configuration, and the machinery to keep the standards support current. If your consumers are only your own users, the standards are overhead. If your consumers are a national portal or a partner catalogue that expects CSW and INSPIRE, they are the entire reason the software exists.

## Conclusion

core-geonetwork fits an institution that has to publish and serve spatial metadata to other institutions, whether through CSW, OAI-PMH or an INSPIRE-aligned profile, and that has the Java and search infrastructure to run it. It is the wrong choice for a small internal catalogue whose consumers are only your own users, since the standards support and plugin structure are the bulk of the work. Before you adopt it, pick the branch that matches your production timeline, since 4.4 and 4.2 lines are being released in parallel, and plan the schema and template configuration for your metadata profile early, because that is the part that shapes the rest.

## FAQ

### What is core-geonetwork?

It is the repository for GeoNetwork, a catalogue application to manage spatially referenced resources, providing metadata editing and search functions plus an interactive web map viewer. The project describes itself as being used in numerous Spatial Data Infrastructure initiatives across the world.

### Which metadata standards does GeoNetwork support?

The features list names OGC-CSW 2.0.2, ISO 1911x and DCAT-AP metadata profiles and OAI-PMH protocols, with the repository topics also naming ISO19110, ISO19115, ISO19119 and ISO19139 schemas, INSPIRE and OpenSearch.

### Where is the GeoNetwork documentation kept?

The GeoNetwork Manual and Online Help are included in the `docs/manual` folder and compiled into HTML pages during a release for the docs.geonetwork-opensource.org website. The online help is also compiled and included in the `war` web archive, so a deployed instance ships with its own help.

### How do I set up a GeoNetwork development environment?

The README points to the Software Development Documentation at `/software_development/`, which covers setting up a development environment, building GeoNetwork, compiling the user documentation and making a release. Module specific documentation is in README.md files inside each module.

## Sources

- [geonetwork/core-geonetwork on GitHub](https://github.com/geonetwork/core-geonetwork)
- [License: GPL-2.0](https://github.com/geonetwork/core-geonetwork/blob/main/LICENSE)
- [Project website](http://geonetwork-opensource.org/)
- [README](https://github.com/geonetwork/core-geonetwork/blob/main/README.md)
- [Releases](https://github.com/geonetwork/core-geonetwork/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/geonetwork-core-geonetwork