Hi Even
thanks for your thoughts.
On Thu, Dec 12, 2013 at 8:30 PM, Even Rouault
wrote:
>> - rasters - currently we do not have API to cancel requests for raster
>> blocks. This means that currently we need to wait until the raster
>> block is fully read even when we cancel the rendering job. GDA
Hi Frank
On Fri, May 11, 2012 at 10:47 PM, Frank Warmerdam wrote:
> It occurs to me it would be a huge win in some cases to
> extend that so if none of the segments could possible
> intersect the envelope then we can be sure there is
> no intersection and return FALSE without any use of
> GEOS.
Hi all,
when fetching features in OGR with an active spatial filter, first a
bounding box test is used to resolve simple cases and then exact
intersection with GEOS is done to determine whether the feature is
really within the filter (if compiled with GEOS). I would like to have
an option to force
Hi Even
On Sat, May 7, 2011 at 7:16 PM, Even Rouault
wrote:
> Hi,
>
> I've written a new RFC to add the capability to delete fields, reorder fields
> and alter field definitions, in OGR layer definitions.
>
> http://trac.osgeo.org/gdal/wiki/rfc35_deletereorderalterfielddefn
Thanks a lot f
On Sat, Aug 7, 2010 at 4:33 PM, Frank Warmerdam wrote:
>
> Re: the TestCapability(), I'd like to see this added too.
> I think this could be done without restarting the RFC
> process.
I've done minor edits to the RFC, stating:
The drivers supporting this method will return TRUE to OLCIgnoreField
Hi,
As there have been no further comments on RFC 29, I would like to call
for vote on it:
http://trac.osgeo.org/gdal/wiki/rfc29_desired_fields
Regards
Martin
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gd
On Fri, Jul 30, 2010 at 3:44 PM, Frank Warmerdam wrote:
>
> Martin,
>
> I do not agree with applications directly changing the OGRFieldDefn, even
> if ultimately the flag is stored here. There needs to be a virtual method
> on the OGRLayer (IMHO) so that drivers have an opportunity to hook the
>
Hi Tamas
On Thu, Jul 29, 2010 at 9:10 PM, Tamas Szekeres wrote:
> Frank,
>
> If you refer to the OGR_GEOMETRY, OGR_GEOM_WKT, OGR_GEOM_AREA special
> fields, both return a meaningful value (ie. an empty string) when the
> geometry is null. In this regard it would be enough to disable only the
> ge
On Thu, Jul 29, 2010 at 3:15 PM, Daniel Morissette
wrote:
> Martin Dobias wrote:
>>
>> I've updated the RFC to reflect your suggestions:
>>
>> http://trac.osgeo.org/gdal/wiki/rfc29_desired_fields
>>
>> Given that there has been no further discussion,
On Wed, Jul 21, 2010 at 6:59 PM, Martin Dobias wrote:
>
> So, in case there will be no further comments, I'll update the RFC to
> match the API you've proposed.
Hi Frank,
I've updated the RFC to reflect your suggestions:
http://trac.osgeo.org/gdal/wiki/rfc29_desired_
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. F
Hi Frank
On Wed, Jul 21, 2010 at 4:45 PM, Frank Warmerdam wrote:
> Martin Dobias wrote:
>>
>> Hi,
>>
>> based on the discussion about optimizing the performance of reading
>> features in OGR few days ago, I've prepared an RFC that proposes API
>> fo
On Wed, Jul 21, 2010 at 3:31 PM, Jez Walters wrote:
> Martin,
>
>
> I may be misunderstanding how the API works (I'm not actually using it
> myself), but if someone wants to parse a given layer of the OS MasterMap
> vector data that is divided into chunks they can't use fixed field numbers,
> b
On Wed, Jul 21, 2010 at 1:36 PM, Jez Walters wrote:
> Although I take your point about the interface not affecting ogr2ogr, surely
> the potential speed boost is worth extending to this utility too - or would
> that be a separate ticket? I for one would welcome improving the performance
> of o
Hi Jaz
On Wed, Jul 21, 2010 at 10:43 AM, Jez Walters wrote:
> Martin,
>
>
> When I convert Ordnance Survey MasterMap GML to ESRI Shapefiles using
> ogr2ogr, I'm getting different field numbers for the same field name in
> different GML chunk files. Apologies if I have the wrong end of the stic
Hi,
based on the discussion about optimizing the performance of reading
features in OGR few days ago, I've prepared an RFC that proposes API
for limiting which fields will be fetched when reading features:
http://trac.osgeo.org/gdal/wiki/rfc29_desired_fields
Any comments or suggestions are highl
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 OGRS
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
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
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
On Fri, Jun 25, 2010 at 5:55 PM, Frank Warmerdam wrote:
>> My intent is to use two OGRLayer instances of the same layer: one
>> instance for handling various stuff in main thread, the other one in
>> worker thread for rendering. Can I expect the GetNextFeature calls to
>> be reentrant, i.e. can th
Hi Frank
On Wed, Jun 23, 2010 at 4:58 PM, Frank Warmerdam wrote:
> Martin,
>
> Generally speaking it is not safe to have multiple threads making calls
> into a single OGRLayer at the same time. At the very least you will
> encounter the "messing up" effect on GetNextFeature(), even if you
> seri
Hi Ed
On Wed, Jun 23, 2010 at 3:18 PM, Grissom, Edward (Ed)
wrote:
> In a previous message, Martin said:
>
>> So my only problem is to avoid concurrent reads from
>> both main thread and worker thread. How can be this
>> best accomplished without serializing the access?
>
> Your reads are eventua
Hi Ari
On Wed, Jun 23, 2010 at 7:32 AM, Ari Jolma wrote:
> Martin,
>
> Just a comment. In Geoinformatica, which uses GTK+, I've begun to address
> the same kind of problem using the functions provided by GTK+. So far I've
> not used this on rendering and I've not thought about all the consequenci
Hi all,
in my GSoC project [1] I'm trying to employ multithreading to make
rendering in QGIS both faster (on multi-core machines) and more
pleasant to use (not blocking GUI thread while rendering). I've been
successful with making that work in "ideal" conditions (no concurrent
reads/writes) and no
26 matches
Mail list logo
