<HTML dir=ltr><HEAD>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16890" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV id=idOWAReplyText22466 dir=ltr>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3>Hello, Wolfgang. </FONT><FONT face="Times New Roman" color=#000000 size=3>Regarding the spatial index in Oracle Spatial:</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3>As Fran says, this is a server-side question. When a vector layer is exported to the Oracle Spatial DB, gvSIG explicitly creates a spatial index. This is mandatory if one needs to perform geometric queries on the resulting table (as gvSIG does). If you add tables with geometries from other software or manually (SQL sentences), the spatial index will also have to be created.</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3>According to the Oracle documentation, the default algorithm used for the spatial index is R-tree. There is also a quadtree implementation, but Oracle strongly recommends not to use it as its performance is significantly poorer, probably only to be used if you have a deep knowledge of what your geometries look like and how each algorithm behaves.</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3>When creating the index, we use the default SQL sentence, which uses sensible settings for almost any layer. The only parameter we might add is one that optimizes the performance when the layer is of type POINT.</FONT></DIV>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3></FONT> </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3>Regards,</FONT></DIV>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3></FONT> </DIV></DIV>
<DIV id=idSignature84862 dir=ltr>
<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 dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>De:</B> gvsig_internacional-bounces@listserv.gva.es en nombre de Wolfgang Qual<BR><B>Enviado el:</B> jue 15/10/2009 11:25<BR><B>Para:</B> Users and Developers mailing list; Francisco Peñarrubia<BR><B>Asunto:</B> Re: [Gvsig_english] Question on GeoBD and Metadata when exporting toOracle<BR></FONT><BR></DIV>
<DIV>Hello Fran,<BR>ok. Therefore, it should work... Thank you very much!<BR><BR>Best,<BR>Wolfgang<BR><BR><BR>Francisco José Peñarrubia schrieb:
<BLOCKQUOTE cite="" type="cite"><PRE>Hi Wolfgang.
Spatial Indexes in local are used with local data. I mean, you can have
your own spatial index in your hard disk. In case of Geospatial
Databases, there is no local spatial index. The database manages its own
spatial indexes, and is the responsability of the database admin. So, if
the geospatial database is well configured, then, it's ok. Any spatial
index is ok (for Oracle, Postgis, ArcSDE, mySQL, etc).
Have fun.
Fran Peñarrubia
<A class=moz-txt-link-abbreviated href="http://www.scolab.es/">www.scolab.es</A>
Wolfgang Qual escribió:
</PRE>
<BLOCKQUOTE type="cite"><PRE>Hello list, (hello Juan Lucas!)
some days ago, I posted some questions on GeoBD and Oracle Spatial to
this list - and got very good and detailed information.
Today, another question came to me (ok, a colleague asked me that
question): what type of spatial index is used (if any), if an oracle
spatial layer is loaded into gvSIG:
or: does gvSIG accept/make use of the R-tree-indexing? My colleague
told me that Oracle Quadtree indexing was used before and will be
replaced by R-tree.
Any comment is appreciated.
best,
Wolfgang
---8<----
Wolfgang Qual schrieb:
</PRE>
<BLOCKQUOTE type="cite"><PRE>Hello Juan Lucas,
thank you very much for this detailed information. I just found out
that SDO_TOLERANCE_1 and .._2 are parameters within the ESRI
application. Therefore, they refer to SDO_TOLERANCE values for X and
Y. According to my colleague,
ESRI sets those values to 0.0005. The tolerance parameter of GeoBD
oracle export is set to 0.5 - does that mean that the tolerance is
0.5 meter? Can this be modified? As geometries of the common
geodatabase are used in different departments with different
applications, tolerance values should be identical, don't you think?
Sorry, but I am not that well schooled in this oracle stuff...
Best,
Wolfgang
---8<---
And resolution seems to be available in ESRI-software, too.
Juan Lucas Dominguez Rubio schrieb:
</PRE>
<BLOCKQUOTE type="cite"><PRE>Hello, Wolfgang.
When you export a vector layer to Oracle Spatlai/Locator, the
sequence of actions is as follows:
- if a table with the same name exists, it's deleted (dropped in
cascade mode). This also removes spatial indices associated with the
table
- the new table is created
- geometry metadata for this table name is removed (if existed)
- new geometry metadata is written in USER_SDO_GEOM_METADATA
- a spatial index on the geometry column is created
- table records are added (no commits here)
- a single final commit is performed
The tolerance parameter in the metadata is always set to 0.5.
Dimension names are set to 'X', 'Y' and 'Z' (if needed) or
'LONGITUDE' and 'LATITUDE'. Max. and min. values for X and Y are set
according to the layer's bounding box. Min. and max. values for 'Z'
(if needed) are always set to 0 and 100 (this is not very nice, but
has no bad effect since the Z value does not currently take part in
any geometric operation). Dimension names can be anything you want.
You could use 'BREITE' instead of 'LATITUDE', 'EASTING' instead of
'X' or whatever.
SDO_TOLERANCE_1 and SDO_TOLERANCE_2 refer to tolerance for X and Y
perhaps?
Remember that the tolerance unit is implicit and depends on the
table's coordinate system (SRID). If the SRID corresponds to a
geodetic coordinate system (latitude, longitude), then the tolerance
is assumed to be expressed in meters. If the SRID corresponds to a
projected coordinate system (such as the German EPSG:3146X series)
then the tolerance is assumed to be expressed in the same unit used
by the coordinate system (usually meters). This also applies if the
SRID is NULL. According to this, it would be a bad idea to have a
table with geometries whose vertices are in latitude and longitude
and setting the SRID to NULL, because the tolerance (0.5) would
correspond to a few dozens of kilometers.
The tolerance settings are very unlikely to have any effect when you
work with gvSIG because the application checks again the true
relationship between geometries after they have been converted to
the gvSIG geometry model. In other words: the 'select by rectangle'
tool should not behave in a strange way even if you have a bad
tolerance value. Of course you will see the effects of a bad
tolerance value from other applications or when you execute a SQL
statement directly against your database.
So the metadata stored for a Oracle Spatial/Locator table are:
- Owner
- Table name
- Geometry column name (the metadata record will be replicated for
several values because a table can have more than one geometry column)
- Dimension info (for each dimension: dimension name, max value, min
value, tolerance)
- SRID (possibly NULL)
If you have a 3D vector layer (for example a 3D shapefile) I think
you will not notice the third dimension while you work with views
and layouts, but if you export that layer to your Oracle
Spatial/Locator database, it will be stored with a 3D geometry
column (you can see the number of dimensions of each using
Sqldeveloper for example)
As you perhaps know, Oracle Spatial/Locator supports 4D geometries
(XYZT, I think Oracle normally uses the letter T instead of M for
the 4th dimension). When you open one of these tables with gvSIG,
the resulting layer is a 3D layer (4th dimension is discarded)
I have never heard about a parameter called resolution in the table
metadata. Perhaps you are talking about some operations that allow
you to restrict the result by setting a min and max_resolution
value, but this is not connected to tables' metadata.
I agree that it would be a good idea to let the user set the
metadata values.
Regards,
Juan Lucas Domínguez Rubio
---
Prodevelop SL, Valencia (España)
Tlf.: 96.351.06.12 -- Fax: 96.351.09.68
<A class=moz-txt-link-freetext href="http://www.prodevelop.es/">http://www.prodevelop.es</A> <A class=moz-txt-link-rfc2396E href="http://www.prodevelop.es/"><http://www.prodevelop.es/></A>
---
------------------------------------------------------------------------
*De:* <A class=moz-txt-link-abbreviated href="mailto:gvsig_internacional-bounces@listserv.gva.es">gvsig_internacional-bounces@listserv.gva.es</A> en nombre de
Wolfgang Qual
*Enviado el:* jue 24/09/2009 8:59
*Para:* Users and Developers mailing list
*Asunto:* [Gvsig_english] Question on GeoBD and Metadata when
exporting toOracle
Hi list,
in our City administration, different GIS software is used to work with
spatial data. Among them, ArcMap and gvSIG allow to access a central
oracle spatial database. Thanks to the great GeoBD extension, accessing
that database via gvSIG is very comfortable, even exporting new layers
to the database is possible.
Yesterday, a colleague of mine who is in charge of the overall design of
the geodatabase asked me to provide some details on GeoBD's
capabilities. He asked me about metadata that is created by that
extension when exporting a shapefile to the oracle spatial database and
possibilities to set custom settings for the metadata. In this context,
he also talked about "tolerance" (SDO_TOLERANCE_1, SDO_TOLERANCE_2),
"resolution". I have no idea, whether GeoBD sets these values.
Therefore, I would be very happy, if someone of you (maybe the
developers from Prodevelop) could give me some details on the type and
values of metadata that is written to new oracle spatial layers. That
would be very great to have.
Best regards and thank you very much for your help.
Wolfgang
--
Wolfgang Qual
Landeshauptstadt München
Referat für Gesundheit und Umwelt
RGU-UW 11
Sg. 1 Gesundheits- und Umweltberichterstattung,
Energie und Klimaschutz
Bayerstr. 28a, 80335 München
Tel.: +49 (0)89 233-477 17
Fax.: +49 (0)89 233-477 05
E-Mail: <A class=moz-txt-link-abbreviated href="mailto:wolfgang.qual@muenchen.de">wolfgang.qual@muenchen.de</A>
_______________________________________________
Gvsig_internacional mailing list
<A class=moz-txt-link-abbreviated href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</A>
<A class=moz-txt-link-freetext href="http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional">http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional</A>
------------------------------------------------------------------------
_______________________________________________
Gvsig_internacional mailing list
<A class=moz-txt-link-abbreviated href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</A>
<A class=moz-txt-link-freetext href="http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional">http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional</A>
</PRE></BLOCKQUOTE><PRE>--
Wolfgang Qual
Landeshauptstadt München
Referat für Gesundheit und Umwelt
RGU-UW 11
Sg. 1 Gesundheits- und Umweltberichterstattung,
Energie und Klimaschutz
Bayerstr. 28a, 80335 München
Tel.: +49 (0)89 233-477 17
Fax.: +49 (0)89 233-477 05
E-Mail: <A class=moz-txt-link-abbreviated href="mailto:wolfgang.qual@muenchen.de">wolfgang.qual@muenchen.de</A>
</PRE></BLOCKQUOTE><PRE>--
*Wolfgang Qual
* *Referat für Gesundheit und Umwelt*
Umweltschutz
Umweltvorsorge
RGU-UW 11
Bayerstraße 28a
80335 München
Telefon +49 - 89 - 233 - 4 77 17
Telefax +49 - 89 - 233 - 4 77 05
<A class=moz-txt-link-freetext href="http://www.muenchen.de/umweltatlas">http://www.muenchen.de/umweltatlas</A>
<A class=moz-txt-link-abbreviated href="mailto:uw11.rgu@muenchen.de">uw11.rgu@muenchen.de</A>
Bitte beachten Sie die Hinweise zur elektronischen
Kommunikation mit der Landeshauptstadt München:
<A class=moz-txt-link-freetext href="http://www.muenchen.de/ekomm">http://www.muenchen.de/ekomm</A>
------------------------------------------------------------------------
_______________________________________________
Gvsig_internacional mailing list
<A class=moz-txt-link-abbreviated href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</A>
<A class=moz-txt-link-freetext href="http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional">http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional</A>
</PRE></BLOCKQUOTE><PRE>_______________________________________________
Gvsig_internacional mailing list
<A class=moz-txt-link-abbreviated href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</A>
<A class=moz-txt-link-freetext href="http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional">http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional</A>
</PRE></BLOCKQUOTE><BR><BR>
<DIV class=moz-signature>-- <BR>
<TABLE cellSpacing=0 cellPadding=3 width=350 bgColor=white border=0>
<TBODY>
<TR>
<TD bgColor=#330066 colSpan=2><IMG height=35 alt="" src="https://correo.prodevelop.es/exchange/jldominguez/Borradores/RE:%20[Gvsig_english]%20Question%20on%20GeoBD%20and%20Metadata%20when%20exporting%20toOracle.EML/1_multipart/logo_b.gif" width=170 border=0></TD></TR>
<TR>
<TD vAlign=bottom align=left width=3 bgColor=#330066><BR></TD>
<TD vAlign=top><FONT face=Arial,Helvetica,Geneva,Swiss,SunSans-Regular size=2><B>Wolfgang Qual<BR><BR></B></FONT><FONT face=Arial,Helvetica,Geneva,Swiss,SunSans-Regular size=1><BIG><B>Referat für Gesundheit und Umwelt</B></BIG><BR>Umweltschutz<BR>Umweltvorsorge<BR>RGU-UW 11<BR><BR>Bayerstraße 28a<BR>80335 München<BR><BR>Telefon +49 - 89 - 233 - 4 77 17<BR>Telefax +49 - 89 - 233 - 4 77 05<BR><BR><A class=moz-txt-link-freetext href="http://www.muenchen.de/umweltatlas">http://www.muenchen.de/umweltatlas</A><BR><A class=moz-txt-link-abbreviated href="mailto:uw11.rgu@muenchen.de">uw11.rgu@muenchen.de</A><BR></FONT></TD></TR>
<TR>
<TD vAlign=top colSpan=2><SMALL><FONT face="Helvetica, Arial, sans-serif">Bitte beachten Sie die Hinweise zur elektronischen<BR>Kommunikation mit der Landeshauptstadt München:<BR><A class=moz-txt-link-freetext href="http://www.muenchen.de/ekomm">http://www.muenchen.de/ekomm</A></FONT></SMALL></TD></TR></TBODY></TABLE></DIV></DIV></BODY></HTML>