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
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
