Difference between revisions of "03.05.2012 Geoprocessing"
Line 30: | Line 30: | ||
'''Follow up:''' | '''Follow up:''' | ||
+ | |||
EB: | EB: | ||
* To read the wiki, & eventually send questions to FB | * To read the wiki, & eventually send questions to FB |
Latest revision as of 11:22, 3 May 2012
WP3 Skype 12.05.03 10.00 - 10.30
Cluster geospatial
SPREAD and Geoprocessing; Anton Ellenbroek, Fabrice Brito, Emmanuel Blondel
FB: Updates on geoprocessing. Francesco finished the description of the library; https://gcube.wiki.gcube-system.org/gcube/index.php/Geospatial_Data_Processing
The code is enriched with examples, and shows how to use it from JAVA. Includes streaming.
To use the service, one must understand how to provide input, output, parameters, and self-implemented BL. Simple examples from Emmanuel could start to migrate his re-allocation approach.
EB: Simple example for SPREAD would be to generate an intersection. Question before processing is to link the layers to the data.
FB: Layers could be managed by WFSWeb Feature Service. the service can accept references such as: baselayer=http://somedomain.org/wfs?blabla & targetlayer=http://somedomain.org/wfs?blabla
EB: Our starting point are TS, but we have no established relation yet with a specific layer. We have a base layer (FAO Areas) and a user selected taget layer (EEZ). Before processing we need to establish the relation between TS and layer. In my case, we ned to go even further; fao-area, target layer, and csquares. But we can start simple with 2 layers.
AE: Managing TS is beyond the scope of the geoprocessing offered by terradue. If needed, we should develop our own Business Logic (BL) for that. Another issue, can the library persist intersections?
FB: Depends on the case. One could use e.g. SQL-Lite. With WPS-Hadoop the results are usualy not saved, but we could add some BL with Java. EB could use an existing code and bring it to the process.
EB: Can we also discover if a intersection already exist? In SPREAD, we are not yet at data processing phase. The current Intersection Engine stores intersection result in a single big table. Before processing, check if it exists.
FB: We can support that with the WPS. The community will have to develope the BL. We have a geoserver to check.
EB: We have to consider the tools that were already decided in FAO. FAo has a contract with Geosolutions to work on the intersection engine, and improve it's interoperability.
FB: The WPS-hadoop should work with existing code, we do not want to wait for third parties to developed code later. BL is develoed in JAVA, try to find some component that we can port to the environment. We need ideas of a simple example what needs to be processed.
Follow up:
EB:
- To read the wiki, & eventually send questions to FB
- To prepare a first simple use-case for SPREAD (input, output, parameters, data)
Next call Tuesday 08-05 10.00 am.