[Geoserver-users] Java OGC Web Services Client SDK

OK. I will start a new Maven module for what I'm doing and work with
that for now.

We will work on getting the Geoserver module on your project space so
that I can add an extension.

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wednesday, June 17, 2009 4:06 PM
To: Patel, Ronak Avinash (US SSA); geoserver-users
Subject: Re: [Geoserver-users] Java OGC Web Services Client SDK

Please keep the discussion on the list, as other developers need to
chime in as well.

The answer is it really depends on the functionality. Some functionality

is suitable for being put into the core of geoserver. But some
functionality is more suitable for being an extension. From what I have
heard of what you want to do it sounds like this is more suitable as an
extension. If the extension gets enough uptake from users and other
developers, the community may decided that it should be core
functionality.

Also, becoming a committer to a project like GeoServer takes time. We
don't just hand out commit access to people. Getting commit access takes

the trust of the other committers. By first developing in a community
module is a good way to start earning that trust. It allows the other
developers to review your code, and come to know the quality of your
work.

But even after that, it takes more to get commit access to the core,
outside of your module. Getting core commit access usually amounts to
contributing minor patches that fix bugs. Once enough of your patches
have been reviewed and accepted, and again once that trust is earned,
you will be granted core commit access.

All in all for newcomers it is usually best to start developing code as
an extension, if anything to become familiar with GeoServer development.

-Justin

Patel, Ronak Avinash (US SSA) wrote:

Would adding this little thing qualify as a new feature and module?

Why

can't I just bundle it with the existing code and let it ride?

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wednesday, June 17, 2009 3:43 PM
To: Patel, Ronak Avinash (US SSA)
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Java OGC Web Services Client SDK

Hi Ronak,

Patel, Ronak Avinash (US SSA) wrote:

Justin,

Codewise, where do you guys already produce GeoRSS? I was thinking of
using Rome from java.net and its GeoRSS extensions:

http://wiki.java.net/bin/view/Javawsxml/GeoRSS
http://wiki.java.net/bin/view/Javawsxml/Rome

In the wms module there is a georss output format. If you want to see

it

quickly in action just ask geoserver for the following url:

http://localhost:8080/geoserver/wms/reflect?layers=topp:states&format=rs

s

It does not use the rome library, it rolls its own georss producer.

There is also the geosync community module which produces an rss feed:

http://svn.codehaus.org/geoserver/trunk/src/community/geosync/

It does use the rome library.

Do you mind if I bring in other dependencies? I don't know how the

whole

approval process works here on that...

Well the way it usually works is you request permission to create a
community module. And then you are given some community space (like
where geosync lives) to build your module. You are free to add the
dependencies you need. Getting a community module is relatively easy,
you just need to mail the list and explain your intentions, and get

the

approval of at least one PSC member.

After you feel your community module has matured enough that it is

ready

to become a geoserver extension, it can be upgraded to an extension
module. However, there are certain requirements for extensions above
that of community modules, it needs documentation, a maintainer, a
certain percentage of test coverage, etc...

The community module process is explained in detail here:

http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules

I would like to group the RSS code with the Catalog code or with the
rest of the RSS generation code...

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Tuesday, June 16, 2009 4:18 PM
To: Patel, Ronak Avinash (US SSA)
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Java OGC Web Services Client SDK

Patel, Ronak Avinash (US SSA) wrote:

Right but the plumbing to invoke and register the listener and then

what

kind of URL scheme do we want to use....I would imagine that's

something

the Geoserver team would want some say in...also...

You mean the url schema for the feed? Yeah I guess have a couple of
options here. But I am thinking maybe something like:

http://localhost:8080/geoserver/rest/catalog.rss

Besides publishing the bounding box for coverages, which is pretty

much

what I need, do we want to expand this to features as well?

We could pretty easily i think. The GeoServer catalog model abstracts

the idea of a coverage and a feature type into a "resource". Every
resource has a bounding box so it would be no extra work.

I'm thinking I would also just publish the wms url of the layer out

the

GeoRSS feed so external services can just hit that url to pull the

exact

layer.

Good idea. Simply tagging the feed entry with an atom:link which

points

back to the wms call should be relatively easy as well.

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Tuesday, June 16, 2009 3:39 PM
To: Patel, Ronak Avinash (US SSA)
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Java OGC Web Services Client SDK

Well.. .there is the CatalogListener interface, which can be used to

listen to catalog events. However, on 1.7.x it will the tricky. The

way

things work is that when something in the catalog gets changed,
everything gets updated. So tracking what changed is hard. I guess

your

listener could maintain an internal list, to see what changed on an
event, but it would be a pain.

On trunk however, the events are granular, so you only get an event

for

what changed.

In both cases, once your listener knows what changed, it would be
relatively easy to simply write the result to out a rss feed.

-Justin

Patel, Ronak Avinash (US SSA) wrote:

Thanks Justin...as is usual with me I found the answer right after

I

posted to the mailing list...

I'm going to try to write that GeoRSS feed for changes to the

wms/wfs

catalogs so interested clients can learn of changes to the catalog
(add/remove layers and layer groups).

I'm trying to determine an estimate on that now so I can determine
whether I should go down this path. Otherwise, I'll have to

generate

a

custom GeoRSS external to geoserver using a cron job...grrrr

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Tuesday, June 16, 2009 2:37 PM
To: Patel, Ronak Avinash (US SSA)
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Java OGC Web Services Client SDK

GeoTools has both a WFS and WMS client:

http://docs.codehaus.org/display/GEOTDOC/WMS
http://docs.codehaus.org/display/GEOTDOC/WFS+Plugin

-Justin

Patel, Ronak Avinash (US SSA) wrote:

Hi all,

I had a quick question where I was wondering if anyone knew of a

Java

OGC Web Services Client SDK. I figure this has been done to death

and

must exist out there.

Can anyone point me to an SDK I can use in my program to extract

layers,

features, etc. from Geoserver?

Thanks!!

Ronak Patel

------------------------------------------------------------------------

------------------------------------------------------------------------

------

Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables

unlimited

royalty-free distribution of the report engine for externally

facing

server and web deployment.
http://p.sf.net/sfu/businessobjects

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.