CGI vs. WMS

[Kralidis,Tom [Burlington]]

Depends on your needs.  I love using CGI because it takes away the complexity of navigation in your application, as far as the user interface.
 
As far as the data it's connecting to, I prefer OGC:WMS.  Considering a three-tier application model (data/services/app(s)), you can stand up an OGC:WMS which *any* application can interact with (interoperability).  For symbology, MapServer supports OGC:SLD 1.0.0, which can do the custom styling you require.
 
OGC:WFS is valuable for access to the actual data.  If all you're looking for is map images, with some custom querying/filtering added, I think OGC:WMS with some OGC:SLD (which has filtering capabilities) should help.
 
See the OGC howtos for more info.
 
..Tom
 

	-----Original Message----- 
	From: UMN MapServer Users List on behalf of Jim Cser 
	Sent: Fri 07-Jul-06 14:14 
	To: MAPSERVER-USERS at LISTS.UMN.EDU 
	Cc: 
	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