[Freegis-list] Call for Geo-Spatial Java API

[James Macgill]

I recently sent a message, the bulk of which is included at the end of this 
message, to key developers of a number of Java based projects suggesting 
the creation of a joint interface only project which would help us 
collaborate.

I received positive comments and support for the idea from people involved 
in deegree (JaGo), JTS, GISToolkit, OpenMap, WBK,  GeoServer and GeoTools 2 
(a project I'm involved in)

In order to continue the discussion and to thrash out issues before setting 
such a project up the suggestion was re-posted to the geoENABLER web site 
with the comment system being used to exchange ideas.

You can see the story and the comments so far at:
http://scoop.geoenabler.org/

We would welcome wider involvement and comments from members of the FreeGIS 
list so if you have anything to add please post comments to that site.  We 
are currently building a list of possible names and talking through some 
licence issues and we hope to set the project up in early November.

Many thanks

James

[The following is from the original email]

This email is to suggest the setting up of a new project to host an 
interface only API for geospatial objects in the Java language.

Some of you may have caught me making comments along these lines before, 
for others of you this will be my first contact with your project on this 
topic.

There is an enormous level of effort being carried out in the Open Source 
community towards building GIS solutions. A good deal of these use Java and 
a good many of them make at least some reference to the OpenGIS Consortium. 
As a result there is an enormous level of duplicated effort with the same 
problems being solved and implemented again and again.

A classic example of this is the number of times I have seen bounding box 
classes or interfaces being defined in peoples code. In an ideal world we 
would have one only, and one for coordinates and geometries and features 
and so on.

It would be nice to think that we could create a single mega project 
involving everyone from all existing projects and with everything being 
done only once. However, I strongly suspect that, in the short to mid term, 
that is impractical.

Each existing project has a slightly different audience, a different code 
style and a different set of goals, all of which are valid and it is 
probably impractical to satisfy all requirements within a single project. 
In addition many of the projects target different Java platforms, depending 
on needs, perhaps the most widespread in browsers (Java 1.1) the most 
accepted (Java 1.3) the most cutting edge (Java 1.4.1) or the most compact 
(J2ME)

As a solution therefore I would like to suggest a new, neutral, project 
which contains only interfaces, individual projects would then be free to 
implement these in what every way they liked, probably by wrapping their 
existing code with the new interfaces.

In an ideal world we could aim to have all of the interfaces adopted within 
the javax. namespace or perhaps as an Apache project under jakarta but both 
of those would take time or organise.

The benefits of this neutral API would start to show up immediately, 
particularly with regard to data sources. Between existing projects there 
are readers or connectors for Oracle SDE, PostGIS, MySQL, GML, Shapefile, 
MIF/MID and many more. For most of these, particularly Shapefile, there are 
multiple implementations. With a common API for the core data structures we 
would be able to use each others loaders within our own projects.

As a start I would suggest interfaces for the following:

Geometries - point, line, polygon, etc. (possibly ISO 19107 based)
Feature - attribute information + geometry + meta data (possibly ISO 19109 
based)
FeatureSource - an object from which features can be obtained, stored. i.e. 
a loader
Style - how to represent a given feature (probably based on the OpenGIS 
Styled Layer Descriptor)
Filter - used to express a query (covers things like within, intersects etc)
Map - Concepts like Layer, Area of Interest, visibility and possibly zoom 
level....
Render - takes a Map definition and produces rendered output.

The above list reflects my raster bias and doesn't cover things like 
coordinate transformation but it is a start.

The further you go down that list the more chance there is for disagreement 
and I feel that to try for all of them at once would be a mistake anyway as 
it would involve too many changes in existing code.

The idea that there should be a single interface for a polygon is not a 
hard sell and I suspect that many of us already use or are considering 
using the excellent Java Topology Suite (JTS) as that base. Moving onto a 
more complex object like Feature would come next and at that point a common 
data source interface would be trivial.
Interfaces for things like styling or rendering would be harder to 
harmonize on and could come much further down the line.

I have some quite detailed ideas on the above, but I do not want this email 
to become too long or detailed yet.

For anyone who doesn't know me I should be clear about what the project I 
am involved with is and how that will have biased the above description.

I am one of the lead developers on GeoTools 2 (GT2) a LGPL project in Java 
for processing geospatial data. It is heavily influenced by the 
specifications that come out of the OpenGIS Consortium so this reflects the 
way I think about Features, Filtering and Style.

GT2 already has an interface only core with separate modules which then 
implement those interfaces, so in part what I am suggesting is a process 
whereby those core interfaces are extracted, modified and placed into an 
external, natural, project. Doing just that however, would not take us much 
further forward and it would not lead to confidence in the process being 
project natural.

To succeed the new project would need to be jointly managed by members of 
multiple projects, it needs to remain focused and not try to take on too 
much. It needs to be a resource that projects can use as little or as much 
of as they like and still see some benefit.

I would very much welcome comments on this proposal from project leads (and 
anyone else for that matter)...

[If you have any thought on the above please use the comments system on the 
geoEnabler web site to respond http://scoop.geoenabler.org/]