[Gdal-dev] Geodatabase drive and layer types

Frank Warmerdam warmerdam at pobox.com
Wed Nov 15 11:03:04 EST 2006

Craig Miller wrote:
> 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.


Note - I had expected to have to go the other way, promoting points
to multipoint.

> - 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.

This is a bit uncertain.  Do we want to restrict drivers to only returning
the types that *actually* appear in a layer?  Or to try?  For instance for
our geodatabase case I would expect it to return wkbPoint + wkbMultiPoint even
if no actual multipoints occured.

> Cons:
> - Requires an implementation from all drivers.  Default implementation could
> just return GetType() result.  

Note, we can easily supply a default implementation that returns the existing
layer type if it is specific or else falls back to scanning the layer.  So
we would only need to implement it for drivers that can do something smarter.

> - Like #2, this seems potentially expensive to compute. 

I think the key is that expensive computation is deferred to a method that
only applications that really care would call.  Rather than paying it for
all layers up front at open time.

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

More information about the Gdal-dev mailing list