[mapserver-dev] A thought about a CGI parameter add, basicallya switch for turning a default layer off.

[Stephen Woodbridge]

On 2/2/2011 10:21 AM, Bob Basques wrote:
> Steve,
>
>
> Hmmm, good point on the Copyright thing, I suppose it's complicating
> things, but you could use a KEYWORD / function in the Mapfiles to
> enforce the stamping, or hide such layers from a [toggle_layer] listing.

Yes it is always possible to add another hack to fix an enhancement ;) 
but it probably means the enhancement is not well thought out.

> It's sometimes easier to predict (or assume) that certain layers should
> be on by default. In a GeoMoose configuration, the data
> owners/custodians can have their own publication controls, and they will
> have their preferences for default layers, for particular users, this
> may work very well for them, but other (unpredicted) users, may
> want/need to display things in different combinations of layers in their
> view of the world.

I think that the data publisher should control this not the data 
consumer. If I publish my data a certain way then it should be used that 
way. If a user needs it some other way then maybe the use case changed 
or something else and I should review the requirements with the user. 
This just makes sense, no it is not easier or quick and dirty fix, but 
... I'm just saying! This could also be an education  or planning issue 
for your data providers or a lack of requirements gathering between 
producers and consumers. Or, if using default causes problems then tell 
them not to use that. If GeoMoose requires default, then maybe you 
should consider refactoring it, if the above does not fix the problem.

> I've been a long (LONG) time user of the CGI model for MapServer, even
> building my own image generator before ever moving to using MapServer.
> The CGI methods for me just seem easier and less verbose to use, and
> much quicker to implement on the fly, especially when I have control of
> everything from front to back. Some WMS queries are optional, so not all
> capabilities that a CGI approach would afford are necessarily available
> via WMS all the time. The thread was aimed at making things more
> flexible overall, not just more complicated.

Yeah, I agree CGI is good for quick and dirty prototyping in addition to 
building good full blown application, but now I like using OpenLayers to 
handle talking to mapserver and writing PHP ajax handlers for other 
stuff so the CGI is more than adequate for most of my needs. This may 
not be the case for all users. I'm not opposed to adding features to the 
CGI, but this one just does not seem like a good idea to me as the use 
case can be implemented by the proper use of the existing CGI interface, 
ie: set the layers to off and request the layers you want and if you get 
a default layer that you do not want, then talk to the mapfile publisher.

> Templates work very well, and look like they will work for the layer
> listing too (I thought about this before sending the questions). Lastly,
> since MapServer is in the mix, I can combine CGI with WMS calls as well.
> I may need to run the request through some proxy, but then I have even
> more control over things, A WMS+ service if you will.

Yup, works great and I have used both of these tricks in other projects 
in the past.

> My parting thought on this, would be, if this is truly seen as a
> cumbersome or time consuming thing to add to mapserver, should some

I don't think it is either of these, as I said above.

> review of current capabilities be performed to see what redundant
> capabilities might be removable from MapServer since they are now
> available via other means, like WMS, or at the very least,
> implement/convert them to a WMS like call.

Sounds like this might be something to discuss for 7.0 as 6.0 is pretty 
much locked up for now, and any major change to the mapserver UI that 
would not be backwards compatible would need to happen at a major 
revision. If you want to lead the charge on this now it probably as good 
as anytime to start a discussion and propose changes.

> I prefer to keep both products/services in their own sand boxes, and
> apply the best capabilities list to each, but maybe I'm missing
> something at the big(ger) picture level.

Sorry to rain on your parade, I hear that this is a pain point for 
geoMoose and implementing this would be a simple fix. I'm also just one 
voice so other dev's are certainly welcome to jump in here and disagree 
with me.

That said, I'm pretty adamant that the publisher of a map, should have 
some control over it and should be able to limit the extent that a user 
can modify it. If there is a simple solution that does not violate those 
rights then I'm all for it.

Best regards,
   -Steve W

> :c)
>
>
> bobb
>
>
>
>
>  >>> Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
>
> I do not think this would be a good idea because it would allow a user
> to turn off say a copyright layer for instance.
>
> I think it is better to plan out your application to turn things on that
> you want on as Steve suggests.
>
> So while I do you the CGI even in OpenLayers over the WMS, mostly
> because I learned it first and partly because WMS just makes it too easy
> for unwanted users to pull maps, I am somewhat inclined to think the WMS
> is the better way to go if you want all the capabilities of WMS. What is
> your rationale for adding a all this stuff to the CGI? Does working it
> through the template system meet your needs?
>
> Inquiring minds want to know :)
>
> Best regards,
> -Steve W
>
> On 2/1/2011 10:54 PM, Lime, Steve D (DNR) wrote:
>  > 1) If your interface is smart enough to explicitly turn the
>  > centerlines off why wouldn't you just set STATUS OFF in the mapfile
>  > and explicitly turn them on? I think the REQUIRES parameter is a
>  > better means of triggering this auto-off capability in any regard.
>  >
>  > 2) You might already be able to do the layer list using the
>  > [toggle_layers] tag. It returns a space delimited list of layers that
>  > can be toggled. It's available in any query/browse template so I
>  > imagine you could craft a URL that runs quickly to access them that
>  > way... Just a thought.
>  >
>  > Steve ________________________________________ From:
>  > mapserver-dev-bounces at lists.osgeo.org
>  > [mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Bob Basques
>  > [Bob.Basques at ci.stpaul.mn.us] Sent: Tuesday, February 01, 2011 2:43
>  > PM To: MapServer Dev Mailing List Subject: [mapserver-dev] A thought
>  > about a CGI parameter add, basically a switch for turning a default
>  > layer off.
>  >
>  > All,
>  >
>  >
>  > Is this doable?
>  >
>  >
>  > Was wondering about a mechanism to turn a DEFAULT layer off via CGI,
>  > something like "layers=-centerlines", where the negative sign ( - )
>  > would be used to indicate that a default layer should NOT be drawn
>  > for a CGI request.
>  >
>  >
>  > In short terms, could adding a negative sign ( - ) to the front of a
>  > layer name to NOT draw that layer be easily implemented in the CGI
>  > calls?
>  >
>  >
>  > WARNING: If the above is possible, the next question would be to get
>  > a list of the layers that are available in a MAPFILE (like
>  > GetCapabilities) for drawing. And don't say use WMS, otherwise you
>  > should get rid of the LEGEND generation in MapServer too, since that
>  > can be done via WMS as well. :c) I also have an inkling that
>  > having the ability to poll the mapfile for the layers available might
>  > be an interesting capability to add in that would allow for some
>  > interesting user GUI elements to be built around.
>  >
>  >
>  > ---------
>  >
>  >
>  > Here is my use case (if needed):
>  >
>  >
>  > Say I have a centerline file of a street network for a map, and then
>  > add in a Aerial photo background, I want to turn the centerlines off,
>  > but keep the labels as an overlay. Both the centerlines and the
>  > labels are on by default at the mapfile.
>  >
>  >
>  > Thanks
>  >
>  >
>  > bobb
>  >
>  >
>  >
>  > _______________________________________________ mapserver-dev mailing
>  > list mapserver-dev at lists.osgeo.org
>  > http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>