[fdo-users] RE: SPAM-LOW: RE: [mapguide-users] Problem with OS Geo FDO Providerfor Raster.

[Jason Birch]

Frank wrote:

> I'd add that I think the GDAL provider *could* be suitable for this
> size image if we get to incorporating a tileindexing scheme. 

Hmm.  Copying this to the FDO list too, as it's really about an FDO provider (though MapGuide's the only client for this one currently)

For 50,000 images, I can't imagine that on-the-fly tileindex generation would be all that effective judging by my experience with file access times on only ~100 ecws.  The first user on every reload of the provider would kill the server.  

It would be cool if there were two modes: 

 - by default the provider caches image extents in an in-memory tileindex so that lazy users with few images don't have to do anything and still get good performance
 - optionally, the user can upload some XML into the resource data, defining a static tileindex so that the files don't need to be read the initial time.

These would use the same structure and access methods, it would only be the initial population of the index that would be different.

Rapid image serving is critical; especially when even sophisticated folks somehow expect Google-level performance from a single server over a single connection.  This is one area I'm taking some initial flack on, as performance isn't as good as it was with the old proprietary MapGuide (with either the ADSK provider or the GDAL one).  

My testing shows that about half of the load time is because of server-side re-rendering and delivery to the browser, but about half of it (in my 100-image set) seems to be taken up re-accessing all of the images on every load.

I might be able to round up some (not enough) $$$ to put towards Frank's time to add this kind of functionality.  

Anyone else in the same boat as me?  Frank, what would it take?  Would we see some performance enhancements with a simple version upgrade on GDAL as well?

Jason