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

[Nichols, Mark A.]

I'm interested in this thread.  I have similar problems.  I'm trying to
create a cache of ALL of my tiles right now so that I can get some
better performance.  Even with cached tiles, the PNG's are still rather
large and makes for slow performance in my particular situation.  It
would be great if I had a tool to create a cache tile catalog.  Even
better, if the images could be jpg's instead of png's, I could drop the
file sizes from 100k to 20k easily.  Or so it seems.

 

What kind of $$$ are we talking about?  You can email me privately if
you'd prefer.  This functionality is very important to me.

 

In the mean time, the code I have for caching tiles isn't working
correctly.  If you have something you're willing to share, please pass
it on.

 

Mark Nichols

Spicer Group

markn at spicergroup.com

 

 

________________________________

From: mapguide-users-bounces at lists.osgeo.org
[mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of Andy
Morsell
Sent: Thursday, February 22, 2007 1:42 AM
To: 'MapGuide Users Mail List'
Cc: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-users] Problem with OS Geo FDOProviderfor Raster.

 

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 --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-users/attachments/20070222/db3a331a/attachment.html