search

datagouv / data.gouv.fr

Ce dépôt rassemble les tickets techniques qui portent sur data.gouv.fr.
https://www.data.gouv.fr
76 stars 14 forks source link

Support consommation DCAT depuis un appel CSW de Geonetwork #913

Closed ThomasG77 closed 9 months ago

ThomasG77 commented 2 years ago

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

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

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

curl -H "Content-Type: application/xml" --data-binary @demo-csw-dcat.xml https://sig.oreme.org/geonetwork/srv/eng/csw

Problème dans ce 2nd cas: pas de records retournés. Nous avons enlevé le filtre iso19139 avec pour avoir des records

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:Query></csw:GetRecords>' >| demo-csw-dcat-no-filter-iso19139.xml
curl -H "Content-Type: application/xml" --data-binary @demo-csw-dcat-no-filter-iso19139.xml https://sig.oreme.org/geonetwork/srv/eng/csw
fvanderbiest commented 1 year ago

Je plussoie le besoin ici :-) Je mets en lien @fgravin @jahow @fxprunayre pour les échanges entre équipes etalab / geonetwork

jeanpommier commented 1 year ago

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 ?

maudetes commented 1 year ago

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 !

maudetes commented 1 year ago

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

fxprunayre commented 1 year ago

Suite à notre réunion quelques exemples côté GeoNetwork pour les tests:

Remarques:

jeanpommier commented 1 year ago

Oh, mince, désolé d'avoir raté la réunion, mon agenda me fait des blagues en ce moment

maudetes commented 1 year ago

Compte rendu sur le point de synchro d'hier. N'hésitez pas à commenter si il manque des infos ou comporte des erreurs :

Compte rendu du point de synchronisation

Participants

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

Historique

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.

Options de consommation DCAT

OGC API Record

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.

CSW endpoint

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)

endpoint DCAT dédié dans GeoNetwork-core

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.

Autres considérations

Next steps

ThomasG77 commented 1 year ago

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 (?!)

maudetes commented 1 year ago

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:

Exemple:

<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 ?

fxprunayre commented 1 year ago

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/

maudetes commented 1 year ago

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.

maudetes commented 1 year ago

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.

fxprunayre commented 1 year ago

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.

fgravin commented 1 year ago

Bonjour,

Merci @fxprunayre pour les évolutions dans ogc-api-records. J'aimerais être sûr de bien comprendre et synthétiser les discussions.

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.

maudetes commented 1 year ago

Bonjour,

Merci @fxprunayre pour les évolutions et la mise à jour de app.titellus.net !

Consommation CSW

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.

Consommation API OGC Records

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).

fxprunayre commented 1 year ago

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

ou équivalent GET https://apps.titellus.net/geonetwork/srv/eng/csw?SERVICE=CSW&VERSION=2.0.2&REQUEST=GetRecords&outputSchema=http://www.w3.org/ns/dcat%23&elementSetName=full&resultType=results&CONSTRAINTLANGUAGE=CQL_TEXT&CONSTRAINT_LANGUAGE_VERSION=1.1.0&CONSTRAINT=documentStandard%3D%27iso19139%27&

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).

maudetes commented 1 year ago

Merci pour les indications sur la consommation avec les filtres, je ne les avais pas mis sur mes tests précédents !

Update des tests côté moissonnage

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 :

Coté data.gouv.fr, nous sommes disponibles pour échanger prochainement avec les personnes intéressées pour discuter des solutions pressenties.

vfabry commented 1 year ago

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

fgravin commented 1 year ago

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/:

Merci pour ces updates et pour nos échanges.

maudetes commented 1 year ago

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.

fxprunayre commented 1 year ago

un point de synchro en petit comité etalab / geonetwork

ok, je suis disponible cette semaine, @maudetes.

maudetes commented 1 year ago

Voici mon compte rendu du point de synchronisation technique. N'hésitez pas à compléter ou à commenter.

Participants

Contexte

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.

Points abordés

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.

Points de sortie

Autres considérations

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.

maudetes commented 1 year ago

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.

maudetes commented 1 year ago

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.

bchartier commented 1 year ago

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 :

Objet de la réunion

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

Contexte

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)

Nouveaux moissonneurs

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 de ces moissonneurs

Lacunes actuelles du moissonnage des ressources géographiques par data.gouv.fr :

  1. 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.

  2. Problématique des identifieurs à utiliser pour identifier un dataset de manière fiable :

    • un seul dct:identifier utilisé par data.gouv
    • plusieurs id dans les fiches GN -> problème de réconsiliation (en particulier si un jeu de données suis plusieurs chemins pour remonter à data.gouv) pour identifier que telle ressource correspond à telle autre ressource déjà référencées par ailleurs. @fgravin précise : le dcat:identifier du Dataset est le resource ID dans les 2 cas (pour CSW et API records)

Autres sujets évoqués

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 :

Et maintenant ?

Pour la suite, reste à déterminer :

Pour tester les possibilités de moissonnage, utilisation de la plateforme de démo. Quelques liens fournis :

jeanpommier commented 1 year ago

@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 ?

landryb commented 1 year ago

@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 ?

landryb commented 1 year ago

@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.

maudetes commented 1 year ago

@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).

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.

jeanpommier commented 1 year ago

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 !

jeanpommier commented 1 year ago

ah, pardon, je viens de voir qu'il est programmé en cron, donc y'a plus qu'à attendre voir. Merci !

landryb commented 1 year ago

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 :)

maudetes commented 1 year ago

@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:

jeanpommier commented 1 year ago

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.

jeanpommier commented 1 year ago

@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 !

maudetes commented 1 year ago

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 :

jeanpommier commented 1 year ago

OK, merci, je vais regarder cette histoire de licence. Merci pour l'analyse détaillée

maudetes commented 1 year ago

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):

Par 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:

landryb commented 1 year ago

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.

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 :)

landryb commented 1 year ago

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.

maudetes commented 1 year ago

@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.

landryb commented 1 year ago

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

fgravin commented 1 year ago

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 ?

maudetes commented 1 year ago

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).

landryb commented 1 year ago

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.

fgravin commented 1 year ago

é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.

landryb commented 1 year ago

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..

maudetes commented 1 year ago

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.

landryb commented 1 year ago

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 :)

fgravin commented 1 year ago

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: