[sldev] Plotting Data on SLURL

[Yoz Grahame]

(Sorry for taking so long over this reply - things have been a mite  
hectic over here)

On Apr 7, 2008, at 11:40 AM, Harold Brown wrote:
> [[  Forgot to send to list ]]
>
> Is there any further word on updates to the mapAPI system?
>
> As of right now not all regions can be displayed, nor are the tile
> sets exactly the freshest the further you zoom out.
>
> I have my own API wrapper made for OpenLayers (
> http://www.openlayers.org ), using my custom TML service that uses the
> SL backend (with some small issues).   The wrapper is fairly complete,
> but I haven't continued work as I don't know what direction LL will be
> going with the mapAPI system.
>
> You can view a demo of the wrapper at:
> http://www.mysldev.com/OpenLayer/oslurl.html
>
> The Region Names are a virtual TML service that generates an image
> dynamically for the region name.

Let's separate out the various components of the SL map system for  
this conversation:

1: The map tile generator. This is a nasty legacy system which is  
desperately in need of an overhaul, and also the main cause of some  
tiles being out of date. Unfortunately, right now, those who are most  
able to fix it are taken up with various big scaling and stability  
tasks. We do have the ability to fire off regeneration of specific  
tiles, though it still takes a day or two for the fresh tiles to be  
fully replicated across servers.

2: The backend service which makes the map tiles available to the web  
servers. Another legacy service which we'd rather didn't exist -  
ideally the web service hosts should be able to pull web-ready tiles  
on demand.

3: The front-facing web services called by the Javascript map. These  
are primarily used for translating between X+Y coords and region  
names. We have no problems with anyone calling these from any app,  
within the bounds of sensible usage (i.e. non-painful load levels). We  
have a long-term aim of making more and better web services available  
to developers, a process we're intending to accelerate this year.

4: The Javascript API used by map pages, which lives in slmapapi.js  
and sits on top of the GMaps API. This is the second version of the  
Javascript API. We chose GMaps as the underlying API as it's solid,  
has good cross-browser support and is popular amongst web developers.  
However, it also requires that developers acquire and use a GMaps API  
key - something we don't see as a significant barrier, but it does add  
a dependency.

Harold: The OpenLayers work you're doing looks great. We currently  
have no specific plans for major changes to the mapAPI's existing  
functions (i.e. the combination of items 3 and 4 above). Generally  
speaking, your code should be fine for the forseeable future. If you  
have any specific areas of concern, if there are major dependencies  
which you think we should know about, or if there are particular  
enhancements you'd like to see, please let me know so that I can  
ensure they're considered in any future plans.

-- Yoz Linden, Program Manager for Web & Internal Tools