<HTML><HEAD><TITLE>Re: [Gvsig_english] new problems with an oracle layer</TITLE>
<META content="text/html; charset=unicode" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18372"></HEAD>
<BODY>
<DIV id=idOWAReplyText37665>
<DIV><FONT color=#000000 size=3 face="Times New Roman">Hello. It would also be very interesting to know the result of this:</FONT></DIV>
<DIV> </DIV>
<DIV>SELECT SDO_UTIL.GETNUMVERTICES(c.SHAPE) FROM PLAN.GRUEN_POLY c WHERE c.OBJECTID = 57;</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Regards</DIV>
<DIV><FONT color=#000000 size=3 face="Times New Roman"></FONT> </DIV></DIV>
<DIV id=idSignature37707>
<DIV><FONT size=2 face="Courier New"><FONT size=3 face="Times New Roman">Juan Lucas Domínguez Rubio<BR></FONT>---</FONT></DIV>
<DIV><FONT size=2 face="Courier New"><FONT size=2 face="Courier New"><FONT size=2 face="Courier New">Prodevelop SL, Valencia (España)</FONT></DIV>
<DIV>
<DIV><FONT size=2 face="Courier New">Tlf.: 96.351.06.12 -- Fax: 96.351.09.68<BR></FONT><A href="http://www.prodevelop.es/"><FONT size=2 face="Courier New">http://www.prodevelop.es</FONT></A><BR><FONT size=2 face="Courier New">---</FONT></DIV></FONT></DIV></FONT></DIV>
<DIV><BR>
<HR>
<FONT size=2 face=Tahoma><B>De:</B> gvsig_internacional-bounces@listserv.gva.es en nombre de Juan Lucas Dominguez Rubio<BR><B>Enviado el:</B> vie 25/06/2010 13:23<BR><B>Para:</B> Users and Developers mailing list; gvsig_internacional@listserv.gva.es<BR><B>Asunto:</B> Re: [Gvsig_english] new problems with an oracle layer<BR></FONT><BR></DIV>
<DIV>
<DIV id=idOWAReplyText15619>
<DIV><FONT color=#000000 size=3 face="Times New Roman">Hello, Kornel. Thanks.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">"SDO_ORDINATE_ARRAY"(x1, y1, 0, x2, y2, 0, x3, y3, 0...)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">created and what happened with the missing vertices.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">operation like this:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman">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 color=#000000 size=3 face="Times New Roman"></FONT> </DIV></DIV>
<DIV id=idSignature29752>
<DIV><FONT size=2 face="Courier New"><FONT size=3 face="Times New Roman">Juan Lucas Domínguez Rubio<BR></FONT>---</FONT></DIV>
<DIV><FONT size=2 face="Courier New"><FONT size=2 face="Courier New"><FONT size=2 face="Courier New">Prodevelop SL, Valencia (España)</FONT></DIV>
<DIV>
<DIV><FONT size=2 face="Courier New">Tlf.: 96.351.06.12 -- Fax: 96.351.09.68<BR></FONT><A href="http://www.prodevelop.es/"><FONT size=2 face="Courier New">http://www.prodevelop.es</FONT></A><BR><FONT size=2 face="Courier New">---</FONT></DIV></FONT></DIV></FONT></DIV>
<DIV><BR>
<HR>
<FONT size=2 face=Tahoma><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></DIV></BODY></HTML>