Home

Plant

Retrieval of Agricultural Production Standards

Mon, 2012-11-26 15:17 — jewie
Use cases: 
Automatic Compliance Checking
Description: 
Within the FutureFarm project there has been proposed an machine-readable encoding for the representation of agricultural productions standards. These represenations can be retrieved from rules servers using only HTTP methods. A prototype standards viewer can be tested on http://test.futurefarm.eu.
Deviations: 
This is an implementation only for the selection and retrieval of the machine-readable encodings of relevant production standards in to the client (e.g. FMIS). The process of compliance checking of these rule sets against field operations data is subject of another implementation.

e LABs

Mon, 2012-06-11 09:31 — f.van.diepen
Publisher: 
UNCEFACT
Specification: 
eLABS xsd
Description: 

exhange message for laboratory observations from labs to customer.

The laboratory observation information exchange process is used between the laboratory party who is reporting about the observation and the user of these observation report. This user is usually the party who uses the content of the report, but this user can also be the party who ordered and pays for the observation or has any other connection with the observation report.
The observation report can be used in private and in a public context.

The e-Lab observation report is a message send by the laboratory to the concerned parties who are eligible to receive the results of the observations on the sample, performed by the laboratory . The observations are done on samples water, soil, agricultural commodities, plant products, animal product and or samples taken from live animals. It includes a broad usage ranging from soil, fertilizer, crop products, animal feed, and health status and diagnostic on live animals. These results are used to obtain information of the quality of soil, water, crop products, animal products , or health information about plants or animals.
Only two types of parties are involved, the laboratory and the receiving parties.

Version: 
0.3
Licence: 
free of rights (uncefact licence)

Request for Weather Nowcast (GeoTIFF to XML conversion)

Wed, 2012-03-21 11:30 — Markku Koistinen
Purpose: 

Disease Pressure Service provides farmer the information on elevated risk of a crop (etc) disease. DPS alarms may be used e.g. to trigger a spraying event. The purpose of the data transfer is to get a weather nowcast for the Disease Pressure Service internal processes. The applicable actors are Advisory Service (Disease Pressure Service), Intermediator (Weather Service) and Field (Parcel).

Concept: 

Weather Service Provider provides weather information (e.g. nowcast) in GeoTIFF format through a Web Coverage Service interface. The actual weather data variable values are stored into metadata of a returned GeoTIFF image. Lightweight ESB like service was implemented between Disease Pressure Service and Weather Service to a) convert the WCS interface into more convenient SOA interface with XML message exchange and to b) eliminate the need to implement image metadata manipulation routines into the Disease Pressure Service server side code.

Used standards/de facto standards: GeoTIFF, WCS, ESB, SOA, XML, REST

More on SOA: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp...

More on REST: https://www.ibm.com/developerworks/webservices/library/ws-restful/

Design: 

Interface provides XML message exchange capability for Disease Pressure Service (DPS) when requesting weather information (nowcast) from Weather Service Provider’s (WSP) Web Coverage Service interface. The sequence begins with getNowcast action request (within a XML message) from the DPS to the lightweight ESB Service (ESBS) implement. The parameters (coverage) include the coordinates of the area the weather info is requested, weather variables needed and the timestamp of the sample. ESBS parses the request into a valid WCS request format (URL) and passes it to the WSP. The WSP response input stream (GeoTIFF image) is read by ESBS and the image metadata is applied utilizing Apache Sanselan class libraries. The valid parameters are extracted from the image metadata, parsed into a XML and passed to the DPS as a response.

The DPS and the ESBS services are implemented using Java EE (http://www.oracle.com/technetwork/java/javaee/overview/index.html). In order to implement GeoTIFF metadata reader you need to download and install e.g. Apache Sanselan (used in this implement) class libraries ( http://commons.apache.org/sanselan/download_sanselan.cgi).

Implementation: 

Disease Pressure Service uses a SOAP client for message exchange with ESB Service (REST implement). The DPS’s weather request (XML message exchange) triggers an event where the Weather Service Provider’s Web Coverage Service interface is called. The method is using basic Java .io and .net class libraries (InputStream is = url.openStream() where the url is an object from a class URL created passing WSC service url to the constructor). The beauty of the Apache Sanselan is that it can read the image metadata directly from the input stream (metaData = Sanselan.getMetadata(is, null)). The Sanselan metadata container type is an array list (ArrayList <Object> al = new ArrayList() , al = metadata.getItems()). The XML messaging between DPS and ESBS is currently using proprietary format but a possibility to use e.g. AgroXML is investigated.

Standards: 
GeoTIFF
WCS
XML
Source: 

agriXchange project team

Model: 

Test

Wed, 2011-09-14 11:16 — Esther
Use cases: 
Geo Fertilizer
Description: 
Test

Lot creation traceability

Fri, 2011-07-08 17:22 — a.turchi
Use cases: 
IACS
Purpose: 

Forwarding of data about creation of a new batch

Concept: 

After an actor executed a process of batch creation, it sends data about it to a central repository or to che customer

Design: 

The stream, usually persisted in a file, is sent to the receiver. It is important to stress that the semantic is hold in the receiver database, or - better - is shared between them

Implementation: 

In this case it is an Xml file, with a structur similar to the following example. Please notice that there is no description of Ids.

2
139
23
39
1
59
2004-11-04
2004-11-04

01214530436
148
AAAA1
42
4
-1
0001.5

...
...
...

Technical details: 
Xml file for general traceability purpose
Model: 

Interface to Compliance Checking

Fri, 2011-07-08 14:29 — m.schmitz
Use cases: 
Automatic Compliance Checking
Concept: 

Service for an automated assessment of agricultural production and management standards.

Design: 

The farmer verifies with help of a farm managment system or a similar software his data.

Implementation: 

Standards : W3C OWL, W3C RIF, XML

Request for Subsidies via open and standardized interface

Fri, 2011-07-08 14:04 — m.schmitz
Use cases: 
IACS
Purpose: 

Request for subsidies with the an application and a standardized interface.

Concept: 

The farmer needs an account at the agency. Request Form is integrated into specialized application or a farm managmend system.

Design: 

Web based service based on agroXML and or a similar data standard and with accompanying letter.

LPIS Boundery - Request via Applications & Web Service

Fri, 2011-07-08 12:42 — m.schmitz
Use cases: 
IACS
Concept: 

Request for LPIS Bounderiey with the web user interface. An desktop application provided by the IACS authorities has an exclusive access to the data.

Design: 

The farmer needs an account at the agency. With this Account he has access to the personalised data and a gis system.

Implementation: 

Web Service with an proprietary xml standard with GML.

Fertilization advice reply (Dutch)

Fri, 2011-07-08 12:06 — ari_ronkainen
Use cases: 
Geo Fertilizer
Concept: 

Manual contact and delivery

Design: 

Manual contact and delivery

Implementation: 

Manual contact and delivery

Fertilization advice request (Dutch)

Fri, 2011-07-08 10:55 — ari_ronkainen
Use cases: 
Geo Fertilizer
Concept: 

Manual request

Design: 

Manual request

Implementation: 

Manual request

Syndicate content