[mapserver-dev] Ready for 5.6.2?

[Tamas Szekeres]

2010/3/17 Frank Warmerdam <warmerdam at pobox.com>

>
> I wrote a small test script (msautotest/mspython/ogr_query.py) and I
> did not observe any problems with resultsGetShape() and queryByRect().
> What problem were you expecting?
>
>
Frank,

I didn't have enough time to track this down in more detail, but I'll create
a test example sooner or later.



>
>  2. resultsGetShape may retrieve different features when panning the view
>> within the same selection. (A persistent mapObj reference is required
>> between the pan operations to test this)
>>
>
> I can confirm that if doing a draw on the layer effectively invalidates
> the last query result since the draw applies a different spatial query
> criteria to the layer, clearing the one from the last query operation.
>
> I hadn't really imagine applications would expect query results to
> persist through major operations like a draw.
>
>
In my understanding msDrawQueryLayer should do the normal drawing in a
backup copy of the layer (whichShapes on a different instance in effect).
This should mean that the original result set is retained for the layer at
the data source level.

In any case the standpoint you mentioned would be quite a bad news with
regards to the existing scripts, by the fact that the content of the result
cache may be invalid in some cases. I think we should advertise this effect
stronger in the related documentation since there's no chance to invalidate
the references to the result cache at the client by MapServer.



>
>  3. GetShape doesn't work anymore (ie. the former 2 pass approach). It
>> retrieves null shapes with no items.
>>
>
> I did not observe any problem with it in my testing.  Of course, you
> can't necessarily use the id's from the resultset since they are not
> FIDs.  But if, somehow, you know the fid's you want you can fetch them
> with GetShape().
>
>
I didn't notice we altered the meaning of the index in the result cache, in
this regard GetShape cannot be used anymore to pick up the results based on
their index value. I think however we should at least establish an option to
switch to the 2 pass behaviour (perhaps a processing option would be
sufficient) since it seems to break the things significantly at the user's
side. Moreover, with regards to many of the file based data sources I don't
see a strong pressure to switch to this single pass approach to increase the
preformance.



>
>  4. Moving the selected shapes outside of the visible region MapServer
>> triggers an error (failed to draw layer)
>>
>
> I'm not clear on what you mean by moving them around.
>
>
This issue may be related to a previous one. Between the drawings we may
change the extent of the map, and there's no more shapes inside the current
extent existing in the result cache.


Not strictly related but the API change I mentioned in my previous mail
would somewhat help for the driver to decide whether a whichShapes call
would be related to a query (and subsequent resultsgetshapes may happen) or
just related to a normal drawing operation. By using this extra parameter
the driver could keep a copy of the resultset at a separate place in
layerinfo to use in a subsequent resultsgetshape call.


Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20100317/e3294a1a/attachment.html