Difference between revisions of "WhereTheFaoAmI"
(→WhereTheFaoAmI Experiment) |
(→Experimentation) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 10: | Line 10: | ||
Conditions to call this service: | Conditions to call this service: | ||
| − | * The user must have an account on the infrastructure | + | * The user must have an account on the infrastructure; |
| − | * The device must have access to (an external) GPS | + | * The device must have access to (an external) GPS; |
| − | * The user must click a button <Get Fao Area> to invoke the service | + | * 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 | + | * The service should only use wifi. |
To make it useful for on-board data collection, a 'few' additional requirements have to be added: | To make it useful for on-board data collection, a 'few' additional requirements have to be added: | ||
| Line 19: | Line 19: | ||
* 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. | * 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. | * 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 === | === 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 | + | 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 | + | This hypothesis can be tested by e.g. adding a feature to find the FAO area to the NKUA mobile Application. |
=== Prediction === | === Prediction === | ||
| Line 30: | Line 31: | ||
=== Experimentation === | === Experimentation === | ||
| + | The service can be developed once a WPS interface for the Statistical Manager can be invoked via REST calls; July 2014? | ||
| + | |||
| + | Two components are required: | ||
| + | * The SM based FAO-Area identifier (Receives GPS coordinates, provides FAO-Area); | ||
| + | * The Mobile App FAO-Area requester (requests GPS coordinates, receives FAO-Area). | ||
| + | |||
| + | Additional features on both app (UI and vizualization) and infrastructure (user identifier, message, error and exception handling) are taken for granted. | ||
=== Conclusion === | === Conclusion === | ||
Latest revision as of 09:52, 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?
Two components are required:
- The SM based FAO-Area identifier (Receives GPS coordinates, provides FAO-Area);
- The Mobile App FAO-Area requester (requests GPS coordinates, receives FAO-Area).
Additional features on both app (UI and vizualization) and infrastructure (user identifier, message, error and exception handling) are taken for granted.
