[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] An effort on collaboration...
|
On 31-Jan-07, at 11:49 AM, Sunburned Surveyor wrote:
There has been some interesting e-mails on the JPP Developer
mailing list the last few hours. I won't bore everyone with the
details, but the discussion has made me realize that I need to do a
bettter job building a good working relationship with the UDig
developers. I have talked about some of this with Jody before, but
I found that opportunities to share code were limited because UDig
and OpenJUMP have some significant differences in design and
architecture. For example, the ability to share GUI code is
severely limited. I quickly dismissed any real effort to share code
becuase I felt that it would be to much work.
Perhaps that was a mistake on my part. I didn't realize it at the
time, but the good relationship with UDiggers is another benefit of
the effort that will be needed to share more code between the
projects, and I didn't consider that benefit before. If we want
open source GIS to be a success, especially in the Java world, then
we need to work together.
Let me briefly list some of what I am working on in OpenJUMP. If
the UDiggers are interested, I will put some hard work into
creating code that can be used by both projects. (I'll need some
guidance on how this can be done.)
[1] I'm working on a ESRI Shapefile parser as part of my long-term
plan to overcome some of OpenJUMP's memory limitations. I hope this
parser will provide "iterative" and RAM independent access to
features. I also want it to offer access to features based on
location and attribute values. I think that is something that the
UDig team could tap into. (Imagine a dialog that allows the user to
import all features in a Roads Shapefile with a type attribute with
that has a value of highway...)
As part of my work on the ESRI Shapefile parser I've been putting
together a group tools that can be used to represent and manipulate
binary data. I've made these classes rather generic, and they could
be applied to the I/O of other binary file formats, not just ESRI
Shapefiles.
You might want to take a look at Geotools since it does this sort of
thing. Shapefile support is pretty complete in geotools although the
code needs to be cleaned up a bit by now as it has been through a few
iterations.
[2] I've done some work for a private company that involved
creation of a "data source catalog" for OpenJUMP. My main goal when
designing the system was to allow users to track the association
between data sources and layers. The work on the catalog has come
to a standstill, but I hope to conitnue it when the ESRI Shapefile
parser is complete and I implement a Shapefile Data Source.
I think this may be the greatest opportunity for collaboration
between UDig and OpenJUMP. Wouldn't it be great if the two programs
could share the same tools for I/O, and if users could work with
geospatial data sources through a somewhat similar catalog system?
You ideas about catalog would be valuable. We've had a uDig catalog
for a while and introduced it to Geotools but time has come to review
it and see if there are improvements/simplifications that can be made.
[3] I've been overhauling OpenJUMP's CursorTool code. I don't know
how much of this code could be used by UDig, because it is fairly
high-level and GUI related. However, I am going to be working on
some algorithms that compute "snapping" points on JTS Geometries,
and some of those algorithms might be useful to UDiggers. I'm also
tying in some of these CursorTools to a "Poisition Clipboard". I
think that is something that UDig might find handy. (Once again, we
would need to wrap the underlying code in a different GUI.)
At the very least I think we can trade ideas for design. And code
sharing may become apparent.
[4] At some point I need to write a DXF Parser for OpenJUMP. I've
looked at the spec, and even started sketching some notes on how I
would implement this. I think UDig had some DXF support as a plug-
in at some point. This is also something I need to look at.
In actual fact I think it was a port from a JUMP plugin. The work
stopped before it got very far unfortunately. For example it could
only read features no write capabilities.
If you would like we can organize an IRC meeting at some point.
Jesse
