Report of E-Conference about the implementation of the Geospatial component of EDIT WP5.4
30/11/2007 from 10h to 11h30 (via Skype)
Markus DÃ¶ring (BGBM) Malte Ebach (BGBM) Dilan Laetif (SZMS) Andras Gubanyi (HNHM) Jorge Lobo (CSIC) Bart Meganck (RMCA) Patricia Mergen (RMCA) Pablo Sastre Olmos (CSIC) Pere Roca Ristol (CSIC) Franck Theeten (RMCA)
The main objectives of this discussion is to have a status on the available services of the Geospatial components and to check their compatibility with the other areas of the EDIT Cybertaxonomy platform. Thus the importance of having colleagues form the dev-list to attend. I attach the draft JPA3 (M24-M42) for info.
Agenda with the topics to discuss:
Short Status from each participant on the status geospatial services in development (not exclusively all directly related to EDIT, but also from other projects that could be reused for EDIT), the technologies and standards used.
Further steps to be agreed upon for JPA3 (the ideas were sent to the EDIT team-leader mailing lists, but we have not received many comments so far. Hereunder are several suggestions of modules to be constructed around the core geospatial platform of Madrid. These services have been identified as useful for taxonomic research during the assessment phase. But we have to set priorities to achieve this realistically. Additionally to these modules there are also further developments needed on the core components of the platform as highlighted by CSIC in the JPA3.
o Module for Camera and Publication ready maps based on OGC compatible core components developed by CSIC (RMCA/CSIC) o Testing of module for camera-ready maps (IPSAS/CUB) o Module to upload end-user georeferenced data and georeferenced data from external sources like GBIF, Gazetteers, layers (RMCA/CSIC) o Module for distribution modeling based on presence data when no absence data (typically the case of Museum specimens). Test implementations with Garp and Maxent (RMCA/MIZPAN) o Module to link sampling localities on the Geospatial Platform to the corresponding literature resources and vise-versa (RMCA) o Module for Phylogeography (link with Barcoding) and module for morphometric variants by geospatial regions.
- Organization of a joint Geospatial training course with WP5.4, WP7 and WP8
Topics: Guidelines on information to collect during field sampling, Post processing of the collected information, Usage of Geospatial related and statistical tools, Production of Distribution maps
- Any other urgent issue raised by the participants.
A Introduction :
The first goal of the e-conference was to have a status report on the development of the geographical components of the EDIT cybertaxonomy platform and to check the interoperability and compatibility of these developments with the other components of the platform.
The second aim was to centralize the comments of developers of the Cyber-taxonomy Platform and the members of the WP5.4 group on the draft text of the 3rd JPA and to select the most feasible components from the one proposed by this document.
The e-conference confirmed that the target audience of the platform is the community of taxonomists. Identified priorities are to finalise the services of the core elements of the geospatial platform, namely visualisation and uploading of own data in form of both points or areas. The modules to offer them in priority are the possibility to produce publication-ready maps and basic analysis of the spatial completeness of data from occurrence data they upload to the platform..
In the future plans (JPA4) we could add further services, such as the link to literature, facilities for the production of checklists, visualisation of morphological variants and phylogeography.
The main discussion focused on the degree of integration which should be followed in the implementation of the platform.
Discussion about the visual outlook of the platform and its interface introduced the idea of an online solution, because this would be the main advantage of the platform in comparison with the existing desktop local GIS application.
When discussing the possible types of output data we tended to promote a more modular approach, with separate service (map creation, transformation of raster to point, calculation of uncertainty, conversion to DarwinCore, etc..), which are compatible with other data providers.
This discussion intersects with the nature of the concept of â€œplatformâ€: modular approach consider that the platform should encompass not only the end-user interface, but also an underlying web services.
We investigated several points, more particularly the possibility for the platform to cache maps and the development of a REST interface to query it. After some discussions we agreed that the caching of maps is not a key feature of the platform at the moment (as the data furnished by the platform are not supposed to be permanent), but that the development of an interface able to query the data such as it was webservice is necessary. We will follow what Markus calls REST â€˜senso latuâ€™ (a service â€œusing the URL to transmit individual parameters, not XML messages").
C Technical issues:
C.1-Define the symbology dynamically for the legends bound to a map.
We agreed on the idea that we must not define this legend completely on the fly, but to use a predefined set of classes, interval and boundaries which can be customized by the user in synchronization with the upload of point data. This solution also implies that the user will only upload vector data, while raster data whill be statically embedded in the service and used as background layer..
C.2-Input parameters (such as the datum): We made a first enumeration of these parameters:
-Title of the map
-datum of the points / spatial reference system (do we mention the SRID explicitely or predefined set of projections?)
-chosen background map
-Extensions of points for errors
-Bounding box to delimit the boundaries of a map
Suggestion on the fields to add can be found here (http://www.herpnet.org/gbif/Database_fields.html)
Several questions were addressed:
-Can we allow default values for all or part of these parameters?
-Are they given by the user along with the uploaded source data or/and defined after the importation of points by the means of a graphical interface?
D Workplan :
We agreed to focus on the following points.
1) Core components of the GIS platform
1.a Visualisation of data
1.b Upload of data
2) Implementation of a service module (for the production of publication-ready maps)
have still a question about the meaning â€œcamera-ready mapsâ€ which is mentioned in the JPA text!ïƒ by Google the term it seems to mean the same as publication â€“ready in guidelines for preparing illustrations for Publications (http://www.ucpress.edu/books/authors/pdfs/illustrations.pdf) on page 16 are guidelines we may want to use)
3) Production of good documentation, Guidelines and User-guides to the usage of the Geospatial components and its modules. Organisation of trainings of Georeferencing and GIS systems for the end-user in collaboration with other WPs like WP7 and 8.
We suggest to come back to other suggested modules when reviewing the JPA document or writing the next one.
The implementation of point 1.a is almost done by the CSIC. RMCA and CSIC collaborated on the development of a module for 1.b which has already been tested and should be functional soon.
The elements of this e-conference will be used to organize a second larger public forum involving EDIT and non-EDIT partners about the Geospatial Services for taxonomists.
The GIS related service modules suggested will be put to discussion to the user-community to enhance their usability to the daily needs of taxonomists and other potential end-users.
F Source data:
TDWG regions (for background maps)
F Demo applications for visual rendering: