<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Hi Jürgen,</span><br><div> Thinking about it, the simplest solution is to just trust MDSYS.USER_SDO_GEOM_METADATA and get everything from that where possible - SRID and BBOX. The geometry-type it doesn't have, but is that strictly necessary for the list?</div>
<div><br></div><div>This seems like the optimal solution for us; I'd suggest adding the functionality behind the current "Use estimated table metadata" and/or "only look in meta data table" checkboxes. In fact I expected "only look in meta data table" to already do this.</div>
<div><br></div><div>I realise that this can be dangerous as Oracle doesn't keep it up to date, however we do a good job of keeping it up to date ourselves (because if we don't, ArcMap starts doing silly things). I'm sure other organisations are similarly good at keeping their metadata up to date and could benefit too.<br>
</div><div><br></div><div class="gmail_extra"><div>Does that seem like a plausible solution? A local-cache could build on that I guess (store geometry types from pre-accessed tables?)<br>Cheers,</div><div>Jonathan</div>
<br><br><div class="gmail_quote">On 8 February 2014 17:45, Jürgen E. <span dir="ltr"><<a href="mailto:jef@norbit.de" target="_blank">jef@norbit.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Jonathan,<br>
<div class=""><br>
On Tue, 04. Feb 2014 at 17:54:10 +0000, Jonathan Moules wrote:<br>
> The native Oracle provider has been in QGIS for quite a while (a year?)<br>
> and is generally quite good.<br>
> However there are still two fundamental issues that we have with it, both<br>
> as a result of the fact that Oracle doesn't store accurate spatial<br>
> metadata:<br>
<br>
> a) Whenever I "Connect" to the Oracle database, QGIS performs a scan of<br>
> every table to get the metadata which can take almost 2 minutes (the<br>
> results are cached by Oracle and subsequent "Connects" are faster, but<br>
> only for an hour or two). This is using the "Only look in metadata table",<br>
> "use estimated table metadata" and "only existing geomtetry types"<br>
> checkboxes.<br>
</div>> See also - [1]<a href="http://hub.qgis.org/issues/8689" target="_blank">http://hub.qgis.org/issues/8689</a><br>
<br>
That's to determine the geometry types and srids used in the tables.<br>
<br>
That the available metadata tables in Oracle are somewhat optional and you<br>
can't safely assume much about them is really unfortunate.<br>
<br>
We could do another metadata table that stores the outcome of those queries in<br>
the database. That would require the user to have INSERT/UPDATE on that table<br>
and/or CREATE TABLE rights.<br>
<br>
We could also do a local user cache. That would have the advantaage that it<br>
could be used for any database.<br>
<div class=""><br>
> b) When I add a specific Oracle table, QGIS then performs some checks<br>
> against it (I believe trying to find the actual BBOX). This is fine for<br>
> small tables, but for large tables it can take several minutes for the<br>
> layer to get added - locking up QGIS in the interim - even if "render" is<br>
> disabled!<br>
<br>
> The issue becomes even more problematical when re-opening a project - QGIS<br>
> then rescans all of the tables included in the project which can mean a<br>
> several minute delay after opening the project.<br>
<br>
</div>The extent could also be added to that cache. But for this the extent could<br>
also be added as cachedExtent to the data source uri. Parameters for srid and<br>
(geometry)type are already there and I just changed the postgres provider to<br>
depend on those without verifying them. Extent would be the next natural<br>
candidate and possibly speed up the loading of projects even more.<br>
<br>
But those are features which will have to wait until after the release.<br>
<br>
<br>
Jürgen<br>
<span class=""><font color="#888888"><br>
--<br>
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31<br>
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50<br>
Software Engineer D-26506 Norden <a href="http://www.norbit.de" target="_blank">http://www.norbit.de</a><br>
QGIS PSC member (RM) Germany IRC: jef on FreeNode<br>
<br>
--<br>
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH<br>
Rheinstrasse 13, 26506 Norden<br>
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</font></span></blockquote></div><br></div></div>
<br>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.</span>