This is a bit off the subject of Mapdex but if you are an ArcIMS user and would like to publish your imagery data with Google Maps, then check this out...

I have debated with myself and others about if and how we should publish our large raster datasets within the Google Maps framework.  State and local gevernments have large amounts of high quality aerial photography, often much better than what Google Maps provides.  But how do small government agencies deal with the massive computing infrastrcutre of Google?  One of the reasons people like Google Maps is that it is a fast, seamless repository of imagery (high quality in some areas, very low in others).  The speed for Google Maps lies in the tiling scheme.  Unfortunately the Google Map API does not allow (currently) a way to overlay an image that spans multiple tiles, if it is an image then it must conform to the tiling system.  Google Earth is much different.  I and others have shown how realitively easy it is to pass a network link containing ground overlays that span large areas on top of Google Earth's base data.  This is not the case for Google Maps (at least not that I have been able to see). 

So what can you do?

• Build a script that requests each tile from a mapserver/service in real-time.  This works, but of course it is slow and represents a heavy load on the ArcIMS/SDE server.  If a client is using GM and is viewing 40 tiles at once that is 40 requests made to the database/map server for one screen image.
• Pre-build all the images at all the appropriate scales for a mapservice.  This would be blazing fast (it would be exactly what GM does), but it would mean another replication of a dataset.  I did some back of the envelope calculations and figured that to cover all of Kansas at all the appropriate zoom levels (zoom level 7 to zoom level 0) for our 1meter 2002 DOQQ layer would be approximately half a terabyte.  Considering that we already have that dataset in SDE and are quite happy with the performance with our map servers, it would be hard to justify the expense and upkeep in drives just to support GM.  And what do we do if/when Google changes their tiling scheme or image size?  Who really knows what Google's future plans for Google Maps are?
  
• Build a cache-on-the-fly approach for a mapservice.  As interesting as Kansas is, most users don't want to look at every 300m X 300m tile (zoom level 0) over the entire state!  So do the best of both worlds.  As a user zooms into GM for one of our map services we check to see if someone else has requested the image before and if so then return the cache image.  If it is the first time any user has been to an area, then use ArcIMS to build the tiles for the area and save them to the cache.
  

http://geoportal.kgs.ku.edu/googlemaps/

So check out the cache-on-the-fly approach that I have implemented for GM for Kansas.  You can see the 1meter 2002 state-wide DOQQ's or see the 6inch City of Lawrence DOQQ's.  It is quite a difference compared to the imagery that Google has for Kansas and Lawrence.  I will be releasing the ArcIMS script soon (as soon as I document it).  It is fairly straightforward (take GM tile coordinates, reproject to mercator projection, request mercator image of ArcIMS service, & save image for cache). 

I want to thank Just van den Broecke, Brian Flood, & Kyle Mulka for figuring out the Google API javascript (could someone from google please tell me why the getLatLng function is not in the map API?)

If Google is really serious about GM, then they should implement a service like this that allows agencies to provide access to their spatial data via ArcIMS or ArcGIS Server.  It strikes me as an "overnight" SDI for imagery...

So what do you think?

Jeremy