No subject

the largest=20
WMS clients out there without additional configuration on the users part. =
I wasn't=20
aware of the ArcMap issue but would advocate supporting that variation =
too. It's=20
not like we're talking about some minor client, I mean, it's Google Earth =
and ArcGIS.

Fine, we should let them know they are not compliant (good luck), but =
making it
hard for the users of those packages doesn't help. They are unlikely to =
have
read the WMS spec and will blame the service provider more often than the
client vendor. These are folks (on the ArcGIS side especially) that we =
really want
to have a positive experience with open source and open standards.

I need to go back to the documents Tom references but at face value I'd =
prefer to
see MapServer work seamlessly with *major* clients if at all possible.

Steve

>>> Bart van den Eijnden <bartvde at GMAIL.COM> 10/14/07 3:22 PM >>>
I tend to disagree. As a person having worked a lot with standards, I =
think
all vendors implementing a standard should comply with the contract lay =
down
in the standard.

Remember ESRI's ArcMap up until 9.1 did not send the required parameter
QUERY_LAYERS in a GetFeatureInfo request. I did not hear anybody on this
list advocate that Mapserver should be made permissive and assume
QUERY_LAYERS equals LAYERS. If you would go this path then the end is =
near.
Though it would have solved a long-standing irritating/frustrating issue
between Mapserver WMS and ESRI's ArcMap (and there are still a lot of =
9.0/9.1
ArcMap's out there).

Also, imagine falling back on the MAP file's width and height if not
specified, I could write a simple WMS javascript client and forget the =
width
and height parameters in the url, the WMS client would write out <img
src=3D"..." width=3D"650" height=3D"450"> and the browser would totally =
distort
the image if the MAP file says something else then SIZE 650 450.

It just shows which clients are not correctly implementing a spec, and
frankly, the sooner the better. Go and bother the GE people and say they =
are
missing a required parameter.

Personally I can not think of a reason why styles is required but has a
default value, but maybe the people who wrote the WMS spec had a perfectly
good reason for it. But if you do not agree it is a required parameter, go
to the OGC and debate why styles should not be a required parameter ...

Best regards,
Bart

On 10/14/07, Howard Butler <hobu.inc at gmail.com> wrote:
>
> On Oct 13, 2007, at 5:26 PM, Frank Warmerdam wrote:
>
> > Steve Lime wrote:
> >> Hi all: Is anyone else running into problems with clients and
> >> requiring the
> >> styles parameter? I'm putzing with Google Earth which doesn't seem
> >> to send
> >> that parameter which makes using 5.0-based WMS servers a bit
> >> useless. Or am
> >> I missing something with?
> >
> > Steve,
> >
> > I haven't run into this myself, but I have heard problems on IRC.
> >
> > I personally think it is wrong headed for us to require the styles
> > parameter.  If we want to have a "pendantic" mode that requires it
> > that
> > would be find, but I don't see why we should require it by default
> > regardless of what the standard might say.
> >
> > I would suggest we be permissive in what we require.
> >
> > I think this is something that ought to be "fixed" in 5.0.1.
> >
>
> I agree.  The benefit of enforcing this is negligible.  Same for
> width and height too, frankly.  Do the CITE tests require these?
>
> I would like to go back to being more lax about these, especially
> when we can get reasonable defaults from the map file for width/
> height and when styles=3D infers absolutely nothing to anyone.
>
> Howard
>