Java GIS - So why don't we work together?
Someone pointed me at an interesting new project .... actually an interesting old project in new cloths. The Spatiotemporal Epidemiological Modeler is a little component for the eclipse Open Healthcare Framework.
And it includes one feature (out of many) of interest to this discussion: A GIS.
This is exactly what I want to see happen; GIS as a widget that can be rolled into your application de jour.
The actual widget is kind of fun; the data format makes use of Geography Markup Language (GML) to define its polygons and so on. Yes it is an Eclipse RCP application, and no they did not talk to us about using uDig. You can uDig in your own RCP applications - but what they have is nice and specific to their data format. They even have google earth integration - looks like they could of talked to GeoServer and saved some effort.
I assume there was just not enough time / energy / benefit to the developers to work with a larger community on this one. uDig offers an intergration platform so you can roll all kinds of data formats into the same projection and see it on the screen - making use of a number of open source projects to get the job done.
What do we have to work on?
There are several areas of neutral grounds for Java open source projects to meet, greet, and share common geospatial interfaces.
At a low technical level most projects are making use of the JTS Topology Suite to get their polygon game on. Sometimes they wrap the beast up in modern ISO Geometry clothing, and sometimes they just punt raw coordinates onto the screen until JTS is needed for actual work.
At a high level we are often working against the same file formats (shapefile, JPEG2000, etc..) and against the same web services (Web Feature Server, Web Map Sever).
It is in between where things get a bit messy. Geospatial projects often use the same concepts (Feature is something that can be drawn on a Map, A Map is made up of layers of features styled up and made to look pretty, etc...). Occasionally these concepts are based on a specification (the referencing specification describes where a coordinate end up on your map, the geometry specification defines what a surface is, that GML specification defines an XML file format for features, and so on...).
Basically the model is the same - why can't we share code.
How can we work together?
The GeoAPI project defines common interfaces for much of the middle ground. It even has a procedure for projects to collaborate together.
Here is an example: that idea of "Referencing" has a set of interfaces, and there are two implementations:
If you are building an application you can pick and choose.
It would be great if we could pull this off for some more concepts. The process is in place, but perhaps our approach (our sales pitch) has been wrong.
Why don't we work together?
One (bad) design trick you can play to get collaboration started is to present a design that is mostly right, and let others find and correct the mistake. By getting everyone to contribute it becomes much more of a shared property and of interest to all.
Currently we have been driving GeoAPI from mostly one view point - the specifications. This is easy to understand - since the specifications have all the hard naming choices figured out. However by starting with a specification, the process does not feel "open" to collaboration.
In practise the specifications always have mistakes, and collaboration is vital for success. I just wish I could make that point more: Got Java? Got Geography? GeoAPI needs you!
I wish we could stress community building as much as correctness.
Here is where our approach can be fixed: by saying "We should work together" we are being too timid - the statement is easy to agree to - but chances are it will never happen. Enthusiasm, funding and deadlines drive software here rather than good intentions.
We should work together on THIS?
So here is the statement I would like us to make (rather than working on something "abstract"). Let's work together on something specific.
What is a Map
I just want to capture the data model here, we can bust out different widgets to visualize the thing after.
A couple of suggestions:
- Have a look around and see what projects do in the wild
- GeoTools is sick of its representation (it does not do WMS layers) and would love to collaborate on this
- OpenJUMP may be in a similar situation?
- GeoWidgets would love to be the keeper of a Map widget
- OSGeo has a a SoC student working on a 3D widget
If we really get stuck on names - the file format for Open Web Context Document is around. I want to read in and display the result in a number of widgets. The file format is not finished yet (so we provide feedback if we see something we hate). Treat this as an opportunity not a constraint. Sample code exists in uDig to read the file format.
All the best and happy hacking.