Données géographiques

• [^]Re: Données géographiques

  Posté par Pierrick Le Gall (page perso, ) le 12/10/2007 à 17:38. (lien). Évalué à 5.

  Salut Vincent (on étais à l'école ensemble)
  
  

  A noter que camptocamp sort une extension à Talend Open Studio, nommée SDI comme Spatial Data Integrator.

  
  En effet, CampToCamp va fortement collaborer avec Talend pour fournir des traitement spécifiques aux données géographiques.
  
  

  Est ce que vous envisagez d'intégrer un générateur de code python

  
  Non, ce n'est pas dans la roadmap. Chez Talend, il n'y a pas (encore ?) de compétence Python. La question a cependant déjà été évoquée sur notre forum. Je pense que s'il y a des débouchés commerciaux et qu'on arrive à recruter des compétences, il n'y a pas de raison de ne pas le faire :-)
  
  Pour le moment, entre Perl et Java, le moteur de génération est très proche. A mon avis, un langage comme Python nécessitera davantage de développements. Je pense qu'il serait par exemple plus simple d'ajouter Ruby que Python.

  • [^]Re: Données géographiques

    Posté par Farzad FARID (page perso, ) le 13/10/2007 à 18:38. (lien). Évalué à 5.

    Pour le moment, entre Perl et Java, le moteur de génération est très proche. A mon avis, un langage comme Python nécessitera davantage de développements. Je pense qu'il serait par exemple plus simple d'ajouter Ruby que Python.

    
    
    Excellente suggestion, je n'osais pas la faire et je suis content que ce soit un ingénieur de Talend qui la fasse :)
    
    Je pense en effet que la production de code ETL en Ruby serait une excellente chose, le langage lui-même et surtout le framework de développement ayant le vent en poupe et servant dans de plus en plus de projets actuellement.
    
    Je me demande si cette suggestion pourrait être prise au sérieuse et quel somme de travail demanderait cette implémentation ?

    • [^]Re: générer du Ruby

      Posté par Pierrick Le Gall (page perso, ) le 14/10/2007 à 21:28. (lien). Évalué à 3.

      Je pense en effet que la production de code ETL en Ruby serait une excellente chose [...]

      
      Je trouverais ça sympa également, ça pourrait me donner l'occasion d'apprendre Ruby. (et Python aussi d'ailleurs, j'aimerais bien apprendre)
      
      Ensuite il faut être pragmatique : est-ce que les performances de Ruby sont suffisantes pour de gros volumes de données ? Est-ce que Ruby dispose de nombreux connecteurs ? Est-ce possible en France de recruter des développeurs Ruby ? Et surtout, est-ce qu'il y a des retombées commerciales potentielles ? (derrière Talend Open Studio, il y a une entreprise qui rémunère des salariés)
      
      Aujourd'hui Ruby est connu grâce à et pour Ruby On Rails [1], le framework hype de développement Web. Dans Talend Open Studio, on est loin du développement Web (aucun rapport même, si j'ose dire). Donc est-ce que dans les entreprises, les personnes qui font du Ruby sont ceux à qui on va demander d'utiliser Talend Open Studio ? et hors entreprise, est-ce que le développeur Ruby est intéressé par un outil comme Talend Open Studio ?
      
      Je n'ai pas de réponses à toutes ces questions. Je pense simplement qu'il faut qu'elles trouvent des réponses avant qu'on puisse s'engager dans cette voie.
      
      

      [...] quel somme de travail demanderait cette implémentation ?

      
      Comme je le suggérais dans mon message précédent, je pense que le moteur de génération de code a besoin de peu de modifications. Par contre, c'est le développement des composants qui demandera un gros travail. Certains se développent en quelques minutes (tLogRow basique), d'autres en plusieurs jours/semaines (tAggregateRow, tMysqlSCD). Si on voulait être "isofonctionnel" Ruby/Perl il faudrait plusieurs mois de dev et Ruby/Java encore davantage.
      
      [1] http://www.rubyonrails.org/

      • [^]Re: générer du Ruby

        Posté par doupatex () le 15/10/2007 à 04:57. (lien). Évalué à 4.

        est-ce que les performances de Ruby sont suffisantes pour de gros volumes de données ?

        
        
        Aujourd'hui, il existe plusieurs implémentations de Ruby : l'interpréteur C "original" (écrit par Matz, Yukihiri Matsumoto), la machine virtuelle YARV/Ruby2, JRuby, Rubinius, ...
        
        L'interpréteur est assez lent (un petit peu plus que Perl dans les benchmarks). YARV était environ 4 fois plus rapide il y a quelques mois pour mes scripts maison, mais est encore en développement. JRuby est une implémentation complète niveau fonctionnalités, les performances sont équivalentes à l'interprèteur C, et on peut compiler en bytecode JVM (ou utiliser le JIT, voir http://www.headius.com/jrubywiki/index.php/JRuby_Compiler pour plus d'info).
        
        

        Est-ce que Ruby dispose de nombreux connecteurs ?

        
        
        Si tu parles des bibliothèques d'accès aux SGBD écrites en C, c'est assez fournit ; Oracle, PostgreSQL, SQLite, ... Avec JRuby, je suppose qu'on peut utiliser JDBC, donc pas de soucis.
        
        

        Est-ce possible en France de recruter des développeurs Ruby ?

        
        
        Si l'on en croit http://rubyfr.org/ , ça doit exister... Il y a même une carte de France des rubyistes :-)
        
        <publicité éhontée>Sinon ya moi :-))))</publicité éhontée>
        
        

        Et surtout, est-ce qu'il y a des retombées commerciales potentielles ?

        
        
        Je manque de stats sur le sujet, mais je pense que Ruby est un très bon complément au Java (via JRuby), par exemple pour des règles métier complexes et fréquemment mises-à-jour. Ce que je veux dire, c'est que c'est une solution peu utilisée, mais qui a toutes les fonctionnalités de Perl avec une syntaxe objet plutôt agréable, et qui gagnerait à être connue (Rails est l'arbre qui cache la forêt). Les perlistes ne devraient pas avoir trop de difficultés à comprendre un script Ruby (c'était un des buts du créateur du langage).
        
        
        Pour résumer, je crois que si on peut le faire en Perl, on peut aussi le faire en Ruby : les langages sont assez similaires tant au niveau de l'implémentation (vitesse d'exécution) qu'en ce qui concerne les "cibles" potentielles. Après, c'est surtout une question de goûts (je trouve le Ruby plus lisible, au cas où vous ne l'auriez pas deviné ;-) )

      • [^]Re: générer du Ruby

        Posté par Antoine () le 15/10/2007 à 12:28. (lien). Évalué à 3.

        Ensuite il faut être pragmatique : est-ce que les performances de Ruby sont suffisantes pour de gros volumes de données ? Est-ce que Ruby dispose de nombreux connecteurs ? Est-ce possible en France de recruter des développeurs Ruby ? Et surtout, est-ce qu'il y a des retombées commerciales potentielles ?
        
        Pour répondre aux mêmes questions concernant Python :
        
        1. ça dépend de quels types de performances on parle. S'il s'agit d'algorithmes purement calculatoires sur de gros jeux de données, Python est un peu plus rapide que Perl et Ruby ( http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...) ), mais loin du C ou d'autres langages.
        Ceci dit il est aisé de reprogrammer des boucles critiques, soit en C, soit dans un pseudo-Python traduit en C grâce à Pyrex ( http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ ).
        De plus, il y a plein de bibliothèques performantes pour les besoins courants en Python. Il y a même du calcul scientifique avec Numpy ( http://numpy.scipy.org/ ).
        Enfin il y a un optimiseur just-in-time qui permet une accélération appréciable sur certains types de code, Psyco.
        
        2. les connecteurs sont dispos pour tous les SGBD majeurs du marché, de même que pour Perl et Ruby. Il y a aussi un ORM sophistiqué, SQLAlchemy.
        
        3. ben oui, j'en suis la preuve vivante (que les développeurs existent, pas forcément qu'ils sont faciles à recruter :-))
        
        4. c'est effectivement la question majeure pour vous. A mon avis, hormis le Web, Python a une communauté d'utilisateurs plus développée que Ruby (simplement parce que le langage est arrivé à un stade de maturité plus tôt, et les deux langages étant assez proches sur le plan sémantique, il n'y a pas de raison forte d'abandonner Python pour Ruby). Par ailleurs, Python et Ruby sont tous deux sur une phase ascendante, alors que Perl est manifestement en fort déclin.
        Ceci dit, il est évident que Python et Ruby sont très loin de constituer le même marché potentiel que Java ou C#.

      • [^]Re: générer du Ruby

        Posté par Farzad FARID (page perso, ) le 15/10/2007 à 17:29. (lien). Évalué à 2.

        Je trouverais ça sympa également, ça pourrait me donner l'occasion d'apprendre Ruby. (et Python aussi d'ailleurs, j'aimerais bien apprendre)

        
        Pour que mes propos ne passent pas pour du troll, je précise que j'ai utilisé et fait la promotion de Python pendant presque 13 ans. Mais je suis passé sans regret à Ruby l'année dernière car ce langage combine le meilleur de Python et de Perl, en plus de ses propres apports...
        
        

        Ensuite il faut être pragmatique : est-ce que les performances de Ruby sont suffisantes pour de gros volumes de données ? Est-ce que Ruby dispose de nombreux connecteurs ? Est-ce possible en France de recruter des développeurs Ruby ? Et surtout, est-ce qu'il y a des retombées commerciales potentielles ? (derrière Talend Open Studio, il y a une entreprise qui rémunère des salariés)

        
        Quant la machine virtuelle YARV sera intégrée dans Ruby2, les performances du langage exploseront celles de Perl :)
        
        Les développeurs Ruby sont encore un peu rares (ou alors bien cachés), mais la demande des entreprises est de plus en plus forte cette année ! J'ai moi-même été sollicité plusieurs fois pour des projets en Rails alors que je suis encore débutant. Je connais des développeurs expérimentés qui sont passés récemment d'Objective C (sur Mac) ou de Java/EJB à Rails. Je pense que la diffusion du langage et de Rails connaîtra une explosion dans les années à venir.
        
        Quant aux retombées commerciales, comme tu le dis, c'est le marché qui le dictera, mais je pense que les clients voudront plus de Java d'un côté, plus de Ruby/Python de l'autre, et moins de Perl.
        
        Le besoin d'ETL en Ruby et d'intégration en Rails existe, il n'y a qu'à voir le projet "ActiveWarehouse [1]" et son sous-projet "ETL Tools [1]"
        
        [1] http://activewarehouse.rubyforge.org/
        [2] http://activewarehouse.rubyforge.org/etl/

• [^]Re: Données géographiques

  Posté par baud123 (Jabber id, page perso, ) le 12/10/2007 à 17:42. (lien). Évalué à 4.

  Pourrais-tu détailler un tout petit plus la notion d'"ETL géographique" ? :D
  
  Je suppose qu'il y a des fichiers normalisés existants [1] (produits par divers systèmes intégrant un GPS... par exemple, autres ?) et qu'il s'agit de les intégrer à un système d'information géographique (genre basé sur Mapserver, autre ?) ou directement dans un base PostGIS avec les connecteurs (normalisés aussi ?) qui vont bien ?
  
  [1] http://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27information_g%(...)

  • [^]Re: Données géographiques

    Posté par Larry Cow () le 12/10/2007 à 21:50. (lien). Évalué à 1.

    Ca doit pouvoir permettre - notamment - d'agréger des données géo et des données non-géo. Comme par exemple de mettre en lien une table spatiale des clients et des données non-spatiales concernant ces mêmes clients. Quelque-chose comme ça. Ou pas.

    • [^]Re: Données géographiques

      Posté par Libre (page perso, ) le 15/10/2007 à 12:32. (lien). Évalué à 2.

      Bonjour,
      
      Dans le monde du SIG , nous avons de nombreux formats de données (au moins une 40e raster + vecteur). Premier intérêt : gérer et transformer n'importe quel format de données en un autre.
      
      Les données sont génériques, nos besoins (en tant que client d'un fournisseur de données) ne sont pas toujours en adéquation avec les données attributaires fournit. Deuxième intérêt : filtrer les données superflux (ie virer des champs), aggréger, transformer, modifier, filtrer des données en entrés pour éviter d'avoir des données trop importante.
      
      Les données sont souvent très importantes, et se taper à la main quelques Go à la main, c'est ... Bref .Troisième intérêt : automatiser des taches sur des données spatiales, sauver la procédure pour une utilisation lors d'une mise à jour.
      
      Les données sont des données spatiales, on ne veut pas toute la France quand on travaille que sur l'Ile de France, on veut pouvoir faire d'autres traitement spatiaux. Il existe des logiciels pour cela, ceci-dit inclure ce genre de tache dans le processus de préparation de données tel que le propose le logiciel de Tallend est très intéressant.
      
      En espérant avoir fournit quelques réponses aux questions.
      
      Y. en attente de ce fabuleux joujou :)

      --
      http://softlibre.gloobe.org

Licence des scripts générés

• [^]Re: Licence des scripts générés

  Posté par Ludovic Gasc (Jabber id, ) le 13/10/2007 à 09:17. (lien). Évalué à 5.

  Oui, Talend génère des scripts Java ou Perl.
  
  Pour le contexte d'execution, tu choisis ce que tu veux, mais par défaut, il te sort un zip autonome qui contient tout ce qu'il faut pour executer le script (script+librairies).
  Le seul pré-requis est d'avoir la machine virtuelle java ou perl.
  
  J'ai vu dans les scripts générés une référence à la licence LGPL.

• [^]Re: Licence des scripts générés

  Posté par Pierrick Le Gall (page perso, ) le 14/10/2007 à 21:11. (lien). Évalué à 2.

  Copyright (c) 2005-2007, Talend Inc.
  
  This source code has been automatically generated by Talend Open Studio
  / JobDesigner (CodeGenerator version 2.2.0.qualifier).
  You can find more information about Talend products at www.talend.com.
  You may distribute this code under the terms of the GNU LGPL license
  (http://www.gnu.org/licenses/lgpl.html).

  
  
  Donc c'est bien du LGPL comme Ludovic le dit.
  
  Je confirme également que l'intérêt du générateur de code est de créer des scripts autonomes. Pour répondre un peu plus généralement, Talend Open Studio est un client, pas un serveur.

A quoi ça sert ?

• [^]Re: A quoi ça sert ?

  Posté par d-jo (page perso, ) le 13/10/2007 à 16:27. (lien). Évalué à 1.

  Comme post scriptum, j'ajouterais, qu'une série d'exemples ne constitue certes pas une preuve, mais enfin ça aide bien à comprendre quand même.

  • [^]Re: A quoi ça sert ?

    Posté par baud123 (Jabber id, page perso, ) le 13/10/2007 à 18:58. (lien). Évalué à 4.

    je n'avais pas dit que tu faisais fausse route... simplement que tu pensais l'ETL comme une finalité alors que c'est un moyen :
    - à relecture de tes commentaires et des miens, tu voyais l'ETL comme le stockage centralisé de plusieurs données
    - alors que l'objet de l'ETL c'est d'acheminer les données, les faire circuler en adaptant les modèles de données d'une application à l'autre au besoin
    
    Si tu veux je pousse la caricature à fond, l'ETL c'est ce qui te permet d'écrire facilement :
    INSERT INTO PAIE.employé (id_employé_paie,etat_paie_employé...)
    SELECT FROM RH.employé(id_employé_rh, etat_rh_employé...)
    
    cela suppose que tu as aux deux extrémités une application de paie et une application de gestion des Ressources Humaines qui en effectuent le stockage (et les traitements afférents). L'ETL permet de "normaliser" via l'outil tous ces flux de données, par exemple quand tu changes l'un des logiciels bin tu changes au niveau de l'ETL et non pas dans tous les autres logiciels, en terme de développement c'est un des intérêts. En terme de fonctionnement ça évite d'avoir foultitude de scripts de partout qui se déclenchent on ne sait pas comment et qui ne sont même pas tous développés dans les mêmes langages... (ce qui donne un espoir de faire de la réutilisation via l'ETL des interfaces déjà développées).
    Pose plutôt des questions précises si tu veux des réponses précises ;-)