<html>
<head>
</head>
<body style="font-variant: normal; line-height: normal; font-family: Comic Sans MS; margin-left: 4px; margin-right: 4px; margin-bottom: 1px; font-weight: normal; margin-top: 4px; font-style: normal; font-size: 12pt">
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Ok, here goes . . . :c)</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Define a "hack" please? It sounds like any change may be considered a hack, and may also be dependent on who's looking at what.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">The publisher vs system admin argument has been a long standing conversation topic with me. I don't think the System admin should be getting in the way of the publishing process, but rather, they should be supplying the tools to make it easier to publish as well as consume the publised data.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">I think there are also more than a few instances where the rules can and do change for this argument. One is the commercial vs open environment. I need to mention here that I've have focused most of my development life on the publishing of open data. On the commercial side, the idea is to present a unified, and too a large degree, pre-scripted experience, that doesn't change significantly over time. It's about the product and making it the same every time a user experiences it, IE McDonaolds and Google, for example. So they feel comfortable. On the open side, I would say the reverse it true, change is good, as well as control, over anything and everything (if the users had their way), it's in many instances why the open customer took a look at things in the open environment in the first place. Using just these two different publishing/consuming scenarios one can see that things can get into conflict quite easily, and quickly, with regard to perceived and desired capabilities by the publishers as well as the consumers. Lastly I'm going out on a limb here and state that the Open version of publishing/consuming eventually settles into a commercial version over time, especially the longer a tool has been in place. A form follows function sort of thing. </font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">My last piece here, is to emphasize that it's all about the data, not what's done with it. Now this is more than likely a open data publishing perspective, but over the years, software and techniques have come and gone, the one thing that always remains, is that there is data to use and manipulate, preferably is good data and up to date.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Ok, I think I'm done (getting down off soap box) . . .</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">:c)</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">Nice discussion BTW.</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font size="3" face="Comic Sans MS">bobb</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<br>
<br>
>>> Stephen Woodbridge <woodbri@swoodbridge.com> wrote:<br> </p>
<table style="margin-left: 15px; margin-right: 0; margin-bottom: 0; margin-top: 0; font-size: 1em" bgcolor="#f3f3f3" border="0">
<tr>
<td>
<div style="padding-left: 7px; border-left: solid 1px #050505">
<p style="margin-top: 0; margin-bottom: 0">
On 2/2/2011 10:21 AM, Bob Basques wrote:<br>> Steve,<br>><br>><br>> Hmmm, good point on the Copyright thing, I suppose it's complicating<br>> things, but you could use a KEYWORD / function in the Mapfiles to<br>> enforce the stamping, or hide such layers from a [toggle_layer] listing.<br><br>Yes it is always possible to add another hack to fix an enhancement ;)<br>but it probably means the enhancement is not well thought out.<br><br>> It's sometimes easier to predict (or assume) that certain layers should<br>> be on by default. In a GeoMoose configuration, the data<br>> owners/custodians can have their own publication controls, and they will<br>> have their preferences for default layers, for particular users, this<br>> may work very well for them, but other (unpredicted) users, may<br>> want/need to display things in different combinations of layers in their<br>> view of the world.<br><br>I think that the data publisher should control this not the data<br>consumer. If I publish my data a certain way then it should be used that<br>way. If a user needs it some other way then maybe the use case changed<br>or something else and I should review the requirements with the user.<br>This just makes sense, no it is not easier or quick and dirty fix, but<br>... I'm just saying! This could also be an education  or planning issue<br>for your data providers or a lack of requirements gathering between<br>producers and consumers. Or, if using default causes problems then tell<br>them not to use that. If GeoMoose requires default, then maybe you<br>should consider refactoring it, if the above does not fix the problem.<br><br>> I've been a long (LONG) time user of the CGI model for MapServer, even<br>> building my own image generator before ever moving to using MapServer.<br>> The CGI methods for me just seem easier and less verbose to use, and<br>> much quicker to implement on the fly, especially when I have control of<br>> everything from front to back. Some WMS queries are optional, so not all<br>> capabilities that a CGI approach would afford are necessarily available<br>> via WMS all the time. The thread was aimed at making things more<br>> flexible overall, not just more complicated.<br><br>Yeah, I agree CGI is good for quick and dirty prototyping in addition to<br>building good full blown application, but now I like using OpenLayers to<br>handle talking to mapserver and writing PHP ajax handlers for other<br>stuff so the CGI is more than adequate for most of my needs. This may<br>not be the case for all users. I'm not opposed to adding features to the<br>CGI, but this one just does not seem like a good idea to me as the use<br>case can be implemented by the proper use of the existing CGI interface,<br>ie: set the layers to off and request the layers you want and if you get<br>a default layer that you do not want, then talk to the mapfile publisher.<br><br>> Templates work very well, and look like they will work for the layer<br>> listing too (I thought about this before sending the questions). Lastly,<br>> since MapServer is in the mix, I can combine CGI with WMS calls as well.<br>> I may need to run the request through some proxy, but then I have even<br>> more control over things, A WMS+ service if you will.<br><br>Yup, works great and I have used both of these tricks in other projects<br>in the past.<br><br>> My parting thought on this, would be, if this is truly seen as a<br>> cumbersome or time consuming thing to add to mapserver, should some<br><br>I don't think it is either of these, as I said above.<br><br>> review of current capabilities be performed to see what redundant<br>> capabilities might be removable from MapServer since they are now<br>> available via other means, like WMS, or at the very least,<br>> implement/convert them to a WMS like call.<br><br>Sounds like this might be something to discuss for 7.0 as 6.0 is pretty<br>much locked up for now, and any major change to the mapserver UI that<br>would not be backwards compatible would need to happen at a major<br>revision. If you want to lead the charge on this now it probably as good<br>as anytime to start a discussion and propose changes.<br><br>> I prefer to keep both products/services in their own sand boxes, and<br>> apply the best capabilities list to each, but maybe I'm missing<br>> something at the big(ger) picture level.<br><br>Sorry to rain on your parade, I hear that this is a pain point for<br>geoMoose and implementing this would be a simple fix. I'm also just one<br>voice so other dev's are certainly welcome to jump in here and disagree<br>with me.<br><br>That said, I'm pretty adamant that the publisher of a map, should have<br>some control over it and should be able to limit the extent that a user<br>can modify it. If there is a simple solution that does not violate those<br>rights then I'm all for it.<br><br>Best regards,<br>   -Steve W<br><br>> :c)<br>><br>><br>> bobb<br>><br>><br>><br>><br>>  >>> Stephen Woodbridge <woodbri@swoodbridge.com> wrote:<br>><br>> I do not think this would be a good idea because it would allow a user<br>> to turn off say a copyright layer for instance.<br>><br>> I think it is better to plan out your application to turn things on that<br>> you want on as Steve suggests.<br>><br>> So while I do you the CGI even in OpenLayers over the WMS, mostly<br>> because I learned it first and partly because WMS just makes it too easy<br>> for unwanted users to pull maps, I am somewhat inclined to think the WMS<br>> is the better way to go if you want all the capabilities of WMS. What is<br>> your rationale for adding a all this stuff to the CGI? Does working it<br>> through the template system meet your needs?<br>><br>> Inquiring minds want to know :)<br>><br>> Best regards,<br>> -Steve W<br>><br>> On 2/1/2011 10:54 PM, Lime, Steve D (DNR) wrote:<br>>  > 1) If your interface is smart enough to explicitly turn the<br>>  > centerlines off why wouldn't you just set STATUS OFF in the mapfile<br>>  > and explicitly turn them on? I think the REQUIRES parameter is a<br>>  > better means of triggering this auto-off capability in any regard.<br>>  ><br>>  > 2) You might already be able to do the layer list using the<br>>  > [toggle_layers] tag. It returns a space delimited list of layers that<br>>  > can be toggled. It's available in any query/browse template so I<br>>  > imagine you could craft a URL that runs quickly to access them that<br>>  > way... Just a thought.<br>>  ><br>>  > Steve ________________________________________ From:<br>>  > mapserver-dev-bounces@lists.osgeo.org<br>>  > [mapserver-dev-bounces@lists.osgeo.org] On Behalf Of Bob Basques<br>>  > [Bob.Basques@ci.stpaul.mn.us] Sent: Tuesday, February 01, 2011 2:43<br>>  > PM To: MapServer Dev Mailing List Subject: [mapserver-dev] A thought<br>>  > about a CGI parameter add, basically a switch for turning a default<br>>  > layer off.<br>>  ><br>>  > All,<br>>  ><br>>  ><br>>  > Is this doable?<br>>  ><br>>  ><br>>  > Was wondering about a mechanism to turn a DEFAULT layer off via CGI,<br>>  > something like "layers=-centerlines", where the negative sign ( - )<br>>  > would be used to indicate that a default layer should NOT be drawn<br>>  > for a CGI request.<br>>  ><br>>  ><br>>  > In short terms, could adding a negative sign ( - ) to the front of a<br>>  > layer name to NOT draw that layer be easily implemented in the CGI<br>>  > calls?<br>>  ><br>>  ><br>>  > WARNING: If the above is possible, the next question would be to get<br>>  > a list of the layers that are available in a MAPFILE (like<br>>  > GetCapabilities) for drawing. And don't say use WMS, otherwise you<br>>  > should get rid of the LEGEND generation in MapServer too, since that<br>>  > can be done via WMS as well. :c) I also have an inkling that<br>>  > having the ability to poll the mapfile for the layers available might<br>>  > be an interesting capability to add in that would allow for some<br>>  > interesting user GUI elements to be built around.<br>>  ><br>>  ><br>>  > ---------<br>>  ><br>>  ><br>>  > Here is my use case (if needed):<br>>  ><br>>  ><br>>  > Say I have a centerline file of a street network for a map, and then<br>>  > add in a Aerial photo background, I want to turn the centerlines off,<br>>  > but keep the labels as an overlay. Both the centerlines and the<br>>  > labels are on by default at the mapfile.<br>>  ><br>>  ><br>>  > Thanks<br>>  ><br>>  ><br>>  > bobb<br>>  ><br>>  ><br>>  ><br>>  > _______________________________________________ mapserver-dev mailing<br>>  > list mapserver-dev@lists.osgeo.org<br>>  > <a href="http://lists.osgeo.org/mailman/listinfo/mapserver-dev">http://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>><br><br>
</p>
</div>
</td>
</tr>
</table>
</body>
</html>