DATAtourisme

Nouveaux formats JSON et XML disponibles

Nous vous informons de la mise en production ce matin de deux nouveaux formats de données, disponibles dans votre interface diffuseur. Cette nouveauté fait suite aux suggestions des utilisateurs, collectées dans le cadre de notre dernier sondage en ligne.

"Fichiers JSON" : export compressé dans un format ZIP, composé de multiples fichiers JSON
• un fichier par POI, où l’intégralité de sa hiérarchie est détaillée
• un fichier d’index, reprenant la liste des POI inclus dans l’export + leur date de mise à jour (label + lastUpdateDatatourisme + file)
• un fichier de contexte Json-LD, permettant d’obtenir une version sémantique de chaque POI, pour les utilisateurs interessés.

"Fichiers XML" : export compressé dans un format ZIP, composé de multiples fichiers XML.
• un fichier par POI, où l’intégralité de sa hiérarchie est détaillée
• un fichier d’index, reprenant la liste des POI inclus dans l’export + leur date de mise à jour (label + lastUpdateDatatourisme + file)

Ces nouveaux formats présentent de nombreux avantages répondants à différents objectifs :
• Ils sont plus simples à exploiter : les données étant au format JSON ou XML classiques, complètes pour chaque POI
• Pour l’export composé de fichiers JSON, la complexité du web sémantique est externalisée dans un fichier context.json, optionnel pour le traitement des fichiers.
• Ils sont plus simples à traiter : les données étant contenues dans plusieurs fichiers, l’utilisateur n’a pas besoin de se préoccuper de la gestion de la mémoire propre au traitement de fichiers volumineux.
• Sur la base du fichier d’index, l’utilisateur peut facilement exécuter un différentiel pour connaître les POI qui ont été supprimés et ceux qui ont été mis à jour.
• La propriété file du fichier d’index, fournit le chemin (liste des dossiers ou « path ») et le nom du fichier concerné. Il n’est pas nécessaire de « scanner » les dossiers de l’archive.
• Ils sont plus simples à préparer côté serveur : il s’agit d’un assemblage de fichiers pré-calculé pour l’ensemble des flux

A noter : ces formats demandent davantage d’espace sur vos machines pour l’hébergement des données. A titre d’exemple, la base actuelle composée de 375.000 POI génère, pour le format « Fichiers JSON », un fichier compressé de 900 Mo soit 5 Go une fois décompressé.

Toute l’équipe DATAtourisme remercie @Simon_BLUM et @Julien_PERRON qui ont apporté leur aide à cette réalisation en étant bêta testeurs de ces nouveaux formats !

Merci pour le travail effectué pour fournir ces 2 nouveaux formats. D’après l’extrait, cela effectivement permettrait de faciliter les traitements. J’attends avec impatience la 1ère generation complete.

Juste une question à propos de la hiérarchie des folders extrait du fichier zip. Ne serait-il pas possible de les avoir tous au premier niveau plutôt que 0 > 0d > nnn.json, 0> 0c > mmm.json?

Merci.

Bonsoir,

Votre flux Fichiers Json est disponible (privilège de votre investissement sur le forum, j’ai lancé son traitement en avance).

Pour la hiérarchie des dossiers, ce n’est pas possible car les systèmes d’exploitation ne sont pas prévus pour fonctionner avec 370k fichiers dans un dossier.

Le principe est de se baser sur le fichier index qui contient la hiérarchie et le nom de fichier pour traiter les données. (Et ne pas parcourir les dossiers « à l’aveugle »)

Bonne découverte,
Cordialement.

Avoir le dc:identifier dans le fichier index pour chaque object serait un plus sinon pour chaque object on est obligé d’ouvrir le xml associé pour extraire le dc:identifier
Merci

Ah oui, effectivement :slight_smile:

OK, je vais regarder ça, merci.

Bonjour,

@Philippe_SERRA le dc:identifier est un identifiant unique à l’échelle du SIT qui fournit la donnée.
Il n’est pas unique sur l’ensemble des données DATAtourisme. (Qui regroupent les données de nombreux SIT)
L’identifiant unique pour le format json est @id (l’URI de la ressource, pour exemple: https://data.datatourisme.gouv.fr/3/00a6ed32-675a-33e6-85d1-0f604ec990f5), il est fournit dans le fichier index à travers le nom du fichier. (pour l’exemple cité : 3-00a6ed32-675a-33e6-85d1-0f604ec990f5.json)

Nous n’avons pas inclus le dc:identifier dans le fichier index afin d’éviter qu’il soit utilisé comme identifiant unique à l’échelle de la base DATAtourisme. Merci pour votre remarque, il vas falloir que nous clarifions la chose dans la documentation.
(Qui pour information se trouve ici -> https://info.datatourisme.gouv.fr/2018/04/09/documentation-application-diffuseurs-datatourisme)

Cordialement.

Oui c’est juste que utiliser une URI comme indentifiant unique dans un xml c’est étrange,
mettre 00a6ed32-675a-33e6-85d1-0f604ec990f5 ou 3-00a6ed32-675a-33e6-85d1-0f604ec990f5 me semblait plus judicieux (tout en gardant le champs 0/00/13-000249bc-89dc-3a23-bdb8-cce2252d43a7.xml)

Cordialement
Philippe

Après quelques essais, cette nouvelle solution serait effectivement beaucoup plus simple en traitements pour nous. Mais l’obstacle restant est l’impossibilité pour nous de dé-zipper et stocker 900MB + 5GB de fichiers en serverless avant traitement. Nous faisons tout en serverless et streaming, on lit un element du fichier flux et on le traite, ce qui demande très peu de mémoire RAM et de CPU et 0B de disque. Le format ZIP est apparemment difficilement streamable et l’espace de stockage est en fait alloué en mémoire RAM en serverless, il nous faudrait dimensionner une function avec plus de 6GB RAM, ce qui n’est pas possible.

Pour nous, la solution serait d’avoir un flux en fichier JSON, ou une query RDF-SPARQL pour un flux qui retourne un array d’elements JSON, équivalent à la concaténation de tous les fichiers .json contenus dans le fichier ZIP de 5GB.

Est-ce que c’est possible? Sinon nous devrons garder le traitement des CSV ou JSON-LD habituels, ce que nous ne souhaitons pas particulièrement vu les traitements plus nombreux à appliquer.

Merci.

Fred Janon

Bonjour
Il n’est pas prévu de créer de nouvelles modalités de diffusion de données pour le moment. Vous pourriez télécharger et stocker les fichiers JSON sur un hébergement distinct et ne traiter que les fichiers vous intéressant à partir de l’index fourni?..
(Les fichiers mis à disposition ne sont mis à jour qu’une fois par jour, cela vous laisse le temps de faire cette opération sur 24h)
Bonne journée

Bonjour @Philippe_SERRA,

Je comprend parfaitement qu’utiliser une URI comme identifiant peut paraitre étrange. C’est d’ailleurs pour cela que nous avons utilisé « uniquement » la partie unique des URI pour nommer les fichiers dans ce nouveau format. Et pourtant c’est le but initial d’une URI (https://fr.wikipedia.org/wiki/Uniform_Resource_Identifier) et plus concrètement un principe fondateur du format RDF (https://fr.wikipedia.org/wiki/Resource_Description_Framework).

Cordialement.

Quid d’une query RDF-SPARQL pour créer un flux qui génère cet array d’objets JSON? Nous n’avons pas besoin de l’index.

Nous n’utilisons plus de serveurs dédiés depuis 2014, tout tourne en serverless, streaming and queues/notifications.

Bonjour,

Serait-il possible de compresser avec tar? Apparemment tar serait streamable contrairement a zip?

Je n’ai pas eu encore le temps de faire un PoC mais ce serait peut-être une solution simple. Il pourrait y avoir un fichier comprimé avec zip pour les utilisateurs existants et un format tar?

Merci

Bonjour,

Un PoC a confirmé que le format .tar est streamable. Donc le même contenu du fichier .zip en .tar (pas tgz puisque gzippé par le serveur de toute manière) serait la solution pour avoir des applications qui requièrent seulement quelques MB de RAM sans les 7-8GB d’espace disque, idéal pour le serverless.

Est-ce que cela serait envisageable? Cela nous permettrait d’abandonner les fichiers .csv pour les .json et gagner beaucoup de traitements.

Merci d’avance.

« Tape archives (tar) are a file format for storing a sequence of files that can be read and written in a streaming manner »

Pour vous l’identifiant est
00a6ed32-675a-33e6-85d1-0f604ec990f5
ou
3-00a6ed32-675a-33e6-85d1-0f604ec990f5 ?
Merci