[Java-collab] Introduction and a few suggestions on recent topics

Martin Desruisseaux martin.desruisseaux at geomatys.fr
Wed Aug 12 18:50:27 EDT 2009


Hello all

To follow on the GeoAPI discussion, I realize that the geotoolkit fork has 
created tension on both side. But I don't think that GeoAPI should be a victim 
of that. Its design is mostly the product of a tierce party, OGC/ISO, on which 
it should be possible to find consensus if our aim is to find a balance between 
standards and Java usability. We worked hard lately in documenting fully how 
GeoAPI matches OGC/ISO (http://www.geoapi.org/snapshot/javadoc/content.html), 
purging some elements that are not from OGC/ISO, documenting the departures 
(http://www.geoapi.org/snapshot/javadoc/departures.html) so that anyone can find 
quickly the most arbitrary design choices and critic them (if we wanted to force 
our design decisions, we would not have documented them - we would have keeped 
them hiden), integrated UML in the javadoc, etablished a monthly release policy 
and generated for each release a list of difference compared to previous release 
(http://www.geoapi.org/changes/index.html), wrote a first draft of GeoAPI spec. 
(http://jira.codehaus.org/secure/attachment/42434/GeoAPI_3.0.0_draft.pdf), etc.

The French national mapping agency (IGN) has partially translated GeoAPI 
interfaces from Java to Flex (to be commited on GeoAPI SVN probably this 
automn). All this stuff has happened in the last few months.

We are trying to put GeoAPI under OGC rules, which is more open to the community 
that some believe. Many contributors of the proposed geometry project are OGC 
members - they should not fear dictatorial attitude if the project is governed 
by an OGC charter and ISO specifications. The mean thing that I (and some other 
OGC members) expect is to keep the amount of extensions (stuff not in OGC/ISO 
specifications) low, which should help to reduce controverse. Such extensions 
can be left to implementors or other collaborative projects.

     Regards,

         Martin


More information about the Java-collab mailing list