search

SPW-DIG / metawal-core-geonetwork

Metawal - Catalogue pour l'information géographique de Wallonie
http://metawal.wallonie.be
GNU General Public License v2.0
3 stars 1 forks source link

Encodage / INSPIRE / Déclaration du degré de conformité #512

Closed stephyritz closed 4 years ago

stephyritz commented 4 years ago

Problème de conformité des MD en prod pour lesquelles la valeur pour la balise évoquée dans https://github.com/SPW-DIG/metawal-core-geonetwork/issues/489 est "Donnée non testée".

Actuellement, c'est déclaré comme ceci :

<gmd:pass gco:nilReason="missing"/>

Ceci déclenche une erreur de conformité dans le validateur officiel d'INSPIRE car la valeur attendue est visiblement :

<gmd:pass gco:nilReason="unknown"/>

Voir https://github.com/inspire-eu-validation/metadata/blob/2.0/common/conformity-degree.md

A corriger le plus rapidement possible dans le xsl to139 et en 115-3 si nécessaire.

Exemple : http://metawal.wallonie.be/geonetwork/srv/fre/csw-inspire?request=GetRecordById&service=CSW&outputSchema=http://www.isotc211.org/2005/gmd&outputFormat=application/xml&version=2.0.2&elementSetName=full&id=d1a80c5c-419e-47fe-85e2-269792a6f9a2

fxprunayre commented 4 years ago

A corriger le plus rapidement possible dans le xsl to139 et en 115-3 si nécessaire.

Si il faut que ce soit rapide, il suffit d'éditer la fiche ? Le problème n'est pas dans la conversion mais dans la fiche encodée.

fxprunayre commented 4 years ago

Il y a combien de fiches concernées ?

stephyritz commented 4 years ago

La manière de corriger à la main est de cocher ou non cocher la case concernant le degré de conformité. Or ce n'est pas tout à fait juste de faire cela puisqu'il y a des cas ou ce n'est réellement pas testé et donc la valeur devrait être <gmd:pass gco:nilReason="unknown"/>.

Actuellement, si la cas n'est pas coché, il en résulte que nous avons ceci en 19139 : <gmd:pass gco:nilReason="missing"/> Or c'est incorrect d'après le validateur. En l'absence de valeur, nous devons avoir "unknown" et non "missing". Ce changement se fait bien dans la conversion to139 et avait été implémenté pour répondre aux exigences INSPIRE je suppose. C'est juste le missing qui est incorrect.

fxprunayre commented 4 years ago

Pour faire la modif, vue XML et remplacement par <mdq:pass gco:nilReason="unknown"/> en attendant d'avoir le menu pour simplifier la saise ?

Je pense qu'il faut éviter de mettre trop de rustine dans la conversion 19139. Si y'a bcp de fiches, on peut le faire en batch ou en SQL ?

stephyritz commented 4 years ago

Oui je suis d'accord pour éviter les rustines, autant corriger en amont. Je suis en train de recenser les fiches problématiques. Il y a des cas où on à ça dans les fiches :

                     <mdq:pass>
                        <gco:Boolean>0</gco:Boolean>
                     </mdq:pass>

Exemple : http://metawal.wallonie.be/geonetwork/srv/fre/catalog.search#/metadata/eff69ef8-e426-43b5-82da-def09cdf4c5d

Si je résume, voici les différentes étapes :

par 

<mdq:pass gco:nilReason="unknown"/>

<mdq:pass gco:nilReason=""/> par <mdq:pass gco:nilReason="unknown"/>

<mdq:pass gco:nilReason="missing"/> par <mdq:pass gco:nilReason="unknown"/>

stephyritz commented 4 years ago

Pour l'instant je pense qu'il y a au moins 75 fiches concernées. Je suis en train de regarder les erreurs une par une et cette erreur apparaît de très nombreuses fois parmi nos 86 fiches non conformes.

fxprunayre commented 4 years ago

@stephyritz j'ai un peu hacker ton post d'il y a 2 heures. On va lancer la requête sur toutes les fiches pour que ce soit homogène.

davinciagf commented 4 years ago

UPDATE metadata SET data = replace(data, '<gco:Boolean>0</gco:Boolean>', '<gco:Boolean>false</gco:Boolean>') WHERE data LIKE '%<gco:Boolean>0</gco:Boolean>%';

par 

<mdq:pass gco:nilReason="unknown"/>

Pas de présence de ce cas en test : SELECT * from metadata where data LIKE '%%'; @stephyritz as-tu les droits pour vérifier en prod et tester ce cas

<mdq:pass gco:nilReason=""/> par <mdq:pass gco:nilReason="unknown"/>

UPDATE metadata SET data = replace(data, '<mdq:pass gco:nilReason=""/>', '<mdq:pass gco:nilReason="unknown"/>') WHERE data LIKE '%<mdq:pass gco:nilReason=""/>%';

Pas de présence de ce cas en test : SELECT * from metadata where data LIKE '%%'; @stephyritz as-tu les droits pour vérifier en prod et tester ce cas

<mdq:pass gco:nilReason="missing"/> par <mdq:pass gco:nilReason="unknown"/>

UPDATE metadata SET data = replace(data, '<mdq:pass gco:nilReason="missing"/>', '<mdq:pass gco:nilReason="unknown"/>') WHERE data LIKE '%<mdq:pass gco:nilReason="missing"/>%';

Pas de présence de ce cas en test : SELECT * from metadata where data LIKE '%%'; @stephyritz as-tu les droits pour vérifier en prod et tester ce cas

fxprunayre commented 4 years ago

Pas de présence de ce cas en test : SELECT * from metadata where data LIKE '%gco:Boolean/%';

Pourrait être encodé avec <gco:Boolean></gco:Boolean> aussi

davinciagf commented 4 years ago

De même pour ce dernier cas - pas de présence en test. @stephyritz peux-tu vérifier en prod ?

stephyritz commented 4 years ago

De même pour ce dernier cas - pas de présence en test. @stephyritz peux-tu vérifier en prod ?

Vérifier en prod, pas de cas du type 

<mdq:pass>
    <gco:Boolean/>
 </mdq:pass>

ni

<mdq:pass gco:nilReason="missing"/>

Bizarre parce que je suis quasi sûr d'avoir vu ça ce matin.. Mais en ISO19139.. Les requêtes ne sont pas sensibles à un éventuel saut de ligne entre mdq:pass et gco: ?

stephyritz commented 4 years ago

Exemple de fiches problématique (cas 1) : http://metawal.wallonie.be/geonetwork/srv/fre/catalog.search#/metadata/ea3a946c-f25e-44b5-be96-dce9bbc93050

Je ne sais pas si la requête que tu as mis ci-dessus fonctionnerait parce que celle-ci ne renvoie aucun résultat : SELECT * from metawal4.metadata where data LIKE '%gco:Boolean0</gco:Boolean>%' N'est-ce pas plutôt : SELECT * from metawal4.metadata where data LIKE '%<gco:Boolean>0</gco:Boolean>%' ? --> 83 résultats Mais dans ce cas on prend le risque de changer cette valeur dans d'autres balises de . Je pense que le top serait de prendre en compte le dans le LIKE mais alors attention aux sauts de lignes..

davinciagf commented 4 years ago

Oui coquille dans le sql

stephyritz commented 4 years ago

J'ai retrouvé le cas 2 : http://metawal4.test.wallonie.be/geonetwork/srv/fre/catalog.search#/metadata/b353aac2-224c-42f7-89ca-61938ded23eb

Pour le deuxième texte réglementaire concerné. Bizarre que tu ne l'es pas détecté en prod avec ta requête. En prod, j'avais modifié manuellement la valeur donc ce n'est plus le cas. Peut-être que cela résulte de l'action de cocher/décocher ? Bon toujours est-il que le cas le plus fréquent est le premier. Pour le reste on pourra éventuellement agir manuellement.

J'ai bien retrouvé mes droits en DB sur les 3 environnements donc n'hésitez pas à me demander s'il faut tester un select en prod par ex. Par contre, il faut vraiment être vigilant au saut de ligne en SQL, parce que ça c'est bien piégeur.

davinciagf commented 4 years ago

Attnetion, j'ai modifié l'affichage des requêtes de mon précédent post car les coquilles dans le sql était du au type d'affichage ('insert a quote' à la place de 'insert code') - Désolé - j'ai corrigé dans le post.

Pour le cas 1, j'ai refait le test avec et sans la balise pass

SELECT count(*) from metadata where data LIKE '%<gco:Boolean>0</gco:Boolean>%'; Cette première requête donne une valeur de: 83

SELECT count(*) from metadata where data LIKE '%<mdq:pass>'||chr(13)||chr(10)||' <gco:Boolean>0</gco:Boolean>%'; Cette seconde requête incluant la balise pass donne une valeur de : 83

stephyritz commented 4 years ago

Attnetion, j'ai modifié l'affichage des requêtes de mon précédent post car les coquilles dans le sql était du au type d'affichage ('insert a quote' à la place de 'insert code') - Désolé - j'ai corrigé dans le post.

Pour le cas 1, j'ai refait le test avec et sans la balise pass

SELECT count(*) from metadata where data LIKE '%<gco:Boolean>0</gco:Boolean>%'; Cette première requête donne une valeur de: 83

SELECT count(*) from metadata where data LIKE '%<mdq:pass>'||chr(13)||chr(10)||' <gco:Boolean>0</gco:Boolean>%'; Cette seconde requête incluant la balise pass donne une valeur de : 83

Et quid des autres cas en incluant dans les requêtes les sauts de lignes?

davinciagf commented 4 years ago

Pour le second cas:

Il y a une coquille dans l'encodage qui fait que l'on ne retrouvait pas les fiches. @fxprunayre a trouvé la coquille : un espace entre le Boolean et />

SELECT count(*) from metadata where data LIKE '%gco:Boolean />%'; Retourne 6 fiches

SELECT count(*) from metadata where data LIKE '%mdq:pass>'||chr(13)||chr(10)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||chr(32)||'<gco:Boolean />%'; Retourne 5 fiches (la 6eme fiche retourné par la précédante requête est un template : http://metawal4.test.wallonie.be/geonetwork/srv/api/records/3de62d90-63b6-4e32-85e3-742a3665ed57/formatters/xml?approved=true

Les autres requêtes se font directement du la balisse pass et pas de résultat pour le <gco:Boolean></gco:Boolean>

davinciagf commented 4 years ago

Les requêtes de mise à jour (réalisées sur l'env. test):

UPDATE metadata SET data = replace(data, '<gco:Boolean>0</gco:Boolean>', '<gco:Boolean>false</gco:Boolean>') WHERE data LIKE '%<gco:Boolean>0</gco:Boolean>%';

UPDATE metadata SET data = regexp_replace(data,'<mdq:pass>[[:space:]]*<gco:Boolean />[[:space:]]*</mdq:pass>','<mdq:pass gco:nilReason="unknown"/>','g');

UPDATE metadata SET data = regexp_replace(data,'<mdq:pass>[[:space:]]*<gco:Boolean><gco:Boolean/>[[:space:]]*</mdq:pass>','<mdq:pass gco:nilReason="unknown"/>','g');

UPDATE metadata SET data = replace(data, '<mdq:pass gco:nilReason=""/>', '<mdq:pass gco:nilReason="unknown"/>') WHERE data LIKE '%<mdq:pass gco:nilReason=""/>%';

UPDATE metadata SET data = replace(data, '<mdq:pass gco:nilReason="missing"/>', '<mdq:pass gco:nilReason="unknown"/>') WHERE data LIKE '%<mdq:pass gco:nilReason="missing"/>%';

stephyritz commented 4 years ago

Ok, super. Ces requêtes devraient permettre la mise en conformité de la plupart de nos MD considérées actuellement comme non conformes par l'Europe. On lancera la validation par lot ensuite en prod pour identifier les derniers éléments posant problème.

stephyritz commented 4 years ago

Je viens de retrouver le cas 3 après avoir fait des tests de conformité INSPIRE. C'était vraiment piégeur... Il s'agit en fait de cette valeur : <mdq:pass gco:nilReason="" />

Comme vous pouvez le constater avec le prtsc ci-dessous, on ne voit pas ce "sp" dans l'interface d'édition avec vue xml. Il y a 3 cas. Par contre la requête

SELECT * from metawal4.metadata WHERE data LIKE '%<mdq:pass gco:nilReason=% />%';

fait ressortir 12 cas en prod et en test. J'écris cela ici juste pour info et suivi. J'opère les changement manuellement sur les 12 fiches concernées.

cas3_ticket512