Summary of meeting with Jeff Linden on the SL Maps API

April 14, 2007 at 12:47 am (Jeff Linden, Linden Lab, Second Life, SL Maps API, SLOpenID)

Jeff Linden on the ‘old’ Linden Lab SL Maps API

In my opinion, we deployed it before we were really ready to scale it. The way it works is kinda awkward, as anyone who’s tried to hack it up can see.

I think, that what we really should be doing, is just giving out a sim image web service, a name to co-ordinate web service, and let Residents do with it what they will.

The SLOpenID SL Maps API

Jeff Linden on the SLOpenID SL Maps API

Well, I think you did pretty good, certainly a better improvement on the API than we did. In any case, I think for the future of the webmap, we’re in pretty much agreement.

SignpostMarv Martin on the SLOpenID SL Maps API

We’re grabbing the sim maps from the 1:1 scale images that the Linden Lab API spits out, then shrinking and compositing them ourselves for the higher levels.

The 1:1 region images are addressed much clearer- ahern.jpeg vs 997-277-1-0 and 992-1023 992-1023.jpeg vs 31-8-6-0 for example. (in SLOpenID’s higher zoom level example, the first two numbers represent the vertical range of grid co-ordinates, and the second set represent the horizontal range of grid co-ordinates- making it easier to figure out what regions are included in any zoomed out texture).

Jeff Linden on the future Linden Lab SL Maps API

Your API does pretty much everything we want in a future API, but in any case we need to solve our back-end problem first- which is “deliver the sim images in a better way“. I’m actually talking about more than just the API. the way we currently generate these images, it’s painful and delicate.

We only have access to jpeg2000 versions. So we regenerate them into jpgs and stick them in a central db. Then each webserver caches locally.

We only use them internally as jpeg2000 because of the world map in the Second Life Viewer. One developer’s finishing up changes to the in-world map image generator, to spit out both j2k and jpg versions.

Unfortunately, the webmap is not one of our top fires. Though it’s pretty high on our list.

I had jokingly offered Jeff the source code for the SLOpenID API, but as he’s said, there’s a lot of work to do before Linden Lab are ready for an upgrade.

The Viewer world map

SignpostMarv Martin on the world map

Here’s a suggestion: Get rid of the j2k version altogether, replace the world map and mini map with uBrowser. Then the load on grid servers will be instantly lifted. the other suggestion of course would be to add JPEG support into the client

Most of the metadata displayed on the world map is already available on the web. If all the data that the world map uses is available as a web service, then the Viewer can have a field that lets the end-user use a LL or Resident-made solution. Either that, or add greasemonkey support to the in-world browser. I’m sure Cristiano would love the in-world map to have a Snapzilla option.

Jeff Linden on the world map

Using uBrowser for the world map would be easier said than done. As long as we finish that one piece of work that will generate jpg map images. Then it’s just a simple matter of finding a place to cache and a lightweight web service.

It may not be too much work, actually- but I’m not the dev working on the uBrowser. However, the viewer is open source now- anything is possible there, right?

2 Comments

SLOpenID SL Maps API

April 12, 2007 at 6:29 pm (SLOpenID)

It’s not just that I’ve been working on recently, I’ve been doing geeky things for SLOpenID as well.

The post on the SLOpenID blog goes into a bit of detail on the low-complexity SL Maps API replacement for the official one, so I won’t go into too much about it here. I will say it’s worth checking out if you’re a bit frustrated with the complexity of the Linden Lab API.

1 Comment