SWIG Mapscript

Ryan, Adam ARyan at CO.LINN.OR.US
Wed Sep 29 16:37:55 EDT 2004


> -----Original Message-----
> From: Sean Gillies [mailto:sgillies at FRII.COM]
> Sent: Wednesday, September 29, 2004 12:19 PM
> To: MAPSERVER-USERS at LISTS.UMN.EDU
> Subject: Re: [UMN_MAPSERVER-USERS] SWIG Mapscript
>
>
> On Sep 29, 2004, at 1:16 PM, Sean Gillies wrote:
>
> > On Sep 29, 2004, at 12:54 PM, Ryan, Adam wrote:
> >
> >> Mapservers,
> >>
> >> Two methods I use in php mapscript don't seem to be in the SWIG
> >> version.
> >>
> >> Layer->queryByIndex - this is non-critical since I can use
> >> queryByAttribute
> >> with an FID
> >>
> >> Map->loadQuery - this is critical.  There is a saveQuery
> method, but
> >> no
> >> loadQuery?
> >>
> >> Thanks for any insight.
> >>
> >> Adam
> >>
> >
> > Adam,
> >
> > Since I've used the PHP mapscript, I'm not sure what loadQuery and
> > saveQuery are for.  Explain?
> >
> > Sean
> >
>
> Sorry, meant to say that I've *never* used the PHP mapscript
> and don't understand the use for saving and loading queries.
>
> Sean
>

Hey, thanks for the reply.

Am I the only one using saveQuery?  I think saveQuery and loadQuery are
terrific methods.  They generate/read small files of shape index values -
similar, to a bitmap in Avenue I think.  By loading a saved query, I can
return a layer to a previous query 'state', for lack of a better word
(resultCacheObj state?).  This is extremely useful.

Building shapefiles does not allow for dynamic queries using AND, OR, or XOR
with previous queries, and it's too slow.  The layer index problem is easily
handled by changing the layer index value in the saved query file itself
prior to loading.  As long as only one layer is queried at a time, this
works well.

I'm trying to re-write an application using Python and without this
functionality it's a no go.  I can't even emulate a saveQuery because there
is no queryByIndex method, and even if there was, stepping through a list of
indexes and calling queryByIndex is MUCH slower than the loadQuery method.

I'm at a loss.

Adam



More information about the mapserver-users mailing list