g]
Sent: Thursday, April 19, 2012 4:03 AM
To: Tyler Mitchell
Cc: Jason Roberts; gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Layer operations, a proposal
Selon Tyler Mitchell :
>
>
> Jason Roberts wrote:
> ...
> > For scenarios involving large numbers of features, I suspect
Selon Ari Jolma :
> On 04/19/2012 03:04 PM, Even Rouault wrote:
> >> http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra
> >>
> >
> > 3) I'm wondering if it would not be more appropriate to separate the
> creation of
> > fields of the output layer in a separate method that might be called, or
On 04/19/2012 03:04 PM, Even Rouault wrote:
http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra
3) I'm wondering if it would not be more appropriate to separate the creation of
fields of the output layer in a separate method that might be called, or not,
before the real operation. For exam
> http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra
>
Ari,
I have reviewed your proposal and it looks interesting. Here are my observations
:
1) Argument order. A.Operation(B, C) where C is the target layer doesn't seem
very intuitive, but I'm not sure I have something fundamentally better
On 04/18/2012 02:32 AM, Frank Warmerdam wrote:
Ari,
I think this would be an interesting addition. Would you be willing
to write up an RFC?
http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra
In there I call for discussion on the method names. They are now:
Intersection, Union, Identit
Selon Tyler Mitchell :
>
>
> Jason Roberts wrote:
> ...
> > For scenarios involving large numbers of features, I suspect it is much
> > harder to do it fast and within available memory. It is probably necessary
> > to do a multi-pass approach, where the first step operates only on the
> > spatial
On 04/18/2012 11:06 PM, Jason Roberts wrote:
For scenarios involving large numbers of features, I suspect it is much
harder to do it fast and within available memory. It is probably necessary
to do a multi-pass approach, where the first step operates only on the
spatial indexes of the layers invo
Jason Roberts wrote:
...
> For scenarios involving large numbers of features, I suspect it is much
> harder to do it fast and within available memory. It is probably necessary
> to do a multi-pass approach, where the first step operates only on the
> spatial indexes of the layers involved. It is
org
> [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam
> Sent: Tuesday, April 17, 2012 7:32 PM
> To: Ari Jolma
> Cc: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Layer operations, a proposal
>
> Ari,
>
> I think this would be an interesting add
On Wed, Apr 18, 2012 at 7:28 AM, Howard Butler wrote:
> I'm excited by the functionality, but skeptical about having this specific
> functionality in OGR's core. I don't want to be discouraging, but this seems
> like giant scope creep for OGR.
Howard,
It is scope creep for OGR, though it is a
m
Sent: Tuesday, April 17, 2012 7:32 PM
To: Ari Jolma
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Layer operations, a proposal
Ari,
I think this would be an interesting addition. Would you be willing
to write up an RFC?
I think the layer creation step should be a different call t
...@lists.osgeo.org on behalf of Ari Jolma
Sent: Wed 4/18/2012 9:00 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Layer operations, a proposal
On 04/18/2012 06:48 PM, Tyler Mitchell wrote:
>
> Hi Ari,
>
> For what it's worth, I'd sure love to see this functionality
On 04/18/2012 06:48 PM, Tyler Mitchell wrote:
Hi Ari,
For what it's worth, I'd sure love to see this functionality -
essentially ArcInfo workstation like capabilities. I don't have any
opinion on whether it's core or not in GDAL, but when I started doing
something similar with Python (a cou
riginal Message-
From: gdal-dev-boun...@lists.osgeo.org on behalf of Ari Jolma
Sent: Wed 4/18/2012 8:09 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Layer operations, a proposal
On 04/18/2012 05:28 PM, Howard Butler wrote:
> I'm excited by the functionality, but ske
On 04/18/2012 05:28 PM, Howard Butler wrote:
I'm excited by the functionality, but skeptical about having this specific
functionality in OGR's core. I don't want to be discouraging, but this seems
like giant scope creep for OGR.
I agree that we disagree on the scope of GDAL ;) -- or at least
I guess my initial reaction to this is similar to Howard's: excellent,
but aren't these operations covered by GEOS, which is already part of
the GDAL-C stack? I guess I may not understand the relationship between
GDAL and GEOS correctly.
-jeff
___
g
On Apr 17, 2012, at 4:42 PM, Ari Jolma wrote:
> Folks,
>
> I propose a set of new methods for OGR layers (see the PDF). I took the basic
> ideas from page http://courses.washington.edu/gis250/lessons/Model_Builder/
> which seems rather comprehensive. I wrote the pseudo code myself quickly
> (
On 04/18/2012 02:32 AM, Frank Warmerdam wrote:
Ari,
I think this would be an interesting addition. Would you be willing
to write up an RFC?
Yes, but I probably want to include a working patch.
I think the layer creation step should be a different call than the
feature processing step to m
esday, April 17, 2012 7:32 PM
To: Ari Jolma
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Layer operations, a proposal
Ari,
I think this would be an interesting addition. Would you be willing
to write up an RFC?
I think the layer creation step should be a different call than the fe
Ari,
I think this would be an interesting addition. Would you be willing
to write up an RFC?
I think the layer creation step should be a different call than the
feature processing step to maximize the chance that folks who need to
do something very format specific at layer creation can do so an
Folks,
I propose a set of new methods for OGR layers (see the PDF). I took the
basic ideas from page
http://courses.washington.edu/gis250/lessons/Model_Builder/ which seems
rather comprehensive. I wrote the pseudo code myself quickly (thus it
may not be optimal and may contain bugs - improvem
21 matches
Mail list logo
