[mapserver-users] Re: Feature wish: Internal mapfile variables

Wed Oct 5 07:26:12 PDT 2011

Stephen, 

I don't see this type of URL substitution as being any more latent than running a WMS (with SLD) request (same thing right??), especially if it's run through MapServer directly.  We've tried the Scripting process and while it worked, keeping the MapServer version up as they came out was a bit time consuming, not to mention trying to keep things portable.  I'm not interested in adding another "thing" to the MapServer engine toolbox for set up.  I would much rather see something like this be handled inside of MapServer proper. 

I'm looking at the flexibility of having the option.  I can certainly see something like this becoming a potential crutch for some developers as well.  And so, I'm not entirely sold on the idea myself yet, that this is a proper solution.  It's more of a flexibility issue in my mind.  WMS is fine and all, but you can't (yet) do everything, that mapserver can do even though I use WMS services a lot more now than I used to. 

I'm not so sure I would need to go to another server every time I needed to use this type of assembly, but I can sure see it coming in handy if I did.  I'm also all about diiding processes up amongst the data maintainers. This type of capability has the potential to spread to maintenance aspects out and away from dependence on a single publishing point, almost cloud based if you will . . . 

My last piece here, is if this is really turning into a standards question, should there be a discussion about making a complete standards compliant version of MapServer.  I believe quite a bit of stuff could be stripped out of MapServer in this scenario.  Mapserver has been my tool of choice for may years because of it's flexibility, and not necessarily it's standards compliance. 

In the end, all good points that you brought up.  Most of them I'm still pondering myself.  It seems like a good idea on the surface, and I've not heard a really big gotcha in this thread yet about why it would be inherently bad. 

bobb 

>>> Stephen Woodbridge <woodbri at swoodbridge.com> wrote:

Bob,

I think one of the developers would need to answer this. But here are
some thoughts to consider:

This introduces a lot of latency in the response, because you have to
make a socket request to another host, which needs to create a process
and service the request, and send the results back to you. Not to
mention what do you do if the host or connection are down or bad.

If you are just asking this because it is a tricky way to add parameters
to the request, then I would simply ask to have parametrized includes
especially if I could load all my parameters from an initial include
with a computed filename based on the

To some extent you can already do this at the layer level, we normally
call it a WMS layer ;)

Which brings up the other point of making a remote request for an
include, what is the likelihood that a remote hose is going to know
about the data sources on your host? Are you than going to want remote
access to the data also. Oh wait ... that is a WMS request. :)

Ok, sarcasm aside, it is an interesting idea, but I think it has more
potential issues then benefits, but htat is just my 2 cents.

-Steve W

On 10/3/2011 3:18 PM, Bob Basques wrote:
> All,
>
>
> Would adding in INCLUDEs from a URL be pushing it too much, as in:
>
>
> INCLUDE " /http://Myserver.com/cgi-bin/myscript.pl
> <http://Myserver.com/cgi-bin/myscript.pl>/ "
>
>
> Could pass in parameters like so . . .
>
>
> INCLUDE " /http://Myserver.com/cgi-bin/myscript.pl?A=first /
> <http://Myserver.com/cgi-bin/myscript.pl?A=first> thing&b=second
> thing&c=third thing . . . "
>
>
> bobb
>
>
>
>
>
>  >>> "Smith, Michael ERDC-CRREL-NH" <Michael.Smith at usace.army.mil> wrote:
>
> There is an RFC to have includes come from non-file connections
> (databases). It would be another option
>
> http://mapserver.org/development/rfc/ms-rfc-74.html
>
>
> Mike
>
> --
> Michael Smith
>
> Remote Sensing/GIS Center
> US Army Corps of Engineers
>
>
>
> On 10/3/11 2:51 PM, "Stephen Woodbridge" <woodbri at swoodbridge.com> wrote:
>
>  >One idea regarding this that you might want to consider is the ability
>  >to put all the named parameters in an include file, then be able to
>  >include that file via a CGI parameter. So it might look like this:
>  >
>  >
>  >MAP
>  > INCLUDE "client-params-%client_id%.inc"
>  > ...
>  >END
>  >
>  >And then you could have parameter files like:
>  >
>  >client-params-27.inc
>  >client-params-123.inc
>  >etc.
>  >
>  >And these would include nothing but your SET ... commands.
>  >
>  >Then when requesting the map:
>  >
>  >/http://localhost/cgi-bin/mapserv?client_id=123&mode=map&map=/path/to/mapf
>  >ile.map&...
>  >
>  >This would make it very easy to manage a single mapfile for parameters
>  >that are different for each client/user.
>  >
>  >Obviously the client_id could be set via a cookie, or a wrapper script,
>  >or a session variable, or manually, etc.
>  >
>  >-Steve W
>  >
>  >On 10/3/2011 2:39 PM, reholl wrote:
>  >> I'm interested in working on capabilities along these lines. Are there
>  >> existing RFCs that touch on this? If not, perhaps one should be
>  >>created.
>  >>
>  >> This overlaps some configuration ideas I've been mulling over. From the
>  >> original comment here about internal vars being handy for "/when the
>  >>same
>  >> layers are re-used for several customers who like to have a bit
>  >>different
>  >> styling for the same source data/" it occurs to me that a matrix or some
>  >> other constructs more complex than a flat list of internal variables
>  >>might
>  >> be called for -- provided they don't turn the mapfile and internal
>  >>mapserv
>  >> into spaghetti..
>  >>
>  >> Jukka Rahkonen (have I ordered your name properly?), do you want to
>  >>start an
>  >> RFC on this?
>  >>
>  >> To anyone -- would this conversation typically migrate over to 'dev' ?
>  >>
>  >> Robert Hollingsworth
>  >>
>  >>
>  >> I agree that this is a request that comes up often. As usual we'd just
>  >> need someone to lead the effort.
>  >>
>  >> On 11-10-03 12:12 AM, Rahkonen Jukka wrote:
>  >>> Hi,
>  >>>
>  >>> Inspired by the Thomas Bonfort's rendering chain I have been thinking
>  >>>if
>  >>> we could have a native support for using internal mapfile variables.
>  >>>Now
>  >>> Thomas is setting for example a bunch of colours in a definition file
>  >>> which is converted into a real mapfile with python script and c
>  >>> preprocessor.
>  >>> http://mapserver-utils.googlecode.com/svn/trunk/README
>  >>> http://mapserver-utils.googlecode.com/svn/trunk/generate_style.py
>  >>>
>  >>> I would like to see a simple way for setting the variables directly in
>  >>>the
>  >>> mapfile, somehow like
>  >>> MAP
>  >>> SET "pedestrian_clr" "#fafaf5"
>  >>> SET "forest_clr" "#dcdcb4"
>  >>> SET "industrial_clr" "#ebe5d9"
>  >>> ....
>  >>>
>  >>> And then later in the layers use
>  >>> LAYER
>  >>> .....
>  >>> COLOR %pedestrian_clr%
>  >>>
>  >>> The internal variables could be interpreted only from the mapfile and
>  >>>they
>  >>> could not be altered by the web users.
>  >>>
>  >>> Internal variable would help in maintaining big mapfiles with repeating
>  >>> styles like in the OpenStreetMap rendering case. Another use case is
>  >>>when
>  >>> the same layers are re-used for several customers who like to have a
>  >>>bit
>  >>> different styling for the same source data.
>  >>>
>  >>> -Jukka Rahkonen-
>  >>>
>  >>
>  >> --
>  >> View this message in context:
>  >>http://osgeo-org.1803224.n2.nabble.com/Feature-wish-Internal-mapfile-vari
>  >>ables-tp6853853p6856070.html
>  >> Sent from the Mapserver - User mailing list archive at Nabble.com.
>  >> _______________________________________________
>  >> mapserver-users mailing list
>  >> mapserver-users at lists.osgeo.org
>  >> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>  >
>  >_______________________________________________
>  >mapserver-users mailing list
>  >mapserver-users at lists.osgeo.org
>  >http://lists.osgeo.org/mailman/listinfo/mapserver-users
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>

_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20111005/a650e9a4/attachment.htm>