[gdal-dev] Motion: Adopt RFC 29: OGR Set Ignored Fields

[Jason Roberts]

Sorry to jump in as another non-voting user of the API, but I second Raji's
opinion. As a user of the API, I would expect to find consistency with other
APIs and the SQL language, which typically require to specify the fields you
want to retrieve, not the ones you want to ignore.

The RFC presents these use cases:

1. the client renders the layer: all fields can be ignored, only the
geometry is required
2. the client shows attribute table: all fields are required, the geometry
can be ignored

While those may be common for certain applications, such as GIS GUIs, I
would say there is a third case that should be considered:

3. The client is doing some geoprocessing that involves a specific subset of
fields, possibly but not always including the geometry. The client wants to
save bandwidth, memory, and CPU by requesting just the fields of interest.

So the question is, is case #2 more common than case #3, to the point that
the API should make case #2 convenient to code at the cost of making case #3
difficult plus deviating from the design most other APIs use? I believe not.

I would also point out that case #1 is not as common as might be expected
either. The very first thing anyone does in a GIS after they display the
points is to color code them by some attribute. This is case #3.

Best regards, and sorry again for jumping into your vote,

Jason 

-----Original Message-----
From: gdal-dev-bounces at lists.osgeo.org
[mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Ragi Burhum
Sent: Friday, August 06, 2010 12:33 PM
To: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Motion: Adopt RFC 29: OGR Set Ignored Fields

>
> Martin Dobias wrote:
> > 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
>

I hesitated whether to reply to this or not. I am aware that I can
(deservingly) get publicly castrated for chiming in now instead of a
couple of weeks ago. In my defense I can tell you I get digests and
then read them when I have free time. Which is usually at the end of
the week. Like right now. Sigh.

Thus, it may be too late already. I know.

I also realize that I don't have voting power on this, but I still
wanted to gave my opinion because I do care about this library. Very
much actually. Feel free to dismiss this as noise.

There are two elements of this RFC that I think are not ideal.

One is the lack of a TestCapabilities feature so I can decide whether
to use this or not. I saw that other people had expressed their
opinions about it and I assumed it was going to be added. Looking at
the RFC, I don't see that this materialized.

The other, IMHO more importantly, is the issue of specifying **what I
want** (SetDesiredFields) vs specifying **what I don't want**
(SetIgnoredFields). I guess the conversation turned to using
SetIgnoreFields after Frank expressed a preference for
SetIgnoredFields here

http://lists.osgeo.org/pipermail/gdal-dev/2010-July/025487.html

Frank's opinion was: "What if it was determined at some point that
fetching the real FID was sometimes expensive and that in cases where
it does not matter we would like to be able to skip that. Should we
then start dropping the FID for everyone who has ever used
SelectFields() without knowing that some day FID would become
optional? I can live with SelectFields(), but to me it is an approach
at odds with trying to ensure backwards/forwards compatability for
applications."

I humbly disagree that this is a strong enough argument to go the
"ignore fields" approach.

With every single other data abstraction library I ever worked with
(sadly, I have used too many), I usually ask the API *for I what I
want*, and the data abstraction library returns to me that content. In
subsequent versions those APIs, there may be optimizations done here
and there, but the backwards compatibility is retained by continuing
with the same behavior.

If there is some optimization in the future (i.e "FID retrieval is
expensive"), and I want to take advantage of it, then I have to use
the new approach (i.e "not including FID" in my request). If I don't,
my code still works, but I am not taking advantage of the new
optimization, right?

Presumably, if I had asked only for what I needed - and I included
FID, it is because I needed it in the first place, right? If I didn't
need it, I would not have requested it in the first place and I would
get the optimization for free in the future.

Contrast this with the other approach, "explicitly express what you
don't want". I know I only need three fields for my calculation, I
request those. New fields are added. In every subsequent version I can
potentially be getting extra fields that I don't need. So then I need
to go back to my code and exclude newer fields I don't want so I only
get what I need for my calculation. Sounds silly, right? I believe
Martin had it right when he expressed his opinion about this.

Martin has rewritten the RFC to be SetIgnoreFields instead of
SetRequiredFields and I feel like a jackass for providing input so
late. I apologize Martin.

But of course you are all free ignore this as noise as I said earlier.
Then I wouldn't be such a jackass I guess.

my two cents,

- Ragi
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev