EDIT WP5 Platform for Cybertaxonomy

Report
on the EDIT WP5.4 developers meeting, Tervuren July 2nd 2008.

Report
by Bart Meganck, RMCA.

Participants

Andreas
Kohlbecker, BGBM

Andreas
Mueller, BGBM

Pere
Roca Ristol, CSIC

Franck
Theeten, RMCA

Bart
Meganck, RMCA

Patricia
Mergen, RMCA

BGBM : Botanischer
Garten und Botanisches Museum

CSIC
: Consejo Superior de Investigaciones Científicas, Madrid, Spain.

RMCA
: Royal Museum for Central Africa, Tervuren, Belgium.

Subject
of the meeting

This
WP5.4 developers meeting brought together the technical staff of the
institutes involved in the WP5.4 Geoplatform. The aim was to discuss
the ongoing work in the different partner institutes, to enhance
collaboration and interoperability, and to review the timing and
priorities within the upcoming WP5.4 components.

Specifically,
we wanted to go through the work on the core cybertaxonomy platform
in Berlin, and see how to integrate the GIS components in an
interoperable way with the other components of the platform. Based on
this we could define what needs to be adapted in the different GIS
modules.

In
the afternoon, we went through the components lists for JPA3, to see
if the deadlines are realistic to achieve, and to draft a work plan
for JPA4 with assignation of tasks to complete the components.

Priorities

The
discussions clarified which additional developments are needed in
priority for the Geoplatform, and enabled to identify the possible
synergies between the different components. Very broadly, we can say
that JPA3 is concerned with the basic version of the online tools,
whereas JPA4 will see external data (GBIF) connected and used in the
tools.

Priorities
that were defined :

1/
Construction of a webservice around the CSIC demo MapViewer Tool.

Many
functionalities are already available in the current online version
of the CSIC/MNCN
GeoPlatform.
Users
can upload their own point occurrence data in comma separated value
(.csv) format, change the symbology to their liking, and use them in
an interactive map.

The
usefulness of this tool will increase substantially once it can be
used additionally as a webservice enabling applications and website
portals to incorporate their own dynamic maps, generated on-the-fly
by this webservice. Thus the portal could get two faces : an online,
interactive mapmaking website and a background webservice called by a
simple parameterised HTTP request, delivering customised maps in
return.

The
meeting enabled a very fruitful exchange of ideas, with discussion of
the technical requirements and priorities for implementation. After
the meeting, Pere (CSIC) stayed until the 4th of July 2008
to collaborate with RMCA on the web-service “wrapper” around the
MapViewer Tool. Already a first working prototype of the webservice
has been put online (), and BGBM staff is testing it actively.

Through
this newly activated collaboration, requirements and specifications
for occurrence and distribution map generation webservices will be
further defined, as stated in to-do1 of our list (see table at the
end of this document).

2/
distribution

Once
the webservice “wrapper” is fully operational, the next priority
will be expanding the occurrence services into distribution services.
This is a complex topic, with the central question being how to
aggregate data of very diverse nature (specimen/species/different
periods in time) into overall distribution blocks. Once this
(functional) question is solved, technical implementation will pose
less problems, as much of the groundwork is already done in the
“occurence webservice” part.

Here
the question of C5.70 arose : “Implementation of converter
webservice that transforms point occurrence data to distribution
data.”

We
discussed this, and concluded that a converter like this is too
complex for a typical single component. We therefore propose to
reduce the scope of this component, and relaying part of the work to
a new component in JPA4 (see to-do3 and to-do4). Thus no additional
components are necessary within JPA3.

The
new title for the JPA3/C5.70 component could be : “Compile
requirements for point occurrence data/distribution data converter
webservice.”

And
JPA4 could include the following to-do's in a new component :

to-do4
: “Develop summary of requirements for point occurrence
data/distribution data converter webservice”. December 2008 seemed
a realistic deadline for this to-do, but it could be merged into
C5.70 as well, or into to-do5 under JPA4.

To-do5
: “Implementation of converter webservice that transforms point
occurence data to distribution data.” This to-do will be firmly in
JPA4.

3/information
gathering :

We
identified the information to be obtained prior the start of our
upcoming JPA3 components. This information gathering will be mostly
informal and spread between other work. This work is added as
“to-do's” to the list, to have an overview and a timeline of when
it needs to be done.

*
further involve scientists (taxonomists) for testing the geoplatform,
to see what can be done to really make the tools fit for their daily
use. This roughly coincides with to-do1, and is already being done in
RMCA, CSIC and BGBM, in synergy with the testing and improving of the
CSIC “occurrence webservice”.

search
and contact taxonomic publishers, compile a list of requirements for
their publication, in view of the publication ready maps (C5.67).
This work as well has to be done in the very near future.

*
renewing contacts with SMNS Stuttgart, assessing the current status
of the ATBI data gathering and processing, in preparation of C5.60
and C5.73. Both these components (C5.60 is strictly a WP5.2
component) concern the interaction of ATBI data and the Geoplatform.

In
addition to these priorities, the hosting of the webtools was
discussed.

The
question was if it could be done at RMCA, to ensure a stable
environment and a team taking responsability for the good functioning
of the software. As to the organisatorial side this would pose too
much problems, RMCA's only concern for the moment is bandwidth - this
problem should be resolved in the not too distant future.

Functionality
of the Geoplatform services :

In
the discussion on the functional requirements of the GeoPlatform, we
started from the basic philosophy : a common and networked platform
for taxonomic work. This means generic (web)services, that can be
used from within any data aggregating portal of from within other
applications. The user experience is also very important, as
scientists will only use the platform if it is a logical extension of
their current daily toolkit. It should be as unobtrusive as possible,
doing just what is useful for the scientists. That means listening to
the users from an early stage on, as is defined as a priority in this
work. Here the initiative lies mostly at BGBM, the other institutions
collaborating closely on the back-end.

Requirements
that were discussed :

• query
  protocol of the webservices (HTTP parameter names and types)

• standard
  codes for countries and regions (ISO codes, TDWG regions)

• islands
  and overseas territories : these should be shown as insets on the
  main country map. But how to align them without covering important
  parts of the main picture ? That is technically a hard problem,
  because it requires the software to be aware of what is on the
  picture.

• what
  is the exact technical definition of “print quality” : file
  formats, CMYK or RGB schema, dpi ?

• a
  legend for the maps would be very handy, but how to provide it. As
  an inset in the main map (the same problem as with the island
  insets), as a separate file ? What is most convenient for layout ?

• GBIF
  connection : will be the central issue in JPA4 . Here RMCA's
  ItinTool/Generic Query Tool duo will play an important role, as GBIF
  connection is central to that application as well.

• Is
  there any possibility to track already generated maps, so that they
  don't have to be generated over and over again ? Could they be
  stored in a permanent storage (Google?? ) and found through a
  standardised filename, and/or extensive metadata ?

• a
  grid for distribution data : some of the most commonly used grids
  and contours (such as TK25, continents, country borders, TDWG
  regions) should be provided within the tool

• personalised
  grids for distribution data : users should have the possibility to
  upload their own grids and contours ( as shapefiles ? ) for example
  for defining natural parks or country regions.

• more
  input file types : it would be nice if users could upload their data
  in a host of filetypes. This doesn't seem to be too difficult, in
  fact RMCA's ItinTool takes in .csv, KML, GML and GPX files, and can
  output them to a WMS. This WMS layer could then be used in the
  Mapping Tools – as has already been tried successfully.

• conforming
  to the CDM webservice format : before long, the CDM will define its
  own format for webservices. We keep an eye out for this.

• draw
  rectangle, get features within as a list : this is in fact
  “selecting units by spatial criteria” as mentioned in C5.40
  (JPA4). It's what people are used to find as a feature selection
  tool in all kind of mapping services (e.g. Google Maps).

Further
work by the different partners

CSIC

• work
  on Mapping Tool, providing webservice access to it (collaboration
  with RMCA).

• frequently
  check with BGBM and other partners if tool is developed in
  accordance to user requirements

BGBM

• Toto
  Portal (Patricia Kelbert.)

• portal
  connecting to CSIC Mapping Tool, through the webservice connection

• provide
  feedback to CSIC about the webservice and user requirements

RMCA

• Task leadership/coordination/
  follow-up of the components and tasks

• Gather input from the partners for
  the official reporting

• provide feedback to CSIC about the
  webservice and user requirements

• collaborate with CSIC on technical
  issues of the webservices

• consider
  possibility of hosting the WP5.4 GeoServer
  tools in RMCA

MIZPAN
:

• Define
  distribution modelling algorithms necessary for aggregation of
  occurrence data into distribution blocks (technical part of to-do3,
  preparation of C5.70).

IBSAS
& CUB :

• provide
  Slovakia ATBI data in compatible format. Synchronise data
  processing, data formatting and data quality assessment work with
  SMNS/BGBM CDM development.

HNHM
:

• test
  CSIC MapViewer Tool with Atlases, expeditions in Mongolia and ATBI
  Tanzania dataset.s

SMNS
:

• further
  work on CDM with BGBM. Provide info about current status of ATBI
  data gathering and processing in collaboration with IBAS, CUB and
  HNHM.

Attachment
: a spreadsheet schema listing the components and newly identified
to-do’s, with comments and participants for each.