Re: [mapserver-users] Fwd: World Wind and Map Server
The beauty of open source!
>>> On 11/9/2009 at 12:41 PM, in message
<9c2015090911091041u1148f583vff74da6854676...@mail.gmail.com>, Roger
André
wrote:
> -- Forwarded message --
> From: Tom Gaskins
> Date: Mon, Nov 9, 2009 at 9:52 AM
> Subject: Re: World Wind and Map Server
> To: Roger André
> Cc: David Collins
>
>
> Thanks Roger. On looking at this again this morning, the WMS spec
does say
> that a server-specific query string may be part of the server
prefix,
> although we've not encountered that before. It still sounds to me,
however,
> that a map is expected to be returned from a GetCapabilities
request.
> Nevertheless, we'll modify the relevant WWJ code to recognize the
case of an
> existing query string in the server URL. That seems to be all you
need to
> get past the problem
> Thanks,
> Tom
>
>
> On Nov 9, 2009, at 9:34 AM, Roger André wrote:
>
> HI Tom,
>
> I've forwarded your response to the MapServer list, as the
implication is
> that MapServer may not be confirming to WMS spec in the structure of
its
> GetCapabilities request. I can understand your confusion about the
"map"
> mentioned in my message. This "map" has nothng to do with a GetMap
> request. MapServer uses the concept of a "map" document to define a
> specific project. These map documents contain all of the
specifications and
> parameters to define the capabilities and/or appearance a specific
MapServer
> WMS, WFS, WCS, etc. layer.
>
> Anyhow, thanks for the info,
>
> Roger
> --
>
> On Sun, Nov 8, 2009 at 9:21 PM, Tom Gaskins
wrote:
>
>> Roger, Thanks for clarifying, but I think I may still be confused.
WMS
>> defines two primary requests, GetCapabilities and GetMap. The first
one
>> requests the metadata associated with the server and each of the
layers it
>> serves. The second requests a map, always in the form of a raster.
Reading
>> your most recent mail, it seems you're expecting the GetCapabilities
request
>> to return a particular map. Is this correct? I'm also confused
because the
>> request you show that you'd like to specify to the demo's layer
manager
>> doesn't meet the definition of a valid WMS end point, which should
be simply
>> a host address and not contain a query string (elements after the
question
>> mark). The query string is exclusively for WMS parameters, which the
WWJ
>> demo fills in when sending the request. I've included the relevant
text from
>> the WMS spec below.
>>
>> I can understand that mapserver may have its own request protocol,
but the
>> demo you're using is meant to work with only conforming WMS servers.
It's
>> certainly possible for WWJ to visualize data from servers using
other
>> protocols, and many applications do that. We'd be more than happy to
help
>> you determine the best way to interact with mapserver. The demo
you're
>> trying to use, though, isn't intended to to that.
>>
>> Thanks,
>> Tom
>>
>> *6.3.3 HTTP GET*
>> A Web Map Service shall support the "GET" method of the HTTP
protocol (IETF
>> RFC 2616).
>> An Online Resource URL intended for HTTP GET requests is in fact
only a URL
>> prefix to which additional parameters are appended in order to
construct a
>> valid Operation request. A URL prefix is defined in accordance with
IETF RFC
>> 2396 as a string including, in order, the scheme ("http" or
"https"),
>> Internet Protocol hostname or numeric address, optional port number,
path,
>> mandatory question mark '?', and optional string comprising one or
more
>> server-specific parameters ending in an ampersand '&'. The prefix
defines
>> the network address to which request messages are to be sent for a
>> particular operation on a particular server. Each operation may have
a
>> different prefix. Each prefix is entirely at the discretion of the
service
>> provider.
>> This International Standard defines how to construct a query part
that is
>> appended to the URL prefix in order to form a complete request
message.
>> Every WMS operation has several mandatory or optional request
parameters.
>> Each parameter has a defined name. Each parameter may have one or
more legal
>> values, which are either defined by this International Standard or
are
>> selected by the client based on service metadata. To formulate the
query
>> part of the URL, a client shall append the mandatory request
parameters, and
>> any desired optional parameters, as name/value pairs in the form
>> "name=value&" (parameter name, equals sign, parameter value,
ampersand). The
>> '&' is a separator between name/value pairs, and is therefore
optional after
>> the last pair in the request string.
>> When the HTTP GET method is used, the client-constructed query part
is
>> appended to the URL prefix defined by the server, and the resulting
complete
>> URL is invoked as defined by HTTP (IETF RFC 2616).
>> Table 2 summarizes the components of an operation request URL when
HTTP GET
>> is used.
>> *Table 2 — Structure of WMS request using HTTP GET*
>> *6.3.4 HTTP POST*
>> A Web Map Service may su
[mapserver-users] Fwd: World Wind and Map Server
-- Forwarded message --
From: Tom Gaskins
Date: Mon, Nov 9, 2009 at 9:52 AM
Subject: Re: World Wind and Map Server
To: Roger André
Cc: David Collins
Thanks Roger. On looking at this again this morning, the WMS spec does say
that a server-specific query string may be part of the server prefix,
although we've not encountered that before. It still sounds to me, however,
that a map is expected to be returned from a GetCapabilities request.
Nevertheless, we'll modify the relevant WWJ code to recognize the case of an
existing query string in the server URL. That seems to be all you need to
get past the problem
Thanks,
Tom
On Nov 9, 2009, at 9:34 AM, Roger André wrote:
HI Tom,
I've forwarded your response to the MapServer list, as the implication is
that MapServer may not be confirming to WMS spec in the structure of its
GetCapabilities request. I can understand your confusion about the "map"
mentioned in my message. This "map" has nothng to do with a GetMap
request. MapServer uses the concept of a "map" document to define a
specific project. These map documents contain all of the specifications and
parameters to define the capabilities and/or appearance a specific MapServer
WMS, WFS, WCS, etc. layer.
Anyhow, thanks for the info,
Roger
--
On Sun, Nov 8, 2009 at 9:21 PM, Tom Gaskins wrote:
> Roger, Thanks for clarifying, but I think I may still be confused. WMS
> defines two primary requests, GetCapabilities and GetMap. The first one
> requests the metadata associated with the server and each of the layers it
> serves. The second requests a map, always in the form of a raster. Reading
> your most recent mail, it seems you're expecting the GetCapabilities request
> to return a particular map. Is this correct? I'm also confused because the
> request you show that you'd like to specify to the demo's layer manager
> doesn't meet the definition of a valid WMS end point, which should be simply
> a host address and not contain a query string (elements after the question
> mark). The query string is exclusively for WMS parameters, which the WWJ
> demo fills in when sending the request. I've included the relevant text from
> the WMS spec below.
>
> I can understand that mapserver may have its own request protocol, but the
> demo you're using is meant to work with only conforming WMS servers. It's
> certainly possible for WWJ to visualize data from servers using other
> protocols, and many applications do that. We'd be more than happy to help
> you determine the best way to interact with mapserver. The demo you're
> trying to use, though, isn't intended to to that.
>
> Thanks,
> Tom
>
> *6.3.3 HTTP GET*
> A Web Map Service shall support the "GET" method of the HTTP protocol (IETF
> RFC 2616).
> An Online Resource URL intended for HTTP GET requests is in fact only a URL
> prefix to which additional parameters are appended in order to construct a
> valid Operation request. A URL prefix is defined in accordance with IETF RFC
> 2396 as a string including, in order, the scheme ("http" or "https"),
> Internet Protocol hostname or numeric address, optional port number, path,
> mandatory question mark '?', and optional string comprising one or more
> server-specific parameters ending in an ampersand '&'. The prefix defines
> the network address to which request messages are to be sent for a
> particular operation on a particular server. Each operation may have a
> different prefix. Each prefix is entirely at the discretion of the service
> provider.
> This International Standard defines how to construct a query part that is
> appended to the URL prefix in order to form a complete request message.
> Every WMS operation has several mandatory or optional request parameters.
> Each parameter has a defined name. Each parameter may have one or more legal
> values, which are either defined by this International Standard or are
> selected by the client based on service metadata. To formulate the query
> part of the URL, a client shall append the mandatory request parameters, and
> any desired optional parameters, as name/value pairs in the form
> "name=value&" (parameter name, equals sign, parameter value, ampersand). The
> '&' is a separator between name/value pairs, and is therefore optional after
> the last pair in the request string.
> When the HTTP GET method is used, the client-constructed query part is
> appended to the URL prefix defined by the server, and the resulting complete
> URL is invoked as defined by HTTP (IETF RFC 2616).
> Table 2 summarizes the components of an operation request URL when HTTP GET
> is used.
> *Table 2 — Structure of WMS request using HTTP GET*
> *6.3.4 HTTP POST*
> A Web Map Service may support the "POST" method of the HTTP protocol (IETF
> RFC 2616).
> An Online Resource URL intended for HTTP POST requests is a complete URL
> (not merely a prefix as in the HTTP GET case) that is valid according to
> IETF RFC 2396 to which clients transmit request parameters in the body
Re: [mapserver-users] Fwd: World Wind and Map Server
Hi,
it's a matter of properly setting up your service, since MAP is a
vendor-specific parameter in this case. For instance using the
MS_MAPFILE environment variable, so that clients don't need to use the
MAP file parameter at all. Or you can do standard url rewrites with Apache.
Best regards,
Bart
Roger André wrote:
Does anyone in the MapServer Dev. community want to respond to this?
I *think* the implication here is that a vanilla MapServer
"GetCapabilities" request is not conforming to spec.
Roger
--
-- Forwarded message --
From: *Tom Gaskins* mailto:t...@tomgaskins.com>>
Date: Sun, Nov 8, 2009 at 9:21 PM
Subject: Re: World Wind and Map Server
To: Roger André mailto:ran...@gmail.com>>
Cc: David Collins mailto:paul.coll...@nasa.gov>>
Roger, Thanks for clarifying, but I think I may still be confused. WMS
defines two primary requests, GetCapabilities and GetMap. The first
one requests the metadata associated with the server and each of the
layers it serves. The second requests a map, always in the form of a
raster. Reading your most recent mail, it seems you're expecting
the GetCapabilities request to return a particular map. Is this
correct? I'm also confused because the request you show that you'd
like to specify to the demo's layer manager doesn't meet the
definition of a valid WMS end point, which should be simply a host
address and not contain a query string (elements after the question
mark). The query string is exclusively for WMS parameters, which the
WWJ demo fills in when sending the request. I've included the relevant
text from the WMS spec below.
I can understand that mapserver may have its own request protocol, but
the demo you're using is meant to work with only conforming WMS
servers. It's certainly possible for WWJ to visualize data from
servers using other protocols, and many applications do that. We'd be
more than happy to help you determine the best way to interact with
mapserver. The demo you're trying to use, though, isn't intended to to
that.
Thanks,
Tom
*6.3.3 HTTP GET*
A Web Map Service shall support the "GET" method of the HTTP protocol
(IETF RFC 2616).
An Online Resource URL intended for HTTP GET requests is in fact only
a URL prefix to which additional parameters are appended in order to
construct a valid Operation request. A URL prefix is defined in
accordance with IETF RFC 2396 as a string including, in order, the
scheme ("http" or "https"), Internet Protocol hostname or numeric
address, optional port number, path, mandatory question mark '?', and
optional string comprising one or more server-specific parameters
ending in an ampersand '&'. The prefix defines the network address to
which request messages are to be sent for a particular operation on a
particular server. Each operation may have a different prefix. Each
prefix is entirely at the discretion of the service provider.
This International Standard defines how to construct a query part that
is appended to the URL prefix in order to form a complete request
message. Every WMS operation has several mandatory or optional request
parameters. Each parameter has a defined name. Each parameter may have
one or more legal values, which are either defined by this
International Standard or are selected by the client based on service
metadata. To formulate the query part of the URL, a client shall
append the mandatory request parameters, and any desired optional
parameters, as name/value pairs in the form "name=value&" (parameter
name, equals sign, parameter value, ampersand). The '&' is a separator
between name/value pairs, and is therefore optional after the last
pair in the request string.
When the HTTP GET method is used, the client-constructed query part is
appended to the URL prefix defined by the server, and the resulting
complete URL is invoked as defined by HTTP (IETF RFC 2616).
Table 2 summarizes the components of an operation request URL when
HTTP GET is used.
*Table 2 — Structure of WMS request using HTTP GET*
*6.3.4 HTTP POST*
A Web Map Service may support the "POST" method of the HTTP protocol
(IETF RFC 2616).
An Online Resource URL intended for HTTP POST requests is a complete
URL (not merely a prefix as in the HTTP GET case) that is valid
according to IETF RFC 2396 to which clients transmit request
parameters in the body of the POST message. A WMS shall not require
additional parameters to be appended to the URL in order to construct
a valid target for the operation request. When POST is used, the
request message is formulated as an XML document.
*URL Component*
*Description*
http://host[:port]/path[?{name[=value]&}]
URL prefix of service operation. [ ] denotes 0 or 1 occurrence of an
optional part; {} denotes 0 or more occurrences.
name=value&
One or more standard request parameter name/value pairs as defined for
each operation by this International Standard.
On Nov
Re: [mapserver-users] Fwd: World Wind and Map Server
Hi,
>From a document at
>http://www.mapserver.org/ogc/wms_server.html#setting-up-a-wms-server-using-mapserver
you can read this (and more):
"More About the Online Resource URL
As mentioned in the section Setup a Mapfile / wms_onlineresource metadata
above, the following Online Resource URL is perfectly valid for a MapServer WMS
according to section 6.2.2 or the WMS 1.1.1 specification:
http://my.host.com/cgi-bin/mapserv?map=mywms.map&;
However, some people will argue that the above URL contains mandatory
vendor-specific parameters and that this is illegal. First we would like to
point that map=... is not considered a vendor-specific parameter in this case
since it is part of the Online Resource URL which is defined as an opaque
string terminated by ? or & (See WMS 1.1.1 section 6.2.2)."
I have never faced problems with having mapfile included in WMS url, even I
usually clean it out. There can for sure be also other clients than World Wind
which do not like this format.
-Jukka Rahkonen-
Roger André wrote:
Does anyone in the MapServer Dev. community want to respond to this? I
*think* the implication here is that a vanilla MapServer "GetCapabilities"
request is not conforming to spec.
Roger
--
-- Forwarded message --
From: Tom Gaskins
Date: Sun, Nov 8, 2009 at 9:21 PM
Subject: Re: World Wind and Map Server
To: Roger André
Cc: David Collins
Roger, Thanks for clarifying, but I think I may still be confused. WMS
defines two primary requests, GetCapabilities and GetMap. The first one
requests the metadata associated with the server and each of the layers it
serves. The second requests a map, always in the form of a raster. Reading
your most recent mail, it seems you're expecting the GetCapabilities request
to return a particular map. Is this correct? I'm also confused because the
request you show that you'd like to specify to the demo's layer manager
doesn't meet the definition of a valid WMS end point, which should be simply
a host address and not contain a query string (elements after the question
mark). The query string is exclusively for WMS parameters, which the WWJ
demo fills in when sending the request. I've included the relevant text from
the WMS spec below.
I can understand that mapserver may have its own request protocol, but the
demo you're using is meant to work with only conforming WMS servers. It's
certainly possible for WWJ to visualize data from servers using other
protocols, and many applications do that. We'd be more than happy to help
you determine the best way to interact with mapserver. The demo you're
trying to use, though, isn't intended to to that.
Thanks,
Tom
*6.3.3 HTTP GET*
A Web Map Service shall support the "GET" method of the HTTP protocol (IETF
RFC 2616).
An Online Resource URL intended for HTTP GET requests is in fact only a URL
prefix to which additional parameters are appended in order to construct a
valid Operation request. A URL prefix is defined in accordance with IETF RFC
2396 as a string including, in order, the scheme ("http" or "https"),
Internet Protocol hostname or numeric address, optional port number, path,
mandatory question mark '?', and optional string comprising one or more
server-specific parameters ending in an ampersand '&'. The prefix defines
the network address to which request messages are to be sent for a
particular operation on a particular server. Each operation may have a
different prefix. Each prefix is entirely at the discretion of the service
provider.
This International Standard defines how to construct a query part that is
appended to the URL prefix in order to form a complete request message.
Every WMS operation has several mandatory or optional request parameters.
Each parameter has a defined name. Each parameter may have one or more legal
values, which are either defined by this International Standard or are
selected by the client based on service metadata. To formulate the query
part of the URL, a client shall append the mandatory request parameters, and
any desired optional parameters, as name/value pairs in the form
"name=value&" (parameter name, equals sign, parameter value, ampersand). The
'&' is a separator between name/value pairs, and is therefore optional after
the last pair in the request string.
When the HTTP GET method is used, the client-constructed query part is
appended to the URL prefix defined by the server, and the resulting complete
URL is invoked as defined by HTTP (IETF RFC 2616).
Table 2 summarizes the components of an operation request URL when HTTP GET
is used.
*Table 2 - Structure of WMS request using HTTP GET*
*6.3.4 HTTP POST*
A Web Map Service may support the "POST" method of the HTTP protocol (IETF
RFC 2616).
An Online Resource URL intended for HTTP POST requests is a complete URL
(not merely a prefix as in the HTTP GET case) that is valid according to
IETF RFC 2396 to which clients transmit request parameters in the body of
the POST message. A WMS shall not requir
[mapserver-users] Fwd: World Wind and Map Server
Does anyone in the MapServer Dev. community want to respond to this? I
*think* the implication here is that a vanilla MapServer "GetCapabilities"
request is not conforming to spec.
Roger
--
-- Forwarded message --
From: Tom Gaskins
Date: Sun, Nov 8, 2009 at 9:21 PM
Subject: Re: World Wind and Map Server
To: Roger André
Cc: David Collins
Roger, Thanks for clarifying, but I think I may still be confused. WMS
defines two primary requests, GetCapabilities and GetMap. The first one
requests the metadata associated with the server and each of the layers it
serves. The second requests a map, always in the form of a raster. Reading
your most recent mail, it seems you're expecting the GetCapabilities request
to return a particular map. Is this correct? I'm also confused because the
request you show that you'd like to specify to the demo's layer manager
doesn't meet the definition of a valid WMS end point, which should be simply
a host address and not contain a query string (elements after the question
mark). The query string is exclusively for WMS parameters, which the WWJ
demo fills in when sending the request. I've included the relevant text from
the WMS spec below.
I can understand that mapserver may have its own request protocol, but the
demo you're using is meant to work with only conforming WMS servers. It's
certainly possible for WWJ to visualize data from servers using other
protocols, and many applications do that. We'd be more than happy to help
you determine the best way to interact with mapserver. The demo you're
trying to use, though, isn't intended to to that.
Thanks,
Tom
*6.3.3 HTTP GET*
A Web Map Service shall support the "GET" method of the HTTP protocol (IETF
RFC 2616).
An Online Resource URL intended for HTTP GET requests is in fact only a URL
prefix to which additional parameters are appended in order to construct a
valid Operation request. A URL prefix is defined in accordance with IETF RFC
2396 as a string including, in order, the scheme ("http" or "https"),
Internet Protocol hostname or numeric address, optional port number, path,
mandatory question mark '?', and optional string comprising one or more
server-specific parameters ending in an ampersand '&'. The prefix defines
the network address to which request messages are to be sent for a
particular operation on a particular server. Each operation may have a
different prefix. Each prefix is entirely at the discretion of the service
provider.
This International Standard defines how to construct a query part that is
appended to the URL prefix in order to form a complete request message.
Every WMS operation has several mandatory or optional request parameters.
Each parameter has a defined name. Each parameter may have one or more legal
values, which are either defined by this International Standard or are
selected by the client based on service metadata. To formulate the query
part of the URL, a client shall append the mandatory request parameters, and
any desired optional parameters, as name/value pairs in the form
"name=value&" (parameter name, equals sign, parameter value, ampersand). The
'&' is a separator between name/value pairs, and is therefore optional after
the last pair in the request string.
When the HTTP GET method is used, the client-constructed query part is
appended to the URL prefix defined by the server, and the resulting complete
URL is invoked as defined by HTTP (IETF RFC 2616).
Table 2 summarizes the components of an operation request URL when HTTP GET
is used.
*Table 2 — Structure of WMS request using HTTP GET*
*6.3.4 HTTP POST*
A Web Map Service may support the "POST" method of the HTTP protocol (IETF
RFC 2616).
An Online Resource URL intended for HTTP POST requests is a complete URL
(not merely a prefix as in the HTTP GET case) that is valid according to
IETF RFC 2396 to which clients transmit request parameters in the body of
the POST message. A WMS shall not require additional parameters to be
appended to the URL in order to construct a valid target for the operation
request. When POST is used, the request message is formulated as an XML
document.
*URL Component*
*Description*
http://host[:port]/path[?{name[=value]&}]
URL prefix of service operation. [ ] denotes 0 or 1 occurrence of an
optional part; {} denotes 0 or more occurrences.
name=value&
One or more standard request parameter name/value pairs as defined for each
operation by this International Standard.
On Nov 8, 2009, at 12:29 PM, Roger André wrote:
Hi Tom,
Problem is pretty simple to describe actually. One of the executives at my
company found this page, http://worldwind.arc.nasa.gov/java/demos/, and
decided to try out the WMS Layer manager example,
WMSLayerManager.jnlp.
He liked the various layers that were available, and asked me if it would be
possible to view some of our MapServer WMS layers that I publi
