[Geoserver-devel] gt2WMS moving to GeoServer project

GeoServer GeoServer Developer
1

Apologies for the large cross-post, please direct replies to
geoserver-devel@anonymised.com

The gt2wms server is moving to the GeoServer project. We've been wanting
to move the wms server out of GeoTools for awhile, as it doesn't really
fit with the rest of the modular nature. Over at GeoServer we were
planning on integrating the gt2wms anyways, so it seems to make sense to
have the code actually live on in the same cvs. This way our developers
can benefit from one another's approaches, and hopefully combine common
code. Both are OGC web services on top of Geotools, so there should be a
few places of overlap. I'm planning on spending the rest of this week on
integration, and initial attempts are promising. I've successfully got
them running in the same war, and can recieve a getCapabilities document
for both.

There are a few questions that I have, for all interested in the future of
gt2wms, and its integration into geoserver.

1. How much integration do we want? I think common configuration would be
nice to have, so that both services could use the same configuration
files. GetCapabilities responses and Exception handling also seem like
they have some overlap, so we might try to combine those classes. We can
talk more specifics on the geoserver devel list.

2. Maven on GeoServer? The GeoServer project currently uses ant, which is
nice and fast, and currently easier to get working (though maven 1.0 may
prove that wrong). Getting GeoServer on Maven would allow us to more
quickly pick up geotools changes - right now I hand roll the geotools jar
and put it on cvs, which is obviously less than ideal. My plan is to
start tagging geotools with geoserver tags of what is needed, but using
maven would make that less necessary, as it would just download the proper
jars. I'm a bit inclined to stay with ant, but if someone (James?) is
willing to set it up and no one's against the change I'll go along.

3. Package names for the gt2wms. Do we want to keep the geotools package
names, since that's where the code comes from? Or do we want to make a
org.vfny.geoserver.wms package? Or if we're going for a lot of
integration we could make org.vfny.geoserver.requests.wms and
org.vfny.geoserver.responses.wms, and put all the common config code in
org.vfny.geoserver.config. And we can obviously start with one and move
things around if and when we actually acheive integration.

4. Distribution and Marketing. These questions are not pressing, but how
do we want to present the wms? Should we make it available as a
stand-alone wms? Keep the downloadable war format? Integrate it
completely into GeoServer? Create seperate installation instructions?
Many of these questions depend on how much we integrate, but even if we do
integrate a lot we can still have them live as slightly different projects
in user's minds, just ones that inter-operate quite well.

Ok, I'm sure there will be more questions about this, but we can hold off
for discussion on geoserver-devel.

  thanks,

       Chris

2

Just a very simple consideration:

----- Original Message -----
From: "Chris Holmes" <cholmes@anonymised.com>
To: <geotools-devel@lists.sourceforge.net>;
<geotools-gt2-users@lists.sourceforge.net>;
<geoserver-devel@lists.sourceforge.net>
Sent: Tuesday, September 30, 2003 9:06 PM
Subject: [Geotools-devel] gt2WMS moving to GeoServer project

4. Distribution and Marketing. These questions are not pressing, but how
do we want to present the wms? Should we make it available as a
stand-alone wms? Keep the downloadable war format? Integrate it
completely into GeoServer? Create seperate installation instructions?
Many of these questions depend on how much we integrate, but even if we do
integrate a lot we can still have them live as slightly different projects
in user's minds, just ones that inter-operate quite well.

IMHO, wich is only derived from my experiences in developing server side
GIS apps for last 3 years, in all of them there are situations where
definitely a pure
WMS or a pure WFS doesn't is enough. Instead, one must take each ohter
to solve a current problem. I mean, until now I was using ArcIMS,
extensively
working with its AXL format, to query images as to retrieve geometries,
working
on it, and applying bussines logic as a whole.

And since ArcIMS is not the best product I've seen, having a product that
can
manage both needs helps a lot. I would be a mess to use one product to
quering maps and another (or at least one not well integrated with the
datasets working on)
for working with features at a lower level.

That's why mi position is to get the greater integration level possible.

regards,

Gabriel

3

Le Mardi 30 Septembre 2003 21:06, Chris Holmes a écrit :

Apologies for the large cross-post, please direct replies to
geoserver-devel@anonymised.com

The gt2wms server is moving to the GeoServer project. We've been wanting
to move the wms server out of GeoTools for awhile, as it doesn't really
fit with the rest of the modular nature. Over at GeoServer we were
planning on integrating the gt2wms anyways, so it seems to make sense to
have the code actually live on in the same cvs. This way our developers
can benefit from one another's approaches, and hopefully combine common
code. Both are OGC web services on top of Geotools, so there should be a
few places of overlap. I'm planning on spending the rest of this week on
integration, and initial attempts are promising. I've successfully got
them running in the same war, and can recieve a getCapabilities document
for both.

Great, having a frozen WMS in GeoTools and now having it warming up in
GeoServer is good news !

There are a few questions that I have, for all interested in the future of
gt2wms, and its integration into geoserver.

1. How much integration do we want? I think common configuration would be
nice to have, so that both services could use the same configuration
files. GetCapabilities responses and Exception handling also seem like
they have some overlap, so we might try to combine those classes. We can
talk more specifics on the geoserver devel list.

I have successfully (so far) installed and used both of them as separated web
apps. I think using or sharing same configuration context would be nice. The
geoserver configuration system is simple, straight and easy to follow !

2. Maven on GeoServer? The GeoServer project currently uses ant, which is
nice and fast, and currently easier to get working (though maven 1.0 may
prove that wrong). Getting GeoServer on Maven would allow us to more
quickly pick up geotools changes - right now I hand roll the geotools jar
and put it on cvs, which is obviously less than ideal. My plan is to
start tagging geotools with geoserver tags of what is needed, but using
maven would make that less necessary, as it would just download the proper
jars. I'm a bit inclined to stay with ant, but if someone (James?) is
willing to set it up and no one's against the change I'll go along.

As I am doing a cvs check out of GeoTools source once a week and compile it
with Maven, using Maven or ant is not the all story ! What would be cool is
the ease compilation of GeoServer with GeoTools jars just compiled on the
same machine!
GeoTools was using ant before switching to Maven, I strongly believe that
Maven helped a lot in having the whole GeoTools tree compiled.

3. Package names for the gt2wms. Do we want to keep the geotools package
names, since that's where the code comes from? Or do we want to make a
org.vfny.geoserver.wms package? Or if we're going for a lot of
integration we could make org.vfny.geoserver.requests.wms and
org.vfny.geoserver.responses.wms, and put all the common config code in
org.vfny.geoserver.config. And we can obviously start with one and move
things around if and when we actually acheive integration.

Sounds a practical view : starting with gt2wms for the handing-over and ending
with org.vfny.geoserver.* when strong integration is reached.

4. Distribution and Marketing. These questions are not pressing, but how
do we want to present the wms? Should we make it available as a
stand-alone wms? Keep the downloadable war format? Integrate it
completely into GeoServer? Create seperate installation instructions?
Many of these questions depend on how much we integrate, but even if we do
integrate a lot we can still have them live as slightly different projects
in user's minds, just ones that inter-operate quite well.

Having two pieces of webapp (WMS and WFS) is good for webapp developers
willing not to care of both services at the same time. Integration should be
avaiblable at the configuration level (especially if you want to build maps
with WMS and using the same geo-data send GML with WFS). This may allow
strong interoperability between them. Somewhere the key point will be having
the common jar files (like geotools2) in one or more places.

Ok, I'm sure there will be more questions about this, but we can hold off
for discussion on geoserver-devel.

  thanks,

       Chris

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Geotools-gt2-users mailing list
Geotools-gt2-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

didier

4

I know the geoserver developers shold see the deegree project, they are a
strongly interoperability wms and wfs samples,

please visit this comunity, your wms application not connect to database
directly, the wms connect with an wfs server, that wfs is
connect directly to the database or shapefiles, etc. and the wms extract the
information from the wfs in gml format trouhgt wfs request.

William Moreno

The arquitecture of this samples application is one interesting model to
study for the integration gt2wms and geoserver
----- Original Message -----
From: "Richard didier" <dgr@anonymised.com>
To: <geoserver-devel@lists.sourceforge.net>
Sent: Tuesday, September 30, 2003 4:12 PM
Subject: [Geoserver-devel] Re: [Geotools-gt2-users] gt2WMS moving to
GeoServer project

Le Mardi 30 Septembre 2003 21:06, Chris Holmes a écrit :
> Apologies for the large cross-post, please direct replies to
> geoserver-devel@anonymised.com
>
> The gt2wms server is moving to the GeoServer project. We've been

wanting

> to move the wms server out of GeoTools for awhile, as it doesn't really
> fit with the rest of the modular nature. Over at GeoServer we were
> planning on integrating the gt2wms anyways, so it seems to make sense to
> have the code actually live on in the same cvs. This way our developers
> can benefit from one another's approaches, and hopefully combine common
> code. Both are OGC web services on top of Geotools, so there should be

a

> few places of overlap. I'm planning on spending the rest of this week

on

> integration, and initial attempts are promising. I've successfully got
> them running in the same war, and can recieve a getCapabilities document
> for both.

Great, having a frozen WMS in GeoTools and now having it warming up in
GeoServer is good news !

>
> There are a few questions that I have, for all interested in the future

of

> gt2wms, and its integration into geoserver.
>
> 1. How much integration do we want? I think common configuration would

be

> nice to have, so that both services could use the same configuration
> files. GetCapabilities responses and Exception handling also seem like
> they have some overlap, so we might try to combine those classes. We

can

> talk more specifics on the geoserver devel list.

I have successfully (so far) installed and used both of them as separated

web

apps. I think using or sharing same configuration context would be nice.

The

geoserver configuration system is simple, straight and easy to follow !

>
> 2. Maven on GeoServer? The GeoServer project currently uses ant, which

is

> nice and fast, and currently easier to get working (though maven 1.0 may
> prove that wrong). Getting GeoServer on Maven would allow us to more
> quickly pick up geotools changes - right now I hand roll the geotools

jar

> and put it on cvs, which is obviously less than ideal. My plan is to
> start tagging geotools with geoserver tags of what is needed, but using
> maven would make that less necessary, as it would just download the

proper

> jars. I'm a bit inclined to stay with ant, but if someone (James?) is
> willing to set it up and no one's against the change I'll go along.

As I am doing a cvs check out of GeoTools source once a week and compile

it

with Maven, using Maven or ant is not the all story ! What would be cool

is

the ease compilation of GeoServer with GeoTools jars just compiled on the
same machine!
GeoTools was using ant before switching to Maven, I strongly believe that
Maven helped a lot in having the whole GeoTools tree compiled.

>
> 3. Package names for the gt2wms. Do we want to keep the geotools

package

> names, since that's where the code comes from? Or do we want to make a
> org.vfny.geoserver.wms package? Or if we're going for a lot of
> integration we could make org.vfny.geoserver.requests.wms and
> org.vfny.geoserver.responses.wms, and put all the common config code in
> org.vfny.geoserver.config. And we can obviously start with one and move
> things around if and when we actually acheive integration.

Sounds a practical view : starting with gt2wms for the handing-over and

ending

with org.vfny.geoserver.* when strong integration is reached.

>
> 4. Distribution and Marketing. These questions are not pressing, but

how

> do we want to present the wms? Should we make it available as a
> stand-alone wms? Keep the downloadable war format? Integrate it
> completely into GeoServer? Create seperate installation instructions?
> Many of these questions depend on how much we integrate, but even if we

do

> integrate a lot we can still have them live as slightly different

projects

> in user's minds, just ones that inter-operate quite well.

Having two pieces of webapp (WMS and WFS) is good for webapp developers
willing not to care of both services at the same time. Integration should

be

avaiblable at the configuration level (especially if you want to build

maps

with WMS and using the same geo-data send GML with WFS). This may allow
strong interoperability between them. Somewhere the key point will be

having

the common jar files (like geotools2) in one or more places.

>
> Ok, I'm sure there will be more questions about this, but we can hold

off

> for discussion on geoserver-devel.
>
>
>
>
> thanks,
>
>
> Chris
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Geotools-gt2-users mailing list
> Geotools-gt2-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

didier

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

Yes, I do like their design a lot, I think it's quite smart. It might be
a good aim for the future. For now I've had success serving up the same
featureType as an image through the gt2wms code and as gml through wfs
code, on the same servlet. I'll try to get this into cvs soon. Both are
built on top of geotools, so integrating them to just work is actually
quite easily. There are opportunities for more overlap, like exception
reporting and whatnot, which deegree does.

Also we are slowly working to have an integrated feature model with
deegree. The first step is geometries, which have taken the form of the
GeoAPI project, which has been moving along more slowly than we'd all
like. But if and when we do get a common feature model then geoserver
should be able to serve as a wfs for the deegree wms, which would be quite
cool. The next step after that would be to have the gt2wms use the wfs as
a datasource in their style, and then some interfaces allowing us to
easily transfer data between the projects.

So yes, my thought is to have the wms connect to the databases directly
for now, as I've just about finished that, and work later for deegree
style interoperability.

  Chris

On Thu, 2 Oct 2003, Bladimir Moreno wrote:

I know the geoserver developers shold see the deegree project, they are a
strongly interoperability wms and wfs samples,

please visit this comunity, your wms application not connect to database
directly, the wms connect with an wfs server, that wfs is
connect directly to the database or shapefiles, etc. and the wms extract the
information from the wfs in gml format trouhgt wfs request.

William Moreno

The arquitecture of this samples application is one interesting model to
study for the integration gt2wms and geoserver
----- Original Message -----
From: "Richard didier" <dgr@anonymised.com>
To: <geoserver-devel@lists.sourceforge.net>
Sent: Tuesday, September 30, 2003 4:12 PM
Subject: [Geoserver-devel] Re: [Geotools-gt2-users] gt2WMS moving to
GeoServer project

> Le Mardi 30 Septembre 2003 21:06, Chris Holmes a écrit :
> > Apologies for the large cross-post, please direct replies to
> > geoserver-devel@anonymised.com
> >
> > The gt2wms server is moving to the GeoServer project. We've been
wanting
> > to move the wms server out of GeoTools for awhile, as it doesn't really
> > fit with the rest of the modular nature. Over at GeoServer we were
> > planning on integrating the gt2wms anyways, so it seems to make sense to
> > have the code actually live on in the same cvs. This way our developers
> > can benefit from one another's approaches, and hopefully combine common
> > code. Both are OGC web services on top of Geotools, so there should be
a
> > few places of overlap. I'm planning on spending the rest of this week
on
> > integration, and initial attempts are promising. I've successfully got
> > them running in the same war, and can recieve a getCapabilities document
> > for both.
>
> Great, having a frozen WMS in GeoTools and now having it warming up in
> GeoServer is good news !
>
> >
> > There are a few questions that I have, for all interested in the future
of
> > gt2wms, and its integration into geoserver.
> >
> > 1. How much integration do we want? I think common configuration would
be
> > nice to have, so that both services could use the same configuration
> > files. GetCapabilities responses and Exception handling also seem like
> > they have some overlap, so we might try to combine those classes. We
can
> > talk more specifics on the geoserver devel list.
>
> I have successfully (so far) installed and used both of them as separated
web
> apps. I think using or sharing same configuration context would be nice.
The
> geoserver configuration system is simple, straight and easy to follow !
>
> >
> > 2. Maven on GeoServer? The GeoServer project currently uses ant, which
is
> > nice and fast, and currently easier to get working (though maven 1.0 may
> > prove that wrong). Getting GeoServer on Maven would allow us to more
> > quickly pick up geotools changes - right now I hand roll the geotools
jar
> > and put it on cvs, which is obviously less than ideal. My plan is to
> > start tagging geotools with geoserver tags of what is needed, but using
> > maven would make that less necessary, as it would just download the
proper
> > jars. I'm a bit inclined to stay with ant, but if someone (James?) is
> > willing to set it up and no one's against the change I'll go along.
>
> As I am doing a cvs check out of GeoTools source once a week and compile
it
> with Maven, using Maven or ant is not the all story ! What would be cool
is
> the ease compilation of GeoServer with GeoTools jars just compiled on the
> same machine!
> GeoTools was using ant before switching to Maven, I strongly believe that
> Maven helped a lot in having the whole GeoTools tree compiled.
>
> >
> > 3. Package names for the gt2wms. Do we want to keep the geotools
package
> > names, since that's where the code comes from? Or do we want to make a
> > org.vfny.geoserver.wms package? Or if we're going for a lot of
> > integration we could make org.vfny.geoserver.requests.wms and
> > org.vfny.geoserver.responses.wms, and put all the common config code in
> > org.vfny.geoserver.config. And we can obviously start with one and move
> > things around if and when we actually acheive integration.
>
> Sounds a practical view : starting with gt2wms for the handing-over and
ending
> with org.vfny.geoserver.* when strong integration is reached.
>
> >
> > 4. Distribution and Marketing. These questions are not pressing, but
how
> > do we want to present the wms? Should we make it available as a
> > stand-alone wms? Keep the downloadable war format? Integrate it
> > completely into GeoServer? Create seperate installation instructions?
> > Many of these questions depend on how much we integrate, but even if we
do
> > integrate a lot we can still have them live as slightly different
projects
> > in user's minds, just ones that inter-operate quite well.
>
> Having two pieces of webapp (WMS and WFS) is good for webapp developers
> willing not to care of both services at the same time. Integration should
be
> avaiblable at the configuration level (especially if you want to build
maps
> with WMS and using the same geo-data send GML with WFS). This may allow
> strong interoperability between them. Somewhere the key point will be
having
> the common jar files (like geotools2) in one or more places.
>
> >
> > Ok, I'm sure there will be more questions about this, but we can hold
off
> > for discussion on geoserver-devel.
> >
> >
> >
> >
> > thanks,
> >
> >
> > Chris
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Geotools-gt2-users mailing list
> > Geotools-gt2-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
> didier
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

I try to connect geoserver with deegree wms but i can't,

Can you help me?, you have experience in deegree?

William Moreno
----- Original Message -----
From: "Chris Holmes" <cholmes@anonymised.com>
To: "Bladimir Moreno" <bladiyo@anonymised.com>
Cc: "Richard didier" <dgr@anonymised.com>;
<geoserver-devel@lists.sourceforge.net>
Sent: Thursday, October 02, 2003 11:22 AM
Subject: Re: [Geoserver-devel] Re: [Geotools-gt2-users] gt2WMS moving to
GeoServer project

Yes, I do like their design a lot, I think it's quite smart. It might be
a good aim for the future. For now I've had success serving up the same
featureType as an image through the gt2wms code and as gml through wfs
code, on the same servlet. I'll try to get this into cvs soon. Both are
built on top of geotools, so integrating them to just work is actually
quite easily. There are opportunities for more overlap, like exception
reporting and whatnot, which deegree does.

Also we are slowly working to have an integrated feature model with
deegree. The first step is geometries, which have taken the form of the
GeoAPI project, which has been moving along more slowly than we'd all
like. But if and when we do get a common feature model then geoserver
should be able to serve as a wfs for the deegree wms, which would be quite
cool. The next step after that would be to have the gt2wms use the wfs as
a datasource in their style, and then some interfaces allowing us to
easily transfer data between the projects.

So yes, my thought is to have the wms connect to the databases directly
for now, as I've just about finished that, and work later for deegree
style interoperability.

Chris

On Thu, 2 Oct 2003, Bladimir Moreno wrote:

> I know the geoserver developers shold see the deegree project, they are

a

> strongly interoperability wms and wfs samples,
>
> please visit this comunity, your wms application not connect to database
> directly, the wms connect with an wfs server, that wfs is
> connect directly to the database or shapefiles, etc. and the wms extract

the

> information from the wfs in gml format trouhgt wfs request.
>
> William Moreno
>
> The arquitecture of this samples application is one interesting model to
> study for the integration gt2wms and geoserver
> ----- Original Message -----
> From: "Richard didier" <dgr@anonymised.com>
> To: <geoserver-devel@lists.sourceforge.net>
> Sent: Tuesday, September 30, 2003 4:12 PM
> Subject: [Geoserver-devel] Re: [Geotools-gt2-users] gt2WMS moving to
> GeoServer project
>
>
> > Le Mardi 30 Septembre 2003 21:06, Chris Holmes a écrit :
> > > Apologies for the large cross-post, please direct replies to
> > > geoserver-devel@anonymised.com
> > >
> > > The gt2wms server is moving to the GeoServer project. We've been
> wanting
> > > to move the wms server out of GeoTools for awhile, as it doesn't

really

> > > fit with the rest of the modular nature. Over at GeoServer we were
> > > planning on integrating the gt2wms anyways, so it seems to make

sense to

> > > have the code actually live on in the same cvs. This way our

developers

> > > can benefit from one another's approaches, and hopefully combine

common

> > > code. Both are OGC web services on top of Geotools, so there should

be

> a
> > > few places of overlap. I'm planning on spending the rest of this

week

> on
> > > integration, and initial attempts are promising. I've successfully

got

> > > them running in the same war, and can recieve a getCapabilities

document

> > > for both.
> >
> > Great, having a frozen WMS in GeoTools and now having it warming up in
> > GeoServer is good news !
> >
> > >
> > > There are a few questions that I have, for all interested in the

future

> of
> > > gt2wms, and its integration into geoserver.
> > >
> > > 1. How much integration do we want? I think common configuration

would

> be
> > > nice to have, so that both services could use the same configuration
> > > files. GetCapabilities responses and Exception handling also seem

like

> > > they have some overlap, so we might try to combine those classes.

We

> can
> > > talk more specifics on the geoserver devel list.
> >
> > I have successfully (so far) installed and used both of them as

separated

> web
> > apps. I think using or sharing same configuration context would be

nice.

> The
> > geoserver configuration system is simple, straight and easy to follow

!

> >
> > >
> > > 2. Maven on GeoServer? The GeoServer project currently uses ant,

which

> is
> > > nice and fast, and currently easier to get working (though maven 1.0

may

> > > prove that wrong). Getting GeoServer on Maven would allow us to

more

> > > quickly pick up geotools changes - right now I hand roll the

geotools

> jar
> > > and put it on cvs, which is obviously less than ideal. My plan is

to

> > > start tagging geotools with geoserver tags of what is needed, but

using

> > > maven would make that less necessary, as it would just download the
> proper
> > > jars. I'm a bit inclined to stay with ant, but if someone (James?)

is

> > > willing to set it up and no one's against the change I'll go along.
> >
> > As I am doing a cvs check out of GeoTools source once a week and

compile

> it
> > with Maven, using Maven or ant is not the all story ! What would be

cool

> is
> > the ease compilation of GeoServer with GeoTools jars just compiled on

the

> > same machine!
> > GeoTools was using ant before switching to Maven, I strongly believe

that

> > Maven helped a lot in having the whole GeoTools tree compiled.
> >
> > >
> > > 3. Package names for the gt2wms. Do we want to keep the geotools
> package
> > > names, since that's where the code comes from? Or do we want to

make a

> > > org.vfny.geoserver.wms package? Or if we're going for a lot of
> > > integration we could make org.vfny.geoserver.requests.wms and
> > > org.vfny.geoserver.responses.wms, and put all the common config code

in

> > > org.vfny.geoserver.config. And we can obviously start with one and

move

> > > things around if and when we actually acheive integration.
> >
> > Sounds a practical view : starting with gt2wms for the handing-over

and

> ending
> > with org.vfny.geoserver.* when strong integration is reached.
> >
> > >
> > > 4. Distribution and Marketing. These questions are not pressing,

but

> how
> > > do we want to present the wms? Should we make it available as a
> > > stand-alone wms? Keep the downloadable war format? Integrate it
> > > completely into GeoServer? Create seperate installation

instructions?

> > > Many of these questions depend on how much we integrate, but even if

we

> do
> > > integrate a lot we can still have them live as slightly different
> projects
> > > in user's minds, just ones that inter-operate quite well.
> >
> > Having two pieces of webapp (WMS and WFS) is good for webapp

developers

> > willing not to care of both services at the same time. Integration

should

> be
> > avaiblable at the configuration level (especially if you want to build
> maps
> > with WMS and using the same geo-data send GML with WFS). This may

allow

> > strong interoperability between them. Somewhere the key point will be
> having
> > the common jar files (like geotools2) in one or more places.
> >
> > >
> > > Ok, I'm sure there will be more questions about this, but we can

hold

> off
> > > for discussion on geoserver-devel.
> > >
> > >
> > >
> > >
> > > thanks,
> > >
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Geotools-gt2-users mailing list
> > > Geotools-gt2-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
> >
> > didier
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

7

I would have serious reservations about moving to a WFS only datasource for the WMS server. Supporting WFS for those datasources that Geotools does not support natively is a good idea, but using WFS as an another layer between the WMS and the actual data, when Geotools supports the data sources natively is a bad idea imo. It is just asking for performance issues. There is no advantage of adding the extra layer of parsing and encoding when the same functionality can be acheived through the Geotools DataSource API. Sure it is a nice demostration of chaining services but the performance hit would be too much imo.

Sean

your wms application not connect to database
directly, the wms connect with an wfs server, that wfs is
connect directly to the database or shapefiles, etc. and the wms extract the
information from the wfs in gml format trouhgt wfs request.

So yes, my thought is to have the wms connect to the databases directly
for now, as I've just about finished that, and work later for deegree
style interoperability.

Chris

8

I would have serious reservations about moving to a WFS only datasource
for the WMS server. Supporting WFS for those datasources that Geotools
does not support natively is a good idea, but using WFS as an another
layer between the WMS and the actual data, when Geotools supports the
data sources natively is a bad idea imo. It is just asking for
performance issues. There is no advantage of adding the extra layer of
parsing and encoding when the same functionality can be acheived through
the Geotools DataSource API. Sure it is a nice demostration of chaining
services but the performance hit would be too much imo.

I agree, we don't want only WFS datasource. Just as another option.
Basically I think it'd be nice to accept deegree wfs as a geotools
datasource, and have deegree wms accept geoserver as a datasource. For
the former we would just interface with their wfs, which can send features
instead of gml, if and when our feature models are harmonized. For the
latter we need to be serve up serialized harmonized features. Sorry for
the confusion, I didn't mean to imply that we'd get rid of geotools
datasources, just that we'd seek more options for interoperability. I can
easily see how what I wrote could be read that way.

  Chris

Sean

>> your wms application not connect to database
>>directly, the wms connect with an wfs server, that wfs is
>>connect directly to the database or shapefiles, etc. and the wms extract the
>>information from the wfs in gml format trouhgt wfs request.
>
>So yes, my thought is to have the wms connect to the databases directly
>for now, as I've just about finished that, and work later for deegree
>style interoperability.
>
>
> Chris
>
>

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

9

Le Vendredi 3 Octobre 2003 16:44, Chris Holmes a écrit :

> I would have serious reservations about moving to a WFS only datasource
> for the WMS server. Supporting WFS for those datasources that Geotools
> does not support natively is a good idea, but using WFS as an another
> layer between the WMS and the actual data, when Geotools supports the
> data sources natively is a bad idea imo. It is just asking for
> performance issues. There is no advantage of adding the extra layer of
> parsing and encoding when the same functionality can be acheived through
> the Geotools DataSource API. Sure it is a nice demostration of chaining
> services but the performance hit would be too much imo.

I agree, we don't want only WFS datasource. Just as another option.
Basically I think it'd be nice to accept deegree wfs as a geotools
datasource, and have deegree wms accept geoserver as a datasource. For
the former we would just interface with their wfs, which can send features
instead of gml, if and when our feature models are harmonized. For the
latter we need to be serve up serialized harmonized features. Sorry for
the confusion, I didn't mean to imply that we'd get rid of geotools
datasources, just that we'd seek more options for interoperability. I can
easily see how what I wrote could be read that way.

Could we say that, viewed from WMS, any WFS can be seen as a datasource :
GeoTools DataSource API needs {get|add|remove|modify|set}Features(),
commit(), rollback(), setAutoCommit(), getAutoCommit(),
{get|create}MetaData(), getSchema(), abortLoading(), getBounds() methods ...
I believe that a WFS can been seen through its operations as another gt2
datasource.

Having such a WFS datasource (and testing it with deegree) allow access to any
GIS component that has a WFS not only flat files (like Shapefile) or DBMS
(like postgreSQL), but (hopefully ?-) with ArcIMS, GeoMedia, etc. Which leads
us to "real" (or better) interoperability.

didier

  Chris

> Sean
>
> >> your wms application not connect to database
> >>directly, the wms connect with an wfs server, that wfs is
> >>connect directly to the database or shapefiles, etc. and the wms
> >> extract the information from the wfs in gml format trouhgt wfs
> >> request.
> >
> >So yes, my thought is to have the wms connect to the databases directly
> >for now, as I've just about finished that, and work later for deegree
> >style interoperability.
> >
> >
> > Chris
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel