[Gvsig_english] new problems with an oracle layer

Fri Jun 25 20:23:00 CEST 2010

Hello. It would also be very interesting to know the result of this:

SELECT SDO_UTIL.GETNUMVERTICES(c.SHAPE) FROM PLAN.GRUEN_POLY c WHERE c.OBJECTID = 57;

Regards

Juan Lucas Domínguez Rubio
---
Prodevelop SL, Valencia (España)
Tlf.: 96.351.06.12 -- Fax: 96.351.09.68
http://www.prodevelop.es <http://www.prodevelop.es/> 
---

________________________________

De: gvsig_internacional-bounces at listserv.gva.es en nombre de Juan Lucas Dominguez Rubio
Enviado el: vie 25/06/2010 13:23
Para: Users and Developers mailing list; gvsig_internacional at listserv.gva.es
Asunto: Re: [Gvsig_english] new problems with an oracle layer

Hello, Kornel. Thanks.

The .sql script you have sent has a lot of invalid geometries. For example, in the geometry with OBJECTID = 57, the coordinates array should have, at least, 193 + 2 = 195 numbers, but it only has 100, which besides, is not a multiple of 3 (it should be, because it's a 3D geometry).

I have not checked it fully, but it seems like the geometries of that .sql script were written with, at most, 100 numbers (33+1/3 vertices), which means that all the geometries with 34 vertices or more are incomplete and corrupt. This affects more than 200 geometries in that table.

My doubt now is: those geometries are really like that in the table or maybe the application that created the script did not work well?

I recommend you to talk to the DB administrator and ask him to export that table again into a new .sql text file with a very reliable application. The one I use is SqlDeveloper (see screenshot 'oracle_sql.png') but I guess you have better ones.

After you have exported the table as a .sql script again, check the row with OBJECTID = 57. It has a long array of numbers:

"SDO_ORDINATE_ARRAY"(x1, y1, 0, x2, y2, 0, x3, y3, 0...)

If that array (for OBJECTID = 57) has 100 numbers, then that geometry is corrupt, and all the table can be considered corrupt and you should find out how that table was created and what happened with the missing vertices.

If that array (for OBJECTID = 57) has 195 numbers or more, then please send me that new .sql script.

You also have a problem with the SRID code. 31468 is the EPSG code for the projection commonly used in Bavaria, but t's not a sensible SRID value in an Oracle Spatial table. There is a correspondence: EPSG:31468 is SRID = 82032. The database probably believes that you have invented a new SRID code (31468) and lets you use it at your own risk. This can be a problem if you ever try to execute an operation like this:

Select the geometries of table A which intersect with the geometry of table B which is associated with CITY = 'Rosenheim'

If table A has SRID = 31468 (wrong) and table B has SRID = 82032 (OK), then Oracle Spatial will say there is an error. Of course, you'll have problems too if someone reprojects those geometries to another coordinate system and is not aware of that mistake.

Regards,

Juan Lucas Domínguez Rubio
---
Prodevelop SL, Valencia (España)
Tlf.: 96.351.06.12 -- Fax: 96.351.09.68
http://www.prodevelop.es <http://www.prodevelop.es/> 
---

________________________________

De: gvsig_internacional-bounces at listserv.gva.es en nombre de K.Kiss
Enviado el: vie 25/06/2010 12:31
Para: gvsig_internacional at listserv.gva.es
Asunto: Re: [Gvsig_english] new problems with an oracle layer

Any comments about the error found during the export operation?
no, by the import to gvSIG

> Was it the same table?
yes all the same datasource.

> The table was correctly added to the view
no, the process to add this datasource to a new view failed.

I think you were going to send me the script that reproduces the Oracle
Spatial table PLAN.GRUEN_POLY. Will you please do it as soon as possible?

the insert-script is at
http://osgeo-org.1803224.n2.nabble.com/attachment/5208477/0/send2JL.zip.
And the create-Script is on the end of this mail.

I think this thread started with an error (while exporting an Oracle Spatial
table to SHP) reported by Wolfgang. Is it possible to send the that table
too? 

I think its the same table.

Hello,

yes it´s better not to publish all  our private datasources  (like
http://osgeo-org.1803224.n2.nabble.com/attachment/5208477/0/send2JL.zip).
Should be deleted please.

All produced exports either with one " ogr2ogr" or " Toad" produced. In the
archive " send2JL.zip" is the INSERT-script with in it.
After the export with " Toad" had still some " NULL,NULL... " are removed,
otherwise it did not run.

The table could not be imported  in gvsig into an view.

I do not hope we completely together past spoke

Regards
Kornel Kiss

DROP TABLE GRUEN_POLY CASCADE CONSTRAINTS
/

CREATE TABLE GRUEN_POLY
(
  OBJECTID          INTEGER                     NOT NULL,
  GE_CODE           NUMBER(11),
  TYP2              NUMBER(4),
  TYP3              NUMBER(4),
  GRUEN_GRUE        NUMBER(19,6),
  FLAECHE_HA        NUMBER(19,6),
  SHAPE             MDSYS.SDO_GEOMETRY,
  SE_ANNO_CAD_DATA  BLOB,
  OGR_FID           INTEGER                     NOT NULL
)
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING
/

CREATE INDEX I_GRUEN_PEN_POLY_GEOM ON GRUEN_POLY
(SHAPE)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS('initial=2M, next=1M, pctincrease=0, tablespace=OSC_IDX')
/

CREATE UNIQUE INDEX R2160_SDE_ROWID_UK ON GRUEN_POLY
(OGR_FID)
LOGGING
NOPARALLEL
/

-----
Kornel Kiss

Referat für Gesundheit und Umwelt
Anforderungsmanagement Fachanwendungen
Bayerstr. 28a
80335 München
--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/new-problems-with-an-oracle-layer-tp5190806p5221465.html
Sent from the gvSIG international mailing list archive at Nabble.com.
_______________________________________________
Gvsig_internacional mailing list
Gvsig_internacional at listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20100625/3d00b22d/attachment.htm 