<br><br><div style="visibility: hidden; display: inline;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}</style><div class="gmail_quote">
2010/3/17 Frank Warmerdam <span dir="ltr"><<a href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I wrote a small test script (msautotest/mspython/ogr_query.py) and I<br>
did not observe any problems with resultsGetShape() and queryByRect().<br>
What problem were you expecting?<div class="im"><br></div></blockquote><div><br>Frank,<br><br>I didn't have enough time to track this down in more detail, but I'll create a test example sooner or later.<br><br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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)<br>
</blockquote>
<br></div>
I can confirm that if doing a draw on the layer effectively invalidates<br>
the last query result since the draw applies a different spatial query<br>
criteria to the layer, clearing the one from the last query operation.<br>
<br>
I hadn't really imagine applications would expect query results to<br>
persist through major operations like a draw.<div class="im"><br></div></blockquote><div><br>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.<br>
<br>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.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3. GetShape doesn't work anymore (ie. the former 2 pass approach). It retrieves null shapes with no items.<br>
</blockquote>
<br></div>
I did not observe any problem with it in my testing. Of course, you<br>
can't necessarily use the id's from the resultset since they are not<br>
FIDs. But if, somehow, you know the fid's you want you can fetch them<br>
with GetShape().<div class="im"><br></div></blockquote><div><br>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.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
4. Moving the selected shapes outside of the visible region MapServer triggers an error (failed to draw layer)<br>
</blockquote>
<br></div>
I'm not clear on what you mean by moving them around.<div class="im"><br></div></blockquote><div><br>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.<br>
<br><br>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.<br>
<br> <br></div></div>Best regards,<br><br>Tamas<br><br>