[mapserver-users] very large image handling & serving?

[Ed McNierney]

Matt -

It's not how big it is, it's what you do with it that counts.

We're running a MapServer application on a single Windows 2000 server
that's serving dozens of datalayers, several of which are raster
imagery, and one of which is about 600 gigabytes of images.  If you
organize, tile, and index your imagery well, there should be no problem
at all hosting enormous amounts of imagery on a single MapServer system.

The reason that's the case is because well-organized imagery will cause
MapServer to only focus on the relatively small number of source images
you need to create a requested map view.  Since the vast majority of the
imagery is ignored for any one request, it really doesn't matter if
there are 100K of other files lying around untouched or 3 terabytes of
other files lying around untouched.  They're untouched and have no
impact on the request.

You should be MUCH more concerned about characterizing your user
activity.  You're worrying about the wrong thing.  By far the biggest
question you need to answer is how many images (of what size) need to be
served each minute?  Understanding what your user scenario and usage
patterns will be like are the most important variables in answering your
questions.

	- Ed

Ed McNierney
Chief Mapmaker
TopoZone.com
ed at topozone.com
(978) 251-4242


-----Original Message-----
From: Matt.Wilkie [mailto:Matt.Wilkie at gov.yk.ca]
Sent: Thursday, August 23, 2001 8:18 PM
To: freegis-list at intevation.de
Cc: osrs at remotesensing.org; mapserver-users at lists. gis. umn. edu
(E-mail)
Subject: [mapserver-users] very large image handling & serving?


Hi All,

What is the current state of open source / free software solutions
for handling and serving very large images?

Please reply to me directly and I will summarize the responses back
to the lists in about a week.

The goal is to serve up ortho-mosaics with the following dimensions 
and size (uncompressed):

RAW MOSAIC
30 metre Standard: 	37,000 x 32,000 pixels = ~ 1.2gig
15 metre Panchromatic:	74,000 x 64,000 pixels = ~ 4.8gig
60 metre Thermal:       18,500 x 16,000 pixels = ~ 296 meg

IMAGE PRODUCTS 
30 metre RGB Composite      =  1.2gig x 3  =  3.6gig
15 metre Enhanced Composite =  3.6gig x 4  = 14.4 gig

The user would display a decimated reference image of the entire mosaic
and
draw a selection box to select their area of interest.
This could be via a web or standalone app. Most areas of interest
would probably not be larger than screen size (eg. 1280x1064). 

Clients would require everything from full resolution 1to1 images
for remote sensing analysis to decimated "web-ready" screen shots.

Other notes:

- clients are desktop publishing apps (Word, Excel, Publisher, 
Illustrator, PhotoShop), low end GIS (ArcView, MapInfo), high
end GIS/RS (ArcInfo v7&8, PCI), and web browsers (IE, NS).

- Mutli-segmented intranet, Windows NT 4 domain servers

- hardware of the server is yet determined but is not likely to 
be that good, at least initially (eg. ~1ghz, 768mb ram, IDE RAID)

- the sysadmins are all mostly Win32 based, the *nix expertise is
limited thus any *nix-based solution must be GUI and and should be
WIMP friendly.

- there is a non-trivial amount of ESRI inertia, thus for 
Mapserver to win out over ArcIMS there must be compelling 
arguments with pretty pictures.

- there is a non-trivial amount of Microsoft inertia, thus more
compelling arguments and more pretty pictures.

I have no idea what the actual demand on the server will be, but
potentially a lot -- 595 computers spread over 21 subnets on the
intranet just answered to "net view".

The results of this query are not likely to be implemented by
myself; I will be writing it up a report and passing on 
recommendations.



-matt

-----------------------------------------------------------------
Matt Wilkie * Yukon Renewable Resources GIS
http://renres.gov.yk.ca/pubs/rrgis/
-----------------------------------------------------------------