[Gdal-dev] Geodatabase drive and layer types

[Craig Miller]

My mistake.  I meant wkbGeometryCollection not wkbGeometry.  While not
solving my particular problem I believe this is a more accurate description
of what is happening in the Personal Geodatabase driver right now.

Your suggestion for a method to get all possible types would be ideal.
Thinking out loud...
  
Pros:
- wkbMultiPoint layers won't be downgraded to wkbPoint.
- Many benefits for displaying layers in a GUI.
- Potentially low computational cost when type is known out-right, or is
known by observation (e.g. personal geodatabase point layer is mixed
wkbPoint and wkbMultiPoint).  Would wkbGeometryCollection layers return all
possible types or only the actual types in the layer?  The latter seems to
be more expensive.

Cons:
- Requires an implementation from all drivers.  Default implementation could
just return GetType() result.  
- Like #2, this seems potentially expensive to compute. 

--Craig


-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Tuesday, November 14, 2006 6:24 PM
To: Craig Miller
Cc: gdal-dev at lists.maptools.org
Subject: Re: [Gdal-dev] Geodatabase drive and layer types

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