GBIF-World Database on Protected Areas project

The GBIF-WDPA project intersects together the data from GBIF and the World Database on Protected Areas. It was developed by Vizzuality for GBIF and IUCN. I have talked about this project in different posts already, but I thought it could be interesting to share an screencast I created some time ago about it.

The video has a little introduction on what was the project about, what technologies were used and finally a demo of the application itself.

Ah! If you want to try the tool for yourself it is finally published. Try it for:

Australia

United States

Spain

Germany

Great Barrier Reef

Yosemite

Posets Maldeta (Pyrenees)

We are working right now on some more advanced visualizations, but this will come hopefully soon. I hope you enjoy it.

WMS Tiling Clients

For projects relying on open source software and using WMS services for their map applications perhaps the most obvious choice for a client application is to write something using the OpenLayers API. This is a very extensive javascript API and is used to demonstrate the open source OGC compliant servers MapServer and GeoServer. Its straight forward to construct a map and then to overlay multiple layers using WMS services.

The screenshot above shows a layer of 0.1 degree cell densities representing data from Australian National Herbarium rendered using GeoServer layered on top of the Google satellite base layer, all pulled together using OpenLayers.

Running this locally the map was rendered by OpenLayers rather quickly. Running this on an externally hosted server I began to notice curious loading of tiles by OpenLayers. So I did a stripped down comparison of the same functionality using the Google maps API. Rendering the cell density tiles from a WMS service in Google maps was done using a javascript function written by John Deck - available here.

The performance improvement with Google maps was immediately obvious. Using the Firefox YSlow plugin we see:

OpenLayers	Google Maps API

So the main thing of interest here is the number of tiles loaded by OpenLayers compared to Google maps (91 vs 50 - although oddly the total size of the images loaded is roughly equivalent, and the tile size for both seems to be 256x256 pixels). Increasing the size of the tile for OpenLayers does reduce the number of tiles requested (I tested with 512x512 and 1024x1024) but this has little effect on performance in openlayers.

So the performance difference between Google Maps and OpenLayers could be accounted for by any combination of the following:

• Incorrect use of the API (test for OpenLayers is here) and we are missing configuration to reduce tile loading in openlayers
  
• The tile loading algorithm for Google maps is more efficient in only loading the required tiles for selected view areas
• Openlayers is preloading more images to speed up panning. This would be good, but OpenLayers doesnt seem to prioritise the loading of currently viewed tiles.
  

The source for the test for OpenLayers is here, and for Google maps here.

The Taxonomy browser visualization #1 - Tree Lists

Hi, my name is Sergio Alvarez Leiva and this is my first pos at biodivertido, Finally. I'm part of Vizzuality and work as Interaction Designer for GBIF among others. I will mainly be posting about Interaction Design, UX and Design in general, althought I'll try to post about Front.end developing a little. I hope you find it interesting.

Since I began designing for Biodiversity data, I've encountered lot of interesting challenges related to the size of the datasets .

Maybe, one of the hardest challenges is designing a taxonomy browser visualization. The taxonomy browser can represent up to 1.7M names, with nodes with more than 200 childs. That makes it complicate in terms of interaction design and performance.

I will write in a series of post my impressions on different techniques we have been experimenting:

In this first post I'm going to talk about tree list visualizations, but before I get into details, I'd like to talk a little about generic concepts that might be applied to all the visualizations. There is a lot of bibliography about trees out there, but let me introduce here my own "easy" concepts.

When browsing a tree you need to know where you are and what is around you, thats parent and brothers and in general this is called Contextualization. Then you need to be able to find the childs, thats Discovering. All this needs to be easy to do, Usability and UX, and finally must be easy to integrate with the application, Easy integration.

On those terms, the tree list visualization presents some advantages and disadvantages.

- Contextualization: Maybe the list visualization is the most standard way to solve this problem. The tree lists lets the user discover the whole tree by clicking in the different nodes. But the problem is the vertical size that the tree gets when the user deployes a node (This is an integration problem too). When the user will have deployed more than 3 levels, he will have to use the vertical scroll, and probably, this action will make the contextual information (parent nodes and "brothers") out of the visible screen area.

This problem could be solved implementing some variations in the Tree list; We could hide all the nodes not related to the selected child and get more space for view only the important nodes.

-Poor UX : "Discovering biodiversity". We have to involve the users in our play and invite they to discover more and more. I think the Tree Lists are a little boring...we need more action!

- Usability: This visualization is pretty used and the users will understand how it works quickly. On the other hand, I think that in a Tree list is not so easy to find the desired node - the users would have to deploy a lot of nodes, and scroll a lot too, before find their objective. Maybe would be positive for this point to implement a search box. It might depend of the data size.

Conclusion; We've a standard visualization that lets us to implement a Taxonomic browser in a lot of different situations. I think this is not the best solution that we could implement, but its true that we could use this always.