SWIG Mapscript

[Sean Gillies]

On Sep 29, 2004, at 2:37 PM, Ryan, Adam wrote:

>
>> -----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 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
>>>>
>>>
>>
>> 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
>

Adam,

Thanks for the explanation.  I am not against implementing the PHP
savequery
and loadquery, although I do question why these methods write and read
from
the filesystem when your logical combination needs to be done in memory.

Meanwhile, for 4.2, I have an idea.  Instead of manipulating the layer's
resultcache in place, create Python sets of query results and do your
logical
operations on them.  For example::

     import sets

     ...
     layer.query1()  # assume success
     qset1 = sets.Set()
     for i in range(layer.getNumResults()):
         result = layer.getResult(i)
         result_tuple = (result.shapeindex, result.tileindex,
result.classindex)
         qset1.add(result_tuple)

     layer.query2()  # assume success
     qset2 = sets.Set()
     for i in range(layer.getNumResults()):
         result = layer.getResult(i)
         result_tuple = (result.shapeindex, result.tileindex,
result.classindex)
         qset2.add(result_tuple)

     # Union
     qunion = qset1.union(qset2)

     # Intersection
     qintersection = qset2.intersection(qset1)

     # Get shapes from the intersection
     for member in qintersection:
         layer.getShape(member[0], member[1])
         ...


Sets are a first class type in the upcoming Python 2.4, well worth
learning.

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies