[Mapserver-dev] Re:WMS Problems...
Sean Gillies
sgillies at frii.com
Wed Mar 17 11:20:06 EST 2004
Steve,
I vote that outputformats be changed so that we can have multiple
formats using the same driver. Have the format name be the primary
format identifier instead of the driver.
Sean
On Mar 17, 2004, at 9:08 AM, Steve Lime wrote:
> This discussion sort of withered on the vine. Issue number 3 is a big
> deal especially with
> WCS. We'll have a need to serve multiband images (8-bits/band) and
> 16-bit single band
> images from the same server. The same TIFF OutputFormat is not going
> work for both of
> those cases. The other issues are import too. Anyone care to resurrect
> or should I just
> file bugs?
>
> Steve
>
>>>> "Steve Lime" <steve.lime at dnr.state.mn.us> 3/5/2004 10:53:06 AM >>>
> I've moved this to mapserver-dev. Ok, to sum up:
>
> 1) Looks like formats for 1.0.0 are hardcoded. I can't say who's using
> version more frequently but it seems to me that the process to output
> formats should
> be the same across versions even if what appears to the user is
> different. I would
> vote to sync that process.
>
> 2) Formats cannot be excluded from presentation. Bug already exists
> for
> this.
>
> 3) There is no way (within the same mapfile) to have multiple versions
> of the same format. To me this is a big problem especially with very
> flexible
> formats like TIFF. Can we simply choose to support one? Frank's makes
> the most sense to me,
> but I can see where simply a name may be to cryptic.
>
> This covers almost everything in my original note except for 1 thing.
> Why does tiff show up with 1.1.x capabilities documents if no tiff
> image output
> format is defined in the mapfile? The reason this is a problem is that
> requesting
> a tiff generates an error.
>
> Steve
>
>>>> Daniel Morissette <dmorissette at dmsolutions.ca> 3/3/2004 2:27:08 PM
>>>>
> (Should we move this discussion to mapserver-dev?)
>
> Frank Warmerdam wrote:
>>
>> OK, looking in the code I see the following logic. Basically,
> because
> the
>> WMS 1.0.0 format names are ideosyncratic I guess someone (perhaps
> me?) made
>> the decision to just hardcode and support a few formats.
>
> That was me. (Not the decision on the format names, but the limited
> implementation)
>
>
>>
>> One is, should we fix 1.0.0 WMS support to emit entries for all
>> declared formats? Perhaps using the name of the outputformat
>> converted to upper case? This would give us the "well known" names
>> for the default GIF, PNG and JPEG formats and would allow arbitrary
>> other formats to be listed.
>>
>
> That would be a good idea... as Frank suggested, a bug should be filed
>
> if someone really cares about custom formats being listed in WMS 1.0.0
>
>
>> The other issue is that there is currently no way to prevent the
> various
>> internally declared formats from appearing. Basically, all the
> standard
>> formats (if built in) will appear regardless of what output formats
> are
>> declared in the map file. The predefined ones are listed here (from
>> mapoutput.c):
>>
>
> There is already bug 455 which is indirectly related to that issue:
>
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=455
>
>>
>> If you see a need for being able to avoid pre-defined formats from
>> showing up in the list in the capabilities then file another bug
>> about this, but I think we should talk a bit about how to accomplish
>> it without too much disruption.
>>
>
> One possibility could be a flag in the outputformat object that
> indicates whether a given format should be visible in capabilities.
> The
> set of pre-defined formats would have some valid default settings so
> that things like text/xml doesn't appear in capabilities (see bug 455)
>
> In a previous message, Frank also wrote:
>>
>> It seems to me there is some way of adding options to mime types.
> Perhaps
>> we could have something like a mime type of "image/tiff+24bit" or
> something.
>> Anyone know more about this?
>>
>
> There was a thread on this on WMS-Dev back in June/July of 2002:
>
> http://www.intl-interfaces.net/pipermail/wms-dev/2002-June/000180.html
>
>
>
> There were two proposals, one by you (Frank):
>
> <Format>image/png</Format>
> <Format>image/png; name=png8</Format>
> <Format>image/png; name=png24></Format>
>
> and one by Craig Bruce from Cubewerx:
>
> image/png; PhotometricInterpretation=PaletteColor;
> SamplesPerPixel=1;
> BitsPerSample=8
> image/png; PhotometricInterpretation=RGB; SamplesPerPixel=3;
> BitsPerSample="8,8,8"
> image/png
>
> It seemed that everyone agreed on the passing of additional
> parameters,
>
> but not on the name of the parameters to use.
>
> Jeff DLB concluded that email thread by saying that he would include a
>
> note in the WMS spec. I found the following note in the WMS 1.3.0
> discussion paper:
>
> ---
> The basic structure of a MIME type is a string of the form
> "type/subtype". MIME allows additional parameters in a string
> of the form "type/subtype; param1=value1; param2=value2". A server
> may include parameterized MIME types in its list of supported
> output formats. In addition to any parameterized variants, the
> server should offer the basic unparameterized version of the
> format.
> ---
>
> However I didn't find anything specific to the name of the parameters
> to
> use to describe 8 bits vs 24 bits for instance.
>
> Daniel
> --
> ------------------------------------------------------------
> Daniel Morissette dmorissette at dmsolutions.ca
> DM Solutions Group http://www.dmsolutions.ca/
> ------------------------------------------------------------
>
> _______________________________________________
> Mapserver-users mailing list
> Mapserver-users at lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-users
> _______________________________________________
> 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
>
More information about the mapserver-dev
mailing list