[gdal-dev] VirtualOGR with Sqlite
Martin Jensen
martin.martinjensen at gmail.com
Tue Jan 1 14:21:54 PST 2013
Thanks for the quick response!
1) My build was two days old; now it is working!
2) My http debugger showed that a getfeature request was sent to the WFS
without any filters and the request is really really slow so I assumed it
was a full download. Try:
CREATE VIRTUAL TABLE testpdk1 USING VirtualOGR('wfs:
http://geoservice.plansystem.dk/wfs
',0,'pdk:theme_pdk_kommuneplanramme_vedtaget_v');
SELECT * FROM testpdk1 LIMIT 10;
/Martin
On 1 January 2013 21:55, Even Rouault <even.rouault at mines-paris.org> wrote:
> Le mardi 01 janvier 2013 21:45:10, Martin Jensen a écrit :
> > I have been playing around with the virtualOGR table feature made
> available
> > in sqlite and I am absolutely thrilled about this feature.Thanks for the
> > great work!
> >
> > I've come across two small issues that i'd like some help/comments on. I
> am
> > trying to connect to a WFS service which works fine in Sqlite.
> >
> >
> > 1) connecting to all layers in an ogr (WFS) datasource
> >
> > I wanted to try to connect to all layers in the WFS datasource at once.
> > The sqlite driver page says it is possible with the function
> > "ogr_datasource_load_layers" http://www.gdal.org/ogr/drv_sqlite.html, I
> > get the error:
> >
> > no such function: ogr_datasource_load_layers
> >
> > I am using Spatialite 4.0.0 and GDAL 1.10dev from trunk
>
> This has been added yesterday, so maybe your checkout isn't recent enough.
>
> >
> > 2) Using sql with "....limit 10;"
> >
> > All works find using the "create table using virtualOGR()". I was then
> > hoping I could use sql syntax "limit 10" on the wfs datasource because it
> > is a huge dataset. But it seems that the virtual table has fecth the
> entire
> > dataset before retuning the 10 rows. I was thinking the "limit 10" was
> > translated to &maxfeatures=10 in the WFS drivers GetFeature request. Is
> > this expected behaviour or am I doing something wrong?
>
> The limit clause isn't passed to OGR, but only used by the SQLite engine,
> so
> yes this is somehow an expected behaviour. However, the download should be
> partial - prehaps a bit more than 10 features, but not the whole layer if
> it
> is bit - if you iterate only over a few features. I've just tested it
> actually
> and could see the difference on a big enough layer. You can also workaround
> that by just adding "&MAXFEATURES=10" in your connexion string.
>
> Best regards,
>
> Even
>
>
--
Med venlig hilsen
Martin Bjærge Jensen
On 1 January 2013 21:55, Even Rouault <even.rouault at mines-paris.org> wrote:
> Le mardi 01 janvier 2013 21:45:10, Martin Jensen a écrit :
> > I have been playing around with the virtualOGR table feature made
> available
> > in sqlite and I am absolutely thrilled about this feature.Thanks for the
> > great work!
> >
> > I've come across two small issues that i'd like some help/comments on. I
> am
> > trying to connect to a WFS service which works fine in Sqlite.
> >
> >
> > 1) connecting to all layers in an ogr (WFS) datasource
> >
> > I wanted to try to connect to all layers in the WFS datasource at once.
> > The sqlite driver page says it is possible with the function
> > "ogr_datasource_load_layers" http://www.gdal.org/ogr/drv_sqlite.html, I
> > get the error:
> >
> > no such function: ogr_datasource_load_layers
> >
> > I am using Spatialite 4.0.0 and GDAL 1.10dev from trunk
>
> This has been added yesterday, so maybe your checkout isn't recent enough.
>
> >
> > 2) Using sql with "....limit 10;"
> >
> > All works find using the "create table using virtualOGR()". I was then
> > hoping I could use sql syntax "limit 10" on the wfs datasource because it
> > is a huge dataset. But it seems that the virtual table has fecth the
> entire
> > dataset before retuning the 10 rows. I was thinking the "limit 10" was
> > translated to &maxfeatures=10 in the WFS drivers GetFeature request. Is
> > this expected behaviour or am I doing something wrong?
>
> The limit clause isn't passed to OGR, but only used by the SQLite engine,
> so
> yes this is somehow an expected behaviour. However, the download should be
> partial - prehaps a bit more than 10 features, but not the whole layer if
> it
> is bit - if you iterate only over a few features. I've just tested it
> actually
> and could see the difference on a big enough layer. You can also workaround
> that by just adding "&MAXFEATURES=10" in your connexion string.
>
> Best regards,
>
> Even
>
>
--
Med venlig hilsen
Martin Bjærge Jensen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130101/fe617731/attachment.html>
More information about the gdal-dev
mailing list