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

Stephan Holl holl at gdf-hannover.de
Fri Dec 9 05:38:35 EST 2005


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




More information about the grass-dev mailing list