[Gvsig_english] Question on GeoBD and Metadata when exporting toOracle

Fri Dec 18 14:30:25 CET 2009

Dear Juan Lucas,
excellent! 

Best,
Wolfgang

jldominguez wrote:
> 
> Hello, Wolfgang. When you choose a connection to see the available Oracle
> Spatial tables, the metadata of some of those tables is written in the
> gvSIG log file (one out of ten, I think, for sampling purposes).
>  
> I have exported a few shapefiles with gvSIG 1.9, and these lines appear in
> the gvSIG log file:
>  
> =========
> OWNER: LLEIDA, TABLE_NAME: GV_SEE_TOL, COLUMN_NAME: GEOMETRY, SRID: 82337
> DIMINFO: DIMENSIONS: 2
> DIMENSION 0: , NAME: X, MIN: 4070148.67213375, MAX: 5192210.139323162,
> TOL: 0.0005
> DIMENSION 1: , NAME: Y, MIN: 5238407.7711313, MAX: 6196031.330266247, TOL:
> 0.0005
> =========
>  
> So yes, the tolerance is set to 0.0005 meters as you suggested.
>  
> 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 Wolfgang Qual
> Enviado el: vie 18/12/2009 13:01
> Para: gvsig_internacional at listserv.gva.es
> Asunto: Re: [Gvsig_english] Question on GeoBD and Metadata when exporting
> toOracle
> 
> 
> 
> 
> Hello Juan Lucas, list.
> A few weeks ago, I wrote a post regarding metadata and Oracle spatial. The
> tolerance value I was referring to was 0.5 in the past, but you mentioned
> that it could be changed. Is this change already reflected in gvSIG 1.9?
> Short answer would be that great!
> 
> Best,
> Wolfgang
> 
> 
> Juan Lucas Dominguez Rubio schrieb:
>> Hello,
>> 
>> Ok yes, 0.5 meters is too much. I'll change it to 0.0005 and if I
>> don't see any problem, I think it'll be like that in the upcoming
>> gvSIG 1.9.
>> 
>> According to the Oracle documentation, tolerance must be smaller than
>> the smallest hole in polygon layers. I don't think you have a polygon
>> layer with holes whose diameter is less than 0.0005 meters (1/2 mm),
>> do you? ;-)
>> 
>> 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/> 
>> <http://www.prodevelop.es/>
>> ---
>>
>> ------------------------------------------------------------------------
>> *De:* Wolfgang Qual [mailto:wolfgang.qual at muenchen.de]
>> *Enviado el:* jue 24/09/2009 11:53
>> *Para:* Users and Developers mailing list; Juan Lucas Dominguez Rubio
>> *Asunto:* Re: [Gvsig_english] Question on GeoBD and Metadata when
>> exporting toOracle
>>
>> 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:
>>> 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
>>> http://www.prodevelop.es <http://www.prodevelop.es/> 
>>> <http://www.prodevelop.es/>
>>> ---
>>>
>>> ------------------------------------------------------------------------
>>> *De:* gvsig_internacional-bounces at listserv.gva.es 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: wolfgang.qual at muenchen.de
>>>
>>> _______________________________________________
>>> Gvsig_internacional mailing list
>>> Gvsig_internacional at listserv.gva.es
>>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Gvsig_internacional mailing list
>>> Gvsig_internacional at listserv.gva.es
>>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>>>  
>>
>>
>> --
>> 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: wolfgang.qual at muenchen.de
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Gvsig_internacional mailing list
>> Gvsig_internacional at listserv.gva.es
>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>>  
> 
> 
> --
> 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: wolfgang.qual at muenchen.de
> 
> 
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
> 
> 
> 
> --
> View this message in context:
> http://n2.nabble.com/Question-on-GeoBD-and-Metadata-when-exporting-to-Oracle-tp3704488p4186183.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
> 
> 
> 
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
> 
> 

-- 
View this message in context: http://n2.nabble.com/Question-on-GeoBD-and-Metadata-when-exporting-to-Oracle-tp3704488p4186542.html
Sent from the gvSIG international mailing list archive at Nabble.com.