Discussion :

[eclesia]

Bonjour,

Annoncé il y a quelques jours sur les listes, voici le message d'origine :
(Rapide résumé en francais à la fin)

We are pleased to announce the new free software project Geotoolkit which is
building a world class, standards based, Java language code library for
geospatial applications.

The Geotoolkit web site is available at

http://www.geotoolkit.org/

which is automatically generated from the code itself.

Geotoolkit is free software. Daily builds of the project as binaries and source
code bundles are available from the project web site. The code is licensed to
anyone for any use except that re-distribution comes with some minor
responsibilities designed to ensure the same freedoms for the recipients. The
code is currently licensed to all users under the terms of the GNU Lesser
General Public License version 2. The code copyright is assigned to the Open
Source Geospatial Foundation (OSGeo). The source code is available to online at

http://hg.geotoolkit.org/

and can be obtained using the mercurial distributed version control system with
the call:
hg clone http://hg.geotoolkit.org/geotoolkit/
which will provide users with a fully independent copy of the repository
including the full history of the project itself and able to generate locally a
working copy of any revision.

Geotoolkit is based on standards shared broadly by the geospatial community.
Geotoolkit leverages the GeoAPI project which defines Java language interfaces
for the standards published jointly by the International Organization for
Standardization (ISO) and the Open Geospatial Consortium (OGC). The core
Geotoolkit library currently implements the following standards:
ISO 19103 Geographic Information --- Conceptual schema language
ISO 19115 Geographic Information --- Metadata
ISO 19111 Geographic Information --- Spatial referencing by coordinates
while extensions implement:
ISO 19108 Geographic Information --- Temporal schema
OGC 05-078r4 OpenGIS Styled Layer Descriptor Profile of WMS --- sld
OGC 05-077r4 OpenGIS Symbology Encoding Implementation Specification --- se
and there are plans to implement more of these standards and their profiles.

Geotoolkit aims to be clean and well designed. The library should build and
deploy a full version of the code every day, including the maven jars and
artifacts, the project web site, and the API javadocs. The code should open in
the major Integrated Development Environments without errors or warnings (except
where such warnings are wrong). All public code should be correctly documented,
must follow the design of the Java language, and should be designed properly for
method and field access, class inheritance, and code reuse.

Geotoolkit is built on the strengths of the Java language. The library follows
the architectural design of the core Java library so as to provide the Java
programmer with a familiar programing environment. The library exploits recent
improvements to the language syntax for improved code quality. The library aims
to run on the recent, high performance virtual machines developed by the major
providers of Java implementations for maximum performace.

Geotoolkit uses the Mercurial distributed version control system. These systems
such as Git, Bazaar, and Mercurial have recently swept the free software world
due to a fundamental technical superiority over previous generation systems.
Among the advantages of these new systems, they allow every developer to be the
master of their own destiny, unfettered to advance in any direction they see fit
and able collaborate with anyone in any way they choose. Mercurial is one of
these systems, recently chosen by Sun for its work on Java, by the Python
community for hosting the Python code, by the Mozilla foundation for hosting the
Firefox project, and by several other major projects.

Project goals will be targeted to making the library as good as it can be rather
than meeting any technical or marketing need of any third part project. The
library will aim to provide regular releases. The project will develop, as the
user community grows, a formal process by which contributions can be integrated
to the central repository.

The governance model for Geotoolkit has not yet been finalized but it will aim
to separate out the community management aspects of governance from the
technical decisions.

Geotoolkit hopes to become a project of the Open Source Geospatial Foundation
(OSGeo). It has formally asked to be accepted for incubation with the foundation
which is the usual preparatory step for projects wishing to be accepted by the
foundation.

Several projects already use the Geotoolkit library. The Constellation web
server (http://www.constellation-sdi.org/) provides high-performance web
services conformant with the CSW, SOS, WMS and WCS specifications of the Open
Geospatial Consortium based on Geotoolkit. The MDWeb project
(http://www.mdweb-project.org/) provides both a server for metadata conformant
with CSW-T and a web client based on the capabilities of Geotoolkit. The
MapFaces project (http://www.mapfaces.org/) provides a framework for building
web clients based on the geospatial infrastrcture and local rendering
capabilities provided by Geotoolkit. The desktop client Puzzle GIS
(http://puzzle-gis.codehaus.org/) uses Geotoolkit as its base library. We also
know of one comercial application already being built using Geotoolkit.



Geotoolkit is a fork of the GeoTools library. Geotoolkit retains the long term
goal but differs in its work approach: keeping the fundamental requirement of
user freedom but restoring an emphasis on code quality, following closely the
improvement of the Java language itself, leveraging new tools for decentralized
collaboration, affirming the independence of the project from any specific user
community, and restructuring the governance model.

Anyone interested by the Geotoolkit library, by our goal of building a great
Java language geospatial library, and by our vision for a distributed,
collaborative project should look at the Geotoolkit web site, browse the
javadocs API documentation, clone the source code repository to build and tinker
with it, try out the commandline tools, and see if the project suits their
needs. Projects which are based on GeoTools today can be ported to Geotoolkit
relatively easily using a migration tool in Geotoolkit, other geospatial
projects will have to evaluate how to transition towards the ISO/OGC spatial
data schema and the GeoAPI interfaces.

En résumé :
GeotoolKit réprend l'objectif d'origine de GeoTools 2, a savoir, une librairie avec un code de qualité et le respect des normes OGC/ISO. GeotoolKit est un fork de Geotools qui utilise les dernieres technologies du langage Java (1.6 et non plus 1.5) ainsi qu'un outil plus efficace pour la collaboration (Mercurial et non plus Subversion).
Meme si GeotoolKit vient juste de sortir, cette librairie sert deja de base pour bon nombre de projets :
- Constellation (Serveur Web)
- MapFaces (Client Web)
- MDWeb (Client/Serveur de metadonnée)
- Puzzle-GIS (Application Desktop)

[bouye]

Ah au moins c'est un peu plus clean d'avoir enleve tout ce qui est deprecated
Hum, cote didacticiel et doc... y en a toujours pas et quant a celle de GeoTools...........
Cote composant d'affichage, c'est toujours le neant total...
Cote desktop... meme combat...

Ah, le SIG Java ou comment se prendre la tete grave pour arriver a avoir un truc simple qui marche !

[eclesia]

héhé
Tu oublis que Puzzle-GIS c'est mon appli, et comme tout les composants swing viennent de geotoolkit-pending. il commence a y en avoir quelque uns.

Ce que ne dis pas l'annonce, c'est que Geotoolkit a un nouveau moteur 2D et un 3D en cours de développement (les deux étant fait ... par moi )

Aller un petit apercu :



Autre chose que ne dis pas l'annonce, c'est que la seule personne capable de développer le module référencing, c'est Martin DesRuisseaux (qui est mon maitre Java et le dernier des fondateurs encore actifs de GeoTools 2 ainsi que GeoAPI). Et cette personne est a l'origine de GeotoolKit et vient de démissionner en quelques tres courtes lignes de Geotools .

En réalité ce qui c'est passé, c'est que le projet geotools c'est mit a aceuillir de plus en plus de monde, mais aussi et en bonne proportion des incompétants aussi bien en Java qu'en SIG, d'autant plus que l'un de ses incompétants c'est hissé à une place de PMC et donne a tour de bras des droits des commits a ses stagiaires. Je te laisse imaginer le m... que geotools est en train de devenir depuis un an.

Geotools, sur sa pente actuelle, va mourir a petit feu faute de structure et de qualité.
GeotoolKit a un tres bel avenir .

Si tu veux en discuter d'avantage, on est sur irc : irc.freenode.net , canal #geotoolkit

[bouye]

Justement (voir l'autre post) pour le moment je ne suis pas vraiment convaincu (non que je doute de la qualite de tes composants*, mais le manque de clarte, de didacticiel -concis et a jour-, bref d'accessibilite pour ceux qui debutent ou meme de facilite d'integration des beans et des libs). Bref je le dis et le redis, je tatonne depuis bien trop longtemps sans vraiment savoir ou je vais**... Autant que la qualite du code, c'est aussi tout ca qu'il faudrait revoir en fond...

*D'autant plus que comme je le disais le JMapPane est lui programme avec les pieds (ce dont je me suis rendu compte lorsque j'ai essaye de l'integrer dans JavaFX).

**Ce n'est pas que ca me generai d'ecrire des didacticiels pour autrui mais juste que la, meme moi je n'arrive a rien de probant... et ca fait longtemps que je tourne en rond.

Je vais rejeter un coup d'oeil a Puzzle, vaut dire que la version 0.2 etait... euh, j'vais rester poli (ca plantait sans rien afficher chez moi). Mais bon entre mon boulot qui bloque le telechargement et mon FAI qui deconne, c'est aussi la croix et la banniere.

[eclesia]

Pour puzzle, ce n'est sans doute pas enormement mieux ^^, quoi que moi je n'ai pas vraiment de soucis, mais bon entre le developpeur de l'appli et l'utilisateur qui clique un peu partout ...

Bref on compte faire des tutos de base pour geotoolkit.
Qu'est ce qui te parait intéressant d'avoir comme exemple et sujet pour ceux-ci ?

[boreal]

Justement (voir l'autre post) pour le moment je ne suis pas vraiment convaincu (non que je doute de la qualite de tes composants*, mais le manque de clarte, de didacticiel -concis et a jour-, bref d'accessibilite pour ceux qui debutent ou meme de facilite d'integration des beans et des libs). Bref je le dis et le redis, je tatonne depuis bien trop longtemps sans vraiment savoir ou je vais**... Autant que la qualite du code, c'est aussi tout ca qu'il faudrait revoir en fond...

C'est un projet Open source, donc libre à toi d'y participer en proposant des ébauches de didacticiels (on les complétera avec beaucoup de plaisir). Il faut bien comprendre que sur un projet pareil on ne peux pas être partout à la fois, et pour l'équipe de Geotoolkit pour l'instant, la priorité c'est la qualité du code produit.

[bouye]

PS quand on quote faut penser à lire en entier

**Ce n'est pas que ca me generai d'ecrire des didacticiels pour autrui mais juste que la, meme moi je n'arrive a rien de probant... et ca fait longtemps que je tourne en rond.

L'Open Source n'est pas sensé être une piêtre excuse pour pallier à une absence d'accessibilité ou de description de l'API.

Pour l'instant je reste concentré sur deux choses :

• Le sacro-sain GeoTools/Geotoolkit/Tiny-GIS et ses multiples moutures/fork/dérivation/nouveau projet qui est sensé être meilleur que l'original car l'original barre en c..., un projet qui semble partir dans tous les sens sans réelle concertation et qui n'est même pas fichu d'offrir un composant d'affichage correct (un comble je trouve), dont je ne sais même pas au final dans quelle direction il me faut partir pour une intégration desktop (apparement c'est soi serveur, soit web -applet- et pour des composants desktop faut des API qui reposent sur une version plus ancienne).
  
  En pastichant à peine, la question qui revient le plus souvent sur le net "Mais comment je fais pour afficher xxx, le didacticiel (pas à jour) de GeoTools me dit d'utiliser le JMapPane mais il n'est pas dans l'API ?" et la réponse "Ah ben pour une raison XYZ qu'on ne citera pas, on a décidé de ne plus le fournir pre-compiler, faut aller télécharger les sources, récupérer toutes les libs qu'on a pas été foutu de lister et le recompiler. Vous z'inquietez pas en l'an -40 avant JC on a décidé de pondre de nouveaux composants d'affichage, on devrait les avoir d'ici 2 à 300 ans" (note : Julien il ne s'agit pas là d'un attaque perso).
  
• Open Map (http://openmap.bbn.com/ ah vi c'est Open Souce) qui a défaut d'être aussi "puissant" dispose d'une API claire, plutôt bien écrite dans laquelle je n'ai pas à me prendre le chou grave pour ajouter des calques bitmap, créer mes propres plugins (nouveaux types de calque), avoir un affichage sur 360°, réécrire mes propres controles en remplacement de ceux (moches) fournis avec, etc...
  
  Il a également ses propres défauts comme par exemple la gestion des images/raster de grande taille. Apparement il me faudra implémenter le support du JAI moi-même.

Seulement voilà, on me fait remarquer que ca serait mieux de se rapprocher des standard du SIG or ces standards semblent être incarnés par GeoTools.

Pour info il y a un mois et demi, un collègue cherchait à intégrer un composant/contrôle GIS dans une API VB.NET, et desespérait du peu de choses dispo sous .NET (par rapport au monde Java). En l'espace de deux recherches Google, je lui ai trouvé MapWindows GIS (http://www.mapwindow.org/ ben mince alors c'est OpenSource aussi) qui est grosso-modo tout ce que GeoTools n'est pas... depuis il l'a intégré aisément à son app VB.NET, à une app VBA, etc...

[eclesia]

Pour l'instant je reste concentré sur deux choses :

• Le sacro-sain GeoTools/Geotoolkit/Tiny-GIS et ses multiples moutures/fork/dérivation/nouveau projet qui est sensé être meilleur que l'original car l'original barre en c..., un projet qui semble partir dans tous les sens sans réelle concertation et qui n'est même pas fichu d'offrir un composant d'affichage correct (un comble je trouve), dont je ne sais même pas au final dans quelle direction il me faut partir pour une intégration desktop (apparement c'est soi serveur, soit web -applet- et pour des composants desktop faut des API qui reposent sur une version plus ancienne).
  
  En pastichant à peine, la question qui revient le plus souvent sur le net "Mais comment je fais pour afficher xxx, le didacticiel (pas à jour) de GeoTools me dit d'utiliser le JMapPane mais il n'est pas dans l'API ?" et la réponse "Ah ben pour une raison XYZ qu'on ne citera pas, on a décidé de ne plus le fournir pre-compiler, faut aller télécharger les sources, récupérer toutes les libs qu'on a pas été foutu de lister et le recompiler. Vous z'inquietez pas en l'an -40 avant JC on a décidé de pondre de nouveaux composants d'affichage, on devrait les avoir d'ici 2 à 300 ans" (note : Julien il ne s'agit pas là d'un attaque perso).
  
• Open Map (http://openmap.bbn.com/ ah vi c'est Open Souce) qui a défaut d'être aussi "puissant" dispose d'une API claire, plutôt bien écrite dans laquelle je n'ai pas à me prendre le chou grave pour ajouter des calques bitmap, créer mes propres plugins (nouveaux types de calque), avoir un affichage sur 360°, réécrire mes propres controles en remplacement de ceux (moches) fournis avec, etc...
  
  Il a également ses propres défauts comme par exemple la gestion des images/raster de grande taille. Apparement il me faudra implémenter le support du JAI moi-même.

Seulement voilà, on me fait remarquer que ca serait mieux de se rapprocher des standard du SIG or ces standards semblent être incarnés par GeoTools.

Merci de ne pas mettre sur le dos de GeotoolKit toutes les tares de Geotools.

Le projet est divisé en 3 parties :

GeotoolKit :Tous les modules de GeotoolKit ont été révu un à un, classe par classe, optimisé, testé et documenté avant d'etre intégré, c'est les conditions de qualité qu'exige le projet. Tu trouveras difficilement quelque chose a redire de ces modules. Ils n'ont plus rien a voir avec geotools.
GeotoolKit-pending : Tous ses modules n'existent pas dans geotools. Ils sont encore en développement avec des niveaux différents de documentation/test/optimisation.Mais ils sont deja d'une toute autre qualité que ceux de geotools.
Geotools-Modified : Les derniers modules de geotools utilisé dans geotoolkit-pending. Les dépendences vers ceux ci sont réduites au minimum et progressivement retiré.