Le portail francophone de la géomatique

Canaux

3458 éléments (6 non lus) dans 55 canaux

Dans la presse

• Décryptagéo, l'information géographique
• Cybergeo
• Revue Internationale de Géomatique (RIG)
• SIGMAG & SIGTV.FR - Un autre regard sur la géomatique
• Mappemonde

Du côté des éditeurs (1 non lus)

• Imagerie Géospatiale
• Toute l’actualité des Geoservices de l'IGN
• arcOrama, un blog sur les SIG, ceux d ESRI en particulier (1 non lus)
• arcOpole - Actualités du Programme
• Géoclip, le générateur d'observatoires cartographiques
• Blog GEOCONCEPT FR

Toile géomatique francophone (5 non lus)

• Géoblogs (GeoRezo.net)
• Conseil national de l'information géolocalisée
• Geotribu (1 non lus)
• Les cafés géographiques
• UrbaLine (le blog d'Aline sur l'urba, la géomatique, et l'habitat)
• Icem7
• Séries temporelles (CESBIO) (1 non lus)
• Datafoncier, données pour les territoires (Cerema)
• Cartes et figures du monde
• SIGEA: actualités des SIG pour l'enseignement agricole
• Data and GIS tips
• Neogeo Technologies (1 non lus)
• ReLucBlog
• L'Atelier de Cartographie
• My Geomatic
• archeomatic (le blog d'un archéologue à l’INRAP)
• Cartographies numériques (1 non lus)
• Veille cartographie
• Makina Corpus
• Oslandia (1 non lus)
• Camptocamp
• Carnet (neo)cartographique
• Le blog de Geomatys
• GEOMATIQUE
• Geomatick
• CartONG (actualités)

Géomatique anglophone

• Planet Geospatial - http://planetgs.com
• Google Maps Mania
• All Points Blog
• Directions Media - Podcasts
• Navx
• James Fee GIS Blog
• Open Geospatial Consortium (OGC)
• Planet OSGeo

Blogs GeoRezo.net

• Parcell'air
• Le coin de l'open-source géospatial
• INSPIRE by clouds
• Les GéoBlogs
• Infobulle
• Le blog SIG & URBA
• Blog Interopérabilité & GéoInformation

Neogeo Technologies (1 non lus)

• 09 July 2024
• 8:38

  Naviguer dans l’Ère des Tuiles Vectorielles : Techniques et Applications

  sur Neogeo Technologies
  C’est quoi une tuile ?

  Pour diffuser des données spatiales sur une carte, il existe différents formats de données dont celui de la tuile vectorielle qui apporte de nouvelles possibilités d’affichage de données (rapidité d’accès à la donnée, facilité de modification du style, interaction directe des utilisateurs avec les objets).

  En effet, une carte numérique peut théoriquement afficher des données à n’importe quelle échelle et à n’importe quel endroit, mais cette flexibilité peut poser des problèmes de performance.

  La mosaïque de tuiles améliore la vitesse et l’efficacité d’affichage :

  • En limitant les échelles disponibles. Chaque échelle est deux fois plus détaillée que la précédente.
  • En utilisant une grille fixe. Les zones que l’on souhaite afficher sont composées de collections de tuiles appropriées.

  

  La plupart des systèmes de tuiles commencent avec une seule tuile englobant le monde entier, appelée « niveau de zoom 0 », et chaque niveau de zoom suivant augmente le nombre de tuiles par un facteur de 4, en doublant verticalement et horizontalement.

  Coordonnées des tuiles

  Chaque tuile d’une carte en mosaïque est référencée par son niveau de zoom, sa position horizontale et sa position verticale. Le schéma d’adressage couramment utilisé est XYZ.

  Voici un exemple au zoom 2 :

  

  On va récupérer la tuile à l’aide de l’adressage XYZ suivant :

  http://server/{z}/{x}/{y}.format

  Par exemple, vous pourrez voir la tuile image de l’Australie à l’adresse suivante, c’est le même principe pour les tuiles vectorielles : [https:]]

  Principe d’une tuile vectorielle

  Les tuiles vectorielles ressemblent aux tuiles raster, mais à la place d’une image, elles contiennent des données permettant de décrire les éléments qui la composent avec des tracés vectoriels. Au lieu d’avoir des ensembles de pixels, il y a donc des ensembles de coordonnées de points, auxquels on peut associer plusieurs informations attributaires.

  Comme leurs cousines raster, les tuiles vectorielles peuvent être mises en cache, côté serveur et côté navigateur, et permettent de naviguer dans des cartes immenses rapidement, même sur des terminaux légers.

  Comment l’utilise-t-on ? Produire des tuiles vectorielles à la volée depuis PostGIS

  Il existe différentes briques pour publier des données à la volée depuis PostGIS, voici notre sélection :

  • pg_tileserv => [https:]] : c’est un serveur de tuile codé en GO et produit par Crunchy Data. On va préférer utiliser la version dockerisée dans nos applications => [https:]]
  • Martin => [https:]] : très similaire à pg_tileserv, codé en RUST et produit par MapLibre.
  • GeoServer : permet également de générer des tuiles vectorielles

  Dans le cadre de ce blog, nous resterons sur l’utilisation de pg_tileserv.

  pg_tileserv

  Par défaut, pg_tileserv permet de produire des tuiles vectorielles à partir des tables géographiques qui sont dans la base de données.

  

  Tout l’intérêt d’utiliser un outil comme pg_tileserv réside dans la génération de tuiles produites à partir d’une analyse plus fine.

  Voici un exemple de requête que l’on peut utiliser pour afficher une donnée cartographique. Cette requête va permettre de simplifier la géométrie en fonction du seuil de zoom et filtrer la donnée en fonction de l’opérateur et de la techno.

  CREATE OR REPLACE FUNCTION generate_couvertures_tiles(
    z integer,
    x integer,
    y integer,
    in_operateur bigint,
    in_techno character varying)
      RETURNS bytea
      LANGUAGE 'plpgsql'
      COST 100
      VOLATILE PARALLEL UNSAFE
  AS $BODY$
  
  #variable_conflict use_variable
  begin
    return (
      WITH
      bounds AS (
        SELECT ST_TileEnvelope(z, x, y) AS geom,
       (CASE
        when z >= 12 then 0
        when z = 11 then 0
        when z = 10 then 10
        when z = 9 then 100
        when z = 8 then 300
        when z = 7 then 900
        when z = 6 then 1500
        when z <= 5 then 3000
        ELSE 1 END
         ) as simplify_tolerance
      ),
  
      mvtgeom AS (
        SELECT fid, operateur, date, techno, usage, niveau, dept, filename,
        ST_AsMVTGeom(
            ST_Simplify(t.geom,simplify_tolerance), bounds.geom) AS geom
  
        FROM couverture_theorique t, bounds
        WHERE ST_Intersects(t.geom, bounds.geom )
        and operateur = in_operateur
        and techno = in_techno
      )
      SELECT ST_AsMVT(mvtgeom)
      FROM mvtgeom
    );
  end;
  $BODY$;

  Pour appeler cette fonction, on va utiliser l’url formatée de la manière suivante :

  https://hostname/tileserv/public.generate_couvertures_tiles/{Z}/{X}/{Y}.pbf?in_operateur=28020&in_techno=3G

  Vous voilà en mesure de faire parler votre imagination pour récupérer les données que vous souhaitez et répondre aux besoins de votre carte.

  On peut penser à la création de Cluster, d’analyse thématique, d’agrégation de couche ou que sais-je.

  Et la performance dans tout ça ?

  Toute cette liberté acquise va nous plonger dans des requêtes de plus en plus complexes et donc nous apporter une performance dégradée. Si chaque tuile prend 10 secondes à se générer, l’expérience utilisateur sera mauvaise.

  Pour remédier à ce contretemps, rappelons-nous que la tuile vectorielle repose sur une grille fixe. Il est donc possible de générer du cache (mise en cache). Cool ! mais comment fait-on cela ?

  C’est parti :

              1 – Créer une table de cache de tuiles

  CREATE TABLE IF NOT EXISTS tiles_cache
  (
      z integer NOT NULL,
      x integer NOT NULL,
      y integer NOT NULL,
      operateur bigint NOT NULL,
      techno character varying COLLATE pg_catalog."default" NOT NULL,
      mvt bytea NOT NULL,
      CONSTRAINT tiles_pkey PRIMARY KEY (z, x, y, operateur, techno)
  )

  2 – Générer le cache

  Pour générer le cache, dans un premier temps on récupère les grilles sur lesquelles on a des données. Le seuil de zoom maximum (max_zoom) peut être défini dans la fonction suivante.

  CREATE OR REPLACE FUNCTION gettilesintersectinglayer(
    liste_operateur bigint,
    liste_techno character varying)
      RETURNS TABLE(x integer, y integer, z integer)
      LANGUAGE 'plpgsql'
      COST 100
      VOLATILE PARALLEL UNSAFE
      ROWS 1000
  
  AS $BODY$
  DECLARE
    tile_bounds public.GEOMETRY;
    max_zoom INTEGER := 7;
  BEGIN
    FOR current_zoom IN 1..max_zoom LOOP
      FOR _x IN 0..(2 ^ current_zoom - 1)
      LOOP
        FOR _y IN 0..(2 ^ current_zoom - 1)
        LOOP
          tile_bounds := ST_TileEnvelope(current_zoom, _x, _y);
          IF EXISTS (
            SELECT 1 FROM couverture_theorique
            WHERE ST_Intersects(geom, tile_bounds)
            AND operateur = liste_operateur
            AND techno = liste_techno
          )
          THEN
            RAISE NOTICE 'Traitement %', current_zoom || ', ' || _x || ', ' || _y;
            z := current_zoom;
            x := _x;
            y := _y;
            RETURN NEXT;
          END IF;
        END LOOP;
      END LOOP;
    END LOOP;
  END;
  $BODY$;

  À l’aide de ce tableau de grilles, on va générer l’ensemble des tuiles et les injecter dans la table de cache.

  with oper as (
    SELECT distinct operateur from couverture_theorique
  ),
  techno as (
    SELECT distinct techno from couverture_theorique
  )
  insert into tiles_cache_couverture(z, x, y, operateur, techno, mvt)
  select tile.z, tile.x, tile.y, oper.operateur,  techno.techno,
  generate_couvertures_tiles(tile.z, tile.x, tile.y, oper.operateur, techno.techno)
  from techno, oper, GetTilesIntersectingLayer(operateur, techno) as tile;

              3 – Le rendu mixte cache ou requête

  Une fois que les tuiles sont insérées dans la table de cache, lorsque l’on va vouloir récupérer la tuile, il va falloir aiguiller la recherche pour que la fonction aille soit récupérer la tuile dans la table de cache ou la générer à la volée.

  CREATE FUNCTION couvertures(z integer, x integer, y integer, liste_operateur integer[], liste_techno character varying[]) RETURNS bytea
      LANGUAGE plpgsql
      AS $$
  
  #variable_conflict use_variable
  begin
    if (z <= 7 and array_length(liste_operateur,1) = 1) then
      return (
        SELECT mvt
        from tiles_cache_couverture
        Where tiles_cache_couverture.x=x
          AND tiles_cache_couverture.y=y
          AND tiles_cache_couverture.z=z
          and operateur = any(liste_operateur)
          and techno = any(liste_techno)
      );
    else
      return (
        WITH
        bounds AS (
          SELECTST_TileEnvelope(z, x, y) AS geom,
         (CASE
          when z >= 12 then 0
          when z = 11 then 0
          when z = 10 then 10
          when z = 9 then 100
          when z = 8 then 300
          when z = 7 then 900
          when z = 6 then 1500
          when z <= 5 then 3000
          ELSE 1 END
           ) as simplify_tolerance
        ),
  
        mvtgeom AS (
          SELECT fid, operateur, date, techno, usage, niveau, dept, filename,
          public.ST_AsMVTGeom(
             ST_Simplify(t.geom,simplify_tolerance), bounds.geom) AS geom
  
          FROM couverture_theorique t, bounds
          WHEREST_Intersects(t.geom, bounds.geom )
          and operateur = any(liste_operateur)
          and techno = any(liste_techno)
        )
        SELECTST_AsMVT(mvtgeom)
        FROM mvtgeom
      );
    end if;
  end;
  $$;

  Maintenant en appelant la couche « couvertures » dans pg_tileserv, sur les zooms les plus petits (inférieur à 8), et donc les plus gourmands pour calculer la simplification géométrique, nous allons utiliser le cache de tuiles. Cependant, lorsque l’on sera relativement proche, on va utiliser la génération des tuiles à la volée car les performances sont bonnes.

  Pour les plus ardus, je vous mets un petit bonus. Un exemple de couche cluster générée coté base de données. Le cluster va s’adapter au seuil de zoom, pour clustériser au niveau départemental, puis communal, puis sous forme de cluster naturel (St_ClusterDBSCAN) avec un espacement dynamique pour chaque seuil de zoom, et enfin un affichage par objet quand on est très proche. On aurait pu imaginer un cluster en nid d’abeille que je trouve plus efficace car le problème du cluster de PostGIS, c’est qu’il va être calculé dans l’emprise de chaque tuile. Cela signifie qu’il découpe des clusters de façon arbitraire quand on a une densité importante entre 2 tuiles.

  CREATE FUNCTION cluster_filtres(z integer, x integer, y integer, filtres text[]) RETURNS bytea
      LANGUAGE plpgsql
      AS $_$
  
  #variable_conflict use_variable
  DECLARE
    query text;
    result bytea;
  begin
    --MISE EN PLACE DES FILTRES
  
    if ( z < 9) then
      --Vue par departement
      query := '
        WITH
        bounds AS (
          SELECT ST_TileEnvelope($1, $2, $3) AS geom
        ),
        item_fitler AS (
          --On récupère nos données filtrées
          SELECT distinct t.id
          FROM table t
          WHERE ' || filtres || '
        ),
        tot_dept AS (
          select code_departement, count(1) as tot_item
          from departement d
          INNER JOIN table t ON ST_Intersects(d.geom, t.geom )
          INNER JOIN item_fitler ON item_fitler.id = t.id
          group by code_departement
        ),
        mvtgeom AS (
          SELECT tot_dept.code_departement, tot_dept.tot_item,
          ST_AsMVTGeom(ST_PointOnSurface(tot_dept.geom), bounds.geom) AS geom
          FROM tot_dept
          INNER JOIN bounds ON ST_Intersects(tot_dept.geom, bounds.geom )
          WHERE tot_item is not null
        )
        SELECT ST_AsMVT(mvtgeom)
        FROM mvtgeom
      ';
      --RAISE NOTICE 'Calling query (%)', query;
      EXECUTE query INTO result USING z, x, y, filtres;
          return result;
     
    elsif ( z <= 10) then
      --Vue par commune, On ajoute un buffer pour récupérer les items autour de la tuile sans devoir le faire sur la France entière
      query := '
        WITH
        bounds AS (
          SELECT ST_TileEnvelope($1, $2, $3) AS geom
        ),
        item_fitler AS (
          --On récupère nos données filtrées
          SELECT distinct t.id
          FROM table t
          INNER JOIN bounds ON ST_Intersects(t.geom, ST_Buffer(bounds.geom, 10000) )
          WHERE ' || filtres || '
        ),
        tot_com AS (
          select insee_com, count(1) as tot_item
          from commune c
          INNER JOIN table t ON ST_Intersects(c.geom, t.geom )
          INNER JOIN item_fitler ON item_fitler.id = t.id
          group by insee_com
          having count(1) > 0
        ),
        mvtgeom AS (
          SELECT tot_com.insee_com, tot_com.tot_item,
          ST_AsMVTGeom(ST_PointOnSurface(tot_com.geom), bounds.geom) AS geom
          FROM tot_com
          INNER JOIN bounds ON ST_Intersects(tot_com.geom, bounds.geom )
          WHERE tot_item is not null
        )
        SELECT ST_AsMVT(mvtgeom)
        FROM mvtgeom
      ';
      --RAISE NOTICE 'Calling query (%)', query;
      EXECUTE query INTO result USING z, x, y, filtres;
          return result;
     
    elsif ( z <= 15) then
      --Vue par cluster
      query := '
        WITH
        bounds AS (
          SELECT ST_TileEnvelope($1, $2, $3) AS geom
        ),
        item_fitler AS (
          --On récupère nos données filtrées
          SELECT distinct t.id
          FROM table t
          INNER JOIN bounds ON ST_Intersects(t.geom, bounds.geom )
          WHERE ' || filtres || '
        ),
        clustered_points AS (
          SELECT ST_ClusterDBSCAN(t.geom, eps :=
            (CASE
              when $1 = 11 then 500
              when $1 = 12 then 385
              when $1 = 13 then 280
              when $1 = 14 then 150
              when $1 = 15 then 75
              ELSE 1 END
            ) , minpoints := 1) over() AS cid,
          t.fid, t.geom
          FROM table t
          INNER JOIN item_fitler s ON s.id = t.id
          group by t.id, t.geom
        ),
        mvtgeom AS (
          SELECT cid, array_agg(id) as ids,
          count(1) as tot_item,
          ST_AsMVTGeom(ST_PointOnSurface(ST_Collect(c.geom)), bounds.geom) AS geom
          FROM clustered_points c, bounds
          WHERE ST_Intersects(c.geom, bounds.geom )
          group by cid, bounds.geom
        )
        SELECT public.ST_AsMVT(mvtgeom)
        FROM mvtgeom
      ';
      RAISE NOTICE 'Calling query (%)', query;
      EXECUTE query INTO result USING z, x, y, filtres;
          return result;
    else
      --vue par objet
      query := '
        WITH
        bounds AS (
          SELECT ST_TileEnvelope($1, $2, $3) AS geom
        ),
        item_fitler AS (
          --On récupère nos données filtrées
          SELECT distinct t.id
          FROM table t
          INNER JOIN bounds ON ST_Intersects(t.geom, bounds.geom )
          WHERE ' || filtres || '
        ),
        mvtgeom as (
          SELECT ST_AsMVTGeom(t.geom, bounds.geom) AS geom, t.id
          FROM item_fitler t , bounds
          WHERE ST_Intersects(t.geom, bounds.geom )
        )
        SELECT ST_AsMVT(mvtgeom)
        FROM mvtgeom
      ';
      EXECUTE query INTO result USING z, x, y, filtres;
          return result;
    end if;
  end;
  $_$;

  Finalement quels avantages ? Fond de plan

  Dans les choix des fonds de plan, les avantages sont multiples.

  On peut assez facilement personnaliser un fond de plan en modifiant les paramètres d’affichage que l’on souhaite utiliser pour chaque élément. Pour faire cela, on peut s’appuyer sur des fichiers de style comme ceux proposés par Etalab : [https:]] .

  Si l’on héberge soit même les fichiers de style, on peut les modifier pour choisir le style des éléments. Voici à quoi ressemble le paramétrage d’un élément issu d’une tuile vectorielle :

      {
        "id": "landuse-commercial",
        "type": "fill",
        "source": "openmaptiles",
        "source-layer": "landuse",
        "filter": [
          "all",
          ["==", "$type", "Polygon"],
          ["==", "class", "commercial"]
        ],
        "layout": {
          "visibility": "visible"
        },
        "paint": {
          "fill-color": "hsla(0, 60%, 87%, 0.23)"
        }
      },

  Il est par exemple possible d’extruder les bâtiments si on souhaite obtenir un rendu 3D

  

  L’affichage vectorielle permet également d’afficher les libellés / icônes toujours dans le bon sens de lecture.

  Choix de l’ordre d’affichage des couches

  Ensuite il est intéressant de rappeler qu’il est possible de modifier l’ordre d’affichage des couches qui sont issues du fond de plan et des couches métiers, ce qui n’est pas possible avec les fonds de plan de type WTMS. On peut donc faire ressortir les libellés des communes sur une couche métier.

  Couche vectorielle

  La couche étant vectorielle, il est également possible de récupérer des attributs de celle-ci.

  Outil de d’édition du style

  Il existe plusieurs outils permettant de modifier le style des données vectorielles. Cependant je vous conseille maputnik qui est très complet et accessible => [https:]]

  Conclusion

  En conclusion, les tuiles vectorielles représentent une avancée significative dans la diffusion et l’affichage de données spatiales, et permettent de créer des applications cartographiques avancées. Encore faut-il les intégrer dans des outils robustes et des méthodologies performantes, afin de répondre aux besoins croissants de précision et de réactivité. La technologie des tuiles vectorielles est essentielle pour le futur de la cartographie numérique, offrant un équilibre entre performance, flexibilité et interactivité.

  Pistes futures ?

  L’authentification et les rôles à travers pg_tileserv. On pourrait imaginer dans un futur blog, comment fusionner l’authentification via un token, le service pg_tileserv et la sécurité de PostgreSQL avec le Row Level Sécurity. Cela permettrait de gérer les droits au niveau de l’objet et nativement dans PostgreSQL.

  Rédacteur : Matthieu Etourneau

• 27 June 2024
• 16:45

  Neogeo est ravie d’annoncer la date de ...

  sur Neogeo Technologies

  Neogeo est ravie d’annoncer la date de son tout premier séminaire dédié à OneGeo Suite, la solution web open source permettant de partager, diffuser et valoriser les données cartographiques d’un territoire.

  Il s’agit d’une opportunité unique aussi bien pour les utilisateurs, que pour ceux qui contribuent aux développements mais aussi les passionnés qui veulent découvrir la solution, les dernières fonctionnalités mises en œuvre, d’approfondir leurs connaissances, et de se connecter avec les différents membres de la communauté.

  Cet événement promet d’être un véritable catalyseur pour ceux qui souhaitent exploiter tout le potentiel OneGeo Suite.

  Ce séminaire a pour but de :

  • Présenter les nouvelles fonctionnalités : Découvrez les innovations et mises à jour récentes de OneGeo Suite,
  • Favoriser les échanges : Échangez avec les autres utilisateurs, les développeurs, et experts du domaine,
  • Inspirer et motiver : Bénéficier et partager de retours d’expériences des utilisateurs et des cas d’utilisation inspirants,
  • Fournir des échanges approfondis : Au travers d’ateliers sur les nouveaux usages, services, connecteurs, la visualisation des données, les performances et limites actuelles des plateformes OGS…

  Programme de la Journée Pourquoi Participer ?

  Participer à ce séminaire vous permettra de :

  • Accéder à des informations exclusives : Soyez parmi les premiers à découvrir les dernières fonctionnalités et la road map de la solution,
  • Améliorer vos connaissances : Grâce aux présentations et aux ateliers,
  • Réseauter avec les membres de la communauté du secteur : Élargissez votre réseau et partagez des idées avec d’autres utilisateurs et experts.
  • Obtenir des réponses à vos questions : Interagissez directement avec les développeurs et les formateurs de la solution.

  Inscription

  Pour participer à ce séminaire exceptionnel, inscrivez-vous dès maintenant –> lien.

  Les inscriptions sont gratuites et obligatoires, ne tardez pas à réserver votre place.

  En conclusion

  Ne manquez pas cette occasion, en amont des Géodatadays 2024, afin de consolider vos connaissances et de renforcer votre utilisation de OneGeo Suite. Rejoignez-nous pour une journée riche en apprentissage, en échanges et en inspiration.

  Nous sommes impatients de vous accueillir et de partager ce premier séminaire OneGeo Suite à vos côtés.

  L’équipe OneGeo Suite

• 17 June 2024
• 10:17

  Mon premier réseau de neurones

  sur Neogeo Technologies

  Pour mieux comprendre l’article sur les réseaux de neurones, cette semaine nous vous proposons de coder un petit réseau de neurones de façon à mieux comprendre ce que sont les poids, le feed forward et les autres notions introduites dans l’article précédent.

  Nous allons réaliser un réseau de neurones à 1 neurone et essayer de lui faire prédire des données placées sur une droite. Cet exercice est trivial, on peut le résoudre sans utiliser d’IA mais restons un peu humble pour commencer.

  Préparation du projet

  Utilisons Jupyter qui reste l’outil de prédilection pour tester et développer une IA.

  # On crée un environnement virtuelle python, et on l'active
  python3 -m venv test_ia
  cd test_ia
  . bin/activate
  
  # On installe jupyter et on le lance
  pip install jupyter
  jupyter notebook

  Cette dernière commande ouvrira Jupyter dans votre navigateur.

  

   

   

   

   

   

   

  Vous pourrez aller dans “File” -> “New” -> “Notebook” pour créer un nouveau fichier et copier/tester notre programme.

  

  De quoi avons-nous besoin ?

  Numpy, c’est une bibliothèque Python optimisée pour la gestion de listes.

  NB : il y a un point d’exclamation en début de ligne, ce qui signifie que la commande sera lancée dans le shell. Ici elle permettra d’installer les dépendances dans notre environnement virtuel.

  !pip install numpy
  import numpy as np
  
  Requirement already satisfied: numpy in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (1.26.4)

  Pandas, la bibliothèque Python star de la data-science, basée elle-même sur Numpy.

  !pip install pandas
  import pandas as pd
  Requirement already satisfied: pandas in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (2.2.2)
  Requirement already satisfied: numpy>=1.23.2 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from pandas) (1.26.4)
  Requirement already satisfied: python-dateutil>=2.8.2 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from pandas) (2.9.0.post0)
  Requirement already satisfied: pytz>=2020.1 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from pandas) (2024.1)
  Requirement already satisfied: tzdata>=2022.7 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from pandas) (2024.1)
  Requirement already satisfied: six>=1.5 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from python-dateutil>=2.8.2->pandas) (1.16.0)
  

  Pytorch, une des principales bibliothèques Python pour faire des réseaux de neurones. Ici on n’installe que la version CPU, la version de base fonctionne avec CUDA, la bibliothèque de calcul scientifique de Nvidia, mais celle-ci prend beaucoup de place sur le disque dur, restons frugaux.

  !pip3 install torch --index-url [https:] 
  import torch
  import torch.nn.functional as F
  Looking in indexes: [https:] 
  Collecting torch
    Downloading [https:] (190.4 MB)
  [2K     [38;2;114;156;31m??????????????????????????????????????[0m [32m190.4/190.4 MB[0m [31m26.4 MB/s[0m eta [36m0:00:00[0mm eta [36m0:00:01[0m[36m0:00:01[0m
  [?25hCollecting filelock
    Downloading [https:] (11 kB)
  Requirement already satisfied: typing-extensions>=4.8.0 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from torch) (4.12.2)
  Collecting sympy
    Downloading [https:] (5.7 MB)
  [2K     [38;2;114;156;31m????????????????????????????????????????[0m [32m5.7/5.7 MB[0m [31m57.2 MB/s[0m eta [36m0:00:00[0m MB/s[0m eta [36m0:00:01[0m
  [?25hCollecting networkx
    Downloading [https:] (1.6 MB)
  [2K     [38;2;114;156;31m????????????????????????????????????????[0m [32m1.6/1.6 MB[0m [31m58.6 MB/s[0m eta [36m0:00:00[0m
  [?25hRequirement already satisfied: jinja2 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from torch) (3.1.4)
  Collecting fsspec
    Downloading [https:] (170 kB)
  [2K     [38;2;114;156;31m??????????????????????????????????????[0m [32m170.9/170.9 kB[0m [31m18.5 MB/s[0m eta [36m0:00:00[0m
  [?25hRequirement already satisfied: MarkupSafe>=2.0 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from jinja2->torch) (2.1.5)
  Collecting mpmath>=0.19
    Downloading [https:] (536 kB)
  [2K     [38;2;114;156;31m??????????????????????????????????????[0m [32m536.2/536.2 kB[0m [31m42.9 MB/s[0m eta [36m0:00:00[0m
  [?25hInstalling collected packages: mpmath, sympy, networkx, fsspec, filelock, torch
  Successfully installed filelock-3.13.1 fsspec-2024.2.0 mpmath-1.3.0 networkx-3.2.1 sympy-1.12 torch-2.3.1+cpu
  

  Matplotlib, pour faire de jolis graphiques.

  !pip install matplotlib
  from matplotlib import pyplot as plt
  %matplotlib inline
  Collecting matplotlib
    Downloading matplotlib-3.9.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (8.3 MB)
  [2K     [38;2;114;156;31m????????????????????????????????????????[0m [32m8.3/8.3 MB[0m [31m44.0 MB/s[0m eta [36m0:00:00[0mm eta [36m0:00:01[0m0:01[0m:01[0m
  [?25hCollecting contourpy>=1.0.1
    Using cached contourpy-1.2.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (306 kB)
  Collecting cycler>=0.10
    Using cached cycler-0.12.1-py3-none-any.whl (8.3 kB)
  Collecting fonttools>=4.22.0
    Downloading fonttools-4.53.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (4.9 MB)
  [2K     [38;2;114;156;31m????????????????????????????????????????[0m [32m4.9/4.9 MB[0m [31m57.3 MB/s[0m eta [36m0:00:00[0m31m72.7 MB/s[0m eta [36m0:00:01[0m
  [?25hCollecting kiwisolver>=1.3.1
    Using cached kiwisolver-1.4.5-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (1.4 MB)
  Requirement already satisfied: numpy>=1.23 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from matplotlib) (1.26.4)
  Requirement already satisfied: packaging>=20.0 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from matplotlib) (24.1)
  Collecting pillow>=8
    Using cached pillow-10.3.0-cp311-cp311-manylinux_2_28_x86_64.whl (4.5 MB)
  Collecting pyparsing>=2.3.1
    Using cached pyparsing-3.1.2-py3-none-any.whl (103 kB)
  Requirement already satisfied: python-dateutil>=2.7 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from matplotlib) (2.9.0.post0)
  Requirement already satisfied: six>=1.5 in /home/seba/.local/share/virtualenvs/blog-simple-neural-network-F0Tscko_/lib/python3.11/site-packages (from python-dateutil>=2.7->matplotlib) (1.16.0)
  Installing collected packages: pyparsing, pillow, kiwisolver, fonttools, cycler, contourpy, matplotlib
  Successfully installed contourpy-1.2.1 cycler-0.12.1 fonttools-4.53.0 kiwisolver-1.4.5 matplotlib-3.9.0 pillow-10.3.0 pyparsing-3.1.2
  from random import randint, seed
  

  Création d’un jeu de données simple

  Pour le principe de la démonstration, on va créer un jeu de données parfaitement linéaire f(x) = 2*x

  On pourra contrôler facilement que les prévisions du réseau sont bien sur cette droite.

  data = pd.DataFrame(columns=["x", "y"],
                      data=[(x, x*2) for x in range(10)],
                     )
  data["x"] = data["x"].astype(float)
  data["y"] = data["y"].astype(float)
  
  data.plot.scatter(x="x", y="y")
  <Axes: xlabel='x', ylabel='y'>
  

  

  data

  Démarrage

  Préparons quelques variables pour le projet. Nous initions aussi le modèle M, si vous voulez tester des évolutions dans le code, relancez cette cellule pour réinitialiser le modèle.

  # On fait en sorte que pytorch tire toujours la même suite de nombres aléatoires
  # Comme ça vous devriez avoir les mêmes résultats que moi.
  torch.manual_seed(1337)
  seed(1337)
  
  # Je crée mon réseau d’un neurone avec une valeur aléatoire
  M = torch.randn((1,1))
  
  # On active le calcul du gradient dans le réseau
  M.requires_grad = True
  print(M)
  
  # On garde une liste de pertes pour plus tard
  losses = list()
  tensor([[-2.0260]], requires_grad=True)
  

  Algorithme général

  Pour que notre réseau apprenne des données, il nous faut une phase de feed forward et une back propagation.

  En quoi ça consiste ?

  Prenons un exemple dans notre jeu de données, la ligne x=9 et y=18.

  # on prend un échantillon
  ix = randint(0, len(data)-1)  # Indice de X
  
  x = data.iloc[ix]["x"]
  y = data.iloc[ix]["y"]
  print(f"{x=},{y=}")
  x=9.0,y=18.0
  

  La phase de feed forward consiste à demander au modèle ce qu’il prévoit comme donnée pour x=9. On utilise l’opérateur “@” qui multiplie des tenseurs.

  X = torch.tensor([x])
  y_prevision = M @ X
  ---------------------------------------------------------------------------
  
  RuntimeError                              Traceback (most recent call last)
  
  Cell In[10], line 2
        1 X = torch.tensor([x])
  ----> 2 y_prevision = M @ X
  
  
  RuntimeError: expected scalar type Float but found Double
  

  Ah oui, Numpy convertit notre Float (32bits) en Double (64 bits) en interne. Transformons notre tenseur en Float dans ce cas.

  X = torch.tensor([x]).float()
  y_prevision = M @ X
  print(f"{y_prevision=}")
  y_prevision=tensor([-18.2339], grad_fn=<MvBackward0>)
  

  Notre modèle prédit donc “-18.2339”, alors que notre y vaut 18.

  C’est normal puisque l’on a initialisé notre modèle avec des valeurs complètement aléatoires.

  Il nous faut donc corriger notre modèle, mais d’abord nous allons utiliser une fonction de perte, ici l1_loss pour voir à quel point on se trompe.

  Y = torch.Tensor([y])
  loss = F.l1_loss(y_prevision, Y)
  print("loss", loss.item())
  loss 36.23392868041992
  

  On se trompe de 36 (c’est à dire 18 – 18,23), c’est beaucoup.

  Pour corriger le modèle nous allons faire la phase de back propagation (ou rétro-propagation ou backward pass).

  Nous allons demander à Pytorch de calculer l’impact des poids du modèle dans cette décision. C’est le calcul du gradient. Cette opération, sans être très compliqué car il s’agit de dériver toutes les opérations effectuées, mérite un article à part entière et ne sera pas traitée dans celui-ci.

  # backward pass
  M.grad = None
  loss.backward()
  

  Attention, il faut toujours réinitialiser le gradient avant de lancer le back propagation.

  Maintenant que nous avons un gradient, nous allons mettre à jour notre modèle en y appliquant une fraction de ce tenseur.

  Pourquoi qu’une fraction ? Ici nous avons une fonction linéaire très simple à modéliser. En appliquant le gradient, on corrigerait tout de suite le modèle. Le problème est que, dans la vraie vie, la situation n’est jamais aussi simple. En réalité, les données sont hétérogènes et donc, appliquer le gradient à une donnée améliore le résultat pour celle-ci mais donnerait un très mauvais gradient pour les autres données.

  Nous allons donc appliquer une fraction du gradient et essayer de trouver le meilleur compromis. On pourra déterminer celui-ci grâce à la fonction de perte.

  Nous allons donc appliquer une modification de 0,1 fois le gradient sur notre modèle, ce 0.1 s’appelle le learning rate.

  # update
  lr = 0.1
  M.data += -lr * M.grad
  print(f"{M.grad=}, {M.data=}")
  M.grad=tensor([[-9.]]), M.data=tensor([[-1.1260]])
  

  Nous verrons lors d’un autre article comment choisir le learning rate.

  Voyons ce que ça donne :

  # forward pass
  y_prevision = M @ X
  print(f"{y_prevision=}")
  y_prevision=tensor([-10.1339], grad_fn=<MvBackward0>)
  

  Pas si mal, on passe de -18 à -10. Ça reste très mauvais mais on n’a exécuté qu’une seule fois notre cycle feed forward / back propagation.

  Faisons en sorte d’appeler plusieurs fois notre algorithme.

  for i in range(1000):
      # on prend un échantillon
      ix = randint(0, len(data)-1)
      
      x = data.iloc[ix]["x"]
      y = data.iloc[ix]["y"]
      
      # forward pass
      y_prevision = M @ torch.tensor([x]).float()
      loss = F.l1_loss(y_prevision, torch.Tensor([y]))
  
      # backward pass
      M.grad = None
      loss.backward()
  
      # update
      lr = 0.01
      M.data += -lr * M.grad
  
      # stats
      losses.append(loss.item())
  

  Voyons ce que donne notre prévision dans un graphique. En rouge les points de données, en bleu la courbe de prévision.

  ax = data.plot.scatter(x="x", y="y", color="red")
  prevision = pd.DataFrame(np.arange(10), columns=["x"])
  m = M.detach()
  prevision["y_prevision"] = prevision["x"].apply(lambda x: (m @ torch.tensor([float(x)]))[0].numpy()) #torch.tensor([4.])
  prevision.plot(y="y_prevision", ax=ax, x="x")
  <Axes: xlabel='x', ylabel='y'>
  

  

  Et si nous sortons du cadre des données avec un X de 2000 ?

  m @ torch.tensor([float(2000)])
  tensor([4028.0156])
  

  Pas mal, on devrait avoir 4000 mais c’est déjà mieux.

  Et par rapport à nos données de base ?

  prevision

  

  Bon, que ce passe-t-il ? Regardons un peu l’évolution de notre perte en fonction des itérations ?

  pd.DataFrame(losses, columns=["loss"]).plot()
  <Axes: >

  

  On voit que les pertes sont importantes pendant 100 itérations et ensuite elles se stabilisent un peu entre 0 et 0.8.

  Est-ce qu’on peut améliorer ça ? Oui très facilement, nous verrons cela ensemble lors d’un prochain article.

  Conclusion

  Nous avons appris comment créer un modèle et faire un apprentissage avec les phases de feed forward et back propagation. Ensuite nous avons vu que le learning rate et gradient permettent de corriger le modèle petit à petit. En faisant quelques centaines d’itérations nous avons un bon modèle de régression.

  J’espère que cette petite introduction vous a donné envie d’aller plus loin.

  Rédacteur : Sébastien Da Rocha

• 11 June 2024
• 9:41

  NEOGEO et SOGEFI allient leur catalogue de données et leur SIG pour les besoins de leurs utilisateurs

  sur Neogeo Technologies

  Une solution mutualisée donnant une gamme complète d’outils pour répondre aux besoins cartographiques des acteurs publics.

  Chez NEOGEO, nous avons décidé de nous associer à SOGEFI pour offrir à nos utilisateurs toute la puissance des données. Grâce à cette collaboration, la plateforme OneGeo Suite de NEOGEO est enrichie par les applications métier Mon Territoire de SOGEFI.

  Ensemble, nous proposons une solution mutualisée qui fournit une gamme complète d’outils adaptés aux besoins des administrateurs, des gestionnaires de données, des services techniques, des élus et du grand public.

   

  

  

   

  Une réponse adaptée à chaque usage cartographique !

   

  

   

  La combinaison de nos deux solutions offre une réponse précise et adaptée aux divers acteurs d’un territoire. Elle repose sur un socle commun robuste solide, structuré et évolutif centré sur les données, ce qui permet de créer un cycle vertueux de gestion de la donnée pour l’ensemble des acteurs de la structure, au bénéfice de leur territoire. Le développement de nos solutions respectives est axé sur l’expérience utilisateur, chaque outil étant conçu pour répondre aux besoins spécifiques des différents profils d’acteurs impliqués.

  OneGeo Suite propose aux administrateurs une gamme de modules pour gérer les référentiels métiers et satisfaire aux exigences de publication et de partage des données Open Data. OGS valorise ces données grâce à des modes de publication et de reporting (Dataviz) adaptés aux besoins des utilisateurs et de leurs publics, qu’il s’agisse de partenaires ou du grand public. Avec son module Explorer pour la recherche et la consultation intuitive des jeux de données, son module Maps pour les fonctionnalités cartographiques avancées, et son module Portal pour un portail collaboratif, OneGeo Suite offre une solution complète et innovante. Cette suite est fondée sur des principes de mutualisation et de co-construction d’outils open source.

  Mon Territoire propose une gamme complète d’outils métiers prêts à l’emploi pour les services techniques et les collectivités. Couvrant de nombreuses compétences, la gamme Mon Territoire utilise une sélection de données Open Data pour assister les agents responsables de l’urbanisme, de l’habitat, des réseaux, de la voirie et du développement économique.

   

  

  Schéma décrivant les usages et les rôles au travers des applications fusionnées OneGeo Suite et Mon Territoire

   

   

   

  Un choix stratégique pour nos entreprises, une décision évidente pour nos clients

   

   

  Laurent Mer – directeur général de NEOGEO

  

   

  « La gamme d’outils clé en main proposée par SOGEFI permet de compléter notre solution OneGeo Suite de catalogage et de diffusion de données par des modules métiers opérationnels directement accessibles aux utilisateurs de la plateforme.L’interopérabilité des deux solutions permet de mutualiser l’accès aux référentiels cartographiques et aux bases de données métier et le partage des droits sur les différents jeux de données offre la possibilité de définir une véritable stratégie de gouvernance des données. Enfin l’accès aux API Opendata proposées par SOGEFI et alimentées en temps réel permet d’enrichir l’offre de référentiels proposés dans le catalogue de données mis à disposition ».

   

   

  Mathilde de Sulzer Wart – directrice générale de SOGEFI

   

   

  

   

  « OneGeo Suite est la réponse idéale pour les structures départementales et régionales qui disposent d’un socle important de données. Les administrateurs de ces dernières disposent alors de tous les outils pour gérer ces importants volumes de données du catalogage à sa publication pour ses adhérents. OneGeo Suite, plateforme complètement Open Source, est totalement interopérable avec notre gamme Mon Territoire, elle apporte une vraie valeur ajoutée pour la diffusion et la valorisation de l’ensemble des données ainsi consolidées au fil du temps par les services et permet à l’IDG la mise en place d’un cycle vertueux de l’information pour l’ensemble de ces acteurs. »

  L’un des avantages de notre collaboration est de pouvoir déployer rapidement des solutions prêtes à l’emploi grâce à un accompagnement spécifique par métiers et compétences. Une équipe pluridisciplinaire est mobilisée pour le déploiement de notre offre commune et le planning établi peut mobiliser différentes équipes en parallèle pour le bon avancement du projet. Chacun sur son métier, NEOGEO et SOGEFI ont à cœur de vous accompagner et de vous conseiller sur vos problématiques. Chacun mène une veille permanente sur l’Opendata ainsi que sur les technologies du domaine et vous propose de vous en faire bénéficier au travers des solutions et des services que nous mettons en place depuis plusieurs années. Construit autour de communautés d’utilisateurs, nos deux solutions sont reconnues sur le marché depuis de nombreuses années, elles sont au service de nombreux usagers qui nous font part de leurs besoins d’évolution et idées pour les versions à venir notamment au travers d’espace d’échanges dédiés (forum, page web dédié…). Ces remontées d’informations sont précieuses pour nos équipes afin de définir les feuilles de route de nos produits.

   

   

  Ce sont bien les produits qui s’adaptent aux besoins des utilisateurs et non les utilisateurs qui s’adaptent au produit.

   

   

   

  Le meilleur des arguments, le témoignage de nos clients

   

   

  

  « Les outils métiers de SOGEFI sont tout à fait en adéquation avec les besoins et les usages des collectivités de toutes tailles dans leurs tâches du quotidien. Les partenariats existants avec Géofoncier sont un vrai plus pour les secrétaires de mairie. Nous pouvons également répondre aux besoins des services techniques des collectivités, des syndicats des eaux, d’assainissement. Les solution OneGeo Suite va nous permettre de maitriser nos données et de les mettre à disposition de nos utilisateurs et partenaires de manière simple et structurée (flux, datavisualisation, carte Web).? Le tout parfaitement intégré à notre SI et répondant à nos exigences en termes d’administration des comptes utilisateurs et des droits sur les données. »

  Guillaume MALATERRE, directeur Adjoint à l’Informatique et responsable du pôle Gouvernance et Exploitation des Données du SIDEC

   

   

  

  « Depuis une douzaine d’année, la plateforme territoriale Guyane-SIG favorise l’accessibilité des données spatiales et la démocratisation de leurs usages sur la Guyane. En 2020, la Collectivité Territoriale de Guyane a initié un travail de modernisation de l’ensemble des composants fonctionnels en deux étapes :

  • • • Nous avions besoins d’un outil performant pour proposer une lecture facilitée de l’information foncière pour l’ensemble de nos partenaires. Les attentes étaient fortes et avec Mon Territoire Carto, nous avons pu bénéficier rapidement d’un outil ergonomique mobilisant de nombreuses données en Opendata que nous avons pu compléter par des productions endogènes.

     

    • Puis les efforts se sont portés sur les outils collaboratifs de partage et de valorisation des données dans le respect des standards. Avec la suite OneGeo, nos partenaires peuvent désormais publier en quelques clics leurs données.

  L’accompagnement nous permet également de proposer régulièrement à nos partenaires des webinaires de présentation des évolutions fonctionnelles. 

  Boris RUELLE, responsable Service de l’Information Géographique de la collectivité territoriale de Guyane

   

   

   

  Le partenariat Neogeo et Sogefi qui a commencé avec le projet Géofoncier, le portail de l’Ordre des Géomètres-Experts

   

   

  

   

  NEOGEO et SOGEFI sont ravis de poursuivre et renforcer leur partenariat déjà éprouvé depuis plusieurs années auprès du Portail Géofoncier. Ce portail porté par l’Ordre des Géomètres-Expert est aujourd’hui une référence nationale dans la valorisation de l’information foncière. L’ambition portée par Géofoncier a su s’appuyer sur la complémentarité des expertises de chacun. Les différents projets ont nécessité un travail de coordination et d’enrichissement mutuel des pratiques et technologies mobilisées par les deux sociétés dans un objectif commun. Nos équipes se connaissent, elles ont l’habitude de travailler ensemble et savent mobiliser les ressources en interne pour assurer une couverture élargie des compétences nécessaires aux projets.

   

  « Depuis de nombreuses années, NEOGEO et SOGEFI sont nos partenaires privilégiés chez Géofoncier. Leurs expertises complémentaires et incontestées dans le domaine de la diffusion et de la valorisation de la donnée cartographique, associée à leurs écoutes attentives de nos besoins, font de NEOGEO et SOGEFI un groupement pertinent et essentiel à notre réussite. Leur engagement fort au quotidien à fournir en concertation des solutions complètes et pérennes ont grandement contribué au succès de Géofoncier. Nous sommes reconnaissants de pouvoir compter sur ces équipes d’experts aussi fiables et compétentes pour nous accompagner dans notre croissance continue.
  

  NEOGEO possède une expertise avérée dans la mise en œuvre de solutions innovantes de partage, de valorisation et de visualisation de données géographiques auprès d’un large public. NEOGEO développe et met en place depuis sa création en 2008 des infrastructures de données géographiques et des plateformes open-source. NEOGEO a intégré en 2022 le groupe Geofit (leader français dans l’acquisition de données spatiales), permettant ainsi de renforcer ses compétences (équipe de 40 collaborateurs) et ses références (une cinquantaine de plateformes cartographiques majeures déployées en France et à l’étranger). C’est aussi la fusion des savoirs faires technologiques des deux structures qui a permis de donner le jour à la solution OneGeo Suite.

  SOGEFI, expert de la data et du webmapping depuis 33 ans propose des solutions pour la gestion et l’exploitation de données par la cartographie. La gamme Mon Territoire est réservée aux collectivités pour la gestion par métier de leur territoire. SOGEFI place l’utilisateur au cœur de ses réflexions et de sa feuille de route et son expertise de la donnée lui permet de proposer des exploitations poussées de la donnée au sein de ses applications. La société équipe aujourd’hui plus de 1000 collectivités et entreprises avec ses solutions web-SIG cadastre, urbanisme, réseaux et voirie. Elle accompagne également le portail Géofoncier sur son expertise de la donnée par la mise à disposition de ses API. »

  Patrick Bezard-Falgas, Directeur général de Géofoncier

   

   

  Pour en savoir plus contactez-nous !

   

• 07 June 2024
• 10:09

  Séminaire, juin 2024

  sur Neogeo Technologies
  

  Le séminaire annuel de Neogeo réalisé cette année dans les locaux de GEOFIT à Nantes s’est achevé avec succès.
  
  Ces quelques jours ont été remplis de moments partagés donnant lieu à des discussions passionnantes, d’ateliers interactifs et d’échanges inspirants.
  
  Nous tenons à remercier chaleureusement tous les participants pour leur présence et leur engagement le tout dans la bonne humeur. Un immense merci également à nos intervenants (TEICEE) pour leurs présentations éclairantes et leur expertise. 
  
  Ce séminaire a été une formidable opportunité pour renforcer le lien entre les équipes, nos connaissances, élargir nos horizons et créer de nouvelles connexions professionnelles.
  
  Nous sommes impatients de mettre en pratique les idées et les stratégies discutées.

  Publié le 07/06/2024

  • LinkedIn

  

  Séminaire annuel NEOGEO c’est parti…
  
  Rien de mieux qu’une formation DevOps pour mettre les équipes autour d’une table et discuter de l’amélioration continue de nos processus de développement
  
  C’est aussi l’occasion de découvrir les salles de réunion du nouveau siège du groupe GEOFIT à Nantes.

  Publié le 05/06/2024

  • LinkedIn
• 29 April 2024
• 9:10

  Découvrez les Réseaux de Neurones – Le Cerveau de l’IA

  sur Neogeo Technologies

  Mais, bien plus encore, ces réseaux de neurones sont également utilisés pour classifier des données ou bien effectuer des prévisions. Ils sont également très utilisés dans le domaine du traitement du langage ou bien celui de la vision par ordinateur, notamment en robotique. Les réseaux de neurones sont donc présents partout autour de nous.

  Cependant, vous ne savez peut-être pas ce qui se cache derrière ces réseaux qui peuvent paraître très obscurs et complexes. Si vous souhaitez comprendre et utiliser ces systèmes de détection, classification et prédiction, il vous faudra d’abord appréhender la notion de réseaux de neurones. Pour cela, nous allons développer un exemple concret.

  Exemple concret – Classification d’une image

  Un réseau de neurones peut par exemple être utilisé pour classer une image dans telle ou telle catégorie. Un exemple concret pourrait être l’application de cette technologie à la détection et la classification des sols sur des images satellites.

  L’idée est donc de donner une image en entrée du réseau de neurones et que celui-ci classe cette image dans la catégorie “urbain” ou bien « rural” par exemple. Le problème revient donc à se poser la question suivante : « Mon image représente-t-elle une zone urbaine ? »

  Si l’on crée le réseau et qu’on donne tout de suite notre image en entrée, on aura un résultat aléatoire, aberrant et très peu exact. Il faut donc entraîner notre réseau avec un jeu de données pour lui apprendre à bien classifier les images. On lui donne donc beaucoup d’images de zones urbaines et rurales pour lui apprendre à les différencier correctement.

  Il existe différentes méthodes d’apprentissage mais la plus répandue (et simple à la compréhension) est l’apprentissage supervisé. Cela consiste à donner le résultat attendu en même temps que la donnée d’entrée. Plus concrètement, chaque image est annotée avec la catégorie “urbain” ou “rural” afin que le réseau puisse confirmer ses résultats et ainsi apprendre de ses erreurs. C’est cette méthode d’apprentissage qui sera expliquée par la suite.

  Un réseau de neurones est basé sur le fonctionnement du cerveau humain. Il est donc composé de plusieurs neurones reliés entre eux de la façon suivante :

  

  Comme on peut le voir, les neurones sont divisés en 3 familles :

  – les entrées : inputs

  – les neurones des couches cachées : hidden layers

  – les sorties : outputs

  Dans notre réseau nous avons : 2 inputs, 1 hidden layer avec 3 neurones et 1 output.

  Il est cependant possible d’avoir autant de neurones que l’on veut dans chaque famille ; on peut également avoir plusieurs couches cachées.

  Une fois le réseau créé, on peut maintenant s’intéresser à son fonctionnement qui consiste en deux phases : la phase de feed forward et celle de back propagation.

  La phase de feed forward consiste à introduire les données en entrée du réseau et de les propager à travers celui-ci. Pour résumer, à chaque couche on calcule la somme pondérée des entrées puis cette valeur est transmise via une fonction d’activation. On reproduit ensuite le processus jusqu’à la couche de sortie. Cette phase est donc celle de prédiction et est utilisée pour l’inférence.

  La phase de back propagation arrive une fois la prédiction effectuée. On calcule alors l’erreur entre la sortie prédite et la sortie réelle. Puis cette dernière est propagée dans le réseau et les poids sont ajustés au fur et à mesure pour minimiser cette erreur.

  L’apprentissage consiste donc en une multitude de cycles : feed forward + back propagation.

  Nous allons maintenant observer la phase de feed forward plus en détails. Cette étape commence par donner une première fois des données en entrée de notre réseau. Chaque neurone de la couche inputs se voit donc affecté d’une valeur. Dans notre cas “Mon image représente-t-elle une zone urbaine ?” on aura des valeurs numériques entre 0 et 1 (probabilité que l’image présente une zone rurale) :

  

  Les valeurs sont ensuite transmises aux neurones de la couche suivante par les connexions :

  

  Les neurones de la deuxième couche fusionnent donc les valeurs des neurones de la couche précédente. La valeur fusionnée obtenue peut ensuite être modifiée en interne par le neurone :

  

  Puis les neurones de la deuxième couche transmettent à leur tour la valeur modifiée à la couche suivante :

  

  De la même façon, le(s) neurone(s) de la couche finale (outputs), peu(ven)t modifier en interne la valeur reçue avant de la retourner :

  

  Une fois la valeur finale obtenue, on a fini la passe de feed forward.

  En réalité, la transmission des valeurs est un peu plus complexe. C’est ce qu’on va détailler par la suite. Pour bien comprendre la transmission, on va se limiter à 3 neurones.

  La transmission des valeurs va dépendre de « l’épaisseur » du lien entre les neurones. Plus le lien est épais, plus la valeur passe dans son intégralité et inversement. Cette épaisseur est appelée poids ou weight et est différente pour chaque lien, comme visible sur l’image suivante :

  

  Ainsi, chaque neurone n’a pas le même poids / la même importance dans le réseau.

  On va maintenant voir comment le neurone peut changer en interne la valeur qu’il reçoit avant de la transmettre. Concrètement, le neurone possède une fonction, dite fonction d’activation, qui sert à déterminer si la valeur doit ou non passer au prochain neurone. Si le résultat de la fonction est proche de 1, la valeur passera et s’il est proche de 0, la valeur ne passera pas.

  Il existe une multitude de fonctions d’activation mais les plus utilisées sont :

  – Sigmoid

  – Unité linéaire rectifiée (Rectified Linear Unit : ReLU)

  – Tangente Hyperbolique (tanh)

  – Linear

  

  Le neurone a également la possibilité d’ajouter un biais en entrée de la fonction d’activation, ce qui permet au neurone d’avoir de l’influence sur l’activation :

  

  Pour résumer :

  – on a un ensemble de neurones

  – on entre les données dans les neurones inputs

  – on lie les couches de neurones avec un certain poids

  – on ajoute des biais, qui sont multipliés par leur propre poids

  – on ajoute les valeurs pour avoir les nouvelles valeurs

  – on fait passer les nouvelles valeurs dans la fonction d’activation

  – on récapitule pour le dernier neurone

  On obtient finalement le résultat.

  Cependant, comme on initialise les biais et les poids aléatoirement, il y a peu de chance pour que le réseau soit performant.

  On va alors passer notre résultat dans une fonction d’erreur. Cette fonction prend en entrée notre résultat et la valeur attendue. Cela nous permet de déterminer la précision de notre réseau.

  On va ensuite réaliser la deuxième étape : la passe de back propagation. De manière très simple, cette étape consiste à déterminer comment on doit modifier les poids de notre réseau pour faire diminuer au maximum notre erreur. Dans la pratique, on modifie un poids à la fois et très peu pour déterminer l’influence de chaque poids sur notre réseau en fonction de son impact sur l’erreur. Cette étape est réalisée par les dérivées de tous les calculs fait lors de la phase de feed forward.

  Conclusion

  Nous avons découvert ce qui se cache derrière un réseau de neurones, son fonctionnement basique ainsi que ses applications diverses. Les réseaux de neurones offrent de nombreuses possibilités pour le domaine de la géomatique avec l’analyse et l’interprétation des données spatiales. La capacité de ces derniers à apprendre à partir de données brutes en fait un outil puissant pour la prédiction, la classification, et même la génération de nouvelles données géospatiales. Cependant, il est essentiel de se rappeler que, malgré leur potentiel, les réseaux de neurones ne sont pas une solution miracle et peuvent présenter des défis en pratique. Il est notamment important de rappeler que la qualité et la quantité des données sont primordiales afin d’obtenir des résultats fiables et significatifs. Finalement, il est également essentiel de noter que l’utilisation efficace des réseaux de neurones nécessite souvent des capacités de calcul élevées et des ensembles de données volumineux.

  Rédactrice : Mathilde POMMIER

• 04 April 2024
• 9:00

  Votre application est-elle compatible avec la licence Affero GPL 3.0??? 

  sur Neogeo Technologies

  Lors du changement de licence sur OneGeo Suite, il est important d’examiner la compatibilité des dépendances avec Affero GPL. Au vu des implications qui en découlent, est-il surtout possible de vérifier que nos dépendances aient toujours une licence conforme ? 

  La compatibilité entre les licences? 

  La compatibilité de licences inclut deux éléments clé à prendre en compte :  

  • Le projet en lui-même (ex : un module Python, une bibliothèque de fonctions, etc.) ; 
  • Un travail dérivé (ex : un logiciel complet comme FireFox). Les travaux dérivés d’un projet, quant à eux, peuvent être des modifications du code du projet ou des produits intégrant le projet. 

  Une compatibilité des licences sera possible lorsque le travail dérivé possède une licence qui n’enfreint pas les règles de la licence du projet. 

  Les licences « copyleft » obligent à redistribuer les travaux dérivés sous la même licence (ou une compatible) pour protéger les libertés du code et de l’utilisateur. A contrario, les licences permissives autorisent le changement de licence, et il est également possible de faire un produit propriétaire, en intégrant des composants sous ce type de licence. Par exemple, Sony base son système d’exploitation propriétaire de la Playstation sur FreeBSD, qui est un logiciel libre sous licence FreeBSD.? 

  Source : [https:] (Creative Commons BY-SA-3.0)? 

  Dans ce schéma, le code en domaine public est intégrable dans un produit MIT, lui-même dans un produit sous licence BSD, lui-même dans un produit licence Apache 2.0, et ainsi de suite jusqu’à la licence Affero GPL 3. 

  Deux catégories supplémentaires sont introduites par ce schéma?: 

  • Weakly protective (faiblement protectrice)?: elle implique qu’une modification du code doit être sous la même licence (donc rester libre). Néanmoins, l’intégration du projet peut se faire dans un produit sous une autre licence (même propriétaire). 
  • Network Protective (protectrice des utilisateurs réseau)?: la licence GPL protège les utilisateurs de la machine. Dans le cadre d’applications client-serveur, la partie serveur protège l’utilisateur du serveur, donc l’administrateur système. Une conformité à la GPL existe dans le cas où l’administrateur système de OneGeo Suite a accès aux sources modifiées du produit, mais pas l’utilisateur de la partie client. Les licences Network Protective permet aussi de protéger la liberté des utilisateurs du client. 

  Notez bien les versions des licences : par exemple la licence Apache 2.0 est compatible avec la licence LGPL, alors que la version 1.1 ne l’est pas. 

  Pour vous aiguiller, voici quelques incompatibilités à souligner?: 

  • Apache 1.1 ou MPL 1.1 (Mozilla Public Licence) ne sont pas compatibles avec les licences GPL, alors qu’une clause explicite de compatibilité existe dans les versions 2.0 de ces mêmes licences ; 
  • CC-BY-3.0?empêche de changer la licence, donc impossible à changer en AGPL. La version 4.0 permet explicitement de changer la licence en GPL 3.0 et donc en AGPL 3.0 ; 
  • Licence originelle BSD?: elle forçait à indiquer une notice de copyright dans la documentation du produit final, ce qui peut poser problème quand il y a de nombreux composants avec cette licence dans un produit. 

  Vérifier la conformité

  En pratique, la conformité de licence peut se vérifier grâce au DevOps.  

  Pour illustrer nos projets, essentiellement en Python et Javascript, nous vous présentons deux outils simples qui pourront vous aider. Dans ces exemples, nous nous en servirons en ligne de commande, afin de comparer les licences des dépendances avec une liste validée de licences.? 

  Vérification des licences en Python? 

  L’outil « pylic » analyse tous les modules Python installés dans l’environnement virtuel et compare leurs licences avec une section du pyproject.toml. S’il trouve un module avec une licence non validée, il sort en émettant erreur que l’on pourra exploiter dans une CI. 

  Commençons par installer le programme?:? 

  $ pip install pylic? 

  Ensuite, nous indiquons à “pylic” les licences compatibles avec notre logiciel, en lui donnant une liste de licences compatibles AGPL 3.0, dans la section tool.pylic de notre pyproject.toml : 

  $ cat << EOF >> pyproject.toml?
  [tool.pylic]? 
  safe_licenses = [? 
  "Apache Software License", 
  "BSD License",? 
  "BSD",?  
  "MIT License",? 
  "MIT",?  
  "Mozilla Public License 2.0 (MPL 2.0)",?
  "GNU Library or Lesser General Public License (LGPL)",?
  "GNU Lesser General Public License v3 or later (LGPLv3+)",? 
  ? "Python Software Foundation License",? 
  "Historical Permission Notice and Disclaimer (HPND)"? 
  ? ]? 
  EOF? 

  Vous remarquerez que ces licences ont parfois des noms très similaires. En effet, “pylic”  s’appuie sur le nom déclaré par le mainteneur du module python (dans le setup.cfg/setup.py…) qui n’est pas normalisé. Nous devons déclarer comme « safe » les deux identifiants « MIT » et « MIT License », alors que nous aurions pu utiliser les identifiants de licence SPDX dans la configuration du module Python. 

  Revenons à “pylic” et lançons une vérification : 

  $ pylic check? 
  ✨ All licenses ok ✨? 

  Comment peut-on faire en cas de non-conformité ?  

  En commentant la licence « Apache Software License » de pyproject.toml, nous obtenons ce message : 

  $ pylic check? 
  Found unsafe licenses:?
  ? nltk (3.8.1): Apache Software License? 
  ? phonenumbers (8.13.8): Apache Software License? 
  ? importlib-metadata (6.1.0): Apache Software License
  ? bleach (6.0.0): Apache Software License? 
  ? cryptography (42.0.1): Apache Software License? 
  ? regex (2023.12.25): Apache Software License?
  ? django-onegeo-suite (1.0.2): Apache Software License?
  ? requests (2.31.0): Apache Software License? 
  ? packaging (23.2): Apache Software License?
  ? pyOpenSSL (24.0.0): Apache Software License?
  ? tzdata (2023.4): Apache Software License? 
  ? elasticsearch (7.17.9): Apache Software License?
  ? async-timeout (4.0.3): Apache Software License?
  ? josepy (1.14.0): Apache Software License? 
  ? django-onegeo-rproxy-mapstore2 (1.0.0b2): Apache Software License? 

  Plutôt simple, non??? 

   

  Vérification des licences en Javascript? 

  De la même façon, on peut vérifier les licences des projets javascript avec license-checker. ilIl n’est toujours pas au courant des licences qui existent donc il faudra construire la liste à la main.? 

  L’utilisation est plutôt simple?:? 

  $ npx license-checker --onlyAllow "CC-BY-4.0;ISC;Apache-2.0;BSD-3-Clause;Custom: [https:] Domain;CC0-1.0;MPL-2.0" --production?? 

  Package « @fortawesome/fontawesome-common-types@0.2.36 » is licensed under « MIT » which is not permitted by the –onlyAllow flag. Exiting.? 

  ?On obtient des erreurs pour chaque licence non autorisée.? 

  L’option «?–onlyAllow?» permet de lister les licences autorisées séparées par des point virgules «?;?». Tandis que l’option «?–production?» permet d’écarter les licences des modules de la section «?devDependencies?» du package.json.? 

  Pensez aussi à corriger la section «?license?» du package.json pour ne pas perturber l’outil?:? 

  ? "license": "AGPL-3.0-only",? 

  Je vous conseille aussi d’ajouter un script dans le package.json pour automatiser les vérifications?:? 

  cat package.json??
  {? 
  [...]? 
  ? "scripts": {?
  [...]??? "lint": "vue-cli-service lint",? 
  ??? "license-checker": "license-checker --onlyAllow \"MIT;CC-BY-4.0;ISC;Apache-2.0;BSD-3-Clause;Custom: [https:] Domain;CC0-1.0;MPL-2.0\" --production"
  ? },? 

  On peut ainsi lancer simplement?:? 

  $ npm run? license-checker? 

   

  Conclusion? 

  Il existe probablement des outils plus sophistiqués pour vérifier la compatibilité des licences des bibliothèque externes utilisées par votre projet, notamment en utilisant la matrice de compatibilité des licences de l’OSADL?: [https:]] ? 

  Mais pour une utilisation légère et rapide dans une CI, ces deux outils feront l’affaire, en investissant néanmoins un peu de temps pour vérifier les nouvelles licences qui peuvent apparaître pendant la vie de votre projet.? ? 

  Sources?:? 

  [https:]] ?: image compatibilité? 

  [https:]] ?: informations sur les compatibilités avec la GPL? 

  [https:]] : compatibilité Apache 2.0 et GPL? 

  [https:]] : utilisation de license-checker? 

   

  Rédacteur : Sébastien DA ROCHA 

   

• 26 March 2024
• 8:00

  Le changement de licence OneGeo Suite

  sur Neogeo Technologies

  Aujourd’hui, l’implication de NEOGEO dans la communauté géomatique prend une autre dimension. En adoptant la licence Affero GPL pour nos logiciels OneGeo Suite et GeoContrib, nous souhaitons renforcer cet engagement. 

  Pourquoi ce changement ? 

  À travers l’adoption de cette nouvelle licence, l’objectif est double : 

  1. Protéger les innovations : Nous souhaitons garantir que les développements réalisés par Neogeo et nos clients demeurent libres. Cette démarche permet de préserver la richesse et la valeur ajoutée de notre travail. 

  2. Partager et collaborer : Lorsqu’un acteur, issu ou non du monde de la géomatique, décide de s’appuyer sur nos travaux, ses contributions seront accessibles à toute la communauté. C’est un cercle vertueux : plus nous collaborons, plus le logiciel s’enrichit pour le bénéfice de tous. 

  Ce changement sera effectif à partir de la version OneGeo Suite 1.1 et pour la version stable GeoContrib 5.4.

  Les 4 libertés du logiciel libre : Un rappel essentiel 

  La notion de logiciel libre repose sur 4 libertés fondamentales : 

  • Le droit d’utiliser le logiciel sans restriction 
  • Le droit d’étudier le logiciel 
  • Le droit de diffuser le logiciel 
  • Le droit de modifier le logiciel et de diffuser les modifications 

  Le Copyleftt : En la matière, le copyleft est un gage d’égalité et de liberté qui vise à empêcher la restriction des droits des utilisateurs.  

  Le logiciel peut être modifié mais sa licence doit rester compatible, tout en conservant notamment le droit de copier le code source.  Le copyleft garantit donc que les logiciels libres le restent. 

  Les licences libres en un coup d’œil

  Il existe actuellement plusieurs licences libres : 

  • Apache : Une licence permissive qui autorise la modification de la licence des fichiers modifiés exclusivement. 
  • GPL : Sans doute la licence libre la plus populaire et le pilier du copyleft. Elle exige que les produits dérivés et programmes associés adoptent une licence compatible, garantissant les mêmes droits aux utilisateurs. 
  • LGPL : Une variante de la GPL, la LGPL offre plus de flexibilité sur l’intégration du code dans un produit sous une autre licence (même non libre) tout en restant compatible avec la GPL. 
  • Affero GPL : La principale différence entre la GPL et l’AGPL réside dans la façon dont elles traitent l’utilisation du logiciel sur des serveurs distants. L’AGPL a été créée pour s’assurer que les services Web basés sur des logiciels libres donnent accès au code source aux utilisateurs distants (même s’ils n’ont pas téléchargé le logiciel).

  Des licences pas si libres

  D’autres licences sont également disponibles mais plus contraignantes en matière de libertés :  

  • SSPL (Server Side Public License) : utilisée par MongoDB et ElasticSearch, la licence limite la mise à disposition d’un logiciel sur des hébergeurs Cloud. Elle vise essentiellement les géants du cloud comme AWS. La plupart des utilisateurs peuvent continuer d’utiliser MongoDB et ElasticSearch comme avant. Cette licence n’est pas reconnue par l’OSI (Open Source Initiative) comme « open source » et celle-ci est parfois critiquée pour ses exigences jugées excessives ; 
  • Freemium (ou shareware) : les logiciels sont gratuits mais le plus souvent non modifiables 
  • CLAs (Contributor License Agreements) : À l’instar d’une NDA (Non Disclosure Agreement), l’agrément doit être signé par les contributeurs afin de céder leurs droits. Cette licence permet également à l’entreprise d’utiliser les contributions d’une manière qui ne serait pas permise par la licence open source sous laquelle le logiciel est publié (ex : changer de licence). 

  Le passage des solutions sur cette nouvelle licence traduit notre volonté de renforcer la liberté, la collaboration et l’innovation dans le domaine géomatique. Nous souhaitons également que ce changement profite à toute la communauté, ainsi que les évolutions qui en découleront.   

  Rédacteur : Sébastien DA ROCHA 

• 05 February 2024
• 16:12

  GPT, capturez-les tous !

  sur Neogeo Technologies

  ChatGPT est un agent conversationnel qui peut vous aider au quotidien. Néanmoins, vous ne savez pas réellement ce que OpenAI, son créateur, fait de vos conversations. Il n’est, d’ailleurs, pas conseillé de lui parler de sujets confidentiels.

  Si vous souhaitez l’utiliser dans vos produits, l’API peut rapidement coûter très cher (compter environ 3 centimes pour le traitement de cet article par exemple, multiplié par le nombre de requêtes par utilisateur, multiplié par les demandes de chaque utilisateur…). Heureusement, la communauté Open Source propose petit à petit des alternatives.

  La première étape était la publication de Llama par Meta (Facebook). Il s’agit d’un modèle d’intelligence presque libre et limité à 500 millions d’utilisateurs. Au-delà, il faut les contacter pour avoir le droit de l’utiliser. Il est également possible de le récupérer sur nos ordinateurs et de s’en servir de façon strictement privée.

  Pour télécharger le modèle, il faut néanmoins montrer patte blanche en remplissant un formulaire et recevoir un lien, par mail, avec une durée de vie limité. En cas d’expérimentation, cela peut vite devenir contraignant.

  Démocratisation technique

  Les développeurs de llama.cpp (surtout Georgi GERGANOV) ont optimisé ce moteur qui vous permet de discuter avec les modèles Llama2.

  Les modèles de Llama2

  Llama2 est disponible en plusieurs tailles (nombre de paramètres) : 7B, 13B et 70B. L’unité « B » correspond à des milliards de paramètres.  

  Sachant que chaque paramètre est stocké sur 2 octets (des flottants de demi-précision), il faut au moins 16Go de RAM pour charger le petit modèle 7B. Les gros modèles sont plus pertinents, mais beaucoup plus lents. 

  Les optimisations

  Les développeurs de LLama.cpp ont travaillé sur 2 optimisations :

  • • Pouvoir lancer les calculs (appelés «?inférence?») sur le CPU en utilisant au maximum ses capacités (optimisation M1, AVX-512 ou AVX2…) et en codant le moteur d’inférence en C++ et sûrement des morceaux en assembleur? ;
    • Compresser le modèle sans trop perdre de pertinence.

  Pour ce dernier point, ils ont développé un codage flottant du 4bits : q4_0 (d’autres variantes avec plus de bits existent). Nous pouvons désormais utiliser un modèle 7B avec 4Go de RAM?! À noter que l’on peut tout de même un peu perdre en pertinence.

  Le travail de llama.cpp est prodigieux mais difficile à utiliser : il arrive que le modèle réponde de manière erronée ou ne rende pas la main après la réponse.

  Ollama

  Désormais la relève existe : Ollama !

  Considéré comme le docker des LLM, il nous permet de télécharger, questionner, supprimer des modèles en une ligne de commande. Concernant les performances, Ollama est une surcouche en Go et utilise llama.cpp.

  Les instructions d’installation sont disponibles ici : [https:]

  Une fois installé, vous pouvez télécharger un modèle aussi simplement que :

  ollama pull llama2

  Une fois téléchargé, vous pouvez le questionner comme ceci :

  ollama run llama2
  >>> comment faire une jointure entre 2 dataframes Pandas ?
  There are several ways to join two pandas DataFrames. Here are a few methods:
  
  1. `merge()`: This is the most common method for joining two DataFrames. It joins the two DataFrames based on a common column, called the "join key". The joined DataFrame will have the columns from both DataFrames.
  "`
  df_left = pd.read_csv('left_data.csv')
  ...

  Attention, Ollama installe aussi un service Systemd en arrière plan. Si vous préférez le lancer à la main, au hasard pour contrôler la RAM de disponible sur votre machine :

  # désactiver le démarrage auto avec la machine
  sudo systemctl disable ollama.service
  # Couper réellement le service 
  sudo systemctl stop ollama.service

  Quel modèle ?

  Llama a apporté son lot de révolutions, mais d’autres équipes de chercheurs ont repris le flambeau, notamment Mistral AI qui a réussi à créer des petits modèles très efficaces.

  Récemment, Hugging Face (l’équivalent de Github dans la sphère IA) a encore amélioré Mistral en créant Zephyr, un petit modèle qui a de très bons résultats pour parler dans plusieurs langues.

  $ ollama run zephyr:7b
  >>> comment faire une jointure entre 2 dataframes Pandas ?
  Pour joindre deux DataFrames en Pandas, vous pouvez utiliser la méthode `merge()`. Ci-dessous une explication de comment utiliser cette méthode :
  
  1. Assurez-vous que les deux DataFrames ont une colonne commune sur laquelle joindre les données. Soit df1 et df2, on appellera cette colonne 'common_column'.
  ...

  Zephyr n’a pas de clause de restriction à 500 millions d’utilisateurs (licence Apache 2.0), il répond en français et sera plus économe en ressources. 

  Ci-dessous, une liste de quelques modèles : 

  

  S’il en détecte un, Ollama va automatiquement utiliser le GPU. Sinon, il se rabat sur le CPU en essayant de tirer parti des instructions disponibles (AVX2, AVX512, NEON pour les M1/M2…)

  Docker

  Si vous utilisez l’image docker de Ollama, il faut penser à couper le service Ollama ou à changer de port TCP d’écoute dans le docker-compose.yaml.

  Voici un docker-compose minimaliste :

  ---
  version: '3.8'
  
  services:
    ollama:
      image: ollama/ollama:latest
      ports:
        - "11434:11434"
      volumes:
        - ollama:/root/.ollama
      restart: unless-stopped
  
  volumes:
    ollama:

  Ensuite, un petit docker compose up -d pour lancer le serveur.

  Comment pouvons-nous lancer une inférence ?

  $ docker compose exec ollama ollama run zephyr:7b
  >>> Salut
  Bonjour,
  
  Je suis heureux d'aider quelqu'un aujourd'hui. Votre expression "Salut" est une forme courante de salutation en français. En France, c'est souvent utilisé entre amis ou entre personnes qui connaissent déjà l'un l'autre. Dans les 
  situations où vous souhaitez être plus formel ou professionnel, vous pouvez utiliser "Bonjour" ou "Bonsoir" suivi du prénom de la personne ou simplement "Madame" ou "Monsieur" si vous ne connaissez pas le prénom.
  
  J'espère que cela vous a été utile. Si vous avez d'autres questions, n'hésitez pas à me contacter.
  
  Bien à vous,
  [Votre nom]
  >>>

  En revanche, utiliser la console de l’image n’est pas pratique, sauf si vous souhaitez télécharger une image et plus jamais y retoucher. Et surtout, nous pouvons utiliser l’API HTTP :

  $ curl -X POST [localhost:11435] -d '{ "model": "zephyr:7b", "prompt": "raconte moi une courte histoire drôle"}'
  {"model":"zephyr:7b","created_at":"2024-01-11T15:27:47.516708062Z","response":"Il","done":false}
  {"model":"zephyr:7b","created_at":"2024-01-11T15:27:47.534749456Z","response":" y","done":false}
  ...

  Pour faciliter la lecture de l’inférence, vous pouvez afficher le texte token par token dans notre app. Il est également possible de s’en servir en python. Voici un exemple de client inclut dans le dépôt :

  [https:]]

  Il est toujours possible d’utiliser le client installé précédemment ollama en ligne de commande, pour requêter le serveur à distance :

  $ OLLAMA_HOST=127.0.0.1:11435 ollama run zephyr:7b-beta-q6_K "raconte moi une courte histoire drôle"

  Docker et l’accélération avec une carte graphique Nvidia

  Vous remarquerez que l’inférence dans le docker n’est pas très rapide. En effet, docker ne laisse pas le container accéder à la carte graphique, par conséquent l’inférence se fait sur le CPU.

  Pour cela, il faut installer un paquet fourni par Nvidia afin de configurer le docker proprement :

  $ curl -fsSL [https:] | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
    && curl -s -L [https:] | \
      sed 's#deb [https:] [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] [https:] | \
      sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
  
  $ apt update
  $ apt install -y nvidia-container-toolkit

  Une fois ce paquet installé, il faut utiliser l’outil fournit pour configurer docker :

  $ nvidia-ctk runtime configure --runtime=docker

  Cela va modifier votre configuration de docker /etc/docker/daemon.json pour activer un runtime nvidia :

  {
  	"runtimes": {
  		"nvidia": {
  			"args": [],
  			"path": "nvidia-container-runtime"
  		}
  	}
  }
  
  

  Ensuite, il suffit de redémarrer docker :

  $ systemctl restart docker

  Désormais, vous devriez pouvoir accéder à votre GPU Nvidia depuis le container :

  $ docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi
  Unable to find image 'ubuntu:latest' locally
  latest: Pulling from library/ubuntu
  a48641193673: Already exists 
  Digest: sha256:6042500cf4b44023ea1894effe7890666b0c5c7871ed83a97c36c76ae560bb9b
  Status: Downloaded newer image for ubuntu:latest
  Thu Jan 11 15:46:38 2024       
  +-----------------------------------------------------------------------------+
  | NVIDIA-SMI 525.147.05   Driver Version: 525.147.05   CUDA Version: 12.0     |
  |-------------------------------+----------------------+----------------------+
  | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
  | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
  |                               |                      |               MIG M. |
  |===============================+======================+======================|
  |   0  NVIDIA GeForce ...  On   | 00000000:2D:00.0  On |                  N/A |
  | 31%   33C    P5    32W / 225W |   1778MiB /  8192MiB |      2%      Default |
  |                               |                      |                  N/A |
  +-------------------------------+----------------------+----------------------+
                                                                                 
  +-----------------------------------------------------------------------------+
  | Processes:                                                                  |
  |  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
  |        ID   ID                                                   Usage      |
  |=============================================================================|
  +-----------------------------------------------------------------------------+

  Une fois cela terminé, l’accès doit être donné à votre container en modifiant le docker-compose.yaml:

  ---
  version: '3.8'
  
  services:
    ollama:
      image: ollama/ollama:latest
      ports:
        - "11435:11434"
      volumes:
        - ollama:/root/.ollama
      restart: unless-stopped
      deploy:
        resources:
          reservations:
            devices:
              - driver: nvidia
                capabilities: [gpu]
                count: all
  
  
  volumes:
    ollama:

  Grâce au docker compose up -d, notre inférence est désormais beaucoup plus rapide.

  Conclusion

  Nous avons découvert comment utiliser les LLM libre, avec des projets comme Ollama et Zephyr, qui rendent l’IA plus démocratique et accessible à un plus grand nombre. Plus besoin de se soucier des coûts prohibitifs de l’API OpenAI, lorsque vous pouvez exploiter ces modèles de langage gratuits et Open source.

  Que vous soyez un développeur, un chercheur ou un professionnel de l’IA, Ollama offre des opportunités passionnantes pour innover, créer et résoudre des problèmes. Le monde de l’IA est désormais entre vos mains.

  Sources

  [https:]]

  [https:]]

  [https:]]

  [https:]]

  [https:]]

   

  Rédacteur : Sébastien DA ROCHA

   

• 9:00

  GPT, capturez-les tous !

  sur Neogeo Technologies

  ChatGPT est un agent conversationnel qui peut vous aider au quotidien. Néanmoins, vous ne savez pas réellement ce que OpenAI, son créateur, fait de vos conversations. Il n’est, d’ailleurs, pas conseillé de lui parler de sujets confidentiels.

  Si vous souhaitez l’utiliser dans vos produits, l’API peut rapidement coûter très cher (compter environ 3 centimes pour le traitement de cet article par exemple, multiplié par le nombre de requêtes par utilisateur, multiplié par les demandes de chaque utilisateur…). Heureusement, la communauté Open Source propose petit à petit des alternatives.

  La première étape était la publication de Llama par Meta (Facebook). Il s’agit d’un modèle d’intelligence presque libre et limité à 500 millions d’utilisateurs. Au-delà, il faut les contacter pour avoir le droit de l’utiliser. Il est également possible de le récupérer sur nos ordinateurs et de s’en servir de façon strictement privée.

  Pour télécharger le modèle, il faut néanmoins montrer patte blanche en remplissant un formulaire et recevoir un lien, par mail, avec une durée de vie limité. En cas d’expérimentation, cela peut vite devenir contraignant.

  Démocratisation technique

  Les développeurs de llama.cpp (surtout Georgi GERGANOV) ont optimisé ce moteur qui vous permet de discuter avec les modèles Llama2.

  Les modèles de Llama2

  Llama2 est disponible en plusieurs tailles (nombre de paramètres) : 7B, 13B et 70B. L’unité « B » correspond à des milliards de paramètres.

  Sachant que chaque paramètre est stocké sur 2 octets (des flottants de demi-précision), il faut au moins 16Go de RAM pour charger le petit modèle 7B. Les gros modèles sont plus pertinents, mais beaucoup plus lents.

  Les optimisations

  Les développeurs de LLama.cpp ont travaillé sur 2 optimisations :

  • Pouvoir lancer les calculs (appelés « inférence ») sur le CPU en utilisant au maximum ses capacités (optimisation M1, AVX-512 ou AVX2…) et en codant le moteur d’inférence en C++ et sûrement des morceaux en assembleur ;
  • Compresser le modèle sans trop perdre de pertinence.

  Pour ce dernier point, ils ont développé un codage flottant du 4bits : q4_0 (d’autres variantes avec plus de bits existent). Nous pouvons désormais utiliser un modèle 7B avec 4Go de RAM ! À noter que l’on peut tout de même un peu perdre en pertinence.

  Le travail de llama.cpp est prodigieux mais difficile à utiliser : il arrive que le modèle réponde de manière erronée ou ne rende pas la main après la réponse.

  Ollama

  Désormais la relève existe : Ollama !

  Considéré comme le docker des LLM, il nous permet de télécharger, questionner, supprimer des modèles en une ligne de commande. Concernant les performances, Ollama est une surcouche en Go et utilise llama.cpp.

  Les instructions d’installation sont disponibles ici : [https:]] .

  Une fois installé, vous pouvez télécharger un modèle aussi simplement que :

  ollama pull llama2

  Une fois téléchargé, vous pouvez le questionner comme ceci :

  ollama run llama2
  
  >>> comment faire une jointure entre 2 dataframes Pandas ?
  
  There are several ways to join two pandas DataFrames. Here are a few methods:
  
  1. `merge()`: This is the most common method for joining two DataFrames. It joins the two DataFrames based on a common column, called the "join key". The joined DataFrame will have the columns from both DataFrames.
  
  ```
  
  df_left = pd.read_csv('left_data.csv')
  
  ...

  Attention, Ollama installe aussi un service Systemd en arrière-plan. Si vous préférez le lancer manuellement, au hasard pour contrôler la RAM de disponible sur votre machine, vous devez :

  # désactiver le démarrage auto avec la machine
  
  sudo systemctl disable ollama.service
  
  # Couper réellement le service
  
  sudo systemctl stop ollama.service

  Quel modèle ?

  Llama a apporté son lot de révolutions, mais d’autres équipes de chercheurs ont repris le flambeau, notamment Mistral AI qui a réussi à créer des petits modèles très efficaces.

  Récemment, Hugging Face (l’équivalent de Github dans la sphère IA) a encore amélioré Mistral en créant Zephyr, un petit modèle qui a de très bon résultats pour parler dans plusieurs langues.

  ollama run zephyr:7b
  
  >>> comment faire une jointure entre 2 dataframes Pandas ?
  
  Pour joindre deux DataFrames en Pandas, vous pouvez utiliser la méthode `merge()`. Ci-dessous une explication de comment utiliser cette méthode :
  
  1. Assurez-vous que les deux DataFrames ont une colonne commune sur laquelle joindre les données. Soit df1 et df2, on appellera cette colonne 'common_column'.
  
  ...

  Zephyr n’a pas de clause de restriction à 500 millions d’utilisateurs (licence Apache 2.0), il répond en français et sera plus économe en ressources.

  Ci-dessous, une liste de quelques modèles :

  

  S’il en détecte un, Ollama va automatiquement utiliser le GPU. Sinon, il se rabat sur le CPU en essayant de tirer parti des instructions disponibles (AVX2, AVX512, NEON pour les M1/M2…)

  Docker

  Si vous utilisez l’image docker de Ollama, il faut penser à couper le service Ollama ou à changer de port TCP d’écoute dans le docker-compose.yaml.

  Voici un docker-compose minimaliste :

  ---
  
  version: '3.8'
  
  services:
  
    ollama:
  
      image: ollama/ollama:latest
  
      ports:
  
        - "11434:11434"
  
      volumes:
  
        - ollama:/root/.ollama
  
      restart: unless-stopped
  
  volumes:
    ollama:

  Ensuite, un petit docker compose up -d pour lancer le serveur.

  Comment pouvons-nous alors lancer une inférence ?

  $ docker compose exec ollama ollama run zephyr:7b
  
  >>> Salut
  
  Bonjour,
  
  Je suis heureux d'aider quelqu'un aujourd'hui. Votre expression "Salut" est une forme courante de salutation en français. En France, c'est souvent utilisé entre amis ou entre personnes qui connaissent déjà l'un l'autre. Dans les situations où vous souhaitez être plus formel ou professionnel, vous pouvez utiliser "Bonjour" ou "Bonsoir" suivi du prénom de la personne ou simplement "Madame" ou "Monsieur" si vous ne connaissez pas le prénom.
  
  J'espère que cela vous a été utile. Si vous avez d'autres questions, n'hésitez pas à me contacter.
  
  Bien à vous,
  
  [Votre nom]
  
  >>> 

  En revanche, utiliser la console de l’image n’est pas pratique, sauf si vous souhaitez télécharger une image et plus jamais y retoucher. Et surtout, nous pouvons utiliser l’API HTTP :

  curl -X POST [localhost:11435] -d '{ "model": "zephyr:7b", "prompt": "raconte moi une courte histoire drôle"}'
  
  {"model":"zephyr:7b","created_at":"2024-01-11T15:27:47.516708062Z","response":"Il","done":false}
  
  {"model":"zephyr:7b","created_at":"2024-01-11T15:27:47.534749456Z","response":" y","done":false}
  
  ...

  Pour faciliter la lecture de l’inférence, vous pouvez afficher le texte token par token dans notre app. Il est également possible de s’en servir en python. Voici un exemple de client inclut dans le dépôt :

  [https:]]

  Il est toujours possible d’utiliser le client installé précédemment ollama en ligne de commande, pour requêter le serveur à distance :

  OLLAMA_HOST=127.0.0.1:11435 ollama run zephyr:7b-beta-q6_K "raconte moi une courte histoire drôle"

  Docker et l’accélération avec une carte graphique Nvidia

  Vous remarquerez que l’inférence dans le docker n’est pas très rapide. En effet, docker ne laisse pas le container accéder à la carte graphique, par conséquent l’inférence se fait sur le CPU.

  Pour cela, il faut installer un paquet fourni par Nvidia afin de configurer le docker proprement :

  curl -fsSL [https:] | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
  
    && curl -s -L [https:] | \
  
      sed 's#deb [https:] [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] [https:] | \
  
      sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
  
  apt update
  
  apt install -y nvidia-container-toolkit

  Une fois ce paquet installé, il faut utiliser l’outil fournit pour configurer docker :

  sudo nvidia-ctk runtime configure --runtime=docker

  Cela va modifier votre configuration de docker /etc/docker/daemon.json pour activer un runtime nvidia :

  {
  
          "runtimes": {
  
                 "nvidia": {
  
                         "args": [],
  
                         "path": "nvidia-container-runtime"
  
                 }
  
          }
  
  }

  Ensuite, il suffit de redémarrer docker :

  systemctl restart docker

  Désormais, vous devriez pouvoir accéder à votre GPU Nvidia depuis le container :

  $ docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi
  
  Unable to find image 'ubuntu:latest' locally
  
  latest: Pulling from library/ubuntu
  
  a48641193673: Already exists
  
  Digest: sha256:6042500cf4b44023ea1894effe7890666b0c5c7871ed83a97c36c76ae560bb9b
  
  Status: Downloaded newer image for ubuntu:latest
  
  Thu Jan 11 15:46:38 2024      
  
  +-----------------------------------------------------------------------------+
  
  | NVIDIA-SMI 525.147.05   Driver Version: 525.147.05   CUDA Version: 12.0     |
  
  |-------------------------------+----------------------+----------------------+
  
  | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
  
  | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
  
  |                               |                      |               MIG M. |
  
  |===============================+======================+======================|
  
  |   0  NVIDIA GeForce ...  On   | 00000000:2D:00.0  On |                  N/A |
  
  | 31%   33C    P5    32W / 225W |   1778MiB /  8192MiB |      2%      Default |
  
  |                               |                      |                  N/A |
  
  +-------------------------------+----------------------+----------------------+
  
  +-----------------------------------------------------------------------------+
  
  | Processes:                                                                  |
  
  |  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
  
  |        ID   ID                                                   Usage      |
  
  |=============================================================================|
  
  +-----------------------------------------------------------------------------+

  Une fois cela terminé, l’accès doit être donnée à votre container en modifiant le docker-compose.yaml:

  ---
  
  version: '3.8'
  
  services:
  
    ollama:
  
      image: ollama/ollama:latest
  
      ports:
  
        - "11435:11434"
  
      volumes:
  
        - ollama:/root/.ollama
  
      restart: unless-stopped
  
      deploy:
  
        resources:
  
          reservations:
  
            devices:
  
              - driver: nvidia
  
                capabilities: [gpu]
  
                count: all
  
  volumes:
  
    ollama:

  Grâce au docker compose up -d, notre inférence est désormais beaucoup plus rapide.

  Conclusion

  Nous avons découvert comment utiliser les LLM libre, avec des projets comme Ollama et Zephyr, qui rendent l’IA plus démocratique et accessible à un plus grand nombre. Plus besoin de se soucier des coûts prohibitifs de l’API OpenAI, lorsque vous pouvez exploiter ces modèles de langage gratuits et Open source.

  Que vous soyez un développeur, un chercheur ou un professionnel de l’IA, Ollama offre des opportunités passionnantes pour innover, créer et résoudre des problèmes. Le monde de l’IA est désormais entre vos mains.

  Sources :

  [https:]]

  [https:]]

  [https:]]

  [https:]]

  [https:]]

  Rédacteur : Sébastien DA ROCHA 

• 31 August 2023
• 10:13

  Séminaire, octobre 2022

  sur Neogeo Technologies

  Brainstorming, ateliers de travail, balade en fat bike sur la plage…

  L’air marin a permis aux collaborateurs de faire émerger de nouvelles idées qui confirment la vision commune des deux entreprises.

  Retour en images sur le séminaire organisé pour les équipes de GEOFIT GROUP et de NEOGEO.

   

• 10:13

  Atelier avec le SMEAG

  sur Neogeo Technologies

  En janvier dernier s’est déroulé un atelier avec les équipes du SMEAG – Syndicat Mixte d’Études et d’Aménagement de la Garonne.

  L’objectif était de présenter la maquette réalisée dans le cadre de la refonte de leur site internet. Le résultat a été très ???????, les personnes présentes ont approuvées le parcours utilisateur et le design associé.

  Nos équipes de production travaillent désormais sur la ????????????? et le ?????????????? du site.

   

• 10:09

  OneGeo Suite, interview GIP ATGERI

  sur Neogeo Technologies

  Lors des Geo Data Days 2022, nous avons eu l’occasion d’interviewer AnneSAGOT Responsable du Pôle PIGMA, et Emeric PROUTEAU, Référent technique, à propos de la mise en place d’une nouvelle plateforme de données en Nouvelle-Aquitaine.

  Ce projet, porté par nos équipes et le GIP ATGeRi, s’est passé «?????? ??? ??? ????????? », malgré les contraintes et imprévus que l’on vous laisse découvrir…

   

• 10:08

  L’Open Source

  sur Neogeo Technologies

  Chez Neogeo, nous marchons à l’Open Source ! Mais qu’est ce que l’Open Source ?
  En quelques slides, découvrez l’un de nos domaines d’expertise.

  Voir l’article