[Metadator] Création automatisée de métadonnées

[Guts]

Bonjour,

La production de métadonnées étant indispensable mais souvent vécue comme une tâche laborieuse et répétitive, j’ai eu à développer un outil pour produire des fiches de métadonnées sous différents formats. Metadator, de son petit nom, s’emploie donc à :

• extraire les informations de shapefiles contenus dans une arborescence
• se baser sur des profils personnalisables pour toutes les informations non techniques
• exporter les fiches en 4 formats : html, Word 2003 (.doc), Excel 2003 (.xls) et XML ISO19139 (en partie seulement) importable dans un outil comme GéoSource.

Développé en Python, ce petit outil sans prétention (commencé après 6 mois de programmation) ne fait pas de miracle et ne supprime pas tout le travail de l’utilisateur. Il a juste vocation à automatiser ce qui peut l’être et à faire en sorte que l’utilisateur n’ait plus qu’à se concentrer sur ce qu’une machine ne peut faire pour lui : description des attributs, pertinence des informations, précisions, etc.

Il y a encore beaucoup d’améliorations à apporter certainement à cet outil, sans parler des bugs mais comme il nous rend sacrément service (surtout dans un contexte de travail où le concept de métadonnées est presque inconnu), je me suis dit que cela pourrait sympa de le faire tourner.

N’hésitez pas à le télécharger et à faire vos retours sur ce fil de discussion.

Parmi les améliorations :

• basculer le tout en classes pour pouvoir ensuite faire du joli multithreading qui devrait amener un gain de performances conséquent
• pouvoir supprimer un profil directement
• édition de contacts déjà existants
• compléter correctement l'export en ISO 19139
  
• export au format ISO19110 (pour les attributs) même si je ne vois toujours pas vraiment l’intérêt de s’embêter avec ça puisque le lien entre la donnée et ses attributs n’est pas moissonné.
• thèmes ISO
  

L'archive étant un peu lourde, je vous laisse avec la documentation que j'aie voulu la plus complète possible et pour télécharger Metadator c'est par ici.

En espérant que ce soit utile à certains.
Julien

****** EDIT du 20/10/2012 ******

Salut,

Devant le peu de retours et également un temps de plus en plus limité, je me suis désintéressé du développement "public" pour me contenter de développer l'outil selon nos besoins principalement.

J'ai donc du renoncer à adapter le programme à d'autres plateformes que Windows, du moins pour l'instant.

Sur le GitHub (https://github.com/Guts/Metadator), vous pouvez trouver 2 versions (copier/coller du README) :

Version script :


Utilisation plus souple mais nécessite des prérequis :

• Windows XP SP3 ou plus
• Microsoft Word 2003 ou plus
• Python 2.7.x : http://www.python.org/download/releases/2.7
• Modules python installables depuis PyPi ou http://www.lfd.uci.edu/~gohlke/pythonlibs:
  
  
  • GDAL/OGR : http://www.gdal.org/ogr
  • Pmw : http://pmw.sourceforge.net/doc/starting.html
  • Pywin32 : http://sourceforge.net/projects/pywin32/
  • Dateutil : http://pypi.python.org/pypi/python-dateutil/
  • xlwt : https://github.com/python-excel/xlwt
  • numpy : http://numpy.scipy.org/
  
  

Il est fortement recommandé d'installer les différents modules via des setup exécutables via http://www.lfd.uci.edu/~gohlke/pythonlibs et notamment le package Base.


Une fois l'archive décompressée, lancer Metadator.py,


Version exécutable :


Utilisation plus facile mais plus rigide ne nécessitant que Windows et Microsoft Word. Une fois l'archive décompressée, lancer Metadator.exe.

Pour info, je continue tout de même de travailler sur certains points :

• export en odt pour éviter la dépendance à Word
• utilisation d'un template xml pour le html : code plus beau (mais python-4suite ne fonctionne pas pour python 2.7 )
• export du catalogue d'attributs (ISO 19110)

++

[Lud]

Merci beaucoup pour cet outil
Si tu le souhaites on peut l'héberger sur le portailsig http://www.portailsig.org/telechargements
*******
EDIT
*******
Et sinon sans avoir essayer, comme amélioration possible ce pourrait être le support d'open office pour les non windowsiens ...

[Guts]

De rien !

Ah oui tiens, ce serait pas mal dans votre partie téléchargement. Comment procède t'on ?

J'ai évidemment penser à faire en sorte que l'outil soit indépendant d'une installation windows et surtout du pack Microsoft Office. Mais je n'ai jamais réussi à charger les modules PyUno (API python de LibreOffice et OpenOffice) . Vraiment, la doc sur ce sujet est très pauvre. J'ai ensuite lorgné du côté de la librairie PyDocx (https://github.com/mikemaccana/python-docx) mais très lourde en termes de dépendances (Yaml y PIL). Il me semble en avoir essayé une autre mais sans être séduit. L'idéal serait de produire un fichier au format .odt, surtout que même la suite Office de Microsoft tend à son intégration totale.

Cependant, dans la documentation, j'indique 2 petites modifications qui devraient suffire à se passer de l'export en word et donc de faire fonctionner l'outil depuis les sources dans l'interpréteur python de Linux ou Mac .i

[Lud]

Oui j'ai vu la doc effectivement
Pour l'intégration à la partie téléchargement, je m'occupe de ça, et je te contacte par mp pour cela. (pas tout de suite mais dès que je peux)
Merci à toi

[Guts]

Hop, petite mise à jour.

Je mets le changelog ici histoire qu'il y ait un certain suivi :

• problèmes d'encodage résolus. Le fichier html est désormais encodé en pur utf-8 (sans BOM) pour une meilleure tolérance aux subitilités des langues latines.
• amélioration de la gestion des contacts
• les fiches word sont au format .docx si l'utilisateur possède Office 2007/2010
• ajout d'une confirmation pour effacer ou renommer un profil déjà existant
• mise à niveau de la version espagnole par rapport à la version francophone
• plusieurs petites corrections de bugs

À venir (WIP) :

• internationalisation via un système de traduction. Objectif : faciliter le développement de front des versions francophones et hispanophones. Permettre des traductions éventuelles faciles.
• réorganisation de la structure des dossiers du programme
• enregistrement de paramètres par défaut
• réduction de la taille du programme (optimisation py2exe)
• option pour transformer les coordonnées en WGS84 pour que l'emprise spatiale soit joliment compatible avec GéoSource et GeoNetwork (vignette automatique et recherche par la carte).

Télécharger :

• version française
• version espagnole

Sinon aucun retour ?

[marmotte_la_gueuse]

Salut!

j'ai juste rapidement regardé ta documentation et ça me semble pas mal foutu du tout :-) J'ai à peine plus d'expérience Python que toi mais serais bien incapable de développer ça, alors bravo!

Juste une petite question / confirmation: pour l'instant, ça ne fonctionne qu'avec des shapefiles, c'est juste?

Merci et bonne journée!

Stéphane

[Lud]

Pour l'instant pour ma part j'ai une erreur

[Guts]

Salut!

j'ai juste rapidement regardé ta documentation et ça me semble pas mal foutu du tout :-) J'ai à peine plus d'expérience Python que toi mais serais bien incapable de développer ça, alors bravo!

Juste une petite question / confirmation: pour l'instant, ça ne fonctionne qu'avec des shapefiles, c'est juste?

Merci et bonne journée!

Stéphane

Salut.
Merci mais il y quand même pas mal de défauts dans le code et l'erreur que rencontre Lud est là pour l'illustrer . Personnellement, ça fonctionne sur la plupart de mes shapefiles.

Pour l'instant ce n'est que pour les shp en effet, mais une adaptation pour d'autres formats est envisageable, l'extraction des données des couches d'information étant basée sur un driver OGR. Au tout début, j'avais produit une version pour les fichiers de MapInfo...ça t'intéresse ?

Lud, peux-tu me donner plus d'infos sur l'erreur stp ?

[Lud]

Oui oui bien sur, je voulais regarder un peu avant, je regarde demain et je te dis. Faut que je fasse l'accès sur le portail ça sera ptet plus simple pour gérer les versions.

[ckiko13]

Bonjour

Je suis en train de tester l'outil. c'est très pratique.
J'ai importé le fichier XML dans Geosource. Ca a bien marché sauf l'étendue.

Par contre, lors du traitement, il récupère la liste d'attributs, qu'il met dans certains des fichiers exportés. Mais pas dans le XML.
Y aurait-il un moyen de récupérer dans Geosource le catalogue d'attributs, plutôt que de tout saisir? Parce que c'est vrai que ce serait un super gain de temps!

Merci

[Lud]

Tiens j'avais dis que je te donnerai l'erreur ... je n'ai pas eu le temps de regarder d'où pouvez provenir le problème, une histoire d'encodage en tout cas
Traceback (most recent call last):

File "metadator_fr.py", line 1127, in <module>
File "metadator_fr.py", line 289, in infos_ogr
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 15: ordinal not in range(128)

[Guts]

Bonjour

Je suis en train de tester l'outil. c'est très pratique.
J'ai importé le fichier XML dans Geosource. Ca a bien marché sauf l'étendue.

Par contre, lors du traitement, il récupère la liste d'attributs, qu'il met dans certains des fichiers exportés. Mais pas dans le XML.
Y aurait-il un moyen de récupérer dans Geosource le catalogue d'attributs, plutôt que de tout saisir? Parce que c'est vrai que ce serait un super gain de temps!

Merci

Merci du retour positif, ça fait toujours plaisir
Pour le catalogue d'attributs, j'y ai pensé mais en commençant à prendre des infos sur la norme iso 19110 qui correspond, j'ai appris que le catalogue d'attributs n'était pas lié en "dur" avec la fiche de métadonnées 19139. Trois conséquences :

1. lors de moissonnages, on perd complètement l'association entre les deux fichiers qui sont pourtant indissociables a priori
2. cela implique de récupérer des complications lors de l'export depuis Metadator et de l'import lors du catalogue, notamment pour la récupération de l'identifiant commun.
3. ça donne la désagréable impression de se taper tout ce travail pour rien...

Ceci étant dit, si le point 2 venait à se résoudre facilement, ce ne serait vraiment pas compliqué d'implanter cette fonctionnalité

Tiens j'avais dis que je te donnerai l'erreur ... je n'ai pas eu le temps de regarder d'où pouvez provenir le problème, une histoire d'encodage en tout cas
Traceback (most recent call last):

L'encodage c'est le mal, les caractères spéciaux et accents c'est pêché.
Cette loi établie, le traceback est un peu court sans son contexte . OS, version, depuis l'exe ou depuis la console, etc. Peux-tu m'en dire davantage stp ?

Sinon je suis en train de finaliser une nouvelle version. Je continue de poster ici ?

[gene]

En vous félicitant pour l'initiative, mais en tant que développeur Python, je ne peux que vous signaler que des problèmes de forme pour vous aider avant la publication du script, que je ne peux pas tester, n'étant pas sur Windows...(je n'examine que les sources). Votre script témoigne, paradoxalement, d'un mélange de débutant et de programmeur confirmé

1) métadonnées du script

• le script Python est fait exclusivement pour Windows du fait de l'utilisation du module win32com pour créer les fichiers docx. Le format docx étant un format XML, il y a d'autre modules plus universels (non liés à Windows, comme le module docx, http://pypi.python.org/pypi/docx/0.1.2) et les chemins des fichiers, windowsiens-> il faut le signaler
• Le script est fait pour une version supérieure à la 2.6 (min 2.7 visible par l'utilisation des import) -> il faut aussi le signaler

2) formalisme

• pour éviter les principaux problèmes d'encodage, il faut le préciser en tête des fichiers:

#!/usr/bin/env python
# encoding: utf-8 ou iso-8859-1 ou ...

• si l'encodage est utf-8, les u avant les chaînes de caractères sont inutiles
• si l'encodage n'est pas précisé, alors ce sera l'encodage par défaut du Windows utilisé qui sera appliqué, avec les problèmes qui vont se poser...
• plutôt que d'utiliser le module codecs, vous devriez utiliser la commande decode comme par exemple:

line = f.readline().decode('iso-8859-1')
ou
line = f.readline().decode('utf-8')

• les appels de module doivent être uniformisés:

from osgeo import ogr   
import osr 
from gdal import SetConfigOption

devraient être:

from osgeo import ogr 
from osgeo import osr
from osgeo.gdal import SetConfigOption

3) redondances
Il y a aussi des redondances comme:

• from dbfpy import dbf

alors que ce module est déjà utilisé par ogr, en partie, pour traiter les attributs. Vous devriez donc tout faire avec le module ogr sans utiliser le module dbfpy (ce qui est beaucoup plus facile puisque ogr facilite l'utilisation du module)

source = ogr.Open('my.shp', 1)
couche = source.GetLayer()
couche_defn = couche.GetLayerDefn()
champs = [couche_defn.GetFieldDefn(i).GetName() for i in range(couche_defn.GetFieldCount())]

4) oublis...

• vous utilisez le module elementtree pour traiter les données XML mais pourquoi alors ne pas utiliser aussi des modules pour traiter les fichiers HTML (comme Beautiful Soup) ? Ils vous permettraient de simplifier énormément votre script .
• Il y a même des modules qui permettent de transformer directement des fichiers XML en HTML comme 4Suite-XML (avec des feuilles de style XSLT).

5) recommandations

• Pour tout ce qui concerne les écritures - lectures de fichier, la commande with est recommandée plutôt que les close file etc.

It is good practice to use the with keyword when dealing with file objects. This has the advantage that the file is properly closed after its suite finishes, even if an exception is raised on the way. It is also much shorter than writing equivalent try-finally blocks:

(http://docs.python.org/tutorial/inputoutput.html)

• il est aussi très fortement recommandé de ne plus utiliser des d'expressions du genre:

i = 0
    while i < def_couche.GetFieldCount():
... 
  i = i+1

• sources de problèmes, qui doivent être remplacé par des itérateurs

En vous félicitant encore et en vous souhaitant une bonne continuation et une publication rapide. Quelques petits changements permettraient d'en faire un script Python universel, non lié à Windows.

[ckiko13]

Bonjour,

Personnellement je ne sais pas programmer, donc je ne me rends pas compte de la difficulté; et peut-être faudrait-il plutôt demander à l'équipe de Geosource comment récupérer le catalogue d'attributs à partir des fichiers que Metadator exporte.
Mais je me demandais s'il n'était pas possible d'avoir un fichier XML des attributs (de même que Metadator crée 2 onglets dans Excel), car dans Geosource, on peut avoir un édition XML du catalogue d'attributs; on pourrait imaginer pouvoir faire un copier-coller.

Bonne journée

[Guts]

Bonjour,

Étant géographe de formation, le monde du code m'est assez étranger, les encouragements, les remarques, retours et critiques, en plus bien organisés de la part d'un développeur, c'est que du bon à prendre ! Merci .

1) métadonnées du script

• le script Python est fait exclusivement pour Windows du fait de l'utilisation du module win32com pour créer les fichiers docx. Le format docx étant un format XML, il y a d'autre modules plus universels (non liés à Windows, comme le module docx, http://pypi.python.org/pypi/docx/0.1.2) et les chemins des fichiers, windowsiens-> il faut le signaler

Le programme est en effet destiné en premier lieu aux utilisateurs de windows, même si le code source peut s'adapter aux systèmes Unix (cf. documentation). Cela vient du fait que je l'ai développé dans un cadre pro précis pour lequel une utilisation "facile" était une exigence, la très grande majorité des utilisateurs lambda travaillant sur windows et dont les géomaticiens ne connaissent presque exclusivement que les solutions ESRI...

Pour ce qui est de PyDocx, comme j'en parlais dans ma 1ère réponse au sujet, j'ai abandonné l'idée pour des raisons de compatibilité plus grande avec le format .doc (le script ne convertit en .docx que si Office 2007 + est installé) mais aussi parce que PyDocx est lourd (PyYAML et PIL requis...).

Voilà pour ce qui est des justifications. Ceci étant dit, je pense à proposer un export en .odt et j'ai édité l'entête en conséquence pour indiquer le windows-friendly .

• Le script est fait pour une version supérieure à la 2.6 (min 2.7 visible par l'utilisation des import) -> il faut aussi le signaler

Corrigé

2) formalisme

• pour éviter les principaux problèmes d'encodage, il faut le préciser en tête des fichiers:

#!/usr/bin/env python
# encoding: utf-8 ou iso-8859-1 ou ...

• si l'encodage est utf-8, les u avant les chaînes de caractères sont inutiles
• si l'encodage n'est pas précisé, alors ce sera l'encodage par défaut du Windows utilisé qui sera appliqué, avec les problèmes qui vont se poser...
• plutôt que d'utiliser le module codecs, vous devriez utiliser la commande decode comme par exemple:

line = f.readline().decode('iso-8859-1')
ou
line = f.readline().decode('utf-8')

Postulat de départ : l'encodage est ma bête noire et est une source d'arrachage de cheveux très fréquente.
Mais je reste dubitatif sur partie de tes recommandations. D'après ce que j'ai retenu du livre de Gérard Swinnen, il me semblait que par défaut l'encodage était considéré comme celui dans lequel est encodé le fichier du script et, s'il n'est pas précisé, l'utf-8 est considéré. Bon, dans le doute, j'ai donc ajouté :

# -*- coding: UTF-8 -*-

... tout en haut du script et précisé dans l'entête :

# Encoding:    utf-8

Ensuite, personnellement, si j'enlève le u avant les "" cela ne fonctionne pas :

# -*- coding: UTF-8 -*-
#!/usr/bin/env python

print u'youpiño'
> youpiño

print 'youpiño'
 > youpiño

Pour le module codecs, je vais voir mais il est tout de même très pratique , notamment pour l'encodage en utf8 sans BOM.

• les appels de module doivent être uniformisés:

from osgeo import ogr   
import osr 
from gdal import SetConfigOption

devraient être:

from osgeo import ogr 
from osgeo import osr
from osgeo.gdal import SetConfigOption

Corrigé

3) redondances
Il y a aussi des redondances comme:

• from dbfpy import dbf

alors que ce module est déjà utilisé par ogr, en partie, pour traiter les attributs. Vous devriez donc tout faire avec le module ogr sans utiliser le module dbfpy (ce qui est beaucoup plus facile puisque ogr facilite l'utilisation du module)

source = ogr.Open('my.shp', 1)
couche = source.GetLayer()
couche_defn = couche.GetLayerDefn()
champs = [couche_defn.GetFieldDefn(i).GetName() for i in range(couche_defn.GetFieldCount())]

Alors d'un côté, j'ai déjà commencé à basculer les fonctions de stats sur les fonctions OGR mais alors de l'autre je ne savais pas du tout que dbfpy était intégré à la librairie !!! Ca vient donc de remonter dans l'ordre des priorités !

4) oublis...

• vous utilisez le module elementtree pour traiter les données XML mais pourquoi alors ne pas utiliser aussi des modules pour traiter les fichiers HTML (comme Beautiful Soup) ? Ils vous permettraient de simplifier énormément votre script .
• Il y a même des modules qui permettent de transformer directement des fichiers XML en HTML comme 4Suite-XML (avec des feuilles de style XSLT).

C'est là où le bât blesse : je ne suis pas du tout développeur et le code n'est donc pas du tout optimisé J'ai bien sûr entendu parler de Beautiful Soup mais cela me paraît très complexe alors du coup... Mais c'est clair que le recours à du templating html via xml notamment serait une grosse amélioration. Le but serait de basculer l'export en html en fonction également.

5) recommandations

• Pour tout ce qui concerne les écritures - lectures de fichier, la commande with est recommandée plutôt que les close file etc.

(http://docs.python.org/tutorial/inputoutput.html)

Je ne savais pas du tout. Ca tombe bien, je venais de voir l'article sur sam&max, un signe !

• il est aussi très fortement recommandé de ne plus utiliser des d'expressions du genre:

i = 0
    while i < def_couche.GetFieldCount():
... 
  i = i+1

• sources de problèmes, qui doivent être remplacé par des itérateurs

Ah...ah bon ?! mince, c'est pourtant très pratique de boucler avec un while et un incrément ! Tu aurais un lien vers une ressource expliquant pourquoi ?

En vous félicitant encore et en vous souhaitant une bonne continuation et une publication rapide. Quelques petits changements permettraient d'en faire un script Python universel, non lié à Windows.

Merci encore, en espérant pouvoir encore échanger. C'est vraiq eu ce serait bien de tendre au multiplateforme. Je vais essayer de garder l'objectif en tête.

Bonjour,

Personnellement je ne sais pas programmer, donc je ne me rends pas compte de la difficulté; et peut-être faudrait-il plutôt demander à l'équipe de Geosource comment récupérer le catalogue d'attributs à partir des fichiers que Metadator exporte.
Mais je me demandais s'il n'était pas possible d'avoir un fichier XML des attributs (de même que Metadator crée 2 onglets dans Excel), car dans Geosource, on peut avoir un édition XML du catalogue d'attributs; on pourrait imaginer pouvoir faire un copier-coller.

Bonne journée

Je me suis penché sur la structure du catalogue d'attributs (mon amour des ISO191** s'élargit de jour en jour...ou pas). Dès que j'ai un peu de temps, j'implémente une fonction mais sans le lien avec la métadonnée je pense, au moins dans un premier temps.

Merci de ton intérêt.