Hi all,
I am jumping in the discussion just to share some thoughts and
concerns which comes after almost two years of work with geotools
geoserver.
First of all, I am not so sure that what we really need now is to
rewrite the GeoServer architecture to pursue a framework approach. I
am sorry and I do not intend to offend anybody but I think, given the
current state of things, we are going the wrong direction.
I am convinced that our priorities should be a bit different as a
couple of people said previously (Paul Ramsey for example, but also
someone else I do not remember exactly).
First of all there a couple of things that should be fixed as soon as
possible in Geotools/GeoServer.
1>Streaming renderer: where do we want to go if we do not make it
faster and stronger? I think should be clear that we need to spend
time on improving it (as currently Dave is doing)
2>If we want GeoServer to scale I believe we need to change the way
the configuration is managed. I have installations of geoserver with
hundreds of layers and I can tell you that it is impossible to manage
them due to the fact that keeping the all catalog in memory as we do
right now is not the best solution. In case you need to reload some
change it takes forever. Moreover some kind of ingestion engine would
be useful.
3>Raster Support: where do we want to go without raster support in
WMS? Sometimes I think that nobody sees that. WCS is for sure far less
important than WMS but WMS without support for raster is NOT a real
WMS. I have seen a lot expectation over the support for rasters but NO
real help besides Martin and Bryce. I know that lately me and Alessio
have kind of disappeared, this has been a mistake I recognized, but we
have been focusing on finding funding for supporting the work (problem
solved hopefully). From now on we will try to participate more but I
can tell you that my feeling sometimes is that our effort has been
kind of underestimated. As I said is just a feeling.
4>Better Spatial DB support, I know I am being generic but it is a
generic item anyway.
Besides, don't you guys see that people are abandoning geotools and geoserver
(especially the first one) because they are not stable at all. Andwe
now propose to change the structure of GeoServer? I know at least 2
groups working with Geotools/Geoserver who want to abandon geotools
and geoserver just because they heard of this switch after having seen
tons of changes in the last 2 years.
I think the idea of going toward a framework structure is good but I
strongly believe that we should put more energies on settling down
and improving what we have both in geotools as well as in geoserver.
1.3 has been a good release, I think next step should be integrating
the branches as they come to maturity as well as improving support in
geotools for rendering, styles and various formats. Only fter all this
we should start talking about a new framework otherwise we will give
the impression that we are aiming towards nice architectures but not
towards real production usability.
Talking about the GeoServer WCS branch.
As Alessio explained before, the WCS branch is trying to provide
support for rasters in WMS while at the same time is introducing a new
WCS service respecting the actual structure based on struts along with
the DTO concepts etc, etc.
The work going on on that side is extremely huge there are many things
we have done/ we have to do before having a good coverage framework.
One for all making the Geoserver WMS serving raster efficiently is
EXTREMELY difficult because of various reasons:
1> the streaming renderer needs to be improved a lot. I was a bit
delusional when I sent out an email about the fact that basically
StreamingRenderer right now DO NOT REALLY support coverages due to the
axis inversion issue (which I solved with a trick). I strongly believe
that we should spend some time on the rendering side before talking
about a new framework otherwise what will we put inside the framework?
Dave is doing a wonderful job on te feature side, maybe I should talk
to him a bit.
2>The coverage plugins when I started working with geotools where in
an inconsistent state. I have been working for months to improve them
and still I am doing that. I can tell you that right now things are
starting to be decently satisfying.
3>Geoserver had NO notion at all of the concept f coverages. Right now
coverages works as smoothly as features both with wcs and wms.
Conclusions:
I hope people don't get me wrong. I put passion in what I do and I try
to do it the best I can. I am sure I have made mistakes during my
contributions, I could have participated a lot more and maybe I could
have done things better. Me and alessio are open to criticism. I
strongly believe in geoserver and geotools and my will is to make them
more usable, more stable and more accepted.
Anyway due to time I have donated to geotools/geoserver and the
experience I have made using/developing it I think these observations
should be carefully evaluated. I think we are at at a critical point,
there is a lot of attention right now on us, I can tell you that NC3A
agency just issued a request for quotation for building a big
framework mplementing various OGC spec and it is looking at geoserver
as a reference for testing interoperability concepts (NC3A is also
funding the OWS4 from OGC). I am trying to convince people in NATO to
use GeoServer and Geotools as a base for developing apps. Again the
concern they have is "geotools and geoserver are good, but they do not
seem mature, they change too much".
Are we sure what we really need right no is focusing on a new
framework or settling down and improving what we have?
I believe what Paul Ramsey said in a previous email hit the target. I
think that for the moment we would maintain the complexity of the
actual structure while working on stability and integration of the
branches. Once this is in place we could start talking about a new
framework.
Simone.
--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant
"Canterò le mie canzoni per la strada
ed affronterò la vita a muso duro
un guerriero senza patria e senza spada
con un piede nel passato
e lo sguardo dritto e aperto nel futuro."
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
On 4/13/06, Alessio Fabiani <alessio.fabiani@anonymised.com> wrote:
Hi all,
for the WCS branch our guidelines are to follow as much as possible the
architecture, the interfaces and the programming style of the trunk release.
Infact for the 1.3.0 release of GeoServer in any time you can switch the
trunk version with the WCS branch without any problem because they are
costantly and fully aligned. Our politic is to change something on the other
services only if is strictly necessary or if there are blocking bugs o leaks
of performance.We are waiting for a detailed analysis of the 1.4.0 architecture to evaluate
te cost of porting the WCS code in the new release. For sure there will be a
lot of work for us to do this because at the end there are of course many
important "points of contact" between WCS and the existing services.In my opinion before switch to the 1.4.0 release the WCS branch should be
ported on 1.3.0 trunk. This will reduce a lot the future work avoiding to do
things twice.
Again, porting the WCS in the trunk at this time means just copy the WCS
branch directory on the trnuk one.Regards,
Alessio.On 4/13/06, Justin Deoliveira <jdeolive@anonymised.com> wrote:
> David Blasby wrote:
> > >>... - it would let the WCS work as a module rather then a branch
etc...
> >
> > Okay, everyone is selling whats happening in 1.4 to allow this, but no
> > one's really explained how its supposed to work. I've asked many times,
> > but I've gotten no answers.
> In my opinion the problem with GeoServer is that is has *no* or little
> architecture in place. Please dont get me wrong, GeoServer has been a
> huge success and is very impressive. But taking it from an application
> to a framework is not a simple matter.
>
> And so not having an architecture leads to no constraints when people
> design classes which leads to a big mess. I think the first step in
> putting one in place to take a step back and take a look at the bigger
> picture, figuring out what major sub systems will be, making the
> decisions that will constrain people when they are doing their design
> (example, the POJO service model), etc..
>
> The reason you are not getting any answers to your questions is because
> you are asking very specific technical questions. And the "framework" is
> not well defined enough yet to answer them. Which is understandable
> since people arent really on the same page yet as to what the scope of
> it will be.
> >
> > If the WCS branch was completely independent of the rest of Geoserver
> > (ie. just another servlet), then I can see what you're saying working.
> > In fact, if that really were the case, then they could just publish the
> > WCS stuff as a separate servlet and not need to change [the current]
> > geoserver much - if at all.
> >
> > But, my understanding of the WCS branch is that its not independent
> > (perhaps someone there can comment because I havent poked much around in
> > what they're doing). It's modified the WMS so you can get
> > raster-in-WMS. I assume there's some type of coverage server (unless
> > they've just extended the wms). There's config system changes
> > (including the GUI) and data changes. I assume they've added a few
> > other things here and there.
> > I can see how the new spring system might help with adding in a new
> > servlet, but what about the rest? These are the more interesting (and
> > more important) tasks. Is the statement at the start of this message
> > just hyper-marketing or is there some type of spring magic that makes
> > all these other things trivial?
> >
> > dave
> > ps. I'm looking forward to the wcs branch since there's a bunch of
> > raster data that I'd like to publish.
>
>
> --
> Justin Deoliveira
> The Open Planning Project
> jdeolive@anonymised.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
> that extends applications into web and mobile media. Attend the live
webcast
> and join the prime developer group breaking into this new coding
territory!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
There are several examples of how the streaming