Hi, I work on GeoServer and GeoTools, and it seems like every couple of
months someone asks me, 'what's the difference between GeoServer and
Deegree?'. And while I can come up with a few reasons - different
philosophies and focus for example, the ultimate answer, from a
layman's perspective, is really not that much. We are both open source
Java based (and servlet based) implementations of OGC specs. You guys
have shot ahead in number of spec implementations, while GeoServer has
focused on ease of use, with web config tools and soon complete
installers.
But every time I have to answer that question it bugs me that we are
replicating so much work, that each of us spends time writing access to
the same datastores, debugging the same protocols, thinking about the
same problems. I know that for CITE we thought about attempting to
integrate our models, and I'm quite happy that GeoAPI seems to be
moving forward now and we could have a common feature model. But I
guess I'm writing because I'd like to see even more attempts at
collaborations between our two projects. I'm thinking perhaps at a
more informal level, perhaps more open source based than OGC based
(that metaphor may beg explaining - it just strikes me that OGC and
standards processes in general seem to involve a lot of compromise,
people fighting it out from their particular stake, while open source
is more collaborating together to build something). I don't think we
should try to merge everything, since that would involve throwing out a
lot of good (and well tested) code, since our approaches are different
enough that one or the other would have to rewrite most everything.
And I think there's something to be said for different open source
approaches, giving people a choice. But I think it would be quite
nice, especially for our users, if our projects inter-operated better
together. I've even had users report trying to use GeoServer WFS with
Deegree WMS, and they've had to bounce back and forth between the two
lists to figure out whose was not compliant with the spec. So perhaps
testing against one another's projects more would be a start. And
maybe subscribing to one another's email lists, which I think would be
most valuable for design discussions, when one group is starting to
figure out a problem the other has already grappled with, for example.
Another might be some mutual wiki pages for resources and howto's at
the ogc level, like tutorials about ogc filters, coordinate
transformations, and wms clients. And once we agree on a feature model
in GeoAPI I'd like to try to get GeoServer's WFS to return those
features directly to the Deegree WMS, and would love some collaboration
on that.
Basically I'd like to stop replicating work, as to me that's one of the
biggest points of open source. Next year I'm probably going to focus
on some sort of more complete SDI solution that anyone would be able to
set up, with really nice installers and configuration tools, focused on
SDI for developing countries. And to do it right I probably need a
Catalog implementation, so I'm very interested in the work you are
doing, and think a great thing would be to not deal with the low level
protocol stuff at all, just use your implementation and focus on making
it really easy to use. So I'll probably start asking a bunch of
questions about that in the future.
One question I have right now though is about your
example_config_new2.xml, the sample of a config file for WFS stuff in
the future. The part I'm especially interested in is Topology and Type
definitions. I think another great way to make things on our users
would be to have our config files be able to interoperate. That might
be asking too much, as I don't think either of us are super flexible -
GeoServer has a UI built on top (though it's pretty decoupled, so
probably could change), and there is also issues of backwards
compatibility. But for an area like what I think your topology stuff
is getting at it makes a lot of sense, as we haven't implemented it yet
and I don't think you have either (correct me if I'm wrong but I think
it was written up as an idea), so we could reasonably collaborate on a
good syntax. Interoperable config files might be a good design goal
for deegree 2.0 and GeoServer 2.0 (something that is on my radar, would
like it to be a framework that supports pluggable services, a server
side corollary to the uDig client project, so people could easily write
plug-ins to GeoServer, all accessing the same data, easily configured
with a nice web based UI), as we will probably both restructure our
config files a bit.
But could you explain what's going on in the Topology stuff a bit? Like
what is it used for? In GeoServer we do not yet deal with complex
featureTypes at all yet, and we're looking for a way to define a syntax
for configuration. What we would ideally like is a way to join
different featureTypes, even if they are in different datastores, like
joining csv files to shapefile geometry definitions, or mysql
geometries. But then we'd also like to be able to have featureTypes
that are both in the a database to have that join be optimized, to just
issue the sql query. And the syntax should also be able to define
filters on the table returned, which it looks like that's what you're
doing in the topology stuff as well (geoserver offers limited support
for this too). We also don't yet offer the ability to map names to
different values, the column name or attribute named is returned
directly, which is nice from the perspective of less configuration on a
user's part, but would be nice to offer more flexibility where
possible. So yes, I'm curious what you have in mind for the topology
stuff, and perhaps other advice on mappings. (this should maybe be
split up into a seperate email, but basically this is a topic that we
are going to try to tackle soon within geotools, and it'd be great to
get some of your feedback).
Ok, I'll wrap this up, since it's already a sprawling mass of thoughts
that I've been meaning to write for awhile. It's just that I'd like to
figure out ways for us to replicate less work, since I think you guys
have a great project, and I think it makes sense to try to work
together a bit more, maybe somehow divide up our focuses even more
consciously, so that we can point users at one another when they are
looking for a solution that the other can provide.
best regards,
Chris
(also, a random question, why are the jai jars included in the wfs
download? Do you use JAI for more than rendering? It seems like they
could be left out of the wfs download, perhaps the java3d stuff too,
and make that full wfs download a decent bit smaller. And how do you
find the java based jai jars fast enough? I've been forcing users to
install JAI if they want to use the WMS, as I've heard it's
substantially faster with the native installs...)
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/