[mapguide-users] Problem with OS Geo FDOProviderfor Raster.

[Andy Morsell]

I agree that all of the awareness that the likes of Google Maps/Earth,
Microsoft Live, etc. has brought to the masses has in turn raised the user
expectations of any web-based GIS application.  This is a double-edged sword
for us in that the awareness is great, but providing similar performance is
next to impossible since we simply do not have the hardware to throw at our
applications.  I also agree that enhancing raster functionality is going to
be critical for the future of MGOS and other applications and will look for
additional funding from clients needing this added functionality.  I would
also be willing to independently contribute some of my own (company) dollars
to functionality enhancements like this if there is a good road map with
detailed functional specs (similar to our RFC's) and timelines to be adhered
to.  In the end, it would result in functionality that would be appealing to
my clients and should would lead to future work.  How can we effectively
start to build these buckets of dollars from potentially multiple
contributors and prioritize the enhancement needs?
 
One area where raster performance gains can be achieved is to use base
layers (tiles) as they do result in much faster map displays since the
rendering is already done.  But, this area also needs some work - some of
which is currently being addressed, some of which is on wish-lists.
Pre-rendering the tiles is critical, however and hopefully we'll see more
people scripting this task or for this functionality to be added to the
core.
 
Andy 

  _____  

From: mapguide-users-bounces at lists.osgeo.org
[mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Wednesday, February 21, 2007 8:28 PM
To: MapGuide Users Mail List; fdo-users at lists.osgeo.org
Subject: RE: SPAM-LOW: RE: [mapguide-users] Problem with OS Geo
FDOProviderfor Raster.



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5726 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide-users/attachments/20070221/400e729e/winmail.bin