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

Mon Oct 3 15:22:18 PDT 2011

I am new to mapserver world, so as you read this, remember I have no idea
what I am talking about  :)

I was thinking about this problem last week, my idea was to look at passing
a reference to a parsing script, that outputs a mapfile.

so instead of this
http://localhost/cgi-bin/mapserv?client_id=123&mode=map&map=/path/to/mapfile.map&.
..
you would pass this url
http://localhost/cgi-bin/mapserv?client_id=123&mode=map&map=/path/to/mapfilescript&.<http://localhost/cgi-bin/mapserv?client_id=123&mode=map&map=/path/to/mapfile.map&.>
..

So the only change to mapserver would be to kindly ask it to pass variables
when getting a mapfile.  eg
/path/to/mapfilescript&client_id=123&mode=map&bbox=........ etc

Then the custom parsing script could do lots of things, like search and
replace $client_id with "123"  or include other files etc.  It could also
build an entire mapfile from scratch, pull stuff from a DB, cache common
requests and I guess lots more.

As I said I have no idea if this is plausible, or if it would impact on
speed to much etc

Matt  :)

On Tue, Oct 4, 2011 at 8:10 AM, Bob Basques <Bob.Basques at ci.stpaul.mn.us>wrote:

>  All,
>
>  I did submit a request very similar to the idea of passing in a MAPFILE
> as a mapserv parameter a few years back. As I recall there was some
> discussion about the idea, and there were also the same sorts of
> reservations about it then, especially the KISS part.  In very early uses of
> MapServer, we used our own wrapper around it to provide this type of
> functionality, but it ended up too cumbersome to maintain along with
> different versions of MapServ as they came along, so we let the idea go.  It
> really needs to be passed through MapServer to be a viable option IMO.
>  Otherwise you need to support to many pieces of things to make things very
> portable.
>
>  I thought the recent introduction of the browse mode using a OpenLayers
> template might resurrect the idea to some degree, but that didn't happen
> either.  I suggested a template passing mechanism for that for example, why
> restrict to just Openlayers, got some discussion going on it, but that was
> all.
>
>  I think it will come about at some point, certainly more folks wanting it
> now than when I first started asking the question  :c)  .
>
>  bobb
>
>
>
> >>> Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
>
> Robert,
>
> All good questions!
>
> Here are some thoughts on this.
>
> 1. we all ready have the CGI parameter substitution, but it does require
> reading the mapfile to get its validation parameters.
>
> 2. we already support includes
>
> 3. you would have to read some of the mapfile to get the connection
> parameters to access the parameters from a database
>
> 4. I like the idea of getting the mapfile from the database, but I think
> if I were to go that route, why would I not keep the whole map file in
> the database? it would be easy to store it as fragments and parameters
> and do the substitution all in the database and just return a text blob
> as a mapfile for mapserver to parse. In Postgresql it would be easy to
> write a few stored procedures to help manage this and implement it on
> the database side of things.
>
> 5. Follow the KISS principal. Keep is simple, make the approach
> incremental based on the existing code as much as possible
>
> -Steve W
>
> On 10/3/2011 3:59 PM, reholl wrote:
> > I really like the idea of pulling mapfile resources from RDBMS and URL.
> > For the URL, I don't think the communications part poses much of a
> > challenge, as the cURL stuff used in the OWS client can be repackaged. I
> > did that once to make a mapserv CONNECTIONTYPE as a SOAP client. I can
> > certainly picture a somewhat generalized mechanism: "fill ANY mapfile
> > value from some outside resource that delivers a construct of the proper
> > form/type." These resources might be chained or arranged in branches.
> > (Does this begin to stray into WPS territory..?) Anything of this
> > complexity poses a risk to performance and readability. There's
> > definitely something to be said for the everything-is-right-here aspect
> > of the mapfile. Does mapserv configuration becomes less 'file' and more
> > 'system.' and with what new maintenance headaches? Or another way to
> > view it: mapfile syntax becomes a de facto programming language, and we
> > already have mapscript in numerous flavors. What's the tipping point for
> > "let's move this complexity into core mapserver"? Given all these
> > caveats, I'd love to explore this further... Robert Hollingsworth
> >
> >     blammo wrote:
> >     All, Would adding in INCLUDEs from a URL be pushing it too much, as
> >     in: INCLUDE "http://Myserver.com/cgi-bin/myscript.pl" Could pass in
> >     parameters like so . . . INCLUDE
> >     "http://Myserver.com/cgi-bin/myscript.pl?A=first thing&b=second
> >     thing&c=third thing . . ." bobb >>> "Smith, Michael ERDC-CRREL-NH"
> >     <[hidden email] </user/SendEmail.jtp?type=node&node=6856380&i=0>>
> >     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" <[hidden email]
> >     </user/SendEmail.jtp?type=node&node=6856380&i=1>> 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:
> >      > >
> >
> >
> > View this message in context: Re: Feature wish: Internal mapfile
> > variables
> > <
> http://osgeo-org.1803224.n2.nabble.com/Feature-wish-Internal-mapfile-variables-tp6853853p6856380.html
> >
> > Sent from the Mapserver - User mailing list archive
> > <http://osgeo-org.1803224.n2.nabble.com/Mapserver-User-f1969211.html> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20111004/07e9bfd1/attachment.htm>