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

Stephan_Holl1 · December 2, 2005, 8:01am

Dear list,

I tried to import a vector-dataset from Oracle-spatial using the OGR
OCI-bindings.

First export the spearfish-rioads to Oracle
using v.out.ogr, which works OK. ogrinfo gives all information, that
everything is fine.

Now I want to reuse the dataset using v.external:
v.external dsn=OCI:user/pw@ORACLESP out=roads_OCI
layer=ROADS_SPEARFISH60

This seems to work OK, also v.db.select roads_OCI gives appropriate
output.

But when I try to display the dataset, only one line is shown, but no
error is given.

When I reimport it in GRASS using v.in.ogr and display the imported
dataset, then all lines are shown on the display...

v.in.ogr -o dsn=OCI:user/pw@ORACLESP out=roads_OCI_import
layer=ROADS_SPEARFISH60 type=line

A debugging-Output (DEBUG=5) is copied here[1].

Thanks for any pointers how to solve this problem.

Best
Stephan

[1]
http://www.gdf-hannover.de/holl/tmp/output_DEBUG5.dvect_OCI_v.external

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

Radim_Blazek3 · December 2, 2005, 8:38am

The problem is obviously missing FID. Try 2 things
1) remove topo file and try to run d.vect
2) try to add FID column (unique id) to the table

Radim

On 12/2/05, Stephan Holl <holl@gdf-hannover.de> wrote:

Dear list,

I tried to import a vector-dataset from Oracle-spatial using the OGR
OCI-bindings.

First export the spearfish-rioads to Oracle
using v.out.ogr, which works OK. ogrinfo gives all information, that
everything is fine.

Now I want to reuse the dataset using v.external:
v.external dsn=OCI:user/pw@ORACLESP out=roads_OCI
layer=ROADS_SPEARFISH60

This seems to work OK, also v.db.select roads_OCI gives appropriate
output.

But when I try to display the dataset, only one line is shown, but no
error is given.

When I reimport it in GRASS using v.in.ogr and display the imported
dataset, then all lines are shown on the display...

v.in.ogr -o dsn=OCI:user/pw@ORACLESP out=roads_OCI_import
layer=ROADS_SPEARFISH60 type=line

A debugging-Output (DEBUG=5) is copied here[1].

Thanks for any pointers how to solve this problem.

Best
Stephan

[1]
http://www.gdf-hannover.de/holl/tmp/output_DEBUG5.dvect_OCI_v.external

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

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

Stephan_Holl1 · December 2, 2005, 9:13am

Hello Radim,

thanks for the quick response.

On Fri, 2 Dec 2005 09:38:54 +0100 Radim Blazek <radim.blazek@gmail.com>
wrote:

The problem is obviously missing FID. Try 2 things
1) remove topo file and try to run d.vect

Yes, after removing the topo-file d.vect shows up the vector-lines, but
v.info complains about the missing topo-file.
ERROR: Cannot open old vector roads_OCI@user1 on level 2

Is this a bug or a feature?

2) try to add FID column (unique id) to the table

Isnt that the job of v.external when "importing/linking"? AFAIK a unique
colums is in the table:
v.db.select roads_OCI|head
ERROR 1: ORA-00904: "FID": invalid identifier
in select FID from ROADS_SPEARFISH60_2 where FID > 0
ERROR 1: ORA-00904: "OGC_FID": invalid identifier
in select ogc_fid from ROADS_SPEARFISH60_2 where ogc_fid > 0
Using ogr_fid column in OGR DB
OGR_FID|cat|label|column3
1|5|unimproved road|0
1|5|unimproved road|0
1|5|unimproved road|0
1|5|unimproved road|0
1|5|unimproved road|0
1|5|unimproved road|0
1|4|light-duty road, improved surface|0
1|5|unimproved road|0
1|5|unimproved road|0
GRASS 6.1.cvs (spearfish60):~/spearfish60/user1/vector/roads_OCI >

Thanks for looking into this.

Best

Stephan

Radim

On 12/2/05, Stephan Holl <holl@gdf-hannover.de> wrote:
> Dear list,
>
> I tried to import a vector-dataset from Oracle-spatial using the OGR
> OCI-bindings.
>
> First export the spearfish-rioads to Oracle
> using v.out.ogr, which works OK. ogrinfo gives all information, that
> everything is fine.
>
> Now I want to reuse the dataset using v.external:
> v.external dsn=OCI:user/pw@ORACLESP out=roads_OCI
> layer=ROADS_SPEARFISH60
>
> This seems to work OK, also v.db.select roads_OCI gives appropriate
> output.
>
> But when I try to display the dataset, only one line is shown, but
> no error is given.
>
> When I reimport it in GRASS using v.in.ogr and display the imported
> dataset, then all lines are shown on the display...
>
> v.in.ogr -o dsn=OCI:user/pw@ORACLESP out=roads_OCI_import
> layer=ROADS_SPEARFISH60 type=line
>
> A debugging-Output (DEBUG=5) is copied here[1].
>
> Thanks for any pointers how to solve this problem.
>
> Best
> Stephan
>
> [1]
> http://www.gdf-hannover.de/holl/tmp/output_DEBUG5.dvect_OCI_v.external
>
> --
> GDF Hannover - Solutions for spatial data analysis and remote
> sensing Hannover Office - Mengendamm 16d -
> D-30177 Hannover Internet: www.gdf-hannover.de - Email:
> holl@gdf-hannover.de Phone : ++49-(0)511.39088507 -
> Fax: ++49-(0)511.39088508
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>

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

Stephan_Holl1 · December 9, 2005, 7:26am

Hello Radim,

On Fri, 2 Dec 2005 10:13:51 +0100 Stephan Holl <holl@gdf-hannover.de>
wrote:

Hello Radim,

thanks for the quick response.

On Fri, 2 Dec 2005 09:38:54 +0100 Radim Blazek
<radim.blazek@gmail.com> wrote:

> The problem is obviously missing FID. Try 2 things
> 1) remove topo file and try to run d.vect

Yes, after removing the topo-file d.vect shows up the vector-lines,
but v.info complains about the missing topo-file.
ERROR: Cannot open old vector roads_OCI@user1 on level 2

Is this a bug or a feature?

> 2) try to add FID column (unique id) to the table

Isnt that the job of v.external when "importing/linking"? AFAIK a
unique colums is in the table:
v.db.select roads_OCI|head
ERROR 1: ORA-00904: "FID": invalid identifier
in select FID from ROADS_SPEARFISH60_2 where FID > 0
ERROR 1: ORA-00904: "OGC_FID": invalid identifier
in select ogc_fid from ROADS_SPEARFISH60_2 where ogc_fid > 0
Using ogr_fid column in OGR DB
OGR_FID|cat|label|column3
1|5|unimproved road|0
1|5|unimproved road|0
1|5|unimproved road|0
1|5|unimproved road|0
1|5|unimproved road|0
1|5|unimproved road|0
1|4|light-duty road, improved surface|0
1|5|unimproved road|0
1|5|unimproved road|0
GRASS 6.1.cvs (spearfish60):~/spearfish60/user1/vector/roads_OCI >

Thanks for looking into this.

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?!

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@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

Radim_Blazek3 · December 9, 2005, 8:15am

On 12/9/05, Stephan Holl <holl@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.

Radim

Stephan_Holl1 · December 9, 2005, 10:38am

Hello Radim,

On Fri, 9 Dec 2005 09:15:46 +0100 Radim Blazek <radim.blazek@gmail.com>
wrote:

On 12/9/05, Stephan Holl <holl@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@ORACLESP" roads_spearfish_shp.shp

ogrinfo -ro "OCI:holl/n8eulen@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@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

Radim_Blazek3 · December 9, 2005, 10:49am

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.

Radim

On 12/9/05, Stephan Holl <holl@gdf-hannover.de> wrote:

Hello Radim,

On Fri, 9 Dec 2005 09:15:46 +0100 Radim Blazek <radim.blazek@gmail.com>
wrote:

> On 12/9/05, Stephan Holl <holl@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@ORACLESP" roads_spearfish_shp.shp

ogrinfo -ro "OCI:holl/n8eulen@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@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

Stephan_Holl1 · December 9, 2005, 10:53am

Hello Radim, Frank,

On Fri, 9 Dec 2005 11:49:10 +0100 Radim Blazek <radim.blazek@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@gdf-hannover.de> wrote:
> Hello Radim,
>
> On Fri, 9 Dec 2005 09:15:46 +0100 Radim Blazek
> <radim.blazek@gmail.com> wrote:
>
> > On 12/9/05, Stephan Holl <holl@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@ORACLESP" roads_spearfish_shp.shp
>
> ogrinfo -ro "OCI:holl/n8eulen@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@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@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

Radim_Blazek3 · December 12, 2005, 8:11am

On 12/9/05, Stephan Holl <holl@gdf-hannover.de> wrote:

Hello Radim, Frank,

On Fri, 9 Dec 2005 11:49:10 +0100 Radim Blazek <radim.blazek@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?

How the tables differ? ogr2ogr probably adds a column
which is then used as FID. But that is not something v.out.ogr
should do, in my opinion!

Radim

Stephan_Holl1 · December 12, 2005, 8:38am

Hello Radim,

On Mon, 12 Dec 2005 09:11:21 +0100 Radim Blazek
<radim.blazek@gmail.com> wrote:

On 12/9/05, Stephan Holl <holl@gdf-hannover.de> wrote:
> Hello Radim, Frank,
>
> On Fri, 9 Dec 2005 11:49:10 +0100 Radim Blazek
> <radim.blazek@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?

How the tables differ? ogr2ogr probably adds a column
which is then used as FID. But that is not something v.out.ogr
should do, in my opinion!

gdf@linux:~> ogrinfo -ro "OCI:holl/pw@ORACLESP" ROADS_SPEARFISH60
-summary
INFO: Open of `OCI:holl/pw@ORACLESP'
using driver `OCI' successful.

Layer name: ROADS_SPEARFISH60
Geometry: Unknown (any)
Feature Count: 825
Extent: (589434.856469, 4914006.337837) - (609527.210215,
4928063.398015) Layer SRS WKT:
PROJCS["UTM Zone 13, Northern Hemisphere",
    GEOGCS["clark66",
        DATUM["North_American_Datum_1927",
            SPHEROID["clark66",6378206.4,294.9786982]],
        PRIMEM["Greenwich",0],
        UNIT["Decimal Degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-105],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["meter",1]]
cat: Integer (0.0)
label: String (2047.0)
column3: Integer (0.0)
gdf@linux:~> ogrinfo -ro "OCI:holl/pw@ORACLESP"
ROADS_SPEARFISH_SHP -summary
INFO: Open of `OCI:holl/pw@ORACLESP' using driver `OCI' successful.

Layer name: ROADS_SPEARFISH_SHP
Geometry: Unknown (any)
Feature Count: 825
Extent: (589434.856469, 4914006.337837) - (609527.210215,
4928063.398015) Layer SRS WKT:
PROJCS["UTM Zone 13, Northern Hemisphere",
    GEOGCS["clark66",
        DATUM["North_American_Datum_1927",
            SPHEROID["clark66",6378206.4,294.9786982]],
        PRIMEM["Greenwich",0],
        UNIT["Decimal Degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-105],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["meter",1]]
cat: Integer (11.0)
label: String (80.0)
column3: Integer (11.0)
gdf@linux:~>

When I log into Oracle, both datasets habe the same FID-colum
(OGR_FID), but the one GRASS created is always 1 and does not increment.

I am stuck.

Where should I start searching for the errors?

Thanks

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@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

Radim_Blazek3 · December 12, 2005, 12:07pm

When I log into Oracle, both datasets habe the same FID-colum
(OGR_FID), but the one GRASS created is always 1 and does not increment.

I am stuck.

Where should I start searching for the errors?

Probably missing OGRFeature::SetFID in v.out.ogr.

Radim

Stephan_Holl1 · December 12, 2005, 1:23pm

Hello Radim,

On Mon, 12 Dec 2005 13:07:57 +0100 Radim Blazek
<radim.blazek@gmail.com> wrote:

> When I log into Oracle, both datasets habe the same FID-colum
> (OGR_FID), but the one GRASS created is always 1 and does not
> increment.
>
> I am stuck.
>
> Where should I start searching for the errors?

Probably missing OGRFeature::SetFID in v.out.ogr.

Are you going to look into this? I am no programmer and do not know
where to insert this.

Thanks in advance

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@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

Radim_Blazek3 · December 12, 2005, 6:25pm

On 12/12/05, Stephan Holl <holl@gdf-hannover.de> wrote:

Hello Radim,

On Mon, 12 Dec 2005 13:07:57 +0100 Radim Blazek
<radim.blazek@gmail.com> wrote:

> > When I log into Oracle, both datasets habe the same FID-colum
> > (OGR_FID), but the one GRASS created is always 1 and does not
> > increment.
> >
> > I am stuck.
> >
> > Where should I start searching for the errors?
>
> Probably missing OGRFeature::SetFID in v.out.ogr.

Are you going to look into this?

Not now.

I am no programmer and do not know
where to insert this.

Not difficult, use GRASS internal line and area+Vect_get_num_lines() numbers.

Radim

Stephan_Holl1 · December 13, 2005, 7:53am

Hello Radim,

On Mon, 12 Dec 2005 19:25:17 +0100 Radim Blazek
<radim.blazek@gmail.com> wrote:

On 12/12/05, Stephan Holl <holl@gdf-hannover.de> wrote:
> Hello Radim,
>
> On Mon, 12 Dec 2005 13:07:57 +0100 Radim Blazek
> <radim.blazek@gmail.com> wrote:
>
> > > When I log into Oracle, both datasets habe the same FID-colum
> > > (OGR_FID), but the one GRASS created is always 1 and does not
> > > increment.
> > >
> > > I am stuck.
> > >
> > > Where should I start searching for the errors?
> >
> > Probably missing OGRFeature::SetFID in v.out.ogr.
>
> Are you going to look into this?

Not now.

No problem. I will wait. Do you want me to fill a bug-report so that
we do not forget this?

> I am no programmer and do not know
> where to insert this.

Not difficult, use GRASS internal line and area+Vect_get_num_lines()
numbers.

Thanks, but not for me I leave that to someone with more
knowlegde...

Gruß

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@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

Radim_Blazek3 · December 13, 2005, 8:19am

On 12/13/05, Stephan Holl <holl@gdf-hannover.de> wrote:

> > > Probably missing OGRFeature::SetFID in v.out.ogr.
> >
> > Are you going to look into this?
>
> Not now.

No problem. I will wait. Do you want me to fill a bug-report so that
we do not forget this?

Yes.
But I don't read bugtracker, it is full of wishes and misunderstandings
and occasionaly somebody is using that as his diary/blog.

Radim

Maciej_Sieczka3 · December 13, 2005, 9:48am

On wto, 2005-12-13 at 09:19 +0100, Radim Blazek wrote:

On 12/13/05, Stephan Holl <holl@gdf-hannover.de> wrote:
> > > > Probably missing OGRFeature::SetFID in v.out.ogr.
> > >
> > > Are you going to look into this?
> >
> > Not now.
>
> No problem. I will wait. Do you want me to fill a bug-report so that
> we do not forget this?

Yes.
But I don't read bugtracker,
it is full of wishes

Please use the Area->grass6.

and misunderstandings

I agree there are but it's anavoidable I'm affraid, at least I think so.

and occasionaly somebody is using that as his diary/blog.

Who do you mean? Which reports? I'm (slowly) cleaning the BT. Do you
have any suggestions?

Maciek

--------------------
W polskim Internecie s± setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.epf.pl/

Stephan_Holl1 · December 13, 2005, 9:59am

Hello Maciek, Radim,

On Tue, 13 Dec 2005 10:48:24 +0100 Maciek Sieczka <werchowyna@epf.pl>
wrote:

On wto, 2005-12-13 at 09:19 +0100, Radim Blazek wrote:
> On 12/13/05, Stephan Holl <holl@gdf-hannover.de> wrote:
> > > > > Probably missing OGRFeature::SetFID in v.out.ogr.
> > > >
> > > > Are you going to look into this?
> > >
> > > Not now.
> >
> > No problem. I will wait. Do you want me to fill a bug-report so
> > that we do not forget this?
>
> Yes.
> But I don't read bugtracker,
> it is full of wishes

Please use the Area->grass6.

Yes, thanks for the hint.

> and misunderstandings

I agree there are but it's anavoidable I'm affraid, at least I think
so.

> and occasionaly somebody is using that as his diary/blog.

Who do you mean? Which reports? I'm (slowly) cleaning the BT. Do you
have any suggestions?

First, thanks for cleaning up the bugtracker! It is quite more useable
now. If it is OK, I will CC this bug to Radim?!

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@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

Radim_Blazek3 · December 13, 2005, 10:15am

On 12/13/05, Maciek Sieczka <werchowyna@epf.pl> wrote:

> But I don't read bugtracker,
> it is full of wishes

Please use the Area->grass6.

> and misunderstandings

I agree there are but it's anavoidable I'm affraid, at least I think so.

> and occasionaly somebody is using that as his diary/blog.

Who do you mean? Which reports? I'm (slowly) cleaning the BT. Do you
have any suggestions?

Thanks, area grass6 looks better, but still many bug can be moved to wish6
for example this is not bug in my opinion:
http://intevation.de/rt/webrt?serial_num=2768&display=History

Radim

Maciej_Sieczka3 · December 13, 2005, 10:36am

On wto, 2005-12-13 at 11:15 +0100, Radim Blazek wrote:

On 12/13/05, Maciek Sieczka <werchowyna@epf.pl> wrote:
> > But I don't read bugtracker,
> > it is full of wishes
>
> Please use the Area->grass6.
>
> > and misunderstandings
>
> I agree there are but it's anavoidable I'm affraid, at least I think so.
>
> > and occasionaly somebody is using that as his diary/blog.
>
> Who do you mean? Which reports? I'm (slowly) cleaning the BT. Do you
> have any suggestions?

Thanks, area grass6 looks better, but still many bug can be moved to wish6
for example this is not bug in my opinion:
http://intevation.de/rt/webrt?serial_num=2768&display=History

Done. I'll try to think less like "a demanding user" and more like "an
overworked developer" from now on, Cheers.

It would be cool if we had a grass6_doc_bug and grass6_doc_wish types.
It will be easier for those willing to improve the documentation to find
cases to work on. I'm goinng to be interested, some day.

Can abybody say if it is doable? I guess we should ask Bernhard Reiter,
ccing him.

Maciek

--------------------
W polskim Internecie s± setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.epf.pl/

Bernhard_Reiter · December 13, 2005, 11:39am

On Tue, Dec 13, 2005 at 11:36:16AM +0100, Maciek Sieczka wrote:

It would be cool if we had a grass6_doc_bug and grass6_doc_wish types.
It will be easier for those willing to improve the documentation to find
cases to work on. I'm goinng to be interested, some day.

Can abybody say if it is doable? I guess we should ask Bernhard Reiter,
ccing him.

I have just created the areas:
doc-grass6
doc-wish-grass6

Hope it is helpful.
Note that beside people at Intevation,
Markus also can create or delete areas.

Bernhard