More cartographical goodness

While preparing to test the viability of monthly map updates, including automated generation of the continental images (I didn’t update those during the last update), I started work this afternoon on a script that’ll calculate what regions are in each of Agni’s continents.

It was surprisingly easy to get the script up and running (the whole process completing in under 4 minutes on the local box)- it’s now setup as a cron-job to update on the 2nd of every month (the images being tentatively generated on the 1st).

After having this take a surprisingly little amount of time to complete, I tried thinking of ways to play with the data before I start playing with the automated image generation on Thursday. After an hour or so of coding and debugging, I came up with this: CSS3-enhanced Continental Maps.

I’ve used the CSS3 :target selector, combined with some Javascript DOM geek-fu to highlight the region currently being hovered over in the list on the left. The map is currently a rather plain absolutely-positioned CSS arrangement, though I hope to use the aforementioned images to make things more interesting to look at.

Gecko- (Firefox and the in-world browser) has no problem with the CSS3 + JS setup, though both Presto (Opera) and WebKit (Safari) handle the CSS3 aspect fine, the JS used to assist the CSS3 code (or rather, what happens as a result of the location changing) results in the page appearing to auto-scroll up and down. Trident (Internet Explorer 7) being Trident, can’t handle the CSS3 at all and thus degrades gracefully to a plain list with a dull looking blob next to it. It also has a rather odd tiling effect which is also likely a result of Trident’s inadequacies.

sw.slr bugfixes

  1. Fixed a problem with auto-discovery of Resident UUIDs failing if Linden Lab’s search engine hadn’t gotten around to indexing it’s own documents.
  2. Fixed a long-standing bug with the Domesday Book, whereby pagination cut-off at 1400 pages.

What is sw.slr ?

Preamble

sw.slr is the term I use to describe my research project implementing microformats for Second Life data. It’s a relatively convinient short-form for Semantic World.SecondLife.com Replacement.

Unstructured data vs. structured data

The majority of content on the web is human-readable (though most of it is aimed at sighted users, not blind ones); A user starts their web-browser of choice, navigates to a website, then the rendering engine (usually one of Gecko, WebKit or Trident) or browser plugins parses the source code/data and renders the page for human reading.

Unstructured, convoluted or seemingly random markup choices (usually termed tag soup) don’t generally have an effect on the human readability of the rendered page, but what happens when you need to embed contact information in the web page ?
The typical implementation would be to just put in a block of HTML in the web page (a paragraph, div or table), then type the details in. Many websites exist, and they’re all likely to mark up the contact information in a variety of ways- this isn’t a problem for human readability.

The problem becomes when computer systems need to read the data- making the information machine readable, so a piece of software can reliably extract the required data. There are numerous ways in which a postal address can be marked up- too many for a piece of software to be programmed to understand (A.I. aside). This is where microformats come in.

Microformats

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards.

Due to the nature of microformats not requiring any separate sources of data (unlike FOAF), the same web page can be used as both a human-readable data source and as a machine readable data source, allowing the software parsing the data to be completely ignorant of the endless combinations of possible markup and only focus on the markup specified by the microformat in question.

World.SecondLife.com

If you examine the source code for a document on Linden Lab’s domain- my Resident profile, for example, you’ll notice that the coding choices seem largely arbitrary, meant to fit the needs of human readability, with only the bare minimum of structure- the multiple profile description elements are given the class attribute value of “desc”. Beyond the aforementioned rendering engine parsing, none of the information contained in the document is machine readable, without the software having to first be taught what the source code actually represents- a process which took many hours of development and testing for all the data sources on world.secondlife.com (Residents, groups, regions, parcels, events).

sw.slr

The documents under the sw.slr project are coded using structured XHTML + appropriate microformats. Taking my Resident profile again, the (which has not been programmed with any prior knowledge of the markup I’ve chosen for sw.slr, beyond the various microformats it support) is able to extract the basic contact info for my avatar and convert it to a vcard- which can be used in a wide array of address book management software:

4f30cf238eb9b1_

As you can see, the Operator extension is able to extract my avatar’s name (being able to also seperate the first and last names), UUID, rezday and photo. What this means any 3rd party web service can parse the the sw.slr site just for microformats, allowing a richer experience when trying to search for Residents, groups, or locations (all marked up with hCard, though in-world locations are using a slightly modified version of geo). There are a few key variations on Linden Lab’s choice of markup;

Semantic improvements

  • Contact details are marked up in hCard.
  • Picks are marked up as hReview
  • Groups founded by the Resident are included and marked up with hCard, being associated with the founder via hResume.
  • The UHU4-version allowed for friends lists to be imported from secondlife.com via a greasemonkey script- marked up using XFN (with full control over which relationships are visible)

Cross-referencing information.

  • Groups founded by the Resident are listed in the Resident profile.
  • Land owned by the Resident (groups too, soon) is listed all in one page, for easy viewing- see Governor Linden‘s list of parcels, for example.

Though currently disabled (various elements of uhu4-based code was disabled due to it’s inefficiency), sw.slr also supports listing which Residents have mentioned another Resident in their picks, as well as listing all of the events hosted by a particular Resident, or held in a particular location.

The general aim of the research project is to demonstrate that SL data can be marked up in semantic ways, allowing for 3rd-party, specialised search engines to index the data. It also allows web developers to locate data within a document more easily- relying less on regex and more on DOM actions.

UHU5 code snippets: LLSD/capabilities components

While trying to find a source-code sherpa, I’ve been working on an LLSD parser- it’s mostly complete now, so I started work on an interface to LL’s capabilities services- here’s some snippets that show off the geekiness of the code:

4f30cf239b6cc1_

Here’s the kicker- uhu_capability_regapi::get_error_codes() doesn’t exist- overloading magic is at work. The actual uhu_capability_regapi class consists of the following chunk of code:

4f30cf239b6cc2_

When uhu_capability_regapi is instantiated, an authenticated call (using the uhu_SL_capability_user object) is made to uhu_capability_regapi::url() (not quite there yet with late static binding yet, still using call_user_func_array(get_class($this)) magic). This document is then parsed using a custom LLSD DTD (no point using the full LLSD spec when we know what to expect, is there ?), and stored as a named array.
When $regapi->get_error_codes() is called, uhu_capability_regapi::__call(‘get_error_codes’) is invoked- because this matches a value stored from the initial LLSD call, the class then fetches, parses and returns a usable structure of the returned LLSD document.

Now since I know what the calls returned by /get_reg_capabilities will be, you might be wondering why I’m using __call() magic. I present a hypothetical:

  1. I release the code, you download and use it.
  2. Linden Lab add another call on the regapi service, while I’m away on holiday/having power outtage.

If I didn’t use the __call() magic, you’d not be able to make use of the newly added feature unless you either patched it in yourself (which you may not have the time/skill/inclination to do), or waited till I got back, became aware of the new call, read through the documentation, added a new method, tested, updated documentation then released it.

By using the overloading features of PHP5, I’m able to “future proof” against any new calls added to a capability service without making any alterations to code. I don’t need to explicitly do anything to use the RegAPI now (once my account gets cleared for use with it, I’ll be able to test that theory :-P ), though I do plan to write a bunch of code to auto-populate an exception class for the RegAPI with values from get_error_codes, just to automate the error detection a little.

Wanted: Source Code Sherpa

I’m in need of a source code sherpa to help me navigate the SL Viewer source code- specifically the portions involved in the retrieval of the in-world events data, so that I can have a more reliable, single data source for the events portion of sw.slr.

If you’re interested in helping out, send me an IM in-world, or on Skype.

Images of Agni

It’s been a while since I updated the map of Agni, so in between UHU5 upgrades, I thought it was prudent to update the map. As before, the image is available on the Second Life Wiki, though for this update I’ve added a new image.

Distribution Guide

A complaint of previous updates was that appeared to have missed out large parts of the new landmass- this was due to the standard “empty sea” image being returned from Linden Lab while the map was being composited. To correct for this, I’ve generated a “sim distribution guide”- basically, a black & white image, with each black square (4 by 4 pixels on the full scale image) representing a single region. With the background being white instead of the blue water colour, it’s much easier to see where individual sims are.

Landmass Statistics

I’ve also added a table to the index for sw.slr that shows how big the grid is compared to a list of English counties and US states/territories.

You may notice that the table has a “grid” column- this is because I plan to add support for OpenSim to sw.slr (the UHU5 upgrades were coded with this specifically in mind), so eventually you’ll be able to see how big each grid tracked by sw.slr is compared to RL places.

It has been suggested that I also track RL-SL population density statistics, but I’m still undecided as to what figure to use for Second Life’s population.

Burning Life 2004 Trailer, saved for future enjoyment

I recently experienced a rather catastrophic had disk failure, resulting in the loss of about 300GB worth of music, video, wallpapers and software archives. Thankfully, all my code is remotely backed up so there wasn’t much of a problem there, and all of my music can be re-ripped.

Unfortunately, a video that holds sentimental value was lost- or at least that’s what I thought. Way back in May 2005, I was stumbling around the internet and came across a website for a rather odd looking virtual world, that had recently held some strange “event”. After lookng around the website, I found a couple of videos that caught my eye- I downloaded them for later viewing, and signed up on the website. I hadn’t noticed the software for this strange, new world required WinXP, so it was another 5 months before I managed to rez for the first time on Orientation Island.

This video of Burning Life 2004 holds sentimental value for me, as it’s what got me interested in Second Life in the first place- hence why I was a little upset at the prospect of losing it. The video was previously hosted on FireballTrailers.com, which quite some time ago became a parked domain, leaving me with what I thought was possibly the only remaining copy of the video in existence. After my friend and data recovery geek managed to recover the video from my nearly obliterated hard disk, I thought it was best to upload the video (along with the first official trailer for Second Life) for the world to once more enjoy such a fantastic piece of Second Life’s history.

auto-update for groups being held back by WEB-787

It seems that Linden Lab’s recent changes to the layout/design of the search appliance has resulted in a rather annoying bug: periods seem to be stripped out of the group name in the result listings, resulting in a false negative for the portion of UHU5 that handles group2key auto-discovery.

Since it doesn’t particularly make sense for the result listing to be lying about the contents of the search result, I’m not willing to make alterations to UHU5 (e.g. have the code parse each individual result document). The search listings should not be considered untrustworthy, therefore I’ll by holding back the deployment of auto-update for groups till after Linden Lab have fixed WEB-787.

An important note to any fan of Torley's music

Torley’s entire collection of published music (with Ogg Vorbis instead of MP3 where avaiable for moar fidelity) totals 3.75 gb:
Burn the collection to DVD once you’re done downloading to avoid having to re-download it all over again.

Truncated descriptions in sw.slr Resident profiles

Those of you with lots of URLs in their profile descriptions may notice that the description gets cut short. This is due to a bug with Linden Lab’s software that results in broken HTML.

I’ve reported the bug to Linden Lab’s bug tracker- go vote for it on if you want the bug to be resolved with any expedience.

The broken HTML is filtered out before it reaches the database, which is what results in the description being truncated. Once Linden Lab fix the bug on their end, the changes will automatically clear up on sw.slr.

Bad Behavior has blocked 194 access attempts in the last 7 days.