[Gdal-dev] Geodatabase drive and layer types

[Frank Warmerdam]

Craig Miller wrote:
> The ESRI Geodatabase driver always returns wkbUnknown as the layer type.  It
> originally returned the type as described in the Geodatabase but when I
> discovered that some wkbPoint layers also had wkbMultipoints Frank updated
> the code to always return wkbUnknown.  At the time this seemed like the most
> reasonable solution.  Since then I've done a bit of thinking and have a few
> ideas for possible workarounds:
> 
> 3 separate ideas from the simplest to the most complex:
> 
> - Return wkbGeometry instead of wkbUnknown:  ESRI describes the datatype for
> each layer but then goes on to mix the datatype.  E.g. in a point layer you
> see point/multipoint values.  So, the description they provide is enough to
> confirm that it is in fact geometry in the table and not just tabular data.
> This seems to align better with the wkbGeometry type.
> 
> - Inspect Geometry:  Force the driver to inspect all geometry and decide for
> itself what the type is.  This is expensive, but is consistent with the
> layer extent function.  Once inspected it would be returned as wkbPoint,
> wkbMultipoint, etc, or wkbGeometry if mixed Type/multiType.
> 
> - Force to one type:  return the layer type as is described in the meta data
> table.  When fetching geometry the driver could automatically force the type
> to the one described.  This is my favorite because everything behaves as
> expected and is transparent to the user of OGR which is the primary reason
> for using a library like this (to get the same view onto all data sources).

Craig,

There is currently no such thing as wkbGeometry, and I'm leery about adding
new fake types.  Also, wkbGeometry doesn't really provide much additional
information over wkbUnknown.

I am really unwilling to read and process all geometries in the table.  This
is very expensive.  Note that layer type must be established at open time
when all the OGRLayer objects are initialized, so we would be faced with
reading every geometry in the database to establish all the layers types.
Ouch!  Note that layer extents are different in that the application has to
specifically ask for them.  We also provide means for applications to ask for
them only if they are cheap to compute.

Force to one type (ie. always promote to "multi" types) would be reasonable
but I have to think there are lots and lots of applications and even
OGR drivers that don't know how to handle geometry container types gracefully
or efficiently.  I'd really rather not have to do this though of the three
options I think it is the most plausible.

But I prefer to stick with option 4 which is don't indicate the geometry
type.

Perhaps we should consider adding a "return a list of possible concrete
geometry types" method that could be invoked on a layer as an extension?
This could return a list such as "wkbPoint,wkbMultiPoint".  It would give
applications that really want to know more about the geometry types that
occur something to call.  And potentially we could even scan the database
for some formats if appropriate.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org