[gdal-dev] Nullable fields in OGR

[Ragi Y. Burhum]

Jason,

Having (successfully) built abstraction layers in the past to wrap
ArcGIS APIs (aka ArcObjects), OGR (and others) for other projects, I
would strongly advice you *NOT* do it. Why? Because you end up with
some API that looks **way** to similar to ArcObjects or OGR! So why
not use one of those APIs in the first place?

The only time I would suggest to do this is when there is a specific
datasource that has a model that is radically different than what is
presented by the data abstraction layer you are using (think XML,
NoSQL datastores, etc).

If this is not your case, then I would offer something that IMHO is a
better approach. Instead of creating a common abstraction, why not use
the extensibility model of 1) OGR to wrap ArcObjects or 2) viceversa ?

1) If you want to use simply OGR as your one abstraction layer, then
use the arcobjects driver for access ESRI APIs. Use the uncommitted
patch available at http://trac.osgeo.org/gdal/ticket/3332
With this you should be able to use ArcObjects inside OGR. Simply use
OGR as it is.

If there is something that you definitely need and it is not supported
by OGR abstractions (like your NULLs comment), bring it up in this
mailing list. If the GDAL/OGR models gets extended because your need
is identified as must have - then everyone benefits.

2) Currently, the only way to do this is by paying for an expensive
FME extension and even then there are many things you cannot do
(outside of the scope of this conversation). You can also use the
ArcObjects extensibility model (not trivial) and create your own OGR
Workspace that can be accessed through the ESRI tools. I have a
half-way implementation of this which I haven't worked had time (nor
energy/will) to work on. I would be happy to share this code with you
if you want to work together on finishing it.

My two cents,

- Ragi

> Date: Thu, 18 Feb 2010 12:37:04 -0500
> From: "Jason Roberts" <jason.roberts at duke.edu>
> Subject: [gdal-dev] Nullable fields in OGR
> To: "'gdal-dev'" <gdal-dev at lists.osgeo.org>
> Message-ID: <01d201cab0c0$fc6afd80$f540f880$@roberts at duke.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> Many relational databases allow fields to be set to NULL. Is this supported
> in OGR? How does one detect whether a field is nullable or not?
>
>
>
> Looking at the class documentation, I see functions OGRFeature::IsFieldSet
> and OGRFeature::UnsetField. Are these intended for checking whether a field
> is NULL and setting it to NULL? Or are they used for something else, such as
> determining which fields have been modified by a caller prior to him calling
> OGRLayer::SetFeature?
>
>
>
> When I looked at OGRFieldDefn, I could not find a method that might be
> intended for checking whether a field was nullable (e.g.
> OGRFieldDefn::IsUnsettable).
>
>
>
> A while back, Mateusz asked this:
>
>
>
>> Yes. Also, most applications I've seen using OGR do define their own
>
>> data models and translate OGRFeature to features of their own types.
>
>> Perhaps it would be interesting to know why they don't use OGRFeature
>
>> as a part of their data model, what's missing...
>
>
>
> I am currently evaluating whether or not I should use OGRFeature directly in
> a data model, or wrap it. Without nullability, I am probably inclined to
> wrap it. As I have mentioned previously on gdal-dev, I'm trying to build
> something that wraps OGR and ArcGIS APIs behind a common abstraction, to
> allow development of tools that work with both. ArcGIS supports nullability
> and it is useful in many situations, so I'd like to cleanly preserve it in
> my abstraction, even if OGR does not presently support it.
>
>
>
> Thanks for any thoughts you have,
>
>
>
> Jason