RE: [Geoserver-devel] GetFeatureInfo

GeoServer GeoServer Developer
1

just answered withouth seeing your reply Chris.
But yes, the spect says you must copy the originar GetMap parameters, though
FORMAT is meaningless for GetFeatureInfo (though I don't remember right now
if the spec says something specific about this), the point is that FORMAT
has no meaning in a GetFeatureInfo request, this it defines its own
parameter: INFO-FORMAT to specify in which format to response, and it is
indeed defined to avoid conflict with the GetMap FORMAT parameter.
so, we would be do? be strict or not?

open to suggestions.

-----Mensaje original-----
De: geoserver-devel-admin@lists.sourceforge.net
[mailto:geoserver-devel-admin@lists.sourceforge.net]En nombre de Chris
Holmes
Enviado el: miércoles, 11 de mayo de 2005 19:55
Para: Alessio Fabiani
CC: geoserver-devel@lists.sourceforge.net
Asunto: Re: [Geoserver-devel] GetFeatureInfo

No, it's covered in the kvp <map_request_copy> in the GetFeatureInfo
request table (I'm on the 1.1.1 spec, top of page 40):

7.3.3.4 map_request_copy
<map request copy> is not a name/value pair like the other parameters.
Instead, most of the GetMap request parameters that generated the
original map are repeated. Two are omitted because GetFeatureInfo
provides its own values: VERSION and REQUEST. The remainder of the
GetMap request shall be embedded contiguously in the GetFeatureInfo
request.

You have to include all the original params of the GetMap request, and
format is one of them. I know, kinda silly, but I'm pretty sure that's
how it works. I'd be fine with not being super strict on the format,
but I'm not sure of our implementation - if we actually use the format
param on our request - like if it's used to generate the map.

C

Quoting Alessio Fabiani <alessio.fabiani@anonymised.com>:

Hi all,

the WMS needs the FORMAT parameter in the GetFeatureInfo request, but
in the OGC specifics seems that this parameter should not be
requested
in GetFeatureInfo.

Is it right? In this case the check on this parameter should be
removed!!!

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

2

Hmmm... Alessio, do you have a specific need to not include it? Maybe
we should see what mapserver does? Like do we consider it the spec
being silly? Or are there other servers out there that may need it.

We should consider that as an open source implementation we will
probably have people writing clients against our server. We would not
want them to write a client which then fails against other servers. So
that makes me lean more towards making it required, so that people
write clients properly against the spec.

Chris

Quoting "ROLDAN, Gabriel raul" <gabriel.raul.roldan@anonymised.com>:

just answered withouth seeing your reply Chris.
But yes, the spect says you must copy the originar GetMap parameters,

though
FORMAT is meaningless for GetFeatureInfo (though I don't remember
right =
now
if the spec says something specific about this), the point is that =
FORMAT
has no meaning in a GetFeatureInfo request, this it defines its own
parameter: INFO-FORMAT to specify in which format to response, and it

is
indeed defined to avoid conflict with the GetMap FORMAT parameter.
so, we would be do? be strict or not?

open to suggestions.

-----Mensaje original-----
De: geoserver-devel-admin@lists.sourceforge.net
[mailto:geoserver-devel-admin@lists.sourceforge.net]En nombre de
Chris
Holmes
Enviado el: mi=E9rcoles, 11 de mayo de 2005 19:55
Para: Alessio Fabiani
CC: geoserver-devel@lists.sourceforge.net
Asunto: Re: [Geoserver-devel] GetFeatureInfo

No, it's covered in the kvp <map_request_copy> in the GetFeatureInfo
request table (I'm on the 1.1.1 spec, top of page 40):

7.3.3.4 map_request_copy
<map request copy> is not a name/value pair like the other
parameters.
Instead, most of the GetMap request parameters that generated the
original map are repeated. Two are omitted because GetFeatureInfo
provides its own values: VERSION and REQUEST. The remainder of the
GetMap request shall be embedded contiguously in the GetFeatureInfo
request.

You have to include all the original params of the GetMap request,
and
format is one of them. I know, kinda silly, but I'm pretty sure
that's
how it works. I'd be fine with not being super strict on the format,
but I'm not sure of our implementation - if we actually use the
format
param on our request - like if it's used to generate the map.

C

Quoting Alessio Fabiani <alessio.fabiani@anonymised.com>:

> Hi all,
>
> the WMS needs the FORMAT parameter in the GetFeatureInfo request,
but
> in the OGC specifics seems that this parameter should not be
> requested
> in GetFeatureInfo.
>
> Is it right? In this case the check on this parameter should be
> removed!!!
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

3

Well the point is that we (Me and Alessio) are involved in an
interoperability test of GeoServer+WCS with some companies, and some
clients do not use this paramter in their requests thus they get back
an exception. Since it is not mandatory to use it, we really would
like to not see that exception, in order to not expose our flank to
futile criticisms from the other companies.
You know how companies are with open source, so we have to be really careful!

Simone.

On 5/11/05, Chris Holmes <cholmes@anonymised.com> wrote:

Hmmm... Alessio, do you have a specific need to not include it? Maybe
we should see what mapserver does? Like do we consider it the spec
being silly? Or are there other servers out there that may need it.

We should consider that as an open source implementation we will
probably have people writing clients against our server. We would not
want them to write a client which then fails against other servers. So
that makes me lean more towards making it required, so that people
write clients properly against the spec.

Chris

Quoting "ROLDAN, Gabriel raul" <gabriel.raul.roldan@anonymised.com>:

> just answered withouth seeing your reply Chris.
> But yes, the spect says you must copy the originar GetMap parameters,
> =
> though
> FORMAT is meaningless for GetFeatureInfo (though I don't remember
> right =
> now
> if the spec says something specific about this), the point is that =
> FORMAT
> has no meaning in a GetFeatureInfo request, this it defines its own
> parameter: INFO-FORMAT to specify in which format to response, and it
> =
> is
> indeed defined to avoid conflict with the GetMap FORMAT parameter.
> so, we would be do? be strict or not?
>
> open to suggestions.
>
>
>
> -----Mensaje original-----
> De: geoserver-devel-admin@lists.sourceforge.net
> [mailto:geoserver-devel-admin@lists.sourceforge.net]En nombre de
> Chris
> Holmes
> Enviado el: mi=E9rcoles, 11 de mayo de 2005 19:55
> Para: Alessio Fabiani
> CC: geoserver-devel@lists.sourceforge.net
> Asunto: Re: [Geoserver-devel] GetFeatureInfo
>
>
> No, it's covered in the kvp <map_request_copy> in the GetFeatureInfo
> request table (I'm on the 1.1.1 spec, top of page 40):
>
> 7.3.3.4 map_request_copy
> <map request copy> is not a name/value pair like the other
> parameters.
> Instead, most of the GetMap request parameters that generated the
> original map are repeated. Two are omitted because GetFeatureInfo
> provides its own values: VERSION and REQUEST. The remainder of the
> GetMap request shall be embedded contiguously in the GetFeatureInfo
> request.
>
>
> You have to include all the original params of the GetMap request,
> and
> format is one of them. I know, kinda silly, but I'm pretty sure
> that's
> how it works. I'd be fine with not being super strict on the format,
> but I'm not sure of our implementation - if we actually use the
> format
> param on our request - like if it's used to generate the map.
>
> C
>
>
>
> Quoting Alessio Fabiani <alessio.fabiani@anonymised.com>:
>
> > Hi all,
> >
> > the WMS needs the FORMAT parameter in the GetFeatureInfo request,
> but
> > in the OGC specifics seems that this parameter should not be
> > requested
> > in GetFeatureInfo.
> >
> > Is it right? In this case the check on this parameter should be
> > removed!!!
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > Want to be the first software developer in space?
> > Enter now for the Oracle Space Sweepstakes!
> > http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
>
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

Hrm. Well I guess clients are already being written not following the
spec. The best thing to do would be to make some 'spec compliant'
option in the web admin tool, as I imagine there are a number of other
things like this that are close calls between how people actually do
things vs. the spec.

So if you have time, then do that, make it an option in services.xml.
If not, then if other companies aren't following it then it sounds like
a psuedo standard to me, so I'm fine with you getting rid of it. Just
whatever you do be sure to do on both head and on the branch. As long
as dblasby has no objections.

Chris

Quoting simone giannecchini <simboss1@anonymised.com>:

Well the point is that we (Me and Alessio) are involved in an
interoperability test of GeoServer+WCS with some companies, and some
clients do not use this paramter in their requests thus they get back
an exception. Since it is not mandatory to use it, we really would
like to not see that exception, in order to not expose our flank to
futile criticisms from the other companies.
You know how companies are with open source, so we have to be really
careful!

Simone.

On 5/11/05, Chris Holmes <cholmes@anonymised.com> wrote:
> Hmmm... Alessio, do you have a specific need to not include it?
Maybe
> we should see what mapserver does? Like do we consider it the spec
> being silly? Or are there other servers out there that may need
it.
>
> We should consider that as an open source implementation we will
> probably have people writing clients against our server. We would
not
> want them to write a client which then fails against other servers.
So
> that makes me lean more towards making it required, so that people
> write clients properly against the spec.
>
> Chris
>
> Quoting "ROLDAN, Gabriel raul" <gabriel.raul.roldan@anonymised.com>:
>
> > just answered withouth seeing your reply Chris.
> > But yes, the spect says you must copy the originar GetMap
parameters,
> > =
> > though
> > FORMAT is meaningless for GetFeatureInfo (though I don't remember
> > right =
> > now
> > if the spec says something specific about this), the point is
that =
> > FORMAT
> > has no meaning in a GetFeatureInfo request, this it defines its
own
> > parameter: INFO-FORMAT to specify in which format to response,
and it
> > =
> > is
> > indeed defined to avoid conflict with the GetMap FORMAT
parameter.
> > so, we would be do? be strict or not?
> >
> > open to suggestions.
> >
> >
> >
> > -----Mensaje original-----
> > De: geoserver-devel-admin@lists.sourceforge.net
> > [mailto:geoserver-devel-admin@lists.sourceforge.net]En nombre de
> > Chris
> > Holmes
> > Enviado el: mi=E9rcoles, 11 de mayo de 2005 19:55
> > Para: Alessio Fabiani
> > CC: geoserver-devel@lists.sourceforge.net
> > Asunto: Re: [Geoserver-devel] GetFeatureInfo
> >
> >
> > No, it's covered in the kvp <map_request_copy> in the
GetFeatureInfo
> > request table (I'm on the 1.1.1 spec, top of page 40):
> >
> > 7.3.3.4 map_request_copy
> > <map request copy> is not a name/value pair like the other
> > parameters.
> > Instead, most of the GetMap request parameters that generated the
> > original map are repeated. Two are omitted because GetFeatureInfo
> > provides its own values: VERSION and REQUEST. The remainder of
the
> > GetMap request shall be embedded contiguously in the
GetFeatureInfo
> > request.
> >
> >
> > You have to include all the original params of the GetMap
request,
> > and
> > format is one of them. I know, kinda silly, but I'm pretty sure
> > that's
> > how it works. I'd be fine with not being super strict on the
format,
> > but I'm not sure of our implementation - if we actually use the
> > format
> > param on our request - like if it's used to generate the map.
> >
> > C
> >
> >
> >
> > Quoting Alessio Fabiani <alessio.fabiani@anonymised.com>:
> >
> > > Hi all,
> > >
> > > the WMS needs the FORMAT parameter in the GetFeatureInfo
request,
> > but
> > > in the OGC specifics seems that this parameter should not be
> > > requested
> > > in GetFeatureInfo.
> > >
> > > Is it right? In this case the check on this parameter should be
> > > removed!!!
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > Want to be the first software developer in space?
> > > Enter now for the Oracle Space Sweepstakes!
> > > http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> > > _______________________________________________
> > > Geoserver-devel mailing list
> > > Geoserver-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >
> >
> >
> >
> >
> > ----------------------------------------------------------
> > This mail sent through IMP: https://webmail.limegroup.com/
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > Want to be the first software developer in space?
> > Enter now for the Oracle Space Sweepstakes!
> > http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > Want to be the first software developer in space?
> > Enter now for the Oracle Space Sweepstakes!
> > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

5

OK, my apologies ... I have read OGC specs once again and you are
right, the <map_request_part> is mandatory, and it includes even the
FORMAT parameter. I sent this request because the Intergraph WMS
viewer doesn't support this, but they are in fault ....

Thank you very much, and my apologies again!

On 5/12/05, Chris Holmes <cholmes@anonymised.com> wrote:

Hrm. Well I guess clients are already being written not following the
spec. The best thing to do would be to make some 'spec compliant'
option in the web admin tool, as I imagine there are a number of other
things like this that are close calls between how people actually do
things vs. the spec.

So if you have time, then do that, make it an option in services.xml.
If not, then if other companies aren't following it then it sounds like
a psuedo standard to me, so I'm fine with you getting rid of it. Just
whatever you do be sure to do on both head and on the branch. As long
as dblasby has no objections.

Chris

Quoting simone giannecchini <simboss1@anonymised.com>:

> Well the point is that we (Me and Alessio) are involved in an
> interoperability test of GeoServer+WCS with some companies, and some
> clients do not use this paramter in their requests thus they get back
> an exception. Since it is not mandatory to use it, we really would
> like to not see that exception, in order to not expose our flank to
> futile criticisms from the other companies.
> You know how companies are with open source, so we have to be really
> careful!
>
> Simone.
>
> On 5/11/05, Chris Holmes <cholmes@anonymised.com> wrote:
> > Hmmm... Alessio, do you have a specific need to not include it?
> Maybe
> > we should see what mapserver does? Like do we consider it the spec
> > being silly? Or are there other servers out there that may need
> it.
> >
> > We should consider that as an open source implementation we will
> > probably have people writing clients against our server. We would
> not
> > want them to write a client which then fails against other servers.
> So
> > that makes me lean more towards making it required, so that people
> > write clients properly against the spec.
> >
> > Chris
> >
> > Quoting "ROLDAN, Gabriel raul" <gabriel.raul.roldan@anonymised.com>:
> >
> > > just answered withouth seeing your reply Chris.
> > > But yes, the spect says you must copy the originar GetMap
> parameters,
> > > =
> > > though
> > > FORMAT is meaningless for GetFeatureInfo (though I don't remember
> > > right =
> > > now
> > > if the spec says something specific about this), the point is
> that =
> > > FORMAT
> > > has no meaning in a GetFeatureInfo request, this it defines its
> own
> > > parameter: INFO-FORMAT to specify in which format to response,
> and it
> > > =
> > > is
> > > indeed defined to avoid conflict with the GetMap FORMAT
> parameter.
> > > so, we would be do? be strict or not?
> > >
> > > open to suggestions.
> > >
> > >
> > >
> > > -----Mensaje original-----
> > > De: geoserver-devel-admin@lists.sourceforge.net
> > > [mailto:geoserver-devel-admin@lists.sourceforge.net]En nombre de
> > > Chris
> > > Holmes
> > > Enviado el: mi=E9rcoles, 11 de mayo de 2005 19:55
> > > Para: Alessio Fabiani
> > > CC: geoserver-devel@lists.sourceforge.net
> > > Asunto: Re: [Geoserver-devel] GetFeatureInfo
> > >
> > >
> > > No, it's covered in the kvp <map_request_copy> in the
> GetFeatureInfo
> > > request table (I'm on the 1.1.1 spec, top of page 40):
> > >
> > > 7.3.3.4 map_request_copy
> > > <map request copy> is not a name/value pair like the other
> > > parameters.
> > > Instead, most of the GetMap request parameters that generated the
> > > original map are repeated. Two are omitted because GetFeatureInfo
> > > provides its own values: VERSION and REQUEST. The remainder of
> the
> > > GetMap request shall be embedded contiguously in the
> GetFeatureInfo
> > > request.
> > >
> > >
> > > You have to include all the original params of the GetMap
> request,
> > > and
> > > format is one of them. I know, kinda silly, but I'm pretty sure
> > > that's
> > > how it works. I'd be fine with not being super strict on the
> format,
> > > but I'm not sure of our implementation - if we actually use the
> > > format
> > > param on our request - like if it's used to generate the map.
> > >
> > > C
> > >
> > >
> > >
> > > Quoting Alessio Fabiani <alessio.fabiani@anonymised.com>:
> > >
> > > > Hi all,
> > > >
> > > > the WMS needs the FORMAT parameter in the GetFeatureInfo
> request,
> > > but
> > > > in the OGC specifics seems that this parameter should not be
> > > > requested
> > > > in GetFeatureInfo.
> > > >
> > > > Is it right? In this case the check on this parameter should be
> > > > removed!!!
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > > Want to be the first software developer in space?
> > > > Enter now for the Oracle Space Sweepstakes!
> > > > http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> > > > _______________________________________________
> > > > Geoserver-devel mailing list
> > > > Geoserver-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > > >
> > >
> > >
> > >
> > >
> > > ----------------------------------------------------------
> > > This mail sent through IMP: https://webmail.limegroup.com/
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > Want to be the first software developer in space?
> > > Enter now for the Oracle Space Sweepstakes!
> > > http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> > > _______________________________________________
> > > Geoserver-devel mailing list
> > > Geoserver-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > Want to be the first software developer in space?
> > > Enter now for the Oracle Space Sweepstakes!
> > > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> > > _______________________________________________
> > > Geoserver-devel mailing list
> > > Geoserver-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >
> >
> > ----------------------------------------------------------
> > This mail sent through IMP: https://webmail.limegroup.com/
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > Want to be the first software developer in space?
> > Enter now for the Oracle Space Sweepstakes!
> > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

6

Problem solved!

Great!
Simone.

On 5/12/05, Alessio Fabiani <alessio.fabiani@anonymised.com> wrote:

OK, my apologies ... I have read OGC specs once again and you are
right, the <map_request_part> is mandatory, and it includes even the
FORMAT parameter. I sent this request because the Intergraph WMS
viewer doesn't support this, but they are in fault ....

Thank you very much, and my apologies again!

On 5/12/05, Chris Holmes <cholmes@anonymised.com> wrote:
> Hrm. Well I guess clients are already being written not following the
> spec. The best thing to do would be to make some 'spec compliant'
> option in the web admin tool, as I imagine there are a number of other
> things like this that are close calls between how people actually do
> things vs. the spec.
>
> So if you have time, then do that, make it an option in services.xml.
> If not, then if other companies aren't following it then it sounds like
> a psuedo standard to me, so I'm fine with you getting rid of it. Just
> whatever you do be sure to do on both head and on the branch. As long
> as dblasby has no objections.
>
> Chris
>
> Quoting simone giannecchini <simboss1@anonymised.com>:
>
> > Well the point is that we (Me and Alessio) are involved in an
> > interoperability test of GeoServer+WCS with some companies, and some
> > clients do not use this paramter in their requests thus they get back
> > an exception. Since it is not mandatory to use it, we really would
> > like to not see that exception, in order to not expose our flank to
> > futile criticisms from the other companies.
> > You know how companies are with open source, so we have to be really
> > careful!
> >
> > Simone.
> >
> > On 5/11/05, Chris Holmes <cholmes@anonymised.com> wrote:
> > > Hmmm... Alessio, do you have a specific need to not include it?
> > Maybe
> > > we should see what mapserver does? Like do we consider it the spec
> > > being silly? Or are there other servers out there that may need
> > it.
> > >
> > > We should consider that as an open source implementation we will
> > > probably have people writing clients against our server. We would
> > not
> > > want them to write a client which then fails against other servers.
> > So
> > > that makes me lean more towards making it required, so that people
> > > write clients properly against the spec.
> > >
> > > Chris
> > >
> > > Quoting "ROLDAN, Gabriel raul" <gabriel.raul.roldan@anonymised.com>:
> > >
> > > > just answered withouth seeing your reply Chris.
> > > > But yes, the spect says you must copy the originar GetMap
> > parameters,
> > > > =
> > > > though
> > > > FORMAT is meaningless for GetFeatureInfo (though I don't remember
> > > > right =
> > > > now
> > > > if the spec says something specific about this), the point is
> > that =
> > > > FORMAT
> > > > has no meaning in a GetFeatureInfo request, this it defines its
> > own
> > > > parameter: INFO-FORMAT to specify in which format to response,
> > and it
> > > > =
> > > > is
> > > > indeed defined to avoid conflict with the GetMap FORMAT
> > parameter.
> > > > so, we would be do? be strict or not?
> > > >
> > > > open to suggestions.
> > > >
> > > >
> > > >
> > > > -----Mensaje original-----
> > > > De: geoserver-devel-admin@lists.sourceforge.net
> > > > [mailto:geoserver-devel-admin@lists.sourceforge.net]En nombre de
> > > > Chris
> > > > Holmes
> > > > Enviado el: mi=E9rcoles, 11 de mayo de 2005 19:55
> > > > Para: Alessio Fabiani
> > > > CC: geoserver-devel@lists.sourceforge.net
> > > > Asunto: Re: [Geoserver-devel] GetFeatureInfo
> > > >
> > > >
> > > > No, it's covered in the kvp <map_request_copy> in the
> > GetFeatureInfo
> > > > request table (I'm on the 1.1.1 spec, top of page 40):
> > > >
> > > > 7.3.3.4 map_request_copy
> > > > <map request copy> is not a name/value pair like the other
> > > > parameters.
> > > > Instead, most of the GetMap request parameters that generated the
> > > > original map are repeated. Two are omitted because GetFeatureInfo
> > > > provides its own values: VERSION and REQUEST. The remainder of
> > the
> > > > GetMap request shall be embedded contiguously in the
> > GetFeatureInfo
> > > > request.
> > > >
> > > >
> > > > You have to include all the original params of the GetMap
> > request,
> > > > and
> > > > format is one of them. I know, kinda silly, but I'm pretty sure
> > > > that's
> > > > how it works. I'd be fine with not being super strict on the
> > format,
> > > > but I'm not sure of our implementation - if we actually use the
> > > > format
> > > > param on our request - like if it's used to generate the map.
> > > >
> > > > C
> > > >
> > > >
> > > >
> > > > Quoting Alessio Fabiani <alessio.fabiani@anonymised.com>:
> > > >
> > > > > Hi all,
> > > > >
> > > > > the WMS needs the FORMAT parameter in the GetFeatureInfo
> > request,
> > > > but
> > > > > in the OGC specifics seems that this parameter should not be
> > > > > requested
> > > > > in GetFeatureInfo.
> > > > >
> > > > > Is it right? In this case the check on this parameter should be
> > > > > removed!!!
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > > > Want to be the first software developer in space?
> > > > > Enter now for the Oracle Space Sweepstakes!
> > > > > http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> > > > > _______________________________________________
> > > > > Geoserver-devel mailing list
> > > > > Geoserver-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > ----------------------------------------------------------
> > > > This mail sent through IMP: https://webmail.limegroup.com/
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > > Want to be the first software developer in space?
> > > > Enter now for the Oracle Space Sweepstakes!
> > > > http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> > > > _______________________________________________
> > > > Geoserver-devel mailing list
> > > > Geoserver-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > > Want to be the first software developer in space?
> > > > Enter now for the Oracle Space Sweepstakes!
> > > > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> > > > _______________________________________________
> > > > Geoserver-devel mailing list
> > > > Geoserver-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > > >
> > >
> > > ----------------------------------------------------------
> > > This mail sent through IMP: https://webmail.limegroup.com/
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > Want to be the first software developer in space?
> > > Enter now for the Oracle Space Sweepstakes!
> > > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> > > _______________________________________________
> > > Geoserver-devel mailing list
> > > Geoserver-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >
> >
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>