[mapserver-users] Fwd: World Wind and Map Server

Steve Lime Steve.Lime at dnr.state.mn.us
Mon Nov 9 13:43:58 EST 2009


The beauty of open source!

>>> On 11/9/2009 at 12:41 PM, in message
<9c2015090911091041u1148f583vff74da68546763ce at mail.gmail.com>, Roger
André
<randre at gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Tom Gaskins <tom at tomgaskins.com>
> Date: Mon, Nov 9, 2009 at 9:52 AM
> Subject: Re: World Wind and Map Server
> To: Roger André <randre at gmail.com>
> Cc: David Collins <paul.collins at nasa.gov>
> 
> 
> 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 <tom at tomgaskins.com>
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 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]&}]<http://host%5B%3Aport%5D/path%5B?%7Bn

> ame%5B=value%5D&%7D%5D>
>> 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<http://worldwind.arc.nasa.gov/java/demos/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 publish
>> internally.  We spent a couple hours trying to figure out what URL
WWJ
>> needed, and finally determined that it needed a full GetCapabilities
URL.
>> This URL for MapServer look like this:
>>  "
>> 
>
http://10.10.10.143/cgi-bin/mapserv?map=/var/www/mapfiles/precip/precip.map&RE

> QUEST=GetCapabilities&SERVICE=WMS&
>> ".
>>
>> However, this URL does not work in WWJ.  When I checked the server
logs to
>> see whether WWJ was actually trying to connect to my WMS, I found
that the
>> request it sends is truncated, and looks like this:
>> 10.10.10.143 - - [05/Nov/2009:09:51:37 -0800] "GET
>> 
>
/cgi-bin/mapserv?EXCEPTIONS=application/vnd.ogc.se_xml&REQUEST=GetCapabilities
> &SERVICE=WMS&
>> HTTP/1.1" 200 539 "-" "Java/1.6.0_07".
>>
>> As you can see, the "map" parameter, which is crucial for MapServer,
has
>> been completely stripped out of the request.  Without this,
>> "map=/var/www/mapfiles/precip/precip.map" paremeter, there is no way
for
>> MapServer to determine which map to serve.
>>
>> Hope that helps,
>>
>> Roger
>> --
>>
>> On Sat, Nov 7, 2009 at 10:17 AM, Tom Gaskins <tom at tomgaskins.com>
wrote:
>>
>>> Roger, I was sent a copy of your mapserver-list message describing
a
>>> problem you're having connecting to map server from WWJ. But the
message
>>> seems to be saying that you're entering a GetCapabilities URL and
expecting
>>> that to generate a GetMap request to the server. Would you please
tell me
>>> what the situation is and what you're trying to do. We almost never
have
>>> problems connecting to conforming WMS servers.
>>> Thanks
>>> Tom
>>>
>>
>>
>>


More information about the mapserver-users mailing list