Yet Another 3D Visualization of Mangani Fossils

This one's better'n the last one, I think:

Click here to view the app.

Same dataset, different way of viewing it.

3D Visualization of the Fossil Distribution of the Human-Chimpanzee Total Clade

What it says.

Click on the image to open the visualization.

I've been compiling data on "pan-mangani" fossils. This is my first March of Man toolshop post in a while: a 3D visualization of that data, where the horizontal axis is longitude, the vertical axis is latitude, and depth (the z-axis) is age. The "blobs" each represent a fossilized individual, and you can mouse over them to see what their taxon is.

Some data is missing, notably a lot of entries for our own species. Other data needs to be refined—some of the better-known species (ahem, Neandertals) are big clouds that need to be tied down to specific sites. Also, I obviously need to do more work on that present-day distribution map. But it's a decent start.


Fun things to do:

• See if you can find the oldest individual (the lone specimen of Sahelanthropus tchadensis).
• Try to find its Chadian compatriots.
• Find the earliest non-African individuals (hint: East Europe and the Malayan Archipelago).
• Wonder what the heck that thing in India is.
• Look for the single cluster of extinct chimpanzees (Pan sp.).
• Find the three subspecies of Homo sapiens other than our own. (Note: these may not be distinct from each other—I just prefer to err on the side of splitting for projects like these. Easier to revise later.)
• Marvel at how easy it is to become sympathetic to multiregionalism when you just view the distribution data without any morphological context and ignore the fact that not all regions are good for preservation.
• Wonder how people can possibly believe in baraminology in the face of such ample evidence. (Adding morphological data to this would help a lot—there really aren't any good "cutoff" points for our lineage.)

UPDATE:

Better version here.

A Plea to Providers of Open Webservices

Let's suppose you have a webservice, and you have decided, out of the goodness of your heart, to make it "open". Anyone can browse it, search it, and utilize the data it provides. This is something you want—for anyone to be able to utilize the data and present it in new, creative ways.


I'm willing to bet you missed a step.


Consider my Flash application, Names on Nodes. Right now it's a standalone program—it can import and export files locally from your system. But it doesn't read data from any webservice. There are many places in the program where it would be extremely useful to do so. For example, instead of having to enter LSIDs manually, it could search for them in uBio. Instead of having to open NexML files locally, it could pull them from TreeBase. Wouldn't that be nice? Why haven't I done that?


Well, fact is, I can't.


The Flash Player has a security mechanism whereby it will not load data across different domains. If my SWF resides on namesonnodes.org, then that is the only place it can load data from. Of course, there are ways around this: a good way, a less good way, and a really stupid way.




The Good Way


If your domain has a file called crossdomain.xml in its root, then the Flash Player will read that to see if cross-domain permission has been allowed. Here's an example of a crossdomain.xml file that allows maximum access across all domains:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
   <site-control permitted-cross-domain-policies="all"/>
   <allow-access-from domain="*" secure="false"/>
   <allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>

(Or, download it here.)


For more information, see the Cross-Domain Policy File Specification.


(Note that the folks at TreeBase are looking into this. I'm on tenterhooks.)




The Less Good Way


I could also make Names on Nodes as an AIR application. This is less good because it means the user would have to install it as an application on their local system, and they couldn't just access it online. But it would allow for more possibilities—not just the ability to load data from anywhere regardless of policy files, but also drag-and-drop from other applications, etc. I am actually planning to create an AIR version someday, but it's not my top priority right now.




The Really Stupid Way


Of course, I could also make a little server-side component on my domain and simply have it pull data from your domain before feeding it to the Flash application. This is really stupid because it greatly increases traffic on my webserver while still causing just as much traffic on your webserver as it would if you had just allowed cross-domain access with a policy file.




In Summary


It takes a matter of seconds to place a cross-domain policy file in your server's root directory (assuming you have access), there are no drawbacks if your service is intended to be open anyway, and there are huge benefits for us Flash developers who want to use your service. I mean, really, why not?

Wrapping Up In Portland

Yesterday was the last day of the iEvoBio Conference, and tonight is my last night in Portland. The conference was quite illuminating and I would definitely like to return for another one.

I've had some time tonight to address a few issues I would like to have tended to before the conference. For one, I hadn't updated the Names on Nodes website to link to the application! This has been remedied. In the process, I removed links to the NEXUS demo application, since it's a bit old and out of sync with the rest by now. I'll probably add it back after adding support for the NEXUS format to Names on Nodes.

I also made a few simple additions to Names on Nodes, including:

• Fullscreen mode
• Ability to specify which characters in a matrix you wish to import

The latter in particular should prove useful—some people were finding it impossible to open NexML files with character matrices. Since Names on Nodes only uses characters as part of apomorphy-based definitions, it's usually a big waste of time and memory to import entire matrices when only a few nomenclaturally-relevant characters (if any) are needed.

Once again I'd like to encourage people to check out the application and make feature requests and report issues on the BitBucket page.