<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 style="display: inline;">
</div><div class="gmail_quote">
2010/3/23 Frank Warmerdam <span dir="ltr"><<a href="mailto:warmerdam@pobox.com" target="_blank">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><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
4. Preserve the behaviour of keeping separate set of results for separate layer instances. In this regard a query on one layer should not invalidate the results for a different layer instance of the same driver.<br>
</blockquote>
<br></div>
This seems to be a lot to expect.  We go to significant effort with<br>
the connection pooling to allow reuse of a connection for different<br>
layers, and in effect in many drivers this connection also carries<br>
a bunch of context with it.  Certainly in the case of OGR an<br>
OGRLayer retains a concept of current query result, but it can<br>
be invalidated by lots of operations other than ResetReading() and<br>
GetNextFeature().  I would imagine this is true to a greater or<br>
lesser to other drivers that pool connections.<div><br></div></blockquote><div><br>Frank,<br><br>It may be driver dependent, but I'm tending to think we should open up a new connection/session/dataset whatever, for those queries which would retain the results at the driver, corresponding to a particular result set stored at layer level.  This is not the case for those queries where the results are not retained (like drawing the layers / background) and the connection pool approach could continue be used in these cases. That's why I suggested an additional parameter in whichShapes to define the purpose of the query.<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>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
5. Creating a clone of a layer should provide to use a separate query (by keeping the results intact on the original layer). This would be essential for msDrawQueryLayer to work when drawing the background before the highlighted features.<br>


</blockquote>
<br></div>
This is also quite impractical for some implementations - certainly<br>
for OGR.<div><br></div></blockquote><div><br>I'm quite unsure how msDrawQueryLayer would ever work with OGR then. In this case, MS_HILITE would require to draw the entire layer first and then the highlighted shapes from the result set. Drawing the entire layer (regardless of whether it's happening on a clone) would reset the spatialfilter on the driver with the same connection, and a subsequent resultsGetShape would fail to retrieve the same features.<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;"><br>
In retrospect, I'm not all that confident that we really considered<br>
the impact of RFC 52 on use cases such as those you raise.  I<br>
certainly didn't understand these impacts.  What is less clear to<br>
me is where to go from here.  RFC 52 was put in place because the<br>
old approach was giving terrible performance in some cases.<br></blockquote><div><br>This is really a good question ;-)  RFC 52 is out in the stable branch and prevents from a number of users to upgrade (we don't know the exact number though). Leaving this version as it stands would bring in more people involved in this version of the API, while we foresee some API change shortly.<br>

I think our best chance would be to provide the original version at the drivers in parallel to the current that means: both getShape and layerGetShape should work properly. This should probably be controlled by a layer processing option at driver level. It would be reasonable to switch the defaults to the 2 pass approach in the stable branch, while the users could eventually override this in their mapfiles.<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;">
But if we put the expectations you list into place there is no<br>
way it can be made fast on OGR short of maintaining distinct<br>
OGRDataset instances for each query in addition to the one used to<br>
draw the layer.  This could cause various performance and<br>
resource problems.<br>
<br></blockquote><div><br>While I don't exactly see the performance impacts, it may require a bit more memory for sure. However since we intend to reuse the results of a query it would definitely imply to store the corresponding reference of the OGRDataset during the time interval when a subsequent access to the query may happen.<br>

<br>I'm also hesitant to think that the 1pass option is better for all OGR data sources in all cases. Having a couple of test scripts to see the performance difference of the same query with these 2 methods would be helpful.<br>

<br><br></div></div>Best regards,<br><br>Tamas<br><br><br>