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

[Dave Fuhry]

Frank,

ogr2ogr -f OCI OCI:taxmap/taxmap1 LB011.mdb StreetCenterline -lco
MULTI_LOAD=YES -lco INDEX=OFF
succeeds where
C:\PGDB-12202005>ogr2ogr -f OCI OCI:taxmap/taxmap1 LB011.mdb StreetCenterline -l
co MULTI_LOAD=NO -lco INDEX=OFF
fails.

   I located the offending geometry.  I'm not sure how to return the
exact element count of an extended VARRAY but its
SDO_UTIL.GETNUMVERTICES(ORA_GEOMETRY) is 349525.333.  Since I'm
loading in 3D it looks like the number of coordinates allowed is at
its max.  I don't have Arc* handy to determine the number of vertices
it really has, although I could check on this if you'd like.  Its
SHAPE_Length is 124806671.920244 which is way out of whack with the
rest of the features in this state plane coordinate system, so I'm
going to consider it bogus.

   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.

   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.

-Dave Fuhry

On 1/20/06, Frank Warmerdam <warmerdam at pobox.com> wrote:
> On 1/20/06, Dave Fuhry <dfuhry at gmail.com> wrote:
> > When appending a personal geodatabase to an Oracle Spatial table with
> > the following command:
> >
> > C:\PGDB-12202005>ogr2ogr -update -append -f OCI OCI:taxmap/taxmap1
> > LB011.mdb StreetCenterline -lco INDEX=OFF
> >
> > I get this error:
> >
> > ERROR 1: OCI-22165: given index [1048576] must be in the range of [0]
> > to [1048575]
> >  in OCICollAppend
> > ERROR 1: Terminating translation prematurely after failed
> >
> > Without the " -update -append" it works fine.  I'm getting a little
> > lost in the OCI code but it looks like the error occurs in
> > ogrocitablelayer.cpp, line 1025 in the OCICollAppend() method call,
> > which OCI docs say appends an element to a collection (which would be
> > an SDO_ELEM_INFO_ARRAY or SDO_ORDINATE_ARRAY in out case).
> >
> > This Intergraph GeoMedia FAQ entry
> > http://support.intergraph.com/geomedia/faq.asp#97 indicates that the
> > number of coordinates I'm trying to add may be maxing out the number
> > allowed in an Oracle SDO array.  But why would it work ok creating a
> > table but fail for an append?  I tried the command without "-update"
> > and it fails then too.
>
> Dave,
>
> There are two implementations of CreateFeature().
> One creates a complete textual INSERT statement
> while the other uses bound variables for some objects,
> including the geometry.  I suspect that creating a new
> layer is using the "unbound", and the append is
> using the "bound" method.  But I'm not exactly sure
> why this would be.  Looking through the code, the
> MULTI_LOAD option controls this.  Are you using
> that by any chance?  Note that layer creation options
> are ignored in the -append case since the layer isn't
> actually being created.
>
> Do you have a geometry with more than a million
> vertices?
>
> 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
>