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" <[email protected]> > Subject: [gdal-dev] Nullable fields in OGR > To: "'gdal-dev'" <[email protected]> > Message-ID: <01d201cab0c0$fc6afd80$f540f8...@[email protected]> > 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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
