CGI vs. WMS

[Fawcett, David]

Puneet, 

You are correct <CFHTTP>.  

David.

-----Original Message-----
From: UMN MapServer Users List [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On
Behalf Of P Kishor
Sent: Friday, July 07, 2006 3:07 PM
To: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-USERS] CGI vs. WMS


On 7/7/06, Jim Cser <Cser at metro.dst.or.us> wrote:
> All the comments were helpful, thanks.   I was not familiar with the
> "mode=map" option in a URL, since all the books I read only gave 
> examples of posting the CGI variables through a form.  For our current

there really is no difference other than using a GET method instead of
POST. "mode=map" is just another key=value pair that your CF server will
happily pick up.

> WMS, we are already using CF to create all our URLs on the fly, so it 
> should be a small step to translate from back to the CGI versions.


Just follow David's advice -- construct your URL (not much different
from how you do via a form, but be sure to escape any funky characters
with the help of  URLEncodedFormat(string) ), and then send a <CFHTTP>
request with the correct CFHTTPPARAMs, and then pick up the response
from #cfhttp.*#

In other words, your CF server becomes the "user" of mapserver, sending
it CGI requests, getting the maps back, and serving them up.



>
>
> >>> Paul Ramsey <pramsey at refractions.net> 07/07/06 12:33 PM >>>
> Jim,
>
> David's advice is right on the money... build up a mode=map URL in 
> your
>
> scripting environment (CF, PHP, whatever) and then fire that off to 
> the
>
> mapserver backend.  Using WMS mode is actually more restrictive than 
> just using the Mapserver CGI variable controls 
> <http://mapserver.gis.umn.edu/docs/reference/cgi/controls> with which 
> you can actually do many/most of the things people lean on mapscript 
> for. (Things like dynamically changing aspects of styling or filtering
>
> or even the PostGIS DATA statements (feel the power!)).
>
> We've used mode=map + cgi variable controls to build some pretty 
> complicated sites (dynamically do thematic mapping of US census data, 
> for example, changing variables, color themes, categorization, etc on 
> the fly) without using mapscript.
>
> Paul
>
> Fawcett, David wrote:
> > Jim,
> >
> > For adding simple mapping to CF apps, I have used CF to dynamically 
> > build a URL request that I then call with <CFHttpRequest>.  I use 
> > mode=map, so the images don't go to the tmp directory.
> >
> > I am guessing that going to a WFS layer for your data source may
> slow
> > down your app.
> >
> > David.
> >
> > -----Original Message-----
> > From: UMN MapServer Users List 
> > [mailto:MAPSERVER-USERS at LISTS.UMN.EDU]
> On
> > Behalf Of Jim Cser
> > Sent: Friday, July 07, 2006 1:15 PM
> > To: MAPSERVER-USERS at LISTS.UMN.EDU
> > Subject: [UMN_MAPSERVER-USERS] CGI vs. WMS
> >
> >
> > What are the pro and cons of using WMS over CGI MapServer?   Does
> anyone
> > here have any direct experience with both?
> >
> > We have a Cold Fusion web application that displays a few maps, with

> > only simple pan/zoom functionality needed * it's not a "GIS-like"
> site.
> > Our previous MapServer apps have used CGI MapServer, but for this 
> > app
> we
> > decided to experiment with implementing a WMS service.  We're a CF
> shop,
> > otherwise we might try PHP or Java mapscript.  Our map layers are
> coming
> > from PostGreSQL/ PostGIS, for what it's worth.
> >
> > The WMS was nice because of the detailed diagnostics returned on
> errors,
> > and for the fact that we aren't filling up a directory with
> > image files.   On the other hand, the lack of ability to dynamically
> > control the symbology is becoming a show-stopper, and with CGI we 
> > can
> at
> > least throw it a URL containing terms like 
> > "map_layername_class_expression=('[PROJECT_ID]'='89' ".
> >
> > Similarly, will switching to a WFS service, or calling a WFS layer
> in
> > the WMS map file have any advantages?  I was looking into filter 
> > encoding, but was getting lost by the distinction between returning 
> > features and returning an image.
> >
> > At this point in our development cycle, it would be preferable to
> "drop
> > in" some functionality, rather than re-write a lot of code, but as I

> > said above, dynamic symbology is the driver.
> >
> > Thanks,
> > Jim Cser
>


-- 
Puneet Kishor http://punkish.eidesis.org/
Nelson Inst. for Env. Studies, UW-Madison http://www.ies.wisc.edu/ Open
Source Geospatial Foundation https://edu.osgeo.org/