geonetwork / geonetwork/core-geonetwork
Add harvester configuration in the `api/sources/harvester` response
- Dominant language
- Java
- Stars
- 521
- Forks
- 515
- Avg merge
- 6d 13h
- Merged PRs (30d)
- 19
Description
**Is your feature request related to a problem? Please describe.**
We're trying to map a complex ecosystem composed of over 100 independently hosted catalogs, maintained by different organizations, and harvesting one another. As you can imagine, manual mapping failed. Even if it worked, the maps would quickly become obsolete as the ecosystem evolves.
Most of these catalogs use GeoNetwork either directly or as part of a platform. It would be trivial to map our ecosystem if the GN `api/sources/harvester` endpoint were to provide more information about the sources.
Currently, the only information we can retrieve about a source is the `name` assigned by the harvester administrator. Unfortunately we can’t expect different catalogs will have the same names for the same sources, so reconciling catalog sources is hazardous.
**Describe the solution you'd like**
Adding information such as the source url and harvest parameters (eg filters for CSW) should be enough to reliably reconcile sources across different catalogs. For instance :
```
{
"type": "harvester",
"name": "Catalogue de données sur la biodiversité",
"url": "https://data.naturefrance.fr/geonetwork/srv/fre/csw",
"filters": "PropertyIsEqualTo('dc:type', 'dataset')",
...
}
```
Notes:
- The `filters` syntax is made up. I don't know if there is a standard non-XML representation.
- I restrict to harvesters because this is our main use case. I haven't considered other types of sources.
Contributor guide
Research direction
Start at the api/sources/harvester endpoint and trace how its current source response is assembled. Review which harvester URL and parameters are available, then verify the endpoint returns the agreed additional information for harvester sources without changing unrelated source types.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100