[Geoserver-devel] WPS in Java

jive · February 5, 2007, 5:46pm

Hi Gao:

The number one tip is to join forces with someone already doing it

You will find the geoserver-devel list intersting (they are starting to
provide support for the "open web" part of the WPS. Their email list
archive contains contacts for people working on this over the last year;
in addition to talks with the "FROGS" framework (which is specifically
focused on WPS).

As for tips;
1. produces the WPS just in terms of pure Java interface and so on, with
a couple implementations - just to make sure you have the concepts correct
2. look into the GeoServer dispatch system as documentation is made
available over the next couple weeks (you can set it up to take care of
both the request and response side of WPS)
3. look into the XML binding documentation in the GeoTools library (if
your WPS is going to be working with large volumes of data in an xml format)

Cheers,
Jody

Jody:

I want to implement WPS( Web Processing Service ) specification of OGC in Java language.
The reference is the python project pyWPS http://pywps.wald.intevation.org
I learn that you are also in the maillist of osgeo and have made a great many contribution for udig
I wanna get some tips from you on how to start this project to implement WPS in Java.
Thanks a lot.
    Gao\_Ang
    gao\_miao@anonymised\.com
      2007\-02\-04

Gao_Ang · February 6, 2007, 3:50am

Jody:

Thanks for your response.
I have made some experiment with Grass SOAP project with WPS specification.
52north WPS has made a implement of Java WPS and make a plug-in for Jump GIS.
JavaWPS will foucs on the implemation of hundreds of functions that come from GRASS GIS and provide more convenient way to and publish GRASS GIS functions. That is to say, GRASS GIS API will be published as services and could be used for free on the internet.

Also, I want to put the mature GRASS functions and algorithms library to the Geoserver and provide the service on the internet.
It's just an idea, I'll try to make some contribution on this project.

Nice to get your tips.
I'm gonna devote to it after I take part in the graduate exam next month.

Best regards
======= 2007-02-06 01:46:35 =======

Hi Gao:

The number one tip is to join forces with someone already doing it

You will find the geoserver-devel list intersting (they are starting to
provide support for the "open web" part of the WPS. Their email list
archive contains contacts for people working on this over the last year;
in addition to talks with the "FROGS" framework (which is specifically
focused on WPS).

As for tips;
1. produces the WPS just in terms of pure Java interface and so on, with
a couple implementations - just to make sure you have the concepts correct
2. look into the GeoServer dispatch system as documentation is made
available over the next couple weeks (you can set it up to take care of
both the request and response side of WPS)
3. look into the XML binding documentation in the GeoTools library (if
your WPS is going to be working with large volumes of data in an xml format)

Cheers,
Jody
Jody:

I want to implement WPS( Web Processing Service ) specification of OGC in Java language.
The reference is the python project pyWPS http://pywps.wald.intevation.org
I learn that you are also in the maillist of osgeo and have made a great many contribution for udig
I wanna get some tips from you on how to start this project to implement WPS in Java.
Thanks a lot.
    Gao\_Ang
    gao\_miao@\.\.\.1054\.\.\.
      2007\-02\-04

= = = = = = = = = = = = = = = = = = = =

Gao_Ang
gao_miao@...1054...
2007-02-06

(attachments)

Andrea_Aime3 · February 10, 2007, 1:50pm

Gao_Ang ha scritto:

Jody:

Thanks for your response. I have made some experiment with Grass SOAP
project with WPS specification. 52north WPS has made a implement of
Java WPS and make a plug-in for Jump GIS. JavaWPS will foucs on the
implemation of hundreds of functions that come from GRASS GIS and
provide more convenient way to and publish GRASS GIS functions. That
is to say, GRASS GIS API will be published as services and could be
used for free on the internet.

Also, I want to put the mature GRASS functions and algorithms library
to the Geoserver and provide the service on the internet. It's just
an idea, I'll try to make some contribution on this project.

Very interesting indeed. I think you and Andrea Antonello, JGrass
developer, may be interested in sharing some idea? Andrea is porting
JGrass to the uDig architecture, uDig being the desktop brother or
Geoserver (they both leverage Geotools to perform actual GIS tasks).

Cheers
Andrea Aime

Andrea_Antonello2 · February 11, 2007, 9:40am

Andrea Aime probaly wrote:

Gao_Ang ha scritto:

Jody:

Thanks for your response. I have made some experiment with Grass SOAP
project with WPS specification. 52north WPS has made a implement of
Java WPS and make a plug-in for Jump GIS. JavaWPS will foucs on the
implemation of hundreds of functions that come from GRASS GIS and
provide more convenient way to and publish GRASS GIS functions. That
is to say, GRASS GIS API will be published as services and could be
used for free on the internet.

Also, I want to put the mature GRASS functions and algorithms library
to the Geoserver and provide the service on the internet. It's just
an idea, I'll try to make some contribution on this project.

Very interesting indeed. I think you and Andrea Antonello, JGrass
developer, may be interested in sharing some idea? Andrea is porting
JGrass to the uDig architecture, uDig being the desktop brother or
Geoserver (they both leverage Geotools to perform actual GIS tasks).

I've tried both the current implementations I know currently, the jump
plugin (or was it in degree? Can't remember... there are so many) and
the pyWps. The python wps is how things should really work. That is
really well made.

I was asked some time ago if JGrass could be used in a J2EE environment,
since JGrass was born pluggable and "should" have a standalone engine.
But at that time the project was already too polluted by some
programming between people not talking to each other.

Indeed now the JGrass stuff will go into UDig. But take into
considerations two things:
- to port the engine part in a proper way we will need some accurate
overview of our design, in order that this could be usable also from
geoserver. We have a clear idea about how it should behave to interact
also with a commandline engine and be chainable, which I feel should
also be a good design for geoserver, but you never know...
- JGrass has ported some of the generic GIS modules and has a lot of
other modules. But remember, GRASS has a hell of modules more, which
would probably need to be bound by some JNI, like the python guys are doing.

Cheers,
Andrea

Andrea_Aime3 · February 11, 2007, 2:43pm

Andrea Antonello ha scritto:

Andrea Aime probaly wrote:

Gao_Ang ha scritto:

Jody:

I've tried both the current implementations I know currently, the jump
plugin (or was it in degree? Can't remember... there are so many) and
the pyWps. The python wps is how things should really work. That is
really well made.

The more I look at python implementations, the more I notice they
are usually simple and clean, easy to understand. The downside, I don't
really see much exception handling, so I'm wondering if they're solid
as well.. Anyways, there's stuff to learn from these guys.

I was asked some time ago if JGrass could be used in a J2EE environment,
since JGrass was born pluggable and "should" have a standalone engine.
But at that time the project was already too polluted by some
programming between people not talking to each other.

Indeed now the JGrass stuff will go into UDig. But take into
considerations two things:
- to port the engine part in a proper way we will need some accurate
overview of our design, in order that this could be usable also from
geoserver. We have a clear idea about how it should behave to interact
also with a commandline engine and be chainable, which I feel should
also be a good design for geoserver, but you never know...

Chainable as in this screenshot?
http://www.clarklabs.org/products/images/growth800.jpg
I did work on a similar modeler just after the degree, unfortunately
the project was a failure... (we did use both GRASS and Autocad Map)...

- JGrass has ported some of the generic GIS modules and has a lot of
other modules. But remember, GRASS has a hell of modules more, which
would probably need to be bound by some JNI, like the python guys are doing.

I thought one could use JNI to leverage libgrass, but about the GRASS
commands, isn't the command line designed to allow building a
description and a user interface out of it, automatically? I remember
some kind of XML descriptive format, autogenerated from the command
line parser...

Cheers
Andrea

Andrea_Antonello2 · February 11, 2007, 3:13pm

I've tried both the current implementations I know currently, the jump
plugin (or was it in degree? Can't remember... there are so many) and
the pyWps. The python wps is how things should really work. That is
really well made.

The more I look at python implementations, the more I notice they
are usually simple and clean, easy to understand. The downside, I don't
really see much exception handling, so I'm wondering if they're solid
as well.. Anyways, there's stuff to learn from these guys.

Absolutely agreed. Also it is important that GRASS is always more
evolving to have clean interfaces towards who wants to use them. This is
what delays a bit projects written in the same language that would like
to be a native GUI, but supports also all the other GUI projects to
exploit GRASS's power.

[...]

Indeed now the JGrass stuff will go into UDig. But take into
considerations two things:
- to port the engine part in a proper way we will need some accurate
overview of our design, in order that this could be usable also from
geoserver. We have a clear idea about how it should behave to interact
also with a commandline engine and be chainable, which I feel should
also be a good design for geoserver, but you never know...

Chainable as in this screenshot?
http://www.clarklabs.org/products/images/growth800.jpg
I did work on a similar modeler just after the degree, unfortunately
the project was a failure... (we did use both GRASS and Autocad Map)...

That is exactly what I meant
The OpenMi interfaces support this kind of chaining.
Is there something left of the modeler that we could start on?

- JGrass has ported some of the generic GIS modules and has a lot of
other modules. But remember, GRASS has a hell of modules more, which
would probably need to be bound by some JNI, like the python guys are doing.

I thought one could use JNI to leverage libgrass, but about the GRASS
commands, isn't the command line designed to allow building a
description and a user interface out of it, automatically? I remember
some kind of XML descriptive format, autogenerated from the command
line parser...

You absolutely remember properly. That builds the tcl/tk GUI in case the
command is called without arguments.
I don't understand exactly what you mean. Why should the JNI binding in
your opinion not work?

Ciao
Andrea

Andrea_Aime3 · February 11, 2007, 4:01pm

Andrea Antonello ha scritto:

Indeed now the JGrass stuff will go into UDig. But take into
considerations two things:
- to port the engine part in a proper way we will need some accurate
overview of our design, in order that this could be usable also from
geoserver. We have a clear idea about how it should behave to interact
also with a commandline engine and be chainable, which I feel should
also be a good design for geoserver, but you never know...

Chainable as in this screenshot?
http://www.clarklabs.org/products/images/growth800.jpg
I did work on a similar modeler just after the degree, unfortunately
the project was a failure... (we did use both GRASS and Autocad Map)...

That is exactly what I meant
The OpenMi interfaces support this kind of chaining.
Is there something left of the modeler that we could start on?

Uarg! Please don't make me think again about the dark ages when I was
programming in VB6... yeah, the thing was
made in a mix VB6, some sprinkles of C++ and a tiny bit of java on the
server side to allow GRASS commands to be called from the client side.
At the beginning of the project I did have a choice between VB6 and
Delphi, chose the former because it seemed to be more supported by
Autodesk, and have been cursing myself for that decision every day so far.

- JGrass has ported some of the generic GIS modules and has a lot of
other modules. But remember, GRASS has a hell of modules more, which
would probably need to be bound by some JNI, like the python guys are doing.

I thought one could use JNI to leverage libgrass, but about the GRASS
commands, isn't the command line designed to allow building a
description and a user interface out of it, automatically? I remember
some kind of XML descriptive format, autogenerated from the command
line parser...

You absolutely remember properly. That builds the tcl/tk GUI in case the
command is called without arguments.
I don't understand exactly what you mean. Why should the JNI binding in
your opinion not work?

GRASS modules are lots of independent "main" program anyways, if you
call the program from the command line interface and it has problems, it
just breaks and you can report it, if you're using JNI you risk bringing
down the the JVM as well. Not something you may want in a long lived app
such as Geoserver. I'm playing with an OGR based datastore, first error
you make and the JVM goes down as well.

Cheers
Andra

Andrea_Antonello2 · February 11, 2007, 9:14pm

- JGrass has ported some of the generic GIS modules and has a lot of
other modules. But remember, GRASS has a hell of modules more, which
would probably need to be bound by some JNI, like the python guys are doing.

I thought one could use JNI to leverage libgrass, but about the GRASS
commands, isn't the command line designed to allow building a
description and a user interface out of it, automatically? I remember
some kind of XML descriptive format, autogenerated from the command
line parser...

You absolutely remember properly. That builds the tcl/tk GUI in case the
command is called without arguments.
I don't understand exactly what you mean. Why should the JNI binding in
your opinion not work?

GRASS modules are lots of independent "main" program anyways, if you
call the program from the command line interface and it has problems, it
just breaks and you can report it, if you're using JNI you risk bringing
down the the JVM as well. Not something you may want in a long lived app
such as Geoserver. I'm playing with an OGR based datastore, first error
you make and the JVM goes down as well.

Ah, well, I didn't expertise that problems, good to know.
Anyway, there are backdraws in both cases. We execute modules with the
old runtime exec (perhaps ProcessBuilder is better now) and the problem
was that some of the vector modules call other modules and if the got
lost in the Nirvana, we were not able to get them back. Shutting down
JGrass didn't kill those modules and some windows user had hughe
problems with modules eating memory :))

However, what would be your idea? To execute modules through process
builders?

Cheers,
Andrea

Andrea_Aime3 · February 12, 2007, 9:12am

Andrea Antonello ha scritto:

Ah, well, I didn't expertise that problems, good to know.
Anyway, there are backdraws in both cases. We execute modules with the
old runtime exec (perhaps ProcessBuilder is better now) and the problem
was that some of the vector modules call other modules and if the got
lost in the Nirvana, we were not able to get them back. Shutting down
JGrass didn't kill those modules and some windows user had hughe
problems with modules eating memory :))

However, what would be your idea? To execute modules through process
builders?

I was thinking about Runtime.exec since ProcessBuilder requires jdk 1.5,
but I was not aware of the vector modules issues... ah, it's a hard world...

Cheers
Andrea

Andrea_Antonello2 · February 12, 2007, 9:22am

Andrea Aime probaly wrote:

Andrea Antonello ha scritto:

Ah, well, I didn't expertise that problems, good to know.
Anyway, there are backdraws in both cases. We execute modules with the
old runtime exec (perhaps ProcessBuilder is better now) and the problem
was that some of the vector modules call other modules and if the got
lost in the Nirvana, we were not able to get them back. Shutting down
JGrass didn't kill those modules and some windows user had hughe
problems with modules eating memory :))

However, what would be your idea? To execute modules through process
builders?

I was thinking about Runtime.exec since ProcessBuilder requires jdk 1.5,
but I was not aware of the vector modules issues... ah, it's a hard world...

Oh how true
I tried ProcessBuilder and it seems to work much better in the sense
that it keeps in better sync input and output stream issues.
In fact that vector issues were told me to be solved, but I never tried
the new binaries. So...
I completely support the idea of the runtime, since I hate JNI with all
my will. The portability nightmare there begins and never ends...

With runtime there should be no big problem to add a huge amount of
GRASS stuff to create WPS... the creation of the proper execution
environment is no big issue... sounds very nice to me.

Ciao
Andrea