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

[andrea antonello]

Hi Alexander,
you know that the GOSC didn't start yet, right? :-)

Jokes apart it is really a pleasure to find someone like you working
on the GSOC.

> 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.

I am excited as well, you already went further than I did when I gave
it a quick try. Congratulations.

> 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.

This part should be possible to generate from the annotated code in
the JGrasstools libs. So fun once, run everytime (or sort of :-)).

> 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..)

That is something we will have to take care. Do the java exceptions
come to the surface or are they translated in beautiful C segmentation
faults? :-)

> 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
> :-)

Yes, I hope it will be simple simple to generate tons of modules
compatiible with Zoo.

I think the one difficult thing might be to handle non local files,
i.e. understand in which way to feed rasters and vectors to the
processes. Apart of the use of WCS and WFS, it will be necessary to
convert what comes from the service (through GDAL I think) into the
modules.

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

Yes, great, looking forward to it.

Cheers,
Andrea

>
> 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
>>
>>
> _______________________________________________
> Zoo-discuss mailing list
> Zoo-discuss at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss