On 07/23/2010 02:31 PM, Martin Dobias wrote:
This is exactly my intent. Vector data providers in QGIS always
receive a list of fields that are needed, however until now OGR data
provider couldn't make use of it, because currently there's no way in
OGR to limit what fields should be fetched. Knowi
On Fri, Jul 23, 2010 at 12:47 PM, Yevgen Antymyrov
wrote:
> On 07/19/2010 02:08 PM, Martin Dobias wrote:
>>
>> Hi,
>>
>> in order to speed up rendering in QGIS as a part of my GSoC project,
>> I've took some time to profile reading of shapefiles in OGR. From the
>> results I'd like to suggest some
On 07/19/2010 02:08 PM, Martin Dobias wrote:
Hi,
in order to speed up rendering in QGIS as a part of my GSoC project,
I've took some time to profile reading of shapefiles in OGR. From the
results I'd like to suggest some changes that significantly contribute
to the speed of data retrieval. On a
On Mon, Jul 19, 2010 at 3:46 PM, Frank Warmerdam wrote:
>
> Would GetFeature() still return a feature with a full vector of
> fields, but those not desired just being left in the null state?
> If so, I think such an approach would be reasonable. However, it will
> require an RFC process to update
On Mon, Jul 19, 2010 at 7:54 PM, Frank Warmerdam wrote:
> Martin Dobias wrote:
>> One note to avoid confusion: the suggestion I've made above relates
>> only to shapefile driver in OGR and doesn't impose any changes to the
>> API. The suggested patch reuses OGRShape instances which are passed
>> b
On Mon, Jul 19, 2010 at 10:54 AM, Frank Warmerdam wrote:
> Ragi Burhum wrote:
>
>> Would it make sense instead of implementing a SetDesiredFields(..) to
>> implement a SetSubFields(string fieldnames) where the function
>> takes a comma delimited list of subfields and then those are parsed by the
>
Ragi Burhum wrote:
Would it make sense instead of implementing a SetDesiredFields(..) to
implement a SetSubFields(string fieldnames) where the function
takes a comma delimited list of subfields and then those are parsed by
the shapefile driver to find out which field values to fetch? That way,
On Mon, Jul 19, 2010 at 6:50 PM, Ragi Burhum wrote:
>> >> 1. allow users of OGR library set which fields they really need. Most
>> >> of time is wasted by fetching all the attributes, but typically none
>> >> or just one attribute is necessary when rendering. For that, I've
>> >> added the followi
>
> Date: Mon, 19 Jul 2010 16:34:40 +0200
> From: Martin Dobias
> Subject: Re: [gdal-dev] Optimizing access to shapefiles
> To: Frank Warmerdam
> Cc: gdal-dev@lists.osgeo.org
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Frank
&g
Hi Frank
On Mon, Jul 19, 2010 at 3:46 PM, Frank Warmerdam wrote:
>> 1. allow users of OGR library set which fields they really need. Most
>> of time is wasted by fetching all the attributes, but typically none
>> or just one attribute is necessary when rendering. For that, I've
>> added the follo
Martin Dobias wrote:
Hi,
in order to speed up rendering in QGIS as a part of my GSoC project,
I've took some time to profile reading of shapefiles in OGR. From the
results I'd like to suggest some changes that significantly contribute
to the speed of data retrieval. On a test shapefile of a road
Martin,
These changes look quite promising. Please add two tickets at
http://trac.osgeo.org/gdal/newticket , one for each topic, and attach the
patch.
On Mon, Jul 19, 2010 at 5:38 PM, Martin Dobias wrote:
> Hi,
>
> in order to speed up rendering in QGIS as a part of my GSoC project,
> I've took
Hi,
in order to speed up rendering in QGIS as a part of my GSoC project,
I've took some time to profile reading of shapefiles in OGR. From the
results I'd like to suggest some changes that significantly contribute
to the speed of data retrieval. On a test shapefile of a road network
(about 100 tho
13 matches
Mail list logo
