[Gdal-dev] OCI-22165 index out-of-range appending PGDB -> Oracle Spatial

Frank Warmerdam warmerdam at pobox.com
Sat Jan 21 10:45:22 EST 2006


On 1/20/06, Dave Fuhry <dfuhry at gmail.com> wrote:
>    It looks like BoundCreateFeature() truncates oversized arrays
> whereas UnboundCreateFeature() causes them to throw an OCI-22165
> exception.  I can't think of any way to improve OGR in this situation
> since any such geometry is going to be way out of the norm.  Even a
> check on (nElemInfoCount > 1048575) could get stale if Oracle decides
> to up the size of those VARRAYS someday.  I'll just leave this
> information in your hands.

Dave,

I suspect that BoundCreateFeature() is getting back errors as it
grows the arrays, but is ignoring them, hence the truncation.   I
don't see any obvious action for me to take.  If you do need to
append features to an existing table, you might want to try using
the -skipfailures flag to ogr2ogr.  This should mean the translation
continues after the one really big feature fails.

>    Thanks for your help.  Support for ESRI Personal Geodatabase export
> in particular is saving us a lot of time and runaround.  If SDE BLOB
> data is stored similarly, I would be excited to have that exportable
> via ODBC someday.

Sweet.

I have recently implement read support for SDE, but it is based on
the ESRI SDE API rather than going through ODBC.  I have established
the binary format for SDE geometries is not the same as in the personal
geodatabase.  And in fact there are several formats for geometry in
SDE depending on the underlying database.

It should be possible to do SDE via ODBC too, but it would be
quite a bit of work.

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    | Geospatial Programmer for Rent




More information about the Gdal-dev mailing list