Sur le fond, je suis plus nuancé que sur la forme. Commençons par les points que j’ai appréciés. François Elie réalise ici une analyse documentée et argumentée qui complète ce que j’ai pu lire sur le sujet jusqu’à présent. Il s’agit d’un vrai travail d’analyse qui se nourrit de son expérience acquise ces dernières années au sein de l’Adullact . La théorie de la mutualisation par la demande (ie l’idée de fédérer les besoins afin de créer des logiciels libres « métier ») et l’usage « commercial » des forges, comme place de marché pour les logiciels, me semblent des idées fort intéressantes, qui ont d’ailleurs amené l’Adullact à la création de l’Adullact projet.

En outre,  le discours tenu dans son livre est dirigé principalement (uniquement …) par ces idées maîtresses. Plus encore, le modèle économique de la mutualisation par la demande serait le modèle économique le plus stable. A le lire, point de salut pour qui n’adopterait pas ce modèle (ndlr : j’exagère, bien entendu). Je regrette, au regard du titre, mais aussi de la position de l’Adullact (même si ce livre est écrit par l’auteur et pas au nom de l’Adullact), que cet ouvrage n’entre pas plus en profondeur dans les modèles économiques et n’explique pas davantage les grands principes des principaux modèles afin de donner une meilleure lecture du « marché de l’Open Source » auprès des maîtrises d’ouvrage. Je trouve qu’il y a discordance entre le titre de l’ouvrage et son contenu.

En tant que Géo-Informaticien, on notera également 4 pages sur l’OSGeo et Open Street Map, illustrant ses propos sur la mutualisation par l’offre (OSGeo ) ainsi que sur la mutualisation par la demande dans le cadre de la production et du partage de la donnée publique (sur un modèle du type Open Street Map ).

Parmi les points que je désapprouve, je note notamment un discours assez rude, sûrement encore imprégné des relations difficiles que l’Adullact avait vécues avec certaines entreprises lors du lancement de l’Adullact Projet (l’auteur ne s’en cache d’ailleurs pas dans son écrit). Les années ont passé, ces sociétés ont évolué et il est dommage de revenir sur ce passé. Mais ce que je désapprouve davantage encore, c’est le propos démagogique de ce paragraphe dans lequel toutes les entreprises du libre sont mises dans un même panier, le panier des anti-mutualistes par la demande. L’argumentaire me semble erroné et c’est oublier les principaux freins à cette mutualisation et les efforts réalisés au quotidien par de nombreuses sociétés (dont Camptocamp) pour mutualiser par la demande … La réalité (car, il faut s’en tenir à la réalité : il n’existe pas encore de place de marché logiciel …) est difficile pour que ce principe de mutualisation par la demande soit systématique : commande publique non adaptée, prise de risque des sociétés, inadéquation des calendriers et budgets, incompatibilité/non convergence des besoins, …

Pour finir sur une note positive et faire le lien entre geo-informatique et Mutualisation par la demande, il me semble que le projet GeoSource est une bonne illustration de ce principe. En analysant la réussite de ce projet, il faut se référer aux principaux facteurs de succès suivants : un commanditaire unique (l’état) au service d’une large communauté d’utilisateurs (ses services et les collectivités), la mise en place d’une infrastructure projet communautaire, des échéances courtes autour de besoins pragmatiques, une demande sensibilisée aux obligations de diffusions de leurs données dans le cadre de la directive INSPIRE, …

David Jonglez, Camptocamp SA Associate Director in charge of commercial development

We are currently working on extending the capabilities of Studio and the goal is to offer three main components:
- A tool to manage the data sources
- A tool to manage and edit MapFiles
- A tool to generate MapFish sites, with view, edit, search and query capabilities.

Studio will allow the administration of the MapFish functionalities:

But, it is also possible to use Studio as a standalone tool, in order, for example, to edit MapFiles.

Be warned: in order to fix Studio Beta, it is possible that the Studio demo site will be redeployed. In this case, your account / mapfiles will be deleted.

We are currently working on extending the capabilities of Studio and the goal is to offer three main components:
- A tool to manage the data sources
- A tool to manage and edit MapFiles
- A tool to generate MapFish sites, with view, edit, search and query capabilities.

Studio will allow the administration of the MapFish functionalities:

But, it is also possible to use Studio as a standalone tool, in order, for example, to edit MapFiles.

Be warned: in order to fix Studio Beta, it is possible that the Studio demo site will be redeployed. In this case, your account / mapfiles will be deleted.

Le Toronto Code Sprint a été l’occasion pour moi de continuer à avancer dans ce process, et faire en sorte d’améliorer encore la qualité et la robustesse du code de ces fonctions.  L’ensemble des modifications réalisées étant intégré à la future release 1.4.0 qui doit sortir sous forme d’une première RC dans un avenir très proche.

A l’issue de ces journées, en guise de bilan, a été réalisé, pour les fonctions d’export:

• Une  réécriture de l’ensemble de la fonction d’export ST_AsSVG, avec ajout de tests unitaires et de test de non régression.  Fonctionnelement, son comportement est très proche de celle de la branche 1.3… sauf qu’elle corrige un bug bloquant sur  des aggrégations de géométries volumineuses (GEOMETRYCOLLECTION) avant export SVG.
• L’ajout dans les fonctions d’export GML et GeoJson de la possibilité de générer des CRS dans un format compliant RFC 5165.  Ce format est attendu par les units tests de validation OGC (CITE) pour GML, et il est recommandé comme format préférentiel par la  spécification GeoJson 1.0.  Une évolution suivante sera de pouvoir rajouter la version de la base EPSG utilisée (envisagée pour la 1.5 de PostGIS)
• Une analyse et mise en place de la couche bas niveau permettant d’assurer un futur support des géométries de type Curves pour GML3 et SVG  (ces deux formats permettant une description des curves). Un post présente les logiques de représentation Curves pour PostGIS . Pour rappel les curves ne font pas parti de OGC SFS 1.1,  mais de ISO/SQL:MM part 3, cette dernière spécification devient le nouvel objectif de PostGIS à terme (à l’horizon de la 2.0).

Un premier prototypage pour GML3 pour les arcstrings et circularstrings a été également réalisé (mais non commité). Il reste en effet encore du travail sur les COMPOUNDCURVE et les curves surfaciques (enchainement de LINESTRING et CIRCULARSTRING).

Pour la prochaine release 1.5 de PostGIS, les fonctions d’import sont également envisagées, i.e pouvoir convertir du GML en Geométrie PostGIS native, et idem pour les KML et le GeoJson…

Bref encore une foultitude de fonctionnalités qui continuent à faire de PostGIS le SGBD spatial de référence en OpenSource.

Merci à Mark, Regina et Paul pour leurs soutiens, conseils et encouragements sur Toronto et sur la mailing list dev ,

Olivier Courtin, GIS Expert, PostGIS Developper

In order to finance fairly and equitably these required developments within the OpenERP community, we would like you to participate in the project by contributing to the improvements => for more details, please see here .

Camptocamp truly hope that individuals and companies linked to the OpenERP project will show participative and/or financial efforts in this development.

Please do not hesitate to contact Luc Maurer for any questions you may have about this call for contributions.

Thank you for your commitment and support.

Many functionalities are available:
* ergonomic design
* large amount of pregenerated base layers (aerial and national maps provided by swisstopo)
* around 50 layers that are concatenated with TileCache
* layertree with groups and radio buttons
* advanced tooltips
* high quality print

This website takes advantage of amazon web services as cloud computing infrastructure.