[udig-devel] A couple of questions about UDig from the OpenJUMP camp...

[Jody Garnett]

Sunburned Surveyor wrote:
> I had a couple of quick questions about UDig. I'll be designing a
> couple of new tools for OpenJUMP, and was trying to think about how I
> can make them easier to port to UDig.
>
> Basically, I want to facilitate some code sharing if possible.
Sweet :-)
> Here are my questions:
>
> [1] Is there any documentation that explains UDig's data source
> framework? ( By data source, I mean something that represents a source
> of features, like an ESRI Shapefile, for instance.) If there isn't any
> of this documentation, where would I look in UDig's source code for
> the appropiate classes?
uDig does its best to be toolkit agnostic, so if you want you could hook 
open
OpenJump's "feature source" and make use of its renderers etc...  At a 
pragmatic level
we have not done this for two reasons:
- license (GPL vs LGPL)
- different opinion on scalability (use memory or stream)

Right now uDig makes use of the GeoTools library, so DataStore / 
FeatureStore etc...
> [2] Jody had mentioned something about a "generic" geometry classes
> that might become a part of GeoTools. I'll be working on some
> precision drafting tools for OpenJUMP. Instead of having these tools
> "hardwired" to JTS I'd like to use a "generic" geometry system. (This
> will allow OpenJUMP to more easily support multiple geometry libraries
> in the future.)
So for the next GeoTools feature model we have separated out the the 
feature model
from the choice of JTS classes or GeoAPI interfaces.  It is still a 
choice that an
implementor would need to make, we are not offering to unify these two 
viewpoints.
Both have respected standards (SFSQL and ISO/GML3) and will be with us a 
long time.
> Does UDig have any plans to implement this abstraction of objects used 
> to represent
> feature geometries?
Nope, we plan to make use of other's hard work :-) There is an 
implementation of the GeoAPI
interfaces done as wrappers around JTS lurking in the GeoTools list 
(stuck waiting on the new
Feature Model before anybody cares).  You can also look to projects like 
gvSig that roll their
own Geometry stuff (and lazily make JTS objects iff the need to do some 
topology operations).
> If UDig and OpenJUMP used the same abstraction of objects that
> represent feature geometries the "engine" of most of my CAD tools
> could be ported to UDig. (I think the GUI portions of the tools
> wouldn't be of much use to you guys, because they'll be built on
> Swing.
I think what an "editing" layer would need to think about is the break 
down of "Geometry" into
a simple view of control handles that could be manipulated. If you 
defined this adapter, and implemented
against JTS today, you could be pretty sure of doing the same thing 
against a GeoAPI based implementation
tomorrow.

Jesse is the one to talk to here.
> [3] Have you guys ever discussed a "native" data storage format that
> doesn't rely on an external database like PostgreSQL but overcomes the
> limitations of ESRI Shapefiles?
A fair bit, we most recently have considered using an FDO bridge to get at
thier "internal" format (think is is basically SQLite tricked out for 
spatial). For
a pure java solution the h2 database combined with "DB in a box" would be
slick. So it is a tradeoff between being part of the wider community or have
some fun as a java hacker.
> I've given a lot of thought to this  concept, which I called the "Open 
> Geospatial
> Database" and I think it  would be great if both OpenJUMP and UDig adopted
> the same native data storage format.
If you implement it we can try it :-) But perhaps consider the comments 
above? I enjoy
a good hack, but the trick now is to be part of the wider community.
> Let me know what you guys think. If I can design these new tools for
> OpenJUMP in a way that plays nice with UDig, I'd like to do that.
Think about the separation between control handles and Geometry, perhaps 
with a
strategy object for "snapping" and I am sure we could have some common 
ground.

Jody