Difference between revisions of "WhereTheFaoAmI"

From D4Science Wiki
Jump to: navigation, search
(WhereTheFaoAmI Experiment)
(Hypothesis)
Line 22: Line 22:
  
 
=== Hypothesis ===
 
=== Hypothesis ===
The iMarine infrastructure is able to offer a responsive (10 ms), accurate (within 0.01 degree) WPS based webservice that informs on the FAO Area that contains a lat / long.
+
The iMarine infrastructure is able to offer a responsive (10 ms in infra), accurate (within 0.01 degree) WPS based webservice that informs on the FAO Area based on a sufficiently accurate lat / long pair.
  
This hypothesis can be tested by e.g. adding a feature to find the FAO area to the NKUA mobile Application or iMarine web-site.
+
This hypothesis can be tested by e.g. adding a feature to find the FAO area to the NKUA mobile Application.
  
 
=== Prediction ===
 
=== Prediction ===

Revision as of 10:48, 15 May 2014

WhereTheFaoAmI Experiment

Many modern applications require geospatial position information which is either retrieved from the device on which the app runs (Mobile phones / tablets), or from a connected GPS receiver.

Although there is no single standard for the position details, most mobile devices can produce a lat / long pair.

(For PC's, an IP based similar service can be suggested, although much less useful.)

In fisheries, it is important for reporting and research to know in what FAO area you are. With access to the device GPS system, the coordinates can be extracted, and using a WPS interface for the Statistical Manager (that can be invoked via REST calls) the FAO areas corresponding to the position can be returned.

Conditions to call this service:

  • The user must have an account on the infrastructure;
  • The device must have access to (an external) GPS;
  • The user must click a button <Get Fao Area> to invoke the service (de-activated when 'No-GPS' or No-Wifi');
  • The service should only use wifi.

To make it useful for on-board data collection, a 'few' additional requirements have to be added:

  • Include 'maps' in the App to reduce calls and traffic to the network (e.g. all csquare codes that have only 1 FAO-area)
  • For the csquares intersecting one or more FAO areas, this requires precise spatial data that is too large to be included in full detail in a device. The device could be loaded with rough maps, only for the "edges" the service need to be called.
  • Other than FAO area, much other information could 'travel'; EEZ, Port Code, etc.
  • In addition to the single calls, a batch process for already collected reports can be foreseen where FAO (Sub)Area is added to collected records once an app reconnects to wifi after a fishing trip.

Hypothesis

The iMarine infrastructure is able to offer a responsive (10 ms in infra), accurate (within 0.01 degree) WPS based webservice that informs on the FAO Area based on a sufficiently accurate lat / long pair.

This hypothesis can be tested by e.g. adding a feature to find the FAO area to the NKUA mobile Application.

Prediction

Experimentation

The service can be developed once a WPS interface for the Statistical Manager can be invoked via REST calls; July 2014?

Conclusion

References and links