Closed ThomasG77 closed 9 months ago
Je plussoie le besoin ici :-) Je mets en lien @fgravin @jahow @fxprunayre pour les échanges entre équipes etalab / geonetwork
Bonjour, +1 ici.
J'ai un client (https://data.naturefrance.fr/geonetwork) qui souhaite résoudre la question d'ici la fin de l'année. Est-ce que cela ne vaudrait pas la peine de prévoir un point sur la question, tous ensemble, afin d'éviter le risque de développements redondants/inadaptés ?
Bonjour à tous ! En effet, un point de synchronisation me semble bienvenu. Pour avancer, je me permets de proposer un framadate sur les deux prochaines semaines : https://framadate.org/lAXwT9ezQeZhm5an. N'hésitez pas à transférer aux personnes intéressées de vos côtés !
Bonjour ! Au vu des résultats du framadate, on pourrait avoir un créneau rapidement, le mardi 25 octobre à 10h. Seul @fvanderbiest n'est pas dispo, mais on essaiera de faire un compte rendu détaillé des discussions.
Je propose le lien suivant pour la visio : https://webinaire.numerique.gouv.fr//meeting/signin/8636/creator/4868/hash/b6a2db989ee04e2b2fd3aa812f2f4ea339588585
Suite à notre réunion quelques exemples côté GeoNetwork pour les tests:
v3 / rdf.search https://vanilla.geocat.net/geonetwork/srv/eng/rdf.search?uuid=da165110-88fd-11da-a88f-000d939bc5d8
v4 / CSW (idem v3 / CSW) https://apps.titellus.net/geonetwork/srv/eng/csw?SERVICE=CSW&VERSION=2.0.2&REQUEST=GetRecordById&outputSchema=http://www.w3.org/ns/dcat%23&ID=da165110-88fd-11da-a88f-000d939bc5d8
v4 / OGC API Records https://apps.titellus.net/geonetwork/api/collections/main/items?q=da165110-88fd-11da-a88f-000d939bc5d8&f=dcat
Remarques:
rdf.search
(d'où la remarque d'@maudetes sur les éléments distribution
manquants) - cf. https://github.com/geonetwork/core-geonetwork/pull/6635Oh, mince, désolé d'avoir raté la réunion, mon agenda me fait des blagues en ce moment
Compte rendu sur le point de synchro d'hier. N'hésitez pas à commenter si il manque des infos ou comporte des erreurs :
François Prunayre, Grégory Delobelle, Benoist Fontaîne, Benoît Lardeau, Florent Gravin, François Prunayre, Olivier Guyot, Julien Daranlot, Thomas Gratier, Estelle Maudet
L'endpoint dédié DCAT (/rdf/search) avait été développé il y a une dizaine d'année et se basait sur une API interne qui utilisait Lucène. Le choix d'utiliser directement ElasticSearch plutôt que Lucène dans GeoNetwork v4, a conduit à la suppression du endpoint DCAT. Cet endpoint était aussi basé sur une bibliothèque qui a vocation à être remplacée par Spring.
A ce jour, trois options nous semblent possibles pour assurer une consommation de GeoNetwork v4 par data.gouv.fr, via différentes expositions de flux DCAT.
Il y a des travaux en cours pour l'ajout d’OGC API Record pour fournir un service de recherche au-dessus du catalogue, qui permet de fournir des sorties json, html, et éventuellement DCAT rdf-xml, etc. Des développements ont notamment eu lieu en septembre pour exposer un flux DCAT. Ces dévelopemments sont actuellement déployés sur différentes plateformes, notamment à l’IFREMER, à l'Agence Européenne de l’Environnement (voir la PR associée). L'OGC API Record est cependant séparée de GeoNetwork core, et nécessiterait donc d'être installée en plus pour toutes les plateformes qui voudraient être moissonnées via DCAT. Côté projet Geonetwork, il pourrait être envisagé de "bundler" dans les fichiers d'installation de Geonetwork cette nouvelle dépendance pour faciliter le déploiement.
Le endpoint CSW de GeoNetwork permet de retourner des résulats au format DCAT (voir la description de ce ticket).
La consommation par data.gouv.fr nécessiterait cependant un développement spécifique pour pouvoir requêter l'endpoint CSW, ainsi que pour récupérer le contenu DCAT encapsulé.
:warning: dcat:Distribution
semble cependant manquer dans le contenu retourné lors de l’exposition CSW avec le schéma DCAT (cf. message précédent)
La dernière solution évoquée serait de migrer l'endpoint DCAT dédié (/rdf/search
) sur GeoNetwork v4. Cela nécessiterait un développement spécifique pour l'utilisation d'ElasticSearch au lieu de Lucène et le passage à la librairie Spring pour l'endpoint. Il faut aussi voir si cette orientation est en phase avec la direction prise lors du passage à la v4, vers une architecture orientée micro-services.
dcat:Distribution
, cf. message précédent.Pour être plus clair pour le cas du tag distribution
, on a sur le endpoint CSW v4 mentionné par @fxprunayre https://apps.titellus.net/geonetwork/srv/eng/csw?SERVICE=CSW&VERSION=2.0.2&REQUEST=GetRecordById&outputSchema=http://www.w3.org/ns/dcat%23&ID=da165110-88fd-11da-a88f-000d939bc5d8, un retour du type suivant (répété car plusieurs ressources)
<dcat:distribution rdf:resource="https://apps.titellus.net/geonetwork/srv/api/records/da165110-88fd-11da-a88f-000d939bc5d8/attachments/basins.zip"/>
alors que sur nos tests côté OREME, sur l'ancien endpoint, celui-ci est de la forme
<dcat:Distribution xmlns:dcat="http://www.w3.org/ns/dcat#"
rdf:about="https://sig.oreme.org/geonetwork/records/19e9f6cc-1af6-41ca-9947-1d2744b90a7c#WWW%3ALINK-1.0-http--link-See%20Noccaea%20caerulescens%20information%20on%20OSU%20OREME%20website">
<dcat:accessURL>https://oreme.org/observation/pollumine/noccaea-caerulescens</dcat:accessURL>
<dct:title xmlns:dct="http://purl.org/dc/terms/">See Noccaea caerulescens information on OSU OREME website</dct:title>
<dct:format xmlns:dct="http://purl.org/dc/terms/">WWW:LINK-1.0-http--link</dct:format>
</dcat:Distribution>
Il faut aussi noter que la casse diffère: distribution
vs Distribution
même si je ne pense pas qu'il y ait une influence (?!)
Bonjour à tous ! Quelques nouvelles du moissonnage de l'endpoint v4 / OGC API Records. L'ensemble du moissonnage au niveau du catalogue exposé par l'endpoint OGC API Records (https://apps.titellus.net/geonetwork/api/collections/main/items?f=dcat) semble être le bon format, excepté quelques points bloquants au niveau de l'identification des datasets, en particulier:
rdf:about
sur le noeud des dcat:Dataset pour identifier le noeud, dont on a besoin plus tard dans le moissonnagedct:identifier
au niveau des champs du Dataset, nécessaire pour l'identification du dataset d'un moissonnage à l'autreExemple:
<dcat:Dataset rdf:about="http://localhost:8080/geonetwork/srv/resources/datasets/6">
<dct:identifier>6</dct:identifier>
...
J'ai rajouté ces points manquants dans un gist pour tester le moissonnage: https://gist.github.com/maudetes/41606ce9fc2d974a343449bf96c14d65.
Vous pouvez consulter le résultat du moissonnage de ce gist par datagouv sur cette orga de test : https://demo.data.gouv.fr/fr/organizations/test-geonetwork-v4/
@fxprunayre, est-ce que les champs manquants pourraient être rajoutés au mapping de manière assez simple côté GeoNetwork ? Sur la question de la distribution manquante avec CSW, est-ce que je peux fournir des informations additionnelles ou c'était assez clair ?
un rdf:about sur le noeud des dcat:Dataset pour identifier le noeud, dont on a besoin plus tard dans le moissonnage
Ajouté (cf. https://github.com/geonetwork/geonetwork-microservices/pull/59)
un dct:identifier au niveau des champs du Dataset, nécessaire pour l'identification du dataset d'un moissonnage à l'autre
dct:identifier
est présent si la resource à un identifiant (peut être différent de l'UUID de la fiche).
Par exemple :
<dcat:CatalogRecord rdf:about="https://sextant.ifremer.fr/geonetwork/srv/metadata/88a2a7a6-8b2d-49b8-9a17-914aea7ed278">
<dct:identifier>88a2a7a6-8b2d-49b8-9a17-914aea7ed278</dct:identifier>
....
<foaf:primaryTopic>
<dcat:Dataset rdf:about="https://sextant.ifremer.fr/geonetwork/srv/metadata/88a2a7a6-8b2d-49b8-9a17-914aea7ed278#resource">
<dct:title>Variance de krigeage annuelle de la densité de l'espèce Mullus barbatus au stade adulte dans le Golfe du Lion (MEDITS, 1994-2019)</dct:title>
<dct:identifier>DOI:10.12770/88a2a7a6-8b2d-49b8-9a17-914aea7ed278</dct:identifier>
Est-ce que vous connaissez des outils pour valider les sorties DCAT ? et quelle "classe de conformité" choisir ? https://www.itb.ec.europa.eu/shacl/dcat-ap, http://www.dcat.be/validator/
dct:identifier
est présent si la resource à un identifiant (peut être différent de l'UUID de la fiche).
Avoir un dct:identifier
stable est nécessaire de notre côté pour identifier un dataset dans le temps. Cela nous permet de ré-identifier un dataset d'un moissonnage à l'autre.
Nous n'avons pas connaissance d'autres outils que ceux cités ci-dessus pour valider des sorties DCAT.
Bonjour à tous ! Suite aux différentes PRs mentionnées dans cette discussion et mergées côté Geonetwork, est-ce que je pourrais avoir des liens vers des catalogues GeoNetwork qui embarquent ces mises à jour pour tester le moissonnage de nouveau (endpoint CSW et API OGC Records) ? Les liens proposés précédemment par @fxprunayre ne retournent plus de contenu.
Je pense qu'un point de synchronisation sur les solutions proposées pourrait être pas mal ensuite, à voir si on fait un point en petit comité datagouv x GeoNetwork dans un premier temps ou ouvert plus largement selon le besoin.
Suite à la sortie de la version 4.2.2 de GeoNetwork https://apps.titellus.net/geonetwork et https://apps.titellus.net/geonetwork/api sont à jour.
Bonjour,
Merci @fxprunayre pour les évolutions dans ogc-api-records
.
J'aimerais être sûr de bien comprendre et synthétiser les discussions.
<csw:GetRecordsResponse>
)Ya t-il une option meilleure que l'autre entre ogc-api-records
et csw
ou bien sont-elles strictement équivalentes ?
Merci pour vos inputs.
Bonjour,
Merci @fxprunayre pour les évolutions et la mise à jour de app.titellus.net !
Malheureusement, je ne peux pas faire de requête GetRecords sur apps.titellus.net. Je me prends en effet une erreur OutputSchema 'dcat' not supported for metadata with '1625'
.
Par contre, l'ajout de la distribution a l'air de correspondre au format moissonné de notre côté.
Pour répondre à @fgravin sur le moissonnage par data.gouv.fr, cette solution nécessite une mise à jour de notre moissonneur pour pouvoir requêter correctement le contenu CSW et extraire la partie DCAT.
L'identifiant du nœud semble bien fonctionner.
Comment discuté plus haut, le dct:identifier
au niveau de Dataset n'est pas nécessairement présent, alors qu'il nous est nécessaire pour identifier un jeu de données d'un moissonnage sur l'autre. Est-ce qu'il serait possible de toujours fournir un identifiant stable au niveau du dataset ?
Il faut que l'on discute la solution à privilégier entre ces deux alternatives, mais cela n'était pas encore tranché à ce stade.
@fxprunayre pourra préciser, mais il me semble que les trois exports ne sont pas exactement équivalents (par exemple landing page
, accrualPeriodicity
ou license
qui n'apparaissent pas sur tous les exports).
Concernant l'appel CSW sur apps.titellus.net, ce n'est pas vraiment que "ca ne marche pas", le rapport indique OutputSchema 'dcat' not supported for metadata with '1723' (dublin-core)
. GeoNetwork reste une application supportant différents schémas et en l'occurrence il n'y a pas eu de mapping dublin-core > dcat. Donc vous pouvez ajuster votre requête comme celle indiquée par @ThomasG77 au début de ce ticket (qui filtre les fiches en ISO19139):
echo '<?xml version="1.0" encoding="UTF-8"?><csw:GetRecords xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:gmd="http://www.isotc211.org/2005/gmd" service="CSW" version="2.0.2" resultType="results" outputSchema="http://www.w3.org/ns/dcat#"><csw:Query typeNames="gmd:MD_Metadata"><csw:ElementSetName>full</csw:ElementSetName><csw:Constraint version="1.1.0"><Filter xmlns="http://www.opengis.net/ogc"><PropertyIsEqualTo><PropertyName>documentStandard</PropertyName><Literal>iso19139</Literal></PropertyIsEqualTo></Filter></csw:Constraint></csw:Query></csw:GetRecords>' >| demo-csw-dcat.xml
curl -H "Content-Type: application/xml" --data-binary @demo-csw-dcat.xml https://apps.titellus.net/geonetwork/srv/eng/csw
Comment discuté plus haut, le dct:identifier au niveau de Dataset n'est pas nécessairement présent,
En effet, d'un point de vue INSPIRE, il est obligatoire. D'un point de vue ISO, non. Donc ça dépendra du "type" de fiche ...
ogc-api-records et csw ou bien sont-elles strictement équivalentes
Non. Comme indiqué en réunion et dans les échanges précédents, l'une repose sur des travaux initiés en 2012 (https://trac.osgeo.org/geonetwork/wiki/proposals/DCATandRDFServices) avec un mapping un peu amélioré depuis selon les schémas (principalement ISO19139, non disponible pour Dublin-core, pour ISO19110, ...). L'autre (https://github.com/geonetwork/geonetwork-microservices/tree/main/modules/services/ogc-api-records) propose un flux DCAT avec un mapping à partir du document de l'index GeoNetwork. Mapping qui peut surement être amélioré selon les objectifs (eg. https://github.com/geonetwork/geonetwork-microservices/issues/65).
Merci pour les indications sur la consommation avec les filtres, je ne les avais pas mis sur mes tests précédents !
J'ai fait quelques tests pour un moissonneur CSW (avec schéma DCAT) que j'ai poussé sur cette PR et que j'ai déployé sur https://demo.data.gouv.fr/.
J'ai créé deux organisations avec chacun un moissonneur basé sur la solution CSW ou OGC API Records avec https://apps.titellus.net en cible :
Pour info, il est possible de trouver les informations de métadonnées de moissonnage d'un jeu de données sur sa page, dans l'onglet Métadonnées
, puis dans le toggle MOISSONNAGE
. Le remote_id
est le dct:identifier
du jeu de données moissonné.
Quelques observations d'intérêt :
dct:identifier
sont tous liés au même jeu de donnée datagouv, car le remote_id vaut None
pour tous. Un seul jeu de données a un dct:identifier
renseigné. Il pourrait peut-être être intéressant de filtrer uniquement sur les jeux de données qui ont un dct:identifier
.Coté data.gouv.fr, nous sommes disponibles pour échanger prochainement avec les personnes intéressées pour discuter des solutions pressenties.
Bonjour, En tant que plateforme régionale, on aimerait bien que data.gouv puisse nous moissonner en DCAT via le CSW ! Vincent Fabry pour Géo2France
Merci @maudetes pour ces premiers tests.
Je constate également un soucis sur les urls des fiches moissonnées, en CSW le hostname est localhost:8080
Nous avons moissonné en CSW geo2france et cela semble bien fonctionner. Quelques remarques sur https://demo.data.gouv.fr/fr/datasets/diagnostics-de-performance-energetique-dpe-3/:
bbox-east-long
4.25573382669
bbox-north-lat
51.0890003105
bbox-south-lat
48.8372121327
bbox-west-long
1.38022461103
et dans la métadonnée
<gmd:extent>
<gmd:EX_Extent>
<gmd:description>
<gco:CharacterString>France</gco:CharacterString>
</gmd:description>
</gmd:EX_Extent>
</gmd:extent>
<gmd:extent>
<gmd:EX_Extent xmlns:xs="http://www.w3.org/2001/XMLSchema">
<gmd:description>
<gco:CharacterString>HAUTS-DE-FRANCE</gco:CharacterString>
</gmd:description>
<gmd:geographicElement>
<gmd:EX_GeographicBoundingBox>
<gmd:westBoundLongitude>
<gco:Decimal>1.38022461103</gco:Decimal>
</gmd:westBoundLongitude>
<gmd:eastBoundLongitude>
<gco:Decimal>4.25573382669</gco:Decimal>
</gmd:eastBoundLongitude>
<gmd:southBoundLatitude>
<gco:Decimal>48.8372121327</gco:Decimal>
</gmd:southBoundLatitude>
<gmd:northBoundLatitude>
<gco:Decimal>51.0890003105</gco:Decimal>
</gmd:northBoundLatitude>
</gmd:EX_GeographicBoundingBox>
</gmd:geographicElement>
</gmd:EX_Extent>
</gmd:extent>
Merci pour ces updates et pour nos échanges.
Bonjour @fgravin,
J'ai pris le temps de regarder le moissonnage de geo2france, il est malheureusement en échec (statut En initialisation
dans l'admin). Cet échec a lieu à cause de limites techniques côté datagouv sur la taille du graphe moissonné. En faisant quelques tests en local en limitant le catalogue, le moissonnage a l'air fonctionnel, même si on retrouve cependant certains points soulevés plus haut (l'uri localhost:8080
, des jeux de données sans fichiers/ressources).
Si on envisage la solution moissonnage DCAT via CSW et que l'exposition reste similaire, il faudra alors faire des développements côté datagouv pour supporter des catalogues de cette taille.
Par ailleurs, je vous invite à plutôt faire des tests sur de nouvelles organisations de tests pour ne pas mélanger les jeux de données déjà existants de ceux nouvellement moissonnés.
Concernant la métadonnée de couverture spatiale, elle n'est pas moissonnée aujourd'hui via DCAT sur data.gouv.fr. C'est un développement que nous avons bien en tête et que nous prévoyons dans le futur.
Et bonjour @fxprunayre, est-ce qu'un point de synchro en petit comité etalab / geonetwork est possible et souhaitable avant de refaire un point plus large avec toutes les personnes intéressées ? Je compte proposer un framadate ouvert prochainement.
un point de synchro en petit comité etalab / geonetwork
ok, je suis disponible cette semaine, @maudetes.
Voici mon compte rendu du point de synchronisation technique. N'hésitez pas à compléter ou à commenter.
Deux options ont été enquêtées tout au long de cette discussion pour permettre un moissonnage des plateformes GeoNetwork v4 par data.gouv.fr :
Le but de cet échange technique était de faire un état des lieux de la faisablité de ces options et préciser les éventuels points de blocage afin de prévoir la suite des opérations.
Lors des moissonneurs de tests créés, plusieurs points ont été soulevés (cf ce commentaire précédent) sur les fiches créées via les deux solutions.
dct:identifier
absent au niveau du Dataset dans l'export API OGC Records (nécessaire pour le moissonnage data.gouv.fr), comme indiqué précédemment par @fxprunayre, il s'agit des fiches sur lesquelles aucun identifiant n'est renseigné par le producteur. Hors données INSPIRE, ces identifiants ne sont pas obligatoires et peuvent être absents. Dans le cas du CSW, le dct:identifier
spécifié au niveau du Dataset est celui de la fiche.
-> Se pose donc la question du bon identifiant à renseigner au niveau du Dataset (UUID de la fiche GeoNetwork, l'URI ou encore les identifiants spécifiés par le producteur). Ce sujet est une question récurrente au niveau des spécifications d'usage DCAT (ex: ici ou là) et doit à terme être coordonné au-delà du moissonnage GeoNetwork vers data.gouv.fr.dct:identifier
au niveau du Dataset lors du moissonnage par data.gouv.fr.dcat:landingPage
sur l'exposition GeoNetwork qui permettra de faire un lien vers la fiche GeoNetwork depuis l'interface data.gouv.fr.Attention aux développements en double dû aux mappings différents (et indépendants), il pourrait être stratégique de se concentrer sur l'une des deux options et de la recommander largement.
J'en profite pour proposer un framadate https://framadate.org/WiL9VcRgMFaaWtIy pour échanger prochainement en visio sur cette question du moissonnage GeoNetwork par data.gouv.fr, ouvert à toutes celles et ceux intéressés par le sujet. Ce sera l'occasion de répondre aux questions et de faire un point sur l'avancement plus accessible que les échanges techniques ci-dessus.
Bonjour ! Au vu des résultats du framadate, je propose le jeudi 9 mars à 14h, avec le lien suivant pour la visio : https://webinaire.numerique.gouv.fr//meeting/signin/8636/creator/4868/hash/b6a2db989ee04e2b2fd3aa812f2f4ea339588585. Je vous laisse vous créer vos propres invitations car je n'ai pas tous vos mails.
Je tente une synthèse de la réunion métadonnées data.gouv.fr / GeoNetwork 4 de ce jour :
Présents côté data.gouv.fr :
Présenter et discuter des possibilités de moissonnage des catalogues GeoNetwork 4 par data.gouv.fr Discussion initiale : https://github.com/etalab/data.gouv.fr/issues/913
Suppression du point d'accès direct DCAT avec la version 4 de GeoNetwork (GN4). Moissonnage de catalogues GeoNetwork 3 (GN3) ok pour data.gouv.fr mais pas avec GN4. Besoin de mettre en place un nouveau moissonnage pour les catalogues GN4 (de nombreuses plateformes sont concernées par la migration vers GN4)
Possibilités étudiées par data.gouv.fr pour moissonner des catalogues GN4
Travaux en cours côté data.gouv.fr : moissonnage CSW DCAT. Ça fonctionne mais pas encore finalisé. Pas encore testable. Possibilité de déployer la branche de test sur l'instance de démo de data.gouv.fr. (voir pullrequest https://github.com/opendatateam/udata/pull/2800)
Travaux réalisés du côté de GN4 : implémentation OGC API records réalisée (depuis version 4.2.3). Testable sur demo.data.gouv.fr/ Pas exactement le même mapping pour les deux solutions.
Exemples de requêtes fournies par @fgravin : CSW: https://dev.geo2france.fr/geonetwork/srv/eng/csw?SERVICE=CSW&VERSION=2.0.2&REQUEST=GetRecords&outputSchema=http://www.w3.org/ns/dcat%23&typenames=gmd:MD_Metadata&elementSetName=full&resultType=results OGC: https://dev.geo2france.fr/ogc-api-records/collections/main/items?f=dcat
L'API records n'est pas encore dans le cœur de GN. Ce sera le cas dans les prochaines versions. Cela devrait suivre dans geOrchestra par voie de conséquence.
Q: Est ce qu'il y a des différences entre un moissonnage via OGC API Records ou CSW GN ? (qui feraient privilégier l'un ou l'autre) du point de vue data.gouv ? R : Pas de moissonnage privilégié par data.gouv.fr. Il faut noter que les mappings mis en place sur les deux sorties DCAT de GN4 ne sont pas identiques. data.gouv.fr va adapter ses moissonneurs pour obtenir des résultats cohérents. @maudetes souhaite qu'on ait un profil DCAT français mis en œuvre au niveau de GeoNetwork qui permette d'homogénéiser les métadonnées DCAT moissonnées par data.gouv.fr. @fgravin ne se prononce pas sur la convergence des mappings.
Lacunes actuelles du moissonnage des ressources géographiques par data.gouv.fr :
Pas de récupération de la couverture spatiale. L'implémentation de l'extension spatiale des données dans DCAT est extrèmement complexe : l'extension spatiale peut être exprimée de manières très différentes.
Problématique des identifieurs à utiliser pour identifier un dataset de manière fiable :
La notion de CSW virtuel n'existe plus dans GN4. On peut mettre en place le même genre de chose en utilisant un sous-portail/subportal et en utilisant son CSW. Cela nécessite une configuration différente côté administration de GN mais n'a pas d'impact sur les moissonneurs de data.gouv.fr (chaque CSW dispose de sa propre URL et reste conforme au standard CSW).
Les métadonnées qui ne sont plus accessibles par moissonnage sont automatiquement archivées par data.gouv.fr :
Pour la suite, reste à déterminer :
Pour tester les possibilités de moissonnage, utilisation de la plateforme de démo. Quelques liens fournis :
@maudetes j'aimerais pouvoir tester un moissonnage (csw-dcat) avec le serveur de test du SIB, https://test-data.naturefrance.fr/geonetwork/srv/eng/csw. J'ai créé un moissonneur sur demo.data.gouv.fr, vous serait-il possible de valider mon moissonneur, qu'on puisse voir si ça marche ?
@maudetes j'aimerais pouvoir tester un moissonnage (csw-dcat) avec le serveur de test du SIB, https://test-data.naturefrance.fr/geonetwork/srv/eng/csw. J'ai créé un moissonneur sur demo.data.gouv.fr, vous serait-il possible de valider mon moissonneur, qu'on puisse voir si ça marche ?
après avoir relu attentivement le ticket, si je comprends bien tant que opendatateam/udata#2800 n'est pas mergée le support csw-dcat n'est pas pleinement opérationnel ?
Il serait intéressant de savoir si https://demo.data.gouv.fr fait tourner cette branche, je vois juste actuellement Moteur open source : udata (6.1.3.dev25115)
en bas a droite actuellement mais ca ne correspond pas a un tag ou une branche du repository udata, a part master
?
Sur https://www.data.gouv.fr la version est actuellement udata (6.1.3.dev25146)
... cf https://github.com/opendatateam/udata/blob/master/docs/versioning.md - je ne sais pas a quoi correspond le dernier chiffre. identifiant de commit subversion ?
par contre je 'pense' que le support du moissonage dcat via ogc-api-records est fonctionnel/testable ?
@maudetes si vous voulez faire des tests 'a grande échelle' pour ogc api records, https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat est disponible et vient juste d'être déployé avec georchestra/ansible#114.
Le geonetwork 4.2.2 de cette instance de demo moissonne les geonetwork de toutes les instances georchestra listées sur https://www.georchestra.org/community.html (donc environ ~15k MD), et le microservice ogc-api-records est en version 4.2.2.
https://demo.georchestra.org/geonetwork/srv/fre/csw?SERVICE=CSW&VERSION=2.0.2&REQUEST=GetRecords&outputSchema=http://www.w3.org/ns/dcat%23&typenames=gmd:MD_Metadata&elementSetName=full&resultType=results est aussi disponible pour des tests de moissonage csw-dcat.
@jeanpommier, j'ai validé le moissonneur. Une erreur SSL a cependant lieu lors du moissonnage. Je n'ai pas enquêté, mais curl https://test-data.naturefrance.fr/geonetwork/srv/eng/csw
me renvoie bien une erreur SSL en local. Je vous laisse regarder de votre côté si vous reproduisez aussi ?
@landryb En effet, il est déjà possible de tester le moissonnage via OGC API Records sur les différents environnements. La plateforme de demo déploie bien https://github.com/opendatateam/udata/pull/2800, et il est donc aussi possible de réaliser des tests sur https://demo.data.gouv.fr/ pour le moissonnage CSW-DCAT.
Je me suis permise de créer deux organisations avec les moissonneurs correspondants pour tester georchestra sur demo : https://demo.data.gouv.fr/fr/organizations/georchestra-ogc-api-records/ et https://demo.data.gouv.fr/fr/organizations/georchestra-csw/. Je peux vous rajouter comme administrateur sur demande (action Demander à rejoindre l'organisation en tant que producteur
).
Côté API OGC Records, le moissonnage semble réussir sans problème, mais seuls 6 dcat:Dataset
sont retournés sur cet endpoint. Cela vous semble-t-il cohérent ?
Côté CSW-DCAT, le moissonnage échoue visiblement à cause de la requête POST, dont voici le contenu :
<csw:GetRecords xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"
xmlns:gmd="http://www.isotc211.org/2005/gmd"
service="CSW" version="2.0.2" resultType="results"
startPosition="1" maxPosition="200"
outputSchema="http://www.w3.org/ns/dcat#">
<csw:Query typeNames="gmd:MD_Metadata">
<csw:ElementSetName>full</csw:ElementSetName>
<ogc:SortBy xmlns:ogc="http://www.opengis.net/ogc">
<ogc:SortProperty>
<ogc:PropertyName>identifier</ogc:PropertyName>
<ogc:SortOrder>ASC</ogc:SortOrder>
</ogc:SortProperty>
</ogc:SortBy>
</csw:Query>
</csw:GetRecords>
qui retourne cette erreur :
<ows:ExceptionReport xmlns:ows="http://www.opengis.net/ows" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2.0" xsi:schemaLocation="http://www.opengis.net/ows http://schemas.opengis.net/ows/1.0.0/owsExceptionReport.xsd">
<ows:Exception exceptionCode="NoApplicableCode">
<ows:ExceptionText>java.lang.RuntimeException: org.fao.geonet.csw.common.exceptions.InvalidParameterValueEx: code=InvalidParameterValue, locator=OutputSchema, message=Error occured while transforming metadata with id '2627' using 'dcat-full.xsl'.</ows:ExceptionText>
</ows:Exception>
</ows:ExceptionReport>
La même requête sans le SortBy
semble retourner les résultats attendus.
Enfin, je lève un point d'attention sur les flux de moissonnage à mettre en place en production pour éviter des doublons de moissonnage, mais ça peut faire l'objet d'une discussion dédiée, et nous pouvons tester le fonctionnement du moissonnage en attendant.
Ha, mince, oui, je crois qu'il y a un souci avec leurs certificats SSL. J'ai changé l'URL pour pointer sur mon serveur de dev, ça permettra déjà de voir. Pouvez-vous relancer le moissonnage ? Serait-il possible que j'aie la main dessus, ça éviterait sans doute qq aller-retours ? Merci en tous cas !
ah, pardon, je viens de voir qu'il est programmé en cron, donc y'a plus qu'à attendre voir. Merci !
Je me suis permise de créer deux organisations avec les moissonneurs correspondants pour tester georchestra sur demo : https://demo.data.gouv.fr/fr/organizations/georchestra-ogc-api-records/ et https://demo.data.gouv.fr/fr/organizations/georchestra-csw/. Je peux vous rajouter comme administrateur sur demande (action
Demander à rejoindre l'organisation en tant que producteur
).
Fait, j'essaierai de comprendre les requetes faites en regardant les logs serveur
- Côté API OGC Records, le moissonnage semble réussir sans problème, mais seuls 6
dcat:Dataset
sont retournés sur cet endpoint. Cela vous semble-t-il cohérent ?
Pas du tout étant donné que https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat en renvoie 10 a cause de la pagination et qu'il y'a théoriquement au moins 10k records.. est-ce que udata supporte la pagination ? ceci dit dans le format dcat je ne vois pas d'informations sur la 'taille' du dataset a parcourir... alors qu'elle est présente dans les formats xml ou json cf https://demo.georchestra.org/ogc-api-records/collections/main/items?f=json
il y'a bien plus de records dans le rdf avec https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat&limit=100 mais il faut bien que le client ait un moyen de connaitre la taille de l'ensemble a paginer, a parcourir avec limit=XXX&offset=YYY
? Je ne sais pas quels parametres sont implémentés par le microservice, mais il est probablment 'sain' d'utiliser la pagination plutot que fixer arbitrairement une valeur enorme et faire tomber le service en demandant tous les records d'un coup.
*Côté CSW-DCAT, le moissonnage échoue visiblement à cause de la requête POST, dont voici le contenu : ... La même requête sans le
SortBy
semble retourner les résultats attendus.
J'imagine que c'est le backend datagouv qui envoie le SortBy dans le POST ? L'erreur est.. étonnante. Je laisserais les experts geonetwork se pencher dessus..
coté serveur, je vois des hits a 2h du matin venant de python-request, je suppose que ce sont les requetes udata ?
51.178.64.211 - - [03/Apr/2023:02:00:01 +0200] "HEAD /geonetwork/srv/fre/csw HTTP/1.1" 200 0 "-" "python-requests/2.24.0"
51.178.64.211 - - [03/Apr/2023:02:00:01 +0200] "POST /geonetwork/srv/fre/csw HTTP/1.1" 200 372 "-" "python-requests/2.24.0"
51.178.64.211 - - [03/Apr/2023:02:02:38 +0200] "HEAD /ogc-api-records/collections/main/items?f=dcat HTTP/1.1" 200 0 "-" "python-requests/2.24.0"
51.178.64.211 - - [03/Apr/2023:02:02:38 +0200] "GET /ogc-api-records/collections/main/items?f=dcat HTTP/1.1" 200 71054 "-" "python-requests/2.24.0"
un host sur l'ip semble le confirmer:
$host 51.178.64.211
211.64.178.51.in-addr.arpa domain name pointer dev-02.infra.data.gouv.fr.
Enfin, je lève un point d'attention sur les flux de moissonnage à mettre en place en production pour éviter des doublons de moissonnage, mais ça peut faire l'objet d'une discussion dédiée, et nous pouvons tester le fonctionnement du moissonnage en attendant.
Oui ca c'était une évidence, mais cette problématique a toujours été présente :)
@jeanpommier, la nouvelle URL fonctionne et il y a bien le même nombre de jeux de données moissonnés que sur la plateforme cible :) Je vous laisse me faire un retour sur le résultat du moissonnage côté contenu.
@landryb, merci de vos retours.
Pour la pagination, cet endpoint ne semble pas retourner d'éléments de pagination en effet. Côté data.gouv.fr, nous supportons la pagination Hydra, comme spécifié dans la documentation de notre moissonneur DCAT. Côté geonetwork, est-ce qu'il a été envisagé d'ajouter des éléments de pagination ?
Concernant le contenu de la requête, c'est bien dans la requête du moissonneur que on utilise le sortBy, comme recommandé ici. Et les appels à 2h du matin semblent bien venir de udata :)
Je veux bien l'avis de @fxprunayre sur ces deux points si c'est possible ? :pray:
Merci. Oui ça a l'air de marcher. Je ne vois pas les images (aperçus) par contre, c'est normal ?
Concernant l'URL précédente, avez-vous une idée du pb ? Le certificat a l'air bien reconnu par les navigateurs. Se pourrait-il que ce soit dû à des certificat CA périmés côté python (udata) ?
Je n'ai pas la main sur les serveurs de test-data.naturefrance.fr (ni de data.naturefrance.fr), donc je ne sais pas trop comment ils les ont configurés.
@maudetes Le pb de certificat me semble bien être du côté du MNHN, ils sont sur le coup. En attendant, je fais le test avec mon serveur de dev. Donc je confirme, le moissonnage se passe bien, le nombre d'enregistrements matche.
Les métadonnées du catalogue sont assez limitées (on est loin d'un ISO valide), cependant je m'interroge à propos de deux éléments :
Merci !
Merci @jeanpommier pour ce retour, concernant le soucis de certificat et les métadonnées moissonnées. Je réponds aux deux questions ci-dessous.
les imagettes d'aperçu ne semblent pas récupérées. C'est normal ?
On n'a pas de méta-données d'image associée à des JDDs sur data.gouv.fr aujourd'hui, donc on ne moissonne pas ces images. Cependant, même si non moissonnée par data.gouv.fr, l'image semble bien exposée dans la métadonnée foaf:thumbnail
.
idem pour la licence. Sur demo.data.gouv.fr, je vois "License not specified". Par exemple https://demo.data.gouv.fr/fr/datasets/referentiel-des-donnees-naturalistes-sensibles-a-la-diffusion/ alors que j'ai bien quelque chose de défini sur https://sib1.dev.pigeosolutions.fr/geonetwork/srv/eng/catalog.search#/metadata/f6695683-74b4-4208-88c4-e09e1e909a30 Mais pas dans le format attendu j'imagine. Pouvez-vous me dire ce qui fait que ça ne passe pas ? Quel serait un exemple de contenu attendu ?
En regardant le contenu exposé en DCAT, je vois deux soucis :
restricted
?) (certaines devant plutôt être exprimées via dct:accesRights ou dct:rights?). Or côté moissonnage, on s'attend aujourd'hui à une unique valeur de licence. On n'est donc pas certain que la bonne valeur soit utilisée s'il y en a plusieurs.OK, merci, je vais regarder cette histoire de licence. Merci pour l'analyse détaillée
Bonjour à toutes et tous,
Pour avancer sur ce sujet, et avoir une première version fonctionnelle (mais améliorable) des deux options en prod, est-ce qu'il serait possible d'avoir un retour côté GeoNetwork (@fxprunayre ou @fgravin peut-être?) sur les points soulevés par les tests de moissonnage de GeoOrchestra (en particulier dans ce commentaire):
SortBy
qui échoue pour le moissonnage CSWPar ailleurs, j'invite ceux qui voudraient à se manifester pour mener des tests sur des plateformes GeoNetwork v4 sur la plateforme de demo https://demo.data.gouv.fr/. Plus on a de tests sur des plateformes réelles, mieux c'est :blush:
suite a pas mal de bricolages lors du community sprint georchestra (cette nuit, ce matin..), https://demo.georchestra.org a été redéployé depuis un build maison produit depuis le fork georchestra/geonetwork rebasé sur le tag 4.2.4 upstream de geonetwork (cf branche https://github.com/landryb/geonetwork/tree/georchestra-gn4.2.x).
Le jar du microservice ogc-api-records a aussi été upgradé pour utiliser la version https://github.com/geonetwork/geonetwork-microservices/releases/tag/4.2.4-0.
'+isTemplate:n AND -indexingError:true'
), https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat renvoie maintenant 9 records au lieu de 6 auparavant, même si a priori on en demanderait 10 - le record manquant serait droppé car avec erreur d'indexation ?enfin, si je remets '+isTemplate:n AND -indexingError:true'
comme config de filtre dans le service ogc-api-records, https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat renvoie bien 10 enregistrements, ce qui semble prometteur.
pour le csw-dcat, faire le meme POST avec le sortBy
sur https://demo.georchestra.org/geonetwork/srv/fre/csw renvoie toujours une erreur sur une MD particulière:
<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport xmlns:ows="http://www.opengis.net/ows" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2.0" xsi:schemaLocation="http://www.opengis.net/ows http://schemas.opengis.net/ows/1.0.0/owsExceptionReport.xsd">
<ows:Exception exceptionCode="NoApplicableCode">
<ows:ExceptionText>java.lang.RuntimeException: org.fao.geonet.csw.common.exceptions.InvalidParameterValueEx: code=InvalidParameterValue, locator=OutputSchema, message=Error occured while transforming metadata with id '2627' using 'dcat-full.xsl'.</ows:ExceptionText>
</ows:Exception>
</ows:ExceptionReport>
a chaque requete CSW, dans le log de geonetwork j'ai:
Error on line 451 of tpl-rdf.xsl:
XPTY0004: A sequence of more than one item is not allowed as the first argument of
encode-for-uri() ("1810", "", ...)
a priori, ce problème viendrait du fait que cette MD est multilingue ?
bref.. pour ce qui est de georchestra, on progresse :)
de ce que je vois des 3 derniers moissonages de https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat on est passé a 25 MD, certaines sont en erreur de validation ((url.b’Invalid URL “http://ogc.geo-ide.application.i2/wxs?map=/opt/data/carto/geoide-catalogue/1.4/org_38012/85a6a543-f6ec-4ec8-a55a-8afed3340df4.intranet.map”
... sans commentaires. quoique.. lol), mais le nombre reste faible car par défaut on n'en demande que 10. je viens de modifier l'url pour ajouter &limit=1000
, le lancement d'une prévisualisation du job m'affiche juste un popup rouge Une erreur inconnue est survenue
après qqs secondes.
dans le log du microservice OAPIR j'ai bien vu passer une requete vers ES pour 1000 records et selon le log apache 7mo de données auraient été renvoyés au moissoneur dcat:
10.1.0.254 - - [05/Jun/2023:09:47:04 +0000] "GET /ogc-api-records/collections/main/items?f=dcat&limit=1000 HTTP/1.0" 200 6891036 "-" "python-requests/2.24.0"
@maudetes si tu veux trigger un moissonage a la main pour voir ce qui remonte...
pas de changement sur le moissonage CSW, toujours 0.
@landryb merci pour le travail d'enquête et d'analyse ! En effet, il y a quelques soucis sur des URLs non valides (sur l'exemple c'est le TLD i2 qui est invalide).
La prévisualisation échoue en effet pour des raisons de timeout dans le cas de gros catalogues. J'ai relancé le moissonnage avec la limite à 1000, qui en a moissonné 995 (?). :clap: Il y a cependant une quasi moitié en erreur à cause de l'absence d'identifiant DCT.identifier au niveau du Dataset, car l'identifiant ne doit pas être renseigné sur les fiches en question.
merci pour le test, je viens de voir les résultats prometteurs. J'ai mis ?items=16000
... on verra bien ce qui remonte la prochaine fois. Le support pour une 'vraie' pagination serait bienvenu, mais j'avoue que je ne vois pas trop quelle heuristique employer (taille de la page, nombre de records a moissonner en tout?), ni comment s'assurer que l'ordre des records renvoyés par le service serait constant..
je ne connais pas du tout les mappings, mais de quel champ inspire/iso19139 est sensé venir DCT.identifier
? p-e que ces fiches ne viennent pas a l'origine d'un catalogue iso mais d'un catalogue opendata moissoné par un catalogue iso (eg via geo2france peut-etre)
autre point de vigilance: si j'ai bien compris, c'est a l'entité fournissant le point de moissonage de ne faire remonter que les métadonnées locales au catalogue, pas les données moissonnées si elles remontent déjà par un autre chemin. On ne peut pas faire un filtre dans la configuration coté moissoneur.
il faudra donc bien le spécifier dans la documentation pour l'adminstrateur du service moissoné (eg eventuellement monter un point d'accès OAPIR spécifique moissonnage par data.gouv sur une url distincte), et proposer des exemples de filtre de configuration du service OAPIR pour exclure les fiches de MD moissonnées depuis une autre source précise, qui générerait des doublons.
edit: pour ceux qui veulent voir ce qui est effectivement moissonné, cf https://demo.data.gouv.fr/fr/organizations/georchestra-ogc-api-records/#/datasets
je ne connais pas du tout les mappings, mais de quel champ inspire/iso19139 est sensé venir
DCT.identifier
? p-e que ces fiches ne viennent pas a l'origine d'un catalogue iso mais d'un catalogue opendata moissoné par un catalogue iso (eg via geo2france peut-etre)
Il s'agit de l'identifiant de la ressource en ligne gmd:RS_Identifier
, or il peut y en avoir plusieurs. GeoNetwork utilise l'uuid de la fiche, ce qui n'est pas non plus correct. On en avait discuté avec @fxprunayre mais il n'y a pas de solution miracle. @maudetes peut-on exposer plusieurs dct.identifier
je ne sais plus ?
En effet, la question des identifiants à exposer n'est pas encore tranchée. De ma compréhension partielle de la propriété dct:Identifier, de la section sur les identifiers ainsi que les guidelines et discussions du SEMIC, l'idéal serait :
Côté udata, aujourd'hui on ne moissonne pas les amds:Identifier, on se contente uniquement de moissonner et d'exposer un unique dct:Identifier. Par contre, ça ne me semble pas très difficile, clairement souhaitable et en phase avec les recommandations si je les ai bien comprises.
Il serait intéressant d'avoir un avis du CNIG sur le sujet. Le bon endroit pour remonter ces questions serait ce repo https://github.com/cnigfr/metadonnee ?
Pour la question de la pagination, à voir ce qui est faisable côté GeoNetwork pour conserver l'ordre des records, mais côté udata, on supporte la pagination Hydra. Si un catalogue de millier de jeu peut être moissonné, la pagination peut être itérée en deuxième itération.
Sur le fait de ne faire moissonner que les données locales au catalogue, on avait en effet évoqué les possibilités de subportal côté GeoNetwork (dans le dernier compte rendu), mais des liens de documentation seraient bienvenus sur la section GeoNetwork de notre doc de moissonnage DCAT (pas encore mis à jour pour la v4).
Sur le fait de ne faire moissonner que les données locales au catalogue, on avait en effet évoqué les possibilités de subportal côté GeoNetwork (dans le dernier compte rendu), mais des liens de documentation seraient bienvenus sur la section GeoNetwork de notre doc de moissonnage DCAT (pas encore mis à jour pour la v4).
de ce que j'y comprends, faire un subportal pour n'avoir qu'un sous-ensemble des MD ne servirait que pour les moissonages CSW-DCAT, étant donné que le microservice OAPIR tape directement sur l'index ES il n'a pas connaissance des subportals configurés dans geonetwork.. il faudrait donc 'filtrer' pour créer le sous-ensemble lors de la requete envoyée a ES.. et donc faire une instance dédiée du microservice.
étant donné que le microservice OAPIR tape directement sur l'index ES il n'a pas connaissance des subportals configurés dans geonetwork.. il faudrait donc 'filtrer' pour créer le sous-ensemble lors de la requete envoyée a ES.. et donc faire une instance dédiée du microservice.
Je pense que les collections
de OGC API Records correspondent à des sources dans GN, donc des sous-portails.
Cf https://sextant.ifremer.fr/geonetwork/api/collections
Après effectivement, lorsqu'on parcourt une collection issue d'un sous portail, on ne trouve aucune fiche. Il doit y avoir un problème d'implémentation ou de configuration peut-être.
Pour moi, un subportal donne un entry point pour les api GN4, CSW et OGC Records.
Je pense que les
collections
de OGC API Records correspondent à des sources dans GN, donc des sous-portails. Cf https://sextant.ifremer.fr/geonetwork/api/collections
Aaah oui très juste, ca me revient, j'avais oublié ce détail.
Après effectivement, lorsqu'on parcourt une collection issue d'un sous portail, on ne trouve aucune fiche. Il doit y avoir un problème d'implémentation ou de configuration peut-être.
oui j'avais aussi vu des bugs en étudiant https://dev.geo2france.fr/ogc-api-records/collections - pour les 'portails thématiques' (eg subportals) chacun faisait remonter toutes les métadonnées de l'index (donc pas de filtrage), et chacun des Harvested collections
faisaient remonter 0 records..
Dans le cas de l'endpoint dcat, il est aussi possible de fournir un endpoint DCAT filtré avec des paramètres d'intérêt, ex https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat&limit=100&q=incendie, mais je ne sais pas si c'est suffisamment puissant/fin pour les besoins.
le moissonage de la nuit dernière du microservice OGC a échoué:
Statut
Échec
Erreurs
Unable to detect format from extension or mime type
coté logs apache, j'ai un http://http.cat/406:
10.1.0.254 - - [06/Jun/2023:00:00:45 +0000] "HEAD /ogc-api-records/collections/main/items?f=dcat&limit=16000 HTTP/1.0" 406 377 "-" "python-requests/2.24.0"
et coté logs microservice, a priori il y'aurait une limite par défaut a 15k records dans la conf de l'index ou d'ES:
Error:
{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"Result window is too large, from + size must be less than or equal to: [15000] but was [16000]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."}],"type":"search_phase_execution_exception","reason":"all shards failed","phase":"query","grouped":true,"failed_shards":[{"shard":0,"index":"gn-records","node":"Xm14XIsPRQiXF8-EfHgK5w","reason":{"type":"illegal_argument_exception","reason":"Result window is too large, from + size must be less than or equal to: [15000] but was [16000]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."}}],"caused_by":{"type":"illegal_argument_exception","reason":"Result window is too large, from + size must be less than or equal to: [15000] but was [16000]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting.","caused_by":{"type":"illegal_argument_exception","reason":"Result window is too large, from + size must be less than or equal to: [15000] but was [16000]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."}}},"status":400}.] with root cause
java.lang.Exception: Error is: Bad Request.
Request:
{"from":0,"size":16000,"query":{"bool":{"must":[{"query_string":{"query":"*:*","fields":[],"type":"best_fields","default_operator":"or","max_determinized_states":10000,"enable_position_increments":true,"fuzziness":"AUTO","fuzzy_prefix_length":0,"fuzzy_max_expansions":50,"phrase_slop":0,"escape":false,"auto_generate_synonyms_phrase_query":true,"fuzzy_transpositions":true,"boost":1.0}}],"filter":[{"query_string":{"query":"+isTemplate:n AND -indexingError:true","fields":],"type":"best_fields","default_operator":"or","max_determinized_states":10000,"enable_position_increments":true,"fuzziness":"AUTO","fuzzy_prefix_length":0,"fuzzy_max_expansions":50,"phrase_slop":0,"escape":false,"auto_generate_synonyms_phrase_query":true,"fuzzy_transpositions":true,"boost":1.0}},{"query_string":{"query":"op0:(1) AND (draft:n OR draft:e)"}}],"adjust_pure_negative":true,"boost":1.0}},"_source":{"includes":"schema","allKeywords","formats","edit","resourceTitleObject","link","contactForResource","*","geom","mainLanguage","resourceDate","resourceAbstractObject","contact","changeDate","id","cl_status","tag","resourceType","metadataIdentifier","createDate","op*"],"excludes":[]},"track_total_hits":2147483647}
je vais remettre la limite a 15k coté client pour le prochain moissonage... mais ca montre clairement le besoin d'une pagination pour ce type de moissonage :)
je vais remettre la limite a 15k coté client pour le prochain moissonage... mais ca montre clairement le besoin d'une pagination pour ce type de moissonage :)
Oui il faut clairement gérer la pagination. Il faudra trouver un financement et l'implémenter. Je ne sais pas si c'est un besoin du BRGM @fxprunayre ?
Au moins, comme c'est un micro service tu devrais pouvoir le scaler et ne pas faire tomber ton GN, ni l'index si tu te débrouilles bien :smirk:
L’amélioration que vous avez en tête
Le endpoint Geonetwork DCAT directement consommable tel que documenté sur https://github.com/etalab/doc.data.gouv.fr/commit/f8a0b32f19f46c22c30add1bfa5cda248861531e#r75959289 n'est plus disponible à partir de la version 4.0 de Geonetwork car il est possible d'avoir une sortie sérialisé DCAT via le end-point CSW (https://github.com/geonetwork/core-geonetwork/wiki/DCAT-enhancements)
Il faut donc au choix rétablir le end-point tel qu'il était en faisant une PR dans Geonetwork mais c'est peu probable sinon il n'aurait pas été déprécié soit il faut voir comment adapter notre consommation du DCAT via l'appel depuis le endpoint CSW.
En dehors des aspects techniques, il faut voir la charge que cela implique pour nous ou le BRGM qui envisageait à un moment de passer par Geonetwork. Cela peut impliquer aussi l'équipe Geonetwork selon si des modifications doivent être faites sur la base de code du projet lui-même.
Constatations techniques préliminaires pour investiguer
Pour avoir une idée du retour de l'appel CSW comparativement à celui existant (attention, ici on tape sur un serveur avec une version 4.2.1 de Geonetwork
J'ai fait un test sur le catalogue de l'OREME qui sont en version 3.10 actuellement (ce qui me permettrait de comparer la sortie dcat actuelle encore supportée et celle via le endpoint CSW
Sortie DCAT "legacy" via https://sig.oreme.org/geonetwork/srv/eng/rdf.search
VS sortie "nouvelle" via le endpoint CSW
Problème dans ce 2nd cas: pas de records retournés. Nous avons enlevé le filtre iso19139 avec pour avoir des records