Difference between revisions of "Java GIS Collaboration"

From OSGeo
Jump to navigation Jump to search
Line 9: Line 9:
 
* [http://www.jump-project.org/project.php?PID=JTS&SID=OVER JTS]
 
* [http://www.jump-project.org/project.php?PID=JTS&SID=OVER JTS]
 
* [http://udig.refractions.net/ uDig] / [http://www.jgrass.org/ JGrass]
 
* [http://udig.refractions.net/ uDig] / [http://www.jgrass.org/ JGrass]
 +
* [http://deegree.sourceforge.net/ Deegree]
 
* ''...''
 
* ''...''
  

Revision as of 15:20, 14 June 2007

Collaboration?

It seems there is a call for collaboration between Java-based GIS projects like Jump and GeoTools, or uDig and gvSig every once in a while. This is an attempt to move from talk to action, since we usually just nod and say "yeah, we should collaborate" and it ends there.

Java-based GIS Projects

What components?

  • GeoAPI (OGC/ISO specifications)
  • GeoTools
  • JTS

Contacts

People from each team who are taking part in this discussion:

The Sunburned Surveyor [sunburned.surveyor@gmail.com]

Problems

Licensing

  • LGPL vs GPL: everyone can use the LGPL code; GPL code will get less reuse
  • Different Feature Models. This makes it difficult to share code. For example, I can't just plug-in a data source from the GeoTools library because it won't give me JUMP Feature objects. It gives me GeoTools Feature objects, which I can't use. :] We can work towards a common Feature implementation, but that is difficult in many cases because so much existing code has been written. In the case of OpenJUMP a lot of code is written and also published bia public interfaces to plug-in developers, which makes it much harder to refactor code. (If you want to change things you break a lot of plug-ins.) One solution may be to design, produce, and maintain code that converts between the different object features.)

Ideas

  • draw a picture (who is using what right now?)
  • have an IRC meeting and figure out where we can collaborate