[Zoo-discuss] GSoC 2015 JGrasstools and Zoo-WPS

Alexander Kmoch alexander.kmoch at aut.ac.nz
Fri Mar 13 01:02:58 PDT 2015


Hi,

with some trickery and crude brute force I got an example from the zoo 
generator [1] to jgrasstools java wps [2] up and running.


http://localhost/cgi-bin/zoo_loader.cgi?service=WPS&version=1.0.0&request=execute&identifier=RasterReprojectorBuilder&DataInputs=inRaster=/vol1/www/smart/tmp/dtm.asc;pCode=EPSG:3003;pInterpolation=NEAREST_NEIGHTBOUR;outRaster=/vol1/www/smart/tmp/dtm_out.tiff;pNorth=5110870.0;pSouth=5110830.0;pWest=1637140.0;pEast=1637190.0;pRows=4;pCols=5

I am getting increasingly excited. There's certainly a long way to go, 
but it looks promising.

Basically I had to collect all jar dependencies for the JGrasstools 
modules, add them to the CLASSPATH of the Generator.jar and it genertes 
the *.zcfg files. So I copy the *.zcfg into the ZOO cgi folder and als 
add all the libs to ZOO main.cfg for CLASSPATH.

The input/output HashMap handling is wrong in the generator. But it's 
not as easy, I admit. But I took one of the examples, 
RasterReprojectWps", and modified it slightly to get the ZOO WPS 
inputs/output HashMaps translated into the OmsAccess thingy maps. I I 
also played with Logging. It's really difficult to debug. For the test I 
had to use all the input parameters, because otherwise the Oms Input 
parser would crash with NumberFormatExceptions (String "NULL" -> Double..)

So the RasterReprojectWps actually works and creates a new raster (from 
the dtm.asc to a GeoTIFF), but the CGI-process does not finish properly 
after the raster creation ... I'll have to look in more depth, why?

In the Apache2 error log: "... [cgi:error] malformed header from script 
'zoo_loader.cgi': Bad header: Finished."

But I think this has some really good potential :-) A lot of work should 
in fact go into the Java handling from ZOO side, and to make it easy to 
develop processes in Java and the JGrasstools/OMS3 Generator is pretty 
good already. But I bet there will be a lot of little mean obstacles to 
get it generalised :-)

I'll see that I prepare a bit more of a detailed project description for 
the application. I'd be happy about some feedback.

Looking forward,
Alex

[1] https://github.com/moovida/zoo-java-example-service
[2] https://github.com/moovida/jgrasstools/tree/nf_zooproject/


Am 13/03/2015 um 15:25 p.m. schrieb Alexander Kmoch:
> Hi,
>
> I got the ZOO WPS SVN working with Java and could successfully
> reproduce/reenact Andrea's (JGrasstools) slightly more elaborate
> zoo-java-example-service with a local data file path and additional jar
> dependencies [1].
>
> I have some questions/ideas/suggestions regarding the ZOO Java API
> (ZOO.java/class)
>
> It seems the JavaScript and Python API access is a bit more elaborate.
> Is it possible to access the ZOO cgi config and env from the JVM? I
> could add some logic for referencing/using the ZOO tmp/data paths for
> valid web file references.
>
> Also I am not quite sure how sophisticated data access via the
> HashMap<String, String> style is to ingest geometries and complex
> features in different styles (Java Topology Suite, Geotools)? I'll lok
> and test a bit.
>
> Fuerthermore I would be happy to provide a more straight forward way to
> develop ZOO Java Services as Maven projects and then just drop the jars,
> no Makefiles for Java :-D Maybe some fixed boilerplate code as part of
> the ZOO API, that employs Java Service Loaders or the likes to read from
> resource files in the user services jars? And Java users can use the API
> as a maven dependency to easily see ZOO Java API in the Eclipse projects?
>
> Exemplary with JGrasstools.
>
> @Andrea, I'll have a look at your generator to understand which approach
> you were following :-)
>
> Cheers,
> Alex
>
>
> [1] https://github.com/moovida/zoo-java-example-service
>
>


More information about the Zoo-discuss mailing list