[Gvsig_english] Question on GeoBD and Metadata when exporting toOracle

Wolfgang Qual Wolfgang.Qual at gmx.net
Fri Dec 18 13:01:01 CET 2009


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/>
> ---
>
> ------------------------------------------------------------------------
> *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/>
>> ---
>>
>> ------------------------------------------------------------------------
>> *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.


More information about the Gvsig_internacional mailing list