GeoTIFF reader/writer performance comparison
GeoTIFF reader/writer performance comparison Cet article est disponible en anglais uniquement. Apache Spatial Information System (SIS) version 1.4 contains a Cloud Optimized GeoTIFF (COG) reader for raster data. The development branch of Apache SIS 1.5 (not yet released at the time of writing this blog) contains also a GeoTIFF writer. Those reader and writer are implemented in pure Java code for avoiding the difficulty of bindings to native libraries such as GDAL. Pure Java code also provides more flexibility for Java developers. For example, the Apache SIS reader accepts any implementation of the Java ReadableByteChannel standard interface as the source of bytes. Another reason for developing GeoTIFF reader and writer in Java was for prototyping the use of new GeoTIFF keys that are proposed in OGC TestBed-19 — Geospatial in space. Coding yet another GeoTIFF reader and writer seems a duplication of work, since most of the geospatial world uses the popular GDAL library for that purpose. But actually, from Apache SIS perspective, there is not so much duplication. The most difficult part in a GeoTIFF reader and writer is to handle tiling and compression efficiently. But this task is largely format-independent, and SIS needs also to handle netCDF and other formats. The Apache SIS library shares code internally, thus reducing the task of GeoTIFF support to header parsing. By contrast, GDAL is largely an aggregation of independent libraries such as libtiff and libpng, each with their own ways to resolve common problems. Nevertheless, coding GeoTIFF support in Java raises questions about how its performances compare to GDAL. There is a widespread belief that Java programs are slower than their C/C++ counterpart. In reality, it depends a lot on the kind of application and how the libraries were coded. Differences in algorithms can play a bigger role than differences in the programming languages. This blog will not answer that debate, because the benchmarks presented here depend a lot on native code, either for I/O operations or for DEFLATE compression (the latter is handled by native code in the java.util.zip standard package). However, the benchmarks in this blog demonstrate the capability of a Java program to avoid adding overhead. The result is that Apache SIS, at least in those benchmarks, compares favorably with GDAL. Method The benchmarks reported in this blog are very limited and only scratch the surface on the topic of raster data handling: All benchmarks were tested with a single image (in two variants). Only one compression method tested (in two variants), together with uncompressed raster. No sub-regions and no sub-samplings tested (there is no technical reasons for this omission). Multi-thread parallelization not tested (would have required some more developments in Apache SIS). Sub-regions and requests for reduced resolutions on COG images should be handled efficiently by Apache SIS, but benchmarking those features would have required a more complex setup, especially if we want to test in a cloud environment. The simple benchmarks in this blog used a single image which was always read fully, from a local file on a laptop. The image was a single non-COG raster with the following properties: Raster Thumbnail Raster Properties Producer: DigitalGlobe Image date: 2014/06/16 File size: 192 Mb Image size: 8192 × 8192 pixels Strip size: 8192 × 128 pixels Sample model: banded (3 separated arrays of red, green and blue). Sample type: bytes, values ranging from 2 to 255. Compression: None CRS: WGS 84 / UTM zone 31N The image was read and rewritten using three libraries: gdal_translate, Java Image I/O and Apache SIS. For each library, the read/write operations were repeated 10 times in order to allow the Java Virtual Machine to warmup. The two first iterations were ignored, and execution time of the remaining 8 iterations were recorded. Average times and standard deviations are reported in this blog. In the particular case of the GDAL library, the execution time of gdalinfo has also been measured and its average value has been subtracted from all gdal_translate times. The intend is to take in account the time needed for loading the GDAL binary, or at least the parts required for reading the image header (it also incidentally includes the time for parsing that header). We apply this correction because our benchmark code relaunches the GDAL command in each iteration, contrarily to Image I/O and Apache SIS libraries which are loaded only during their first iteration. The benchmark code is available on GitHub in the GeoTIFF.java file. The processor of the test machine was Intel Core i7-8750H and the operating system was Fedora Linux 38 (Workstation Edition). Read and write operations were performed in the /tmp/ directory, which uses the tmpfs file system. It means that the raster files reside partially in RAM, so the benchmarks have less delay caused by I/O operations. Method with deflate compression The same tests were executed again with the DEFLATE compression. That compression is performed by the zlib library, accessible in standard Java thought the java.util.zip package. However, the zlib performance varies greatly depending on the data to compress. For fair comparisons, we must ensure that all the tested libraries write the same data. It is not the case by default because: GDAL and Java Image I/O change the sample model from « banded » to « pixel interleaved ». GDAL changes the strip height from 128 pixels to 1 pixel, thus writing strips of 8 kb. Java Image I/O changes the strip height from 128 pixels to 8 pixels, thus writing strips of 64 kb. Apache SIS keeps the sample model and strips height as they were in the image that was read. For avoiding those differences, the input image has been rewritten by Apache SIS with a « pixel interleaved » sample model and strips of 8 pixels in height. In addition, the -co BLOCKYSIZE=8 option has been passed to gdal_translate. A DEFLATE compression has been applied, so the tests will include decompression times in addition of compression times. Results First, we tested reading the uncompressed image and rewriting it uncompressed too. Average execution times are reported below. The « GDAL (reduced) » label means that the average execution time of gdalinfo has been subtracted from the execution time of gdal_translate. Apache SIS appears faster than other libraries for this particular benchmark. It may be because Apache SIS does not reorganize the pixel layout: it writes the image with banded sample model (called « planar configuration » in TIFF), as it was in the image that SIS has read. By contrast, GDAL and Image I/O reorganize the pixels into the pixel interleaved sample model. Note that for a Java application, the Java2D
Geomatys labellisé CNES PME
Depuis juin 2022, Geomatys est titulaire du label CNES PME pour une durée de trois ans, en récompense de son expertise en « standardisation de système d’information géospatiaux interopérables ». Attribué depuis 2020, et comme son nom l’indique, ce label est attribué aux PME innovantes et crédibles agissant dans le domaine du spatial.
Modélisation de la distribution des espèces next-level
Les modèles de répartition des espèces (MDS) sont des modèles statistiques et mécanistes utilisés pour définir la répartition géospatiale des espèces en fonction de la combinaison de variables écologiques (telles que l’environnement biotique et abiotique) offrant des conditions et des possibilités favorisant leur présence. En projetant les MDS sur des environnements futurs, les scientifiques peuvent déterminer où et quand ces conditions seront réunies pour fournir une prédiction de la répartition future des espèces. Ces prédictions sont souvent prévues des mois, des années ou des décennies à l’avance, et sont statiques en ce qui concerne à la fois l’algorithme et les occurrences prédites. Cependant, les facteurs qui affectent les espèces et leurs déplacements ne sont pas statiques. Imaginez que vous puissiez appliquer ces modèles à un monde en évolution en temps réel ! C’est précisément l’aide que nous apportons aux scientifiques en utilisant la technologie de traitement géospatial et de science des données à la volée EXAMIND de Geomatys. Lorsque les conditions environnementales changent, ou sont affectées par des perturbations telles qu’un ouragan ou des projets de développement qui perturbent les habitats actuels, des MDS à échelle fine peuvent être appliqués pour prédire comment les animaux se disperseront. En collaboration avec nos partenaires de la recherche et de l’industrie, nous travaillons à l’application de cette technologie en développement pour, par exemple, gérer les populations animales. Cette capacité deviendra essentielle dans presque tous les domaines, y compris la gestion de la biodiversité, car le changement climatique déstabilise les écosystèmes et les habitudes, et ainsi il perturbe les connaissances sur lesquelles nous nous appuyons actuellement pour prendre des décisions. Un projet dans lequel la technologie de Geomatys facilite ce travail est celui fait pour l’association française pour la gestion et la conservation du cheval de Przewalski, une espèce menacée (TAKH). L’association a présenté son portail Web alimenté par EXAMIND pour visualiser et analyser les populations de chevaux de Przewalski, appelé Shamane, lors du Congrès mondial de la nature de l’UICN de cette année, le 8 septembre 2021 à Marseille. Explorer le platform Shamane (https://takh.geomatys.com/) Bien que l’objectif soit de former des algorithmes d’apprentissage automatique qui puissent aider à prédire le comportement des chevaux en réponse à des facteurs environnementaux variant dans le temps, un travail préliminaire que nous ayons effectué pour faciliter ce projet a été de construire la base de données, en rassemblant des sources de données vastes et disparates, en assurant l’interopérabilité et en les rendant accessibles à l’utilisateur dans un seul environnement. Grâce aux nouvelles fonctionnalités disponible sur son socle EXAMIND en réponse aux besoins des chercheurs TAKH, les utilisateurs peuvent suivre des animaux individuels à travers le temps, basculer leur histoire et leur pedigree, explorer leurs habitats en 4D, interroger des ensembles de données connexes et lancer des analyses, le tout dans l’environnement de l’infrastructure de données spatiales de Shamane. L’outil permet donc non seulement d’analyser les données, mais aussi de fournir des renseignements permettant de prendre des décisions en temps réel en matière de surveillance et de gestion des populations. Vidéo teaser crée pour le TAKH par Les Fées Spéciales La vidéo teaser du projet Shamane ci-dessus illustre comment l’utilisateur peut suivre le mouvement de chevaux individuels génétiquement distincts (représentés par des couleurs différentes, souvent regroupés en troupeaux) dans une vue 3D du paysage. À l’aide du curseur situé en bas de la page, il peut suivre les changements de position des animaux ainsi que l’évolution de l’habitat dans le temps. Cela permet aux chercheurs de déterminer, par exemple, quels types de barrières d’habitat peuvent influencer les déplacements. Dans un prochain temps, ils vont pouvoir également superposer d’autres données, telles que des données météorologiques à cette vue et effectuer des analyses dans la barre latérale de gauche à l’aide d’un notebook de datascience. A priori, ces analyses visent à identifier les facteurs écologiques qui déterminent les comportements de déplacement des animaux afin de soutenir les stratégies de gestion des populations et d’autres efforts de conservation. Bien que l’outil soit disponible via un portail web, l’accès est limité aux utilisateurs autorisés, sécurisé avec la même technologie que celle utilisée par Geomatys dans le domaine de la défense. Ceci est important pour traiter des données sensibles, telles que la localisation précise d’espèces menacées. Cet outil fournit donc une plateforme performante et sécurisée pour gérer la conservation de ces populations fragiles.
Visualisation des conditions météo à la volée en réalité augmenté
Depuis quelques mois les équipes R&D de Geomatys travaillent sur l’exploitation de données GHOM (Géographiques, Hydrographiques, Océano et météo ) en réalité augmentée. L’enjeu étant de convertir, côté serveur à l’aide d’Examind-Server, des formats complexes tel que GRIB, NetCDF ou encore S-57, pour les servir en 3D sur un client Unity et de visualiser ces données à la volée avec des HolloLens. D’autres cas d’usages arrivent en particulier pour le monde maritime, nous vous les présenterons bientôt.
Datalakes geospatiaux : Un pas de plus pour faire face à l’augmentation des volumes de données brutes
Datalakes geospatiaux : Un pas de plus pour faire face à l’augmentation des volumes de données brutes 20/05/2021 user Dans le cadre de ses activités pour les acteurs du domaine Spatial et de l’Observation de la Terre, Geomatys a structuré ses activités selon trois axes : La mise en place et l’exploitation de Datalakes Geospatiaux (basé sur des infrastructure Cloud et exploitant des volumes massifs de donnée) La (Geo)Datascience La visualisation de données incluant la 3D et la réalité augmentée Cet article présente un retour d’expérience sur la mise en place de traitements à la volée sur un DataLake pour les besoins d’une agence spatiale. Que l’on soit en charge de la production et la collecte de données où en charge d’un DataLake et de l’analyse ultérieure de ces mêmes données, force est de constater que la quantité d’information produite ne cesse d’augmenter. Les segments sols et centres de mission scientifiques, n’échappent pas à cette tendance, en raison notamment des nouveaux instruments scientifiques avec de très hautes résolutions, entraînant des volumes de données à produire, stocker et transmettre toujours plus conséquents. Cependant, combien de données seront réellement utilisées au regard du volume de données brutes acquises ? Si l’on prend le cas du satellite optique Sentinel 2, une recherche sur la plateforme SciHub sur l’année 2020, indique que, tous types de produits confondus, un peu moins de 11 Millions de produits ont été générés cette année là et qu’ environ 1,7 millions possèdent une couverture nuageuse supérieure à 95 % soit la quasi totalité de l’image. Il est donc probable que plus de 15% des données acquises en 2020 ne soient jamais utilisées. Ce pourcentage peut varier en fonction du capteur à l’origine de la mesure (radar, optique…) mais le constat reste valable pour tous, un nombre non négligeable de données brutes ne sera pas utilisé pour produire des analyses. A ce pourcentage de données “non utilisables” s’ajoutent les données pour lesquelles la mesure est exploitable mais qui ne seront simplement pas utilisées par manque d’utilisateurs pour la zone ou la période. Pour le producteur (et le gestionnaire de DataLake) cela représente une quantité de données non négligeable (environ 1,7 PetaOctet de données par an. dans le cas de Sentinel 2). Dans le cas de chaînes de production complexes telles que les segments sols de satellite ce nombre peut être multiplié par le nombre de post-traitements que subit la donnée depuis la mesure brute (L0 ou L1) jusqu’à devenir un produit prêt à l’utilisation (L2 à L4). Toujours dans le cas Sentinel 2, trois post-traitements sont appliqués (niveau L1A, L1B et L1C) à la donnée avant d’obtenir une donnée de niveau L2, produite systématiquement. Finalement, ce sont donc plusieurs dizaines de Po de données qui ont été traitées et stockées et qui ne serviront pas. Outre que cela ne s’inscrit pas vraiment dans une démarche “GreenIT”, cela impacte également le coût de l’infrastructure matérielle. Passer d’un traitement systématique à une donnée prête à l’emploi (dans la mouvance de la démarche Analysis Ready Data) et produite à la demande, permettrait d’éviter cette sur-production inutile (note pour l’aspect GreenIT : nous laissons au futur résultat d’une étude ACV le soin de déterminer le point d’équilibre entre traiter deux fois une même image ou mettre le résultat en cache après la première demande, l’un consommant plus d’énergie ou l’autre nécessitant plus de disque dur). Aujourd’hui, cette approche “à la demande” est de plus en plus mise en œuvre pour des traitements à partir des données post-traités (production à la demande d’occupation des sols, de taux d’humidité comme pour le projet européen Phidias sur lequel Geomatrys est impliqué au côté de nombreux partenaires dont le CNES le CINES et l’IRD …), évitant ainsi tout ou partie de la production systématique. Cependant, la plupart des segments sols (du niveau L0 au niveau L2 dans le cas de Sentinel 2) reste sur une approche systématique malgré les quantités de données inutiles. Pourquoi ? Une raison possible, sans doute pas la seule, est qu’un des post-traitements essentiels consiste à projeter sur une grille régulière les mesures dérivées du signal capté par le satellite. La projection des données consiste à associer des valeurs du signal (le signal pour chaque pixels) de manière directe ou indirecte à des coordonnées géospatiales distribuées selon une grille régulière. Cela rend les données beaucoup plus faciles à exploiter que des valeurs distribuées de manière irrégulière. Or, l’algorithme de re-échantillonage à partir de ces simples valeurs est complexe et peut s’avérer coûteux en termes de performances. Depuis 2018, RESTEC (Remote Sensing Technology Center of Japan) société affiliée à l’Agence Spatiale Japonaise (JAXA), travaille avec Geomatys sur l’application de cette projection à la volée pour les données issues des satellites GCOM-C et W. Exemple de sortie d’un service Analysis Ready Data – WMS via Examind Dans l’exemple du GCOM-W, la donnée brute à laquelle est appliquée la projection à la volée correspond à une partie conséquente de l’orbite du satellite. La position de chaque pixel est exprimée en latitude et longitude pour chaque pixel, ainsi de l’équateur au pôle existe t’il une très grande variabilité dans la taille des pixels. L’objectif est donc de fournir à l’utilisateur un accès à la volée à des données prêtes à l’emploi (approche Analysis Ready Data), moins dépendant de la structure initiale des produits et, dans le cas de GCOM-W, de l’orbite du satellite. Pour cela, l’ensemble des données est indexé comme une couche spatio-temporelle unique (ou cube de données). Ainsi l’utilisateur peut télécharger l’emprise spatio-temporelle des données qu’il souhaite via des services standards (WCS ici) indépendamment de la structure des données acquises par le satellite. Proposer un tel service à la volée nécessite de disposer d’une opération de projection efficace. C’est sur cet aspect que nous avons concentré le gros de nos travaux durant 2 ans. Il est assez facile de déterminer les coordonnées géographiques (latitude et longitude) de chaque pixel lorsque ces coordonnées sont déclarées dans le fichier. Il est beaucoup plus difficile d’effectuer
Intelligence Artificielle – du hasard et de la nécessité
Intelligence artificielle : Du hasard et de la nécéssité “Vivre, c’est transformer en conscience une expérience aussi large que possible”disait André Malraux. Nos Intelligences Artificielles contemporaines, souvent fantasmées pour leurs capacités, sont bien loin de ces considérations. Il ne s’agit pas ici de nier, les résultats spectaculaires obtenus depuis le tournant des années 2010, dans le domaine des algorithmes d’apprentissage ou Machine Learning, dû en partie, d’une part à la démocratisation des capacités de calcul nécessaires à ces algorithmes et d’autres part au verrou de la dimensionnalité qu’ont su, si ce n’est résoudre, au moins grandement dégripper les réseaux de neurones convolutifs (ou CNN). La libération de ces verrous a trouvé des applications pour tous et dans tous les domaines , qui plus est de manière si rapide, que les capacités nouvelles de ces outils, ainsi mis en lumière, peuvent se transformer pour certains en miroir aux alouettes. Qui n’a pas entendu ou lu depuis quelques années des récits prophétiques où les robots bientôt rêveraient. A Geomatys, peut être en partie car un de ses fondateurs possédait un retour d’expérience notable sur ces outils manipulés durant sa thèse au milieu des années 2000, de leurs avantages et de leurs limites, nous avons dans un premier temps, regardé ce bel objet qu’étaient les réseaux de neurones convolutifs comme un prolongement de nos activités plutôt que comme un axe d’activité à part entière. Ainsi l’avons nous mis en en œuvre très tôt pour des besoins de classification d’objet dans des d’image satellites, où à d’autres fins mais sans pour autant en faire l’alpha et l’oméga de nos activités futures. Il faut sans doute y voir ici, un hasard conjoncturel où la connaissance de l’outil nous a empêché d’adhérer à la mythologie collective se mettant en place. Ainsi avons-nous continué à consolider nos fondamentaux quant à la maîtrise de la gestion de l’information spatiale pour les grosses infrastructures de données, cet outil étant un parmi tant d’autres. Or aujourd’hui, à la ville comme à la campagne, force est de constater qu’il y a les entreprises qui en sont et celles qui n’en sont pas. Nécessité faisant loi, nous faisons donc ici notre coming out communicationnel et présentons ci-après nos activités dans le domaine pour affirmer que oui, nous en sommes! Aujourd’hui l’IMINT mobilise grandement les réseaux de neurones convolutifs pour automatiser très efficacement les tâches de reconnaissances d’objets dans une image, et avec force données d’apprentissage cela fonctionne très bien eu égard aux types de corrélations spatiales qu’un CNN est capable de capturer. De nombreuses sociétés se sont donc positionnées sur ce segment d’activité. Ayant raté le premier train, nous avons donc décidé de construire nous même notre locomotive et de nous positionner sur ce que nous pensons constituer le gros du potentiel encore sous exploité du Machine Learning, et avons démarré depuis un an trois projets distincts sur chacun des domaines. Couplé aux 15 années d’expertises de Geomatys dans le domaine de l’interopérabilité, du traitement et des infrastructures massives de données géospatiales, et de consolidations de cette expertise dans sa gamme logiciel Examind, nous oeuvrons désormais à transformer nos expériences dans le domaine du machine learning en des fonctionnalités facilement re-mobilisables pour nos client. Ce n’est pas Malraux mais ce n’est pas mal non plus.
Geomatys begins work on OGC Testbed-16
The Open Geospatial Consortium (OGC) organizes a yearly Innovation Initiative (a “testbed”) where members collaborate to quickly prototype the latest solutions to geo-spatial data problems. Geomatys has begun working on this year’s initiative, Testbed-16, which will address Earth Observation Clouds; Data Integration, Interoperability & Analytics; Data Containers; and Security. The full scope of Testbed-16 is summarized in the following schematic: Geomatys will work on 2 components of the testbed workflow: one dealing with Jupyter Notebook and the other with Jupyter Kernel: Geomatys is working on a Datacube solution providing Java/Python API accessible through Jupyter and Zeppelin notebooks. Planned work : 1.Within Geomatys (extending beyond the Testbed objectives): 2. With other OGC Testbed-16 teams: 3. Specific contributions to the Testbed: Architecture of the thematic exploitation platform (TEP) 1 ADES (Application Deployment and Execution Service) is a single server-side component and it is in charge of all aspects pertaining to the deployment and execution of Earth Observation applications on different cloud providers 2 EMS (Execution Management Service) is in charge to validate user credentials, perform product search on OpenSearch Catalogue, transfer requests to the relevant ADES server and execute workflow, dispatching each step to differents ADES where are located the relevant data and merge all results provide by ADES More information: https://www.ogc.org/projects/initiatives/t-16
Geomatys en charge du catalogue Phidias
Le projet Phidias, débuté en octobre 2019, doit préfigurer la mise en place d’une infrastructure de données géospatiale Big Data et multi-thématiques. Il regroupe donc des partenaires aux compétences en calcul scientifique haute performance affirmé et les équipes informatiques d’infrastructure thématique (océanographie, surface continentale, atmosphère). A terme, l’infrastructure Phidias doit fournir un ensemble de services et d’outils interdisciplinaires basés sur des ressources HPC, mobilisables par les différents pôles et facilitant le croisement des données de chacune des infrastructures distantes. Dans ce cadre, Geomatys est en charge de la mise en place d’un catalogue au niveau de la fédération qui permet de découvrir les données des pôles et de solliciter les traitements et services disponibles. Chaque pôle est riche d’un très grand nombre de données, décrites et diffusées selon les pratiques usuelles du domaine, la découverte et l’utilisation des données à un plus haut niveau passent donc par un alignement des variables, unités de mesure et vocabulaire métier. Cet enjeux est en passe d’être résolu par l’utilisation d’ontologies et l’utilisation des derniers concepts en matière de technologie sémantique (JSON-LD…). L’objectif étant de disposer d’un catalogue présentant des ressources avec une description fournie après un enrichissement de vocabulaire automatique et contrôlé qui faciliteront leurs découvertes via des utilisateurs humain mais également leurs utilisations dans des chaînes de traitements complexes mobilisant des ressources multi-thématiques. D’autre post viendront illustrer ces éléments au fur et à mesure des avancées notables du projet. En savoir plus : Press Release : PHIDIAS Launch User-friendly Browsing Experience with HPC Service Access Portal
Valoriser ses données avec Examind Datacube
Chaque jour, nous engendrons des trillions d’octets de données de sources diverses : données satellitaires, géolocalisations, réseaux sociaux, e-mails, transactions, données météorologiques… Chacun contribue à cette accumulation de données en utilisant son Smartphone, effectuant des paiements, en se déplaçant, etc. Toutes ces données sont stockées. La quasi totalité sont localisables directement ou indirectement et l’ensemble constituent ce que l’on appelle le Big Data. Si les entreprises et gouvernements sont bien conscients des enjeux et des bénéficient qui peuvent être tirés de cette multitude d’informations, beaucoup peine à en extraire les analyses nécessaires à l’amélioration de leurs activités, qui plus est lorsqu’il s’agit d’exploiter utilement la dimension spatiale. Ces difficultés proviennent du volume et de l’hétérogénéité des données qui complexifient leur analyse. Or, chacun souhaiterait pouvoir analyser et produire des résultats instantanément pour répondre à ses problématiques. Quel sera l’impact écologique de la circulation dans ma ville demain, compte tenu de la météo, du trafic et des manifestations exceptionnelles prévus ce jour ? Comment appréhender les déplacements des populations d’éléphants de mer par rapport aux conditions environnementales ? Comment déployer les secours suite à un ouragan ? Aujourd’hui, les systèmes d’acquisition de données ouverts se multiplient dans le but de pouvoir produire des analyses toujours plus pertinentes. C’est le cas par exemple, du programme européen de surveillance de la Terre, Copernicus. Grâce à sa constellation de satellites, il permet de collecter une multitude de données sur les océans, la végétation, l’atmosphère, la bathymétrie, l’altimétrie, le climat… Toutes ces données hétérogènes sont librement accessibles aux entreprises et rendent possible la réalisation d’analyses précises à un endroit et un temps donné. Pour permettre l’accroissement des performances des gouvernements et entreprises, il faut donc pouvoir effectuer des analyses instantanées sur une multitude de données hétérogènes. Cela implique une accessibilité simple aux informations. C’est ainsi que les lacs de données « datalake » ont commencé à voir le jour. Ceux-ci regroupent une grande variété de données brutes hétérogènes. Cependant, rassembler ces données dans des « datalake » n’est pas suffisant, puisque la diversité des données rend difficile leur analyse. Il faut donc concevoir des moteurs d’analyse performant capable d’aller forer dans ces amas d’informations, tout en tenant compte de la dimension spatiale, pour en extraire des résultats pertinents. Tout cela de manière simple et instantanée. On voit donc émerger des solutions dites « Datacube ». Ces moteurs d’analyses sont capables de se connecter à de nombreuses sources de données variées, de les filtrer selon le type de données, la situation géographique, la fenêtre temporelle, l’unité de représentation, etc. et d’en extraire les informations nécessaires à une analyse très fine en extrayant facilement des sous-ensembles de données cohérents. Exploiter et valoriser les diverses données d’une entreprise devient beaucoup plus simple et rapide. On parle alors de Data intelligence, et de GeoIntelligence lorsqu’il est fait usage d’information géographique. Afin de répondre à la nécessité d’obtenir des analyses toujours plus rapidement sur des données toujours plus nombreuses, Geomatys a développé Examind Datacube, le moteur d’analyse Big Data géospatial. Déjà connecté à une base enrichie et mise à jour en continue qui regroupe les données en libre accès dites « OSINT » (Open Source Intelligence), Examind Datacube est également capable de se brancher aux sources de données de ses clients. Ainsi, cet outil permet grâce à des algorithmes d’explorer cette grande diversité de données et d’en extraire les analyses les plus pertinentes pour le client. Doté d’une capacité à exploiter et combiner avec précision une très grande variété et volumétrie de données spatiales et temporelles (trajectoires, modèles de prévisions météorologiques, rejeux d’évènements, capteurs, données satellites, données vecteurs dites froides…), Examind Datacube est capable d’effectuer ses analyses sans dupliquer la donnée et même, le cas échéant, en exploitant uniquement les métadonnées enrichies lors de la découverte du jeu de données. Ainsi, la solution requiert un espace de stockage moindre. Les résultats sont obtenus plus rapidement et optimisent les ressources en calcul nécessaires. Cet outil est entièrement développé par les équipes de Geomatys. Ce qui permet une évolution continue et maîtrisée. Il embarque un environnement logiciel qui permet de traiter des données géographiques ou non, et de proposer une variété de traitements tel que de l’algorithmie classique, du machine learning, des géostatistiques etc. Ces traitements peuvent être mis en œuvre aussi bien en environnement Java que Python. Des travaux dans le domaine des Linked-Data et du Web Sémantique sont en cours afin de faciliter l’analyse de ces données et d’améliorer leur enrichissement. Cet outil volontairement générique, peut donc s’adapter à n’importe quel domaine : Dans le contexte environnemental actuel, Examind Datacube peut par exemple, aider à suivre en temps réel les changements environnementaux en agrégeant les données climatiques, d’urbanisation, de terres cultivées, d’habitats naturels, de qualité de l’air ou de l’eau. Les décisions sont ainsi facilitées grâce à des analyses en quasi temps réel. Dans le domaine de la défense, la centralisation de données de sources hétérogènes comme les données géographiques, de réseaux sociaux, du dark et du deep web ou encore de traitement de langage peuvent permettre au gouvernement d’identifier des groupes terroristes ou des réseaux criminels afin de planifier les interventions nécessaires. Examind Datacube peut également servir lors des catastrophes naturelles. Dans un premier temps, pour en anticiper l’arrivée et permettre l’évacuation des zones les plus à risque. Puis, suite à la catastrophe, faciliter l’intervention des secours en identifiant les secteurs les plus touchés grâce à la combinaison des données météorologiques, démographiques, d’images drones, de réseaux sociaux et d’appels d’urgence. Finalement, Examind Datacube est un moyen de répondre efficacement, simplement et rapidement à vos problématiques d’aujourd’hui et de demain, en produisant des informations qualifiées issues du croisement de sources diverses.
Geomatys lauréat du challenge numérique « Nouveaux usages des données LITTO3D »
Le Pôle Mer Méditerranée et le SHOM en partenariat avec la BPI, la DGE et TVT Innovation lance un challenge sur les produits et services utilisant les données Litto3D. « Le produit Litto3D® est une base de données altimétrique unique et continue terre-mer donnant une représentation tridimensionnelle de la forme et de la position du sol sur la frange littorale du territoire français. » Geomatys vainqueur du challenge propose de développer un outil facilitant l’exploitation de données Litto3D : LittoToolbox ! Cet outil à destination des organismes impliqués dans l’aménagement du littoral offrira un service SAAS basé sur la plateforme Examind. Accessible sur abonnement il permettra aux utilisateurs de manipuler les données Litto3D et de les croiser avec d’autres données (Sentinel 1, 2 & 3, données météorologiques, données de capteurs in-situ…). Le projet vise à offrir un environnement de travail pour la manipulation de données de sources hétérogènes, accessible sur abonnement. Depuis cet espace, les utilisateurs disposent : Le projet consiste à adapter la plateforme Examind aux besoins spécifiques des acteurs de l’aménagement du littoral (bureaux d’études, offices de tourisme, ports, services étatiques…), afin de leur proposer un outil distant facilitant la manipulation et le croisement des données Litto3D. LittoToolbox s’appuiera sur la plateforme Examind Cloud structuré sous forme de micro-services pour la communication inter-modules (module de traitements deep-learning, module de stockage des données…). Ce projet est une belle illustration des possibilités d’Examind. Notre plateforme générique constitue une base solide pour tous vos développements d’applications métiers.