[GRASS5] v.external, OGR/OCI and v.in.ogr

[Stephan Holl]

Hello Radim, Frank,

On Fri, 9 Dec 2005 11:49:10 +0100 Radim Blazek <radim.blazek at gmail.com>
wrote:

> It seems to be a bug in Oracle driver for OGR.
> FID is assigned to features by OGR and it is different for
> each driver. It has nothing to do with GRASS.

I see. You already have CCed this to Frank. 

But why does ogr2ogr work from shapefile to Oracle correctly?

Stephan

> 
> On 12/9/05, Stephan Holl <holl at gdf-hannover.de> wrote:
> > Hello Radim,
> >
> > On Fri, 9 Dec 2005 09:15:46 +0100 Radim Blazek
> > <radim.blazek at gmail.com> wrote:
> >
> > > On 12/9/05, Stephan Holl <holl at gdf-hannover.de> wrote:
> > > > I cannot understand the above thing about topology-info. In
> > > > short, Linked OCI-based dataset with v.external does not show
> > > > in the display unless I remove the topo-file. But then nearly
> > > > no other vector-modules are working.
> > > >
> > > > Is this a Bug or a feature?!
> > >
> > > On level 2 (with topo) the elements are accessed using OGR FID,
> > > I have seen in you debug output that all all lines have FID 1.
> > > You should check (ogrinfo) if OGR gives unique FID
> > > (the number following 'OGRFeature(layer):') for each feature.
> >
> > Aha! Here it is! every OGRFeature is 1.
> >
> > OGRFeature(ROADS_SPEARFISH60):1
> >   cat (Integer) = 4
> >   label (String) = light-duty road, improved surface
> >   column3 (Integer) = 0
> >   LINESTRING (601071.341320500010625 4914275.983005239628255
> > 0,601130.543313059955835 4914239.814913230016828
> > 0,601199.645887729944661 4914209.641895060427487 0)
> >
> > OGRFeature(ROADS_SPEARFISH60):1
> >   cat (Integer) = 4
> >   label (String) = light-duty road, improved surface
> >   column3 (Integer) = 0
> >   LINESTRING (601229.638940269942395 4914208.033029629848897
> > 0,601199.645887729944661 4914209.641895060427487 0)
> >
> > OGRFeature(ROADS_SPEARFISH60):1
> >   cat (Integer) = 5
> >   label (String) = unimproved road
> >   column3 (Integer) = 0
> >   LINESTRING (601383.701443820027635 4914490.324604500085115
> > 0,601458.067195220035501 4914506.784756160341203
> > 0,601565.896428929991089 4914540.368791960179806
> > 0,601619.450047809979878 4914568.157080279663205
> > 0,601705.821419609943405 4914621.78729119990021
> > 0,601777.390685699996538 4914706.498295440338552
> > 0,601829.976874400046654 4914804.547851240262389
> > 0,601874.278788840048946 4914851.838009960018098
> > 0,601905.941478710039519 4914864.842336039990187
> > 0,601938.245388729963452 4914871.740031310357153
> > 0,601989.454707090044394 4914880.574088539928198
> > 0,602015.031405410030857 4914890.490086000412703 0)
> >
> > OGRFeature(ROADS_SPEARFISH60):1
> > [...]
> >
> > So I have to blame v.out.ogr for not exporting the data
> > correctly into oracle?!
> >
> > OK, trying to export into shp and import shape into oracle via
> > ogr2ogr: v.out.ogr in=roads dsn=/tmp olayer=roads_spearfish_shp
> >
> > ogrinfo -al roads_spearfish_shp.shp
> >
> > OGRFeature(roads_spearfish_shp):822
> >   cat (Real) =           1
> >   label (String) = interstate
> >   column3 (Real) =           0
> >   LINESTRING (608461.963513449998572
> > 4924891.454097949899733,608500.583600339945406
> > 4924848.395944519899786,608542.302375869941898
> > 4924805.986163049936295,608588.929304940043949
> > 4924753.627536799758673,608679.141620320035145
> > 4924655.828847349621356)
> >
> > OGRFeature(roads_spearfish_shp):823
> >   cat (Real) =           3
> >   label (String) = secondary highway, hard surface
> >   column3 (Real) =           0
> >   LINESTRING (608499.937198620056733
> > 4924995.604408769868314,608461.963730340008624
> > 4924891.45383136998862)
> >
> > OGRFeature(roads_spearfish_shp):824
> >
> > Seems to export OK into shp.
> >
> > Will now try with ogr2ogr and see what happens then.
> >
> > ogr2ogr -f OCI "OCI:holl/pw at ORACLESP" roads_spearfish_shp.shp
> >
> > ogrinfo -ro "OCI:holl/n8eulen at ORACLESP" ROADS_SPEARFISH_SHP
> >
> > OGRFeature(ROADS_SPEARFISH_SHP):805
> >   cat (Integer) = 1
> >   label (String) = interstate
> >   column3 (Integer) = 0
> >   LINESTRING (599766.326235549990088 4925326.424210700206459
> > 0,599779.949210750055499 4925333.039808190427721
> > 0,599819.86159005004447 4925357.376621429808438
> > 0,599920.882107450044714 4925416.319270299747586
> > 0,599964.417756509967148 4925443.534300420433283
> > 0,600159.730849539977498 4925569.802055209875107 0)
> >
> > OGRFeature(ROADS_SPEARFISH_SHP):806
> >   cat (Integer) = 2
> >   label (String) = primary highway, hard surface
> >   column3 (Integer) = 0
> >   LINESTRING (600184.343943119980395 4925585.71580228023231
> > 0,600169.898571319994517 4925605.305413190275431 0)
> >
> > OGRFeature(ROADS_SPEARFISH_SHP):807
> >   cat (Integer) = 2
> >
> > Seems to be OK as well.
> >
> > So I assume that v.out.ogr does not produce unique
> > OGRFeature-numbers when Importing directly into Oracle using OCI.
> >
> > Can anybody confirm?
> >
> > Best
> >         Stephan
> >
> > --
> > GDF Hannover - Solutions for spatial data analysis and remote
> > sensing Hannover Office      -     Mengendamm 16d      -
> > D-30177 Hannover Internet: www.gdf-hannover.de      -      Email:
> > holl at gdf-hannover.de Phone : ++49-(0)511.39088507       -
> > Fax: ++49-(0)511.39088508
> >


-- 
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office      -     Mengendamm 16d      -     D-30177 Hannover
Internet: www.gdf-hannover.de      -      Email: holl at gdf-hannover.de
Phone : ++49-(0)511.39088507       -        Fax: ++49-(0)511.39088508