On 08/06/2012 11:27 AM, Ari Jolma wrote:
I've also started a wiki page for describing the method set in more
detail http://trac.osgeo.org/gdal/wiki/LayerAlgebra (linked to page
http://trac.osgeo.org/gdal/wiki/CodeSnippets since that seemed to me
as the best place).
I've finished making a firs
Folks,
I've committed the layer algebra stuff into trunk in changesets 24736 -
24739. The last one is the initial test code.
I've also started a wiki page for describing the method set in more
detail http://trac.osgeo.org/gdal/wiki/LayerAlgebra (linked to page
http://trac.osgeo.org/gdal/wiki
2012/5/4 Jason Roberts
> it accepts an unlimited number of layers, performs the intersection or
> union
> of all of them, and creates one (new) output.
> The main obvious downside of that is having to create and manage the
> temporary outputs.
Currently the output layer is not checked fo
On Thu, May 3, 2012 at 11:04 PM, Jason Roberts wrote:
> As I mentioned, I do not have a strong opinion about the value of accepting
> multiple inputs. The obvious workaround is to call the same method in a
> loop. The main obvious downside of that is having to create and manage the
> temporary out
-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari Jolma
Sent: Thursday, May 03, 2012 2:35 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RFC 39
On 05/02/2012 09:56 PM, Jason Roberts wrote:
> Hi Ari,
>
> I have been following this proposal with interest. I ha
On 05/02/2012 09:56 PM, Jason Roberts wrote:
1. Would you consider implementing a Symmetrical Difference method? It is
the only one from the ArcGIS Overlay toolset that you did not implement
(except Spatial Join, which does not really apply here).
I've added SymDifference method to the patch. I
Selon Ari Jolma :
> Even,
>
> I've uploaded a version, which fixes these. I added a note that GEOS is
> required, as these probably segfault without it (the methods return
> NULLs and not geometries).
Hi,
Hum, I didn't think at crashes. I thought that the algorithm would just nicely
fail. But ye
Even,
I've uploaded a version, which fixes these. I added a note that GEOS is
required, as these probably segfault without it (the methods return
NULLs and not geometries).
I added a simple test against a pre-computed layer envelope, and it
speeds up the computation in my test case ~30%. Sti
On 05/03/2012 11:27 AM, Peter Halls wrote:
Ari,
as a user (and teacher of users), I would urge you to keep to the
model where the output is always a new object (actually the same as
ArcGIS), rather than consider modifying an input for any of these
spatial operations. That automatically s
apply the patch. The test code is written in
> Python.
>
> Thanks for the interest.
>
> Ari
>
>
>> Best regards,
>>
>> Jason
>>
>> -Original Message-
>> From: gdal-dev-bounces@lists.osgeo.**org
>> [mailto:gdal-dev-bounces@**li
Selon Ari Jolma :
>
> The performance is anyway an internal issues and the main thing is to
> get the API and logic acceptable.
Yes, that's what I meant. Those ideas can be kept in mind for later
improvements.
>
> Ari
>
>
___
gdal-dev mailing list
gd
On 05/02/2012 09:14 PM, Even Rouault wrote:
I've also read your note in the RFC about performance. It is
interesting to see that envelope computation is the limiting factor
when the method layer is in memory. It is an interesting track for a
later optimization where envelope would be cached ins
dev-boun...@lists.osgeo.org] On Behalf Of Ari Jolma
Sent: Wednesday, April 25, 2012 9:33 AM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] RFC 39
Folks,
I'll start a new thread for this RFC.
I've uploaded a new patch, which hopefully corrects the issues Even brought
up. Below are commen
al Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari Jolma
Sent: Wednesday, April 25, 2012 9:33 AM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] RFC 39
Folks,
I'll start a new thread for this RFC.
I've uploaded a new patch, which ho
> What would it take to adopt this RFC?
Ari,
I'm pretty satisfied with the current state of the RFC. From a recent
discussion with Frank, I think he has perhaps some comments to add ?
I've looked at the latest version of the patch. A few comments :
* You should not use GetFeaturesRead() to kno
Folks,
I've added a new patch to the RFC 39 page. The attached files (the
latest patch and the autotest code) contain now
- new methods in OGRFeature and especially the new overlay methods in
OGRLayer
- additions to the C API
- additions to the swig bindings
- documentation of the new overla
On 04/25/2012 04:31 PM, Even Rouault wrote:
Hum, I'm surprised that it has survived your testing ;-) : GetSpatialFilter()
might return NULL (in fact, in the general case, it will), so
GetSpatialFilter()->clone() should segfault.
Fixed
CPLMalloc() cannot return NULL. Internally, it will abo
On 04/25/2012 04:31 PM, Even Rouault wrote:
Hi Ari,
Hum, I'm surprised that it has survived your testing ;-) : GetSpatialFilter()
might return NULL (in fact, in the general case, it will), so
GetSpatialFilter()->clone() should segfault.
I've not yet tested this one at all :) -- I only made sur
Hi Ari,
> I've uploaded a new patch, which hopefully corrects the issues Even
> brought up. Below are comments.
I've reviewed quickly and the new version seems to address my comments well.
>
> I've not added the Append or Buffer methods, which basically work on
> just one layer. I believe such f
Folks,
I'll start a new thread for this RFC.
I've uploaded a new patch, which hopefully corrects the issues Even
brought up. Below are comments.
I've not added the Append or Buffer methods, which basically work on
just one layer. I believe such functionality is simple enough to create
using
20 matches
Mail list logo
