<HTML><HEAD><TITLE>Re: [Gvsig_english] new problems with an oracle layer</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.17063" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText15619>
<DIV><FONT face="Times New Roman" color=#000000 size=3>Hello, Kornel. Thanks.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>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, </FONT><FONT face="Times New Roman" color=#000000 size=3>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).</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>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 </FONT><FONT face="Times New Roman" color=#000000 size=3>means that all the geometries with 34 vertices or more are incomplete and corrupt. This affects more than 200 geometries in that table.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>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?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>After you have exported the table as a .sql script again, check the row with OBJECTID = 57. It has a long array of numbers:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>"SDO_ORDINATE_ARRAY"(x1, y1, 0, x2, y2, 0, x3, y3, 0...)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>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 </FONT><FONT face="Times New Roman" color=#000000 size=3>created and what happened with the missing vertices.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>If that array (for OBJECTID = 57) has 195 numbers or more, then please send me that new .sql script.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>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 </FONT><FONT face="Times New Roman" color=#000000 size=3>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 </FONT><FONT face="Times New Roman" color=#000000 size=3>operation like this:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>Select the geometries of table A which intersect with the geometry of table B which is associated with CITY = 'Rosenheim'</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3>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.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=3></FONT> </DIV></DIV>
<DIV id=idSignature29752>
<DIV><FONT face="Courier New" size=2><FONT face="Times New Roman" size=3>Juan Lucas Domínguez Rubio<BR></FONT>---</FONT></DIV>
<DIV><FONT face="Courier New" size=2><FONT face="Courier New" size=2><FONT face="Courier New" size=2>Prodevelop SL, Valencia (España)</FONT></DIV>
<DIV>
<DIV><FONT face="Courier New" size=2>Tlf.: 96.351.06.12 -- Fax: 96.351.09.68<BR></FONT><A href="http://www.prodevelop.es/"><FONT face="Courier New" size=2>http://www.prodevelop.es</FONT></A><BR><FONT face="Courier New" size=2>---</FONT></DIV></FONT></DIV></FONT></DIV>
<DIV><BR>
<HR>
<FONT face=Tahoma size=2><B>De:</B> gvsig_internacional-bounces@listserv.gva.es en nombre de K.Kiss<BR><B>Enviado el:</B> vie 25/06/2010 12:31<BR><B>Para:</B> gvsig_internacional@listserv.gva.es<BR><B>Asunto:</B> Re: [Gvsig_english] new problems with an oracle layer<BR></FONT><BR></DIV>
<DIV><BR>
<P><FONT size=2>Any comments about the error found during the export operation?<BR>no, by the import to gvSIG<BR><BR>> Was it the same table?<BR>yes all the same datasource.<BR><BR>> The table was correctly added to the view<BR>no, the process to add this datasource to a new view failed.<BR><BR>I think you were going to send me the script that reproduces the Oracle<BR>Spatial table PLAN.GRUEN_POLY. Will you please do it as soon as possible?<BR><BR>the insert-script is at<BR><A href="http://osgeo-org.1803224.n2.nabble.com/attachment/5208477/0/send2JL.zip">http://osgeo-org.1803224.n2.nabble.com/attachment/5208477/0/send2JL.zip</A>.<BR>And the create-Script is on the end of this mail.<BR><BR>I think this thread started with an error (while exporting an Oracle Spatial<BR>table to SHP) reported by Wolfgang. Is it possible to send the that table<BR>too? <BR><BR>I think its the same table.<BR><BR><BR>Hello,<BR><BR>yes it´s better not to publish all our private datasources (like<BR><A href="http://osgeo-org.1803224.n2.nabble.com/attachment/5208477/0/send2JL.zip">http://osgeo-org.1803224.n2.nabble.com/attachment/5208477/0/send2JL.zip</A>).<BR>Should be deleted please.<BR><BR>All produced exports either with one " ogr2ogr" or " Toad" produced. In the<BR>archive " send2JL.zip" is the INSERT-script with in it.<BR>After the export with " Toad" had still some " NULL,NULL… " are removed,<BR>otherwise it did not run.<BR><BR>The table could not be imported in gvsig into an view.<BR><BR>I do not hope we completely together past spoke<BR><BR>Regards<BR>Kornel Kiss<BR><BR>DROP TABLE GRUEN_POLY CASCADE CONSTRAINTS<BR>/<BR><BR>CREATE TABLE GRUEN_POLY<BR>(<BR> OBJECTID INTEGER NOT NULL,<BR> GE_CODE NUMBER(11),<BR> TYP2 NUMBER(4),<BR> TYP3 NUMBER(4),<BR> GRUEN_GRUE NUMBER(19,6),<BR> FLAECHE_HA NUMBER(19,6),<BR> SHAPE MDSYS.SDO_GEOMETRY,<BR> SE_ANNO_CAD_DATA BLOB,<BR> OGR_FID INTEGER NOT NULL<BR>)<BR>LOGGING<BR>NOCOMPRESS<BR>NOCACHE<BR>NOPARALLEL<BR>MONITORING<BR>/<BR><BR>CREATE INDEX I_GRUEN_PEN_POLY_GEOM ON GRUEN_POLY<BR>(SHAPE)<BR>INDEXTYPE IS MDSYS.SPATIAL_INDEX<BR>PARAMETERS('initial=2M, next=1M, pctincrease=0, tablespace=OSC_IDX')<BR>/<BR><BR>CREATE UNIQUE INDEX R2160_SDE_ROWID_UK ON GRUEN_POLY<BR>(OGR_FID)<BR>LOGGING<BR>NOPARALLEL<BR>/<BR><BR>-----<BR>Kornel Kiss<BR><BR>Referat für Gesundheit und Umwelt<BR>Anforderungsmanagement Fachanwendungen<BR>Bayerstr. 28a<BR>80335 München<BR>--<BR>View this message in context: <A href="http://osgeo-org.1803224.n2.nabble.com/new-problems-with-an-oracle-layer-tp5190806p5221465.html">http://osgeo-org.1803224.n2.nabble.com/new-problems-with-an-oracle-layer-tp5190806p5221465.html</A><BR>Sent from the gvSIG international mailing list archive at Nabble.com.<BR>_______________________________________________<BR>Gvsig_internacional mailing list<BR>Gvsig_internacional@listserv.gva.es<BR><A href="http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional">http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional</A><BR></FONT></P></DIV></BODY></HTML>