A metadata record management system written in PHP, intended to be used in conjunction with VuFind or another Solr-based discovery interface. Provides import, export, harvesting (OAI-PMH), normalization, deduplication and Solr index update functionality with support for multiple metadata formats. Also includes an OAI-PMH provider that can be used to access the data stored in RecordManager database. Functionality driven by simple command line programs for easy automation.
GNU General Public License v2.0
47
stars
31
forks
source link
[ALLI-6920] OnkiLightEnrichment: enrich records with available WGS 84 data #105
OnkiLightEnrichment may yield many points to location_geo field in case $localData is false but only the first one is considered the centroid one (if none exists before).
OnkiLightEnrichment: as class variables solrLocationField and solrCenterField are initialized in the class file, I believe that pre-existing installations of RecordManager will readily use them without configuration changes. This may or may not introduce unwanted consequences.
Enrichment\NominatimGeocoder will now check for pre-existing centroid value and add polygon(s) to Solr location field only if the centroid is included in the polygon.
Additionally [related to ALLI-6920], if, for example, NominatimCoder is wanted to be applied after, let's say, MarcOnkiLightEnrichment, one must pay attention to how enrichments are added and their respective execution order:
a. Globally declared enrichments added via Solr configuration enrichment array are called "first" (of course setting the enrichment stage affects this in a way), see code below: https://github.com/NatLibFi/RecordManager/blob/b7913fdcabdc6f9128e59fc0b6384af908fc0633/src/RecordManager/Base/Solr/SolrUpdater.php#L2754-L2775
b. In order to tackle some issues described in a), one could just simply add enrichments via numbers, e.g., enrichments[n] = MarcOnkiLightEnrichment;enrichments[n+1] = NominatimGeocoder; however, this method is not powerful enough to 'beat' the boundary of globally declared enrichments and datasource enrichments. Solely on the datasource configuration side, however, this would work.
All in all, please note that any Solr field value is left unchanged and may not be updated by the code - only additions are made.
Few notes:
location_geo
field in case$localData
is false but only the first one is considered the centroid one (if none exists before).solrLocationField
andsolrCenterField
are initialized in the class file, I believe that pre-existing installations of RecordManager will readily use them without configuration changes. This may or may not introduce unwanted consequences.MarcOnkiLightEnrichment
, one must pay attention to how enrichments are added and their respective execution order: a. Globally declared enrichments added via Solr configurationenrichment
array are called "first" (of course setting the enrichment stage affects this in a way), see code below: https://github.com/NatLibFi/RecordManager/blob/b7913fdcabdc6f9128e59fc0b6384af908fc0633/src/RecordManager/Base/Solr/SolrUpdater.php#L2754-L2775 b. In order to tackle some issues described in a), one could just simply add enrichments via numbers, e.g.,enrichments[n] = MarcOnkiLightEnrichment;
enrichments[n+1] = NominatimGeocoder
; however, this method is not powerful enough to 'beat' the boundary of globally declared enrichments and datasource enrichments. Solely on the datasource configuration side, however, this would work.All in all, please note that any Solr field value is left unchanged and may not be updated by the code - only additions are made.