[mapserver-dev] Ready for 5.6.2?

[Lime, Steve D (DNR)]

I guess I'd recommend a 5.6.2 in spite of these issues. We certainly haven't made things worse. We can cement the query approach for
6.0 then with the possibility of some changes in a 5.6.3 or whatever... (another thread)

Steve
________________________________________
From: Tamas Szekeres [szekerest at gmail.com]
Sent: Wednesday, March 17, 2010 5:14 AM
To: Frank Warmerdam
Cc: Lime, Steve D (DNR); MapServer Dev Mailing List; Daniel Morissette
Subject: Re: [mapserver-dev] Ready for 5.6.2?

2010/3/17 Frank Warmerdam <warmerdam at pobox.com<mailto: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