WP5.4 developers meeting at Tervuren

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

by Bart Meganck, RMCA.



Kohlbecker, BGBM

Mueller, BGBM

Roca Ristol, CSIC

Theeten, RMCA

Meganck, RMCA

Mergen, RMCA

BGBM : Botanischer
Garten und Botanisches Museum

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

: Royal Museum for Central Africa, Tervuren, Belgium.

of the meeting

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.

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

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.


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

that were defined :

Construction of a webservice around the CSIC demo MapViewer Tool.

functionalities are already available in the current online version
of the CSIC/MNCN

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.

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

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.


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).


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.

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

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.

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


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

: “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.

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

gathering :

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”.

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.

addition to these priorities, the hosting of the webtools was

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.

of the Geoplatform services :

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.

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

  • 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).

work by the different partners


  • 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


  • Toto
    Portal (Patricia Kelbert.)

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

  • provide
    feedback to CSIC about the webservice and user requirements


  • 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


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

& CUB :

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


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


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

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