[Mapserver-dev] Re: 3.7 and native image rendering support

[Steve Lime]

John: What I'm proposing is not a modification of output formats, but in how raster input formats
are handled. At the moment there are several legacy raster drivers that, with the exception of one,
are handled by OGR. I propose retiring those drivers in favor of pure OGR raster support. The 
exception would/could be GIF/PNG input, yup input, with world files via GD. The changes are
relatively minor- removing code rather then adding anything.

Steve

Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937

>>> "Administrator" <jnovak at novacell.com> 02/11/03 01:49AM >>>
This is a bit late, but...

I've been using nothing but PNG files as output, and I have local
changes that allow me to render layers with alpha blends.

What is the alternative to PNG output files if this support is
deprecated ?

IMHO, this seems like a rather large change to start at this late date
in the 3.7 development cycle, as it's core functionality.

John Novak

-----Original Message-----
From: Steve Lime [mailto:steve.lime at dnr.state.mn.us] 
Sent: Friday, February 07, 2003 2:55 PM
To: warmerdam at pobox.com 
Cc: Mapserver-dev at lists.gis.umn.edu 
Subject: Re: [Mapserver-dev] Re: 3.7 and native image rendering support


The PNG and GIF support are pure fluff in my mind. I can't imagine
people use them much. 
I've always considered a base version of MapServer to be made up of GD
and LibTiff and perhaps Freetype. That's just my history I guess.

3.7 is not ready, so now's the time. I'm still fixing joins (almost
done) but graticule code, oracle spatial fixes and I imagine other stuff
are still being finalized. EPPL7 OGR support would be crucial for
several groups here in MN.

I can ditch the old drivers and screw around with msDrawRasterLayer, as
you know I'm not 
afraid to dive right in. The 8-bit/24-bit stuff is complicated so this
would have to make life easier...

Steve

>>> Frank Warmerdam <warmerdam at pobox.com> 02/07/03 04:40PM >>>
Steve Lime wrote:
> Currently a lite version requires libtiff anyway, and since you're 
> distributing binaries it doesn't seem that bad. Building GDAL from 
> source may be a pain though. (Out of curiosity does the default build 
> support LZW TIFF or would that require a custom
> build?)

Steve,

Why does a lite version require libtiff?  The default build of GDAL's
internal libtiff TIFF driver supports decompressing LZW but not
compressing them.

> My vote is for simplification...

That's an important vote.  When would we strip away stuff?
Conservatively I would like to see such a change happen post-3.7 though
that puts us in the ackward position of possible releasing a 3.7 with
some buggy drivers.

Also, who would implement this?  I guess if we just strip out everything
bug GDAL it wouldn't be a big job.

Best regards,

-- 
---------------------------------------+--------------------------------
---------------------------------------+------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com 
light and sound - activate the windows | http://pobox.com/~warmerdam 
and watch the world go round - Rush    | Geospatial Programmer for Rent




_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu 
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev 

_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu 
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev