Re: [udig-users] Oracle: sdo_aggr_mbr vs user_sdo_geom_metadata

[Jody Garnett <jody.garnett@xxxxxxxxx>]

Found the original bug report here:
- https://jira.codehaus.org/browse/GEOT-704

One thing you can tell form the age of this bug report is that funding for development of Oracle support does not happen often compared with ArcSDE or PostGIS.

Jody

On 20/08/2010, at 1:23 PM, Jody Garnett wrote:

> Thanks Simon; I better make a geotools bug report and gather up your suggestion:
> - https://jira.codehaus.org/browse/GEOT-3251
> 
> I actually do know what sdo ordinates mean - the data structure is used as part of SDO_GEOMETRY and there is some code in GeoTools to parse such things which I wrote a while back.
> 
> Jody
> 
> On 19/08/2010, at 7:16 PM, Simon Greener wrote:
> 
>> Greetings,
>> (Jodie, I'm on holidays in NZ. Back Sept 3rd.)
>> I learned  when programming GeoRaptor that you
>> can access the root mbr of the Oracle RTree
>> in user_sdo_index_metadata (column sdo_root_mbr).
>> This is an sdo_geometry object. However,
>> when it contains the mbr of a gedetix layer,
>> we haven't worked out what the
>> sdoordinates mean, as yet.
>> But is is blindingly faat: better tahn aggr union.
>> Code is in metedatatool.java in sourceforge repository.
>> best i can do.
>> simon
>> On Thu, 19 Aug 2010 14:23:32 +1000, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:
>> 
>>> Hi Brandon.
>>> 
>>> We had the previous version of our oracle support use the geom
>>> metadadata table; and I after treading the oracle manuals I though
>>> this was the correct approach to determine bounds.
>>> 
>>> I got lots of negative feedback; apparently this table is not often
>>> filled in with the correct information and cannot be trusted.  With
>>> that in mind, when geotools created their "jdbc-ng" rewrite for oracle
>>> support they did not even considering taking the geom metadata table
>>> code used previous.
>>> 
>>> If you like we can make the feature request for GeoTools and see what they say.
>>> 
>>> With respect to SELECT SDO_AGGR_MBR ... I had thought that we avoided
>>> doing this for uDig 1.2.0 - instead assuming a default max extent
>>> based on the coordinate reference system.
>>> 
>>> When Maurcio returns from vacation we can ask him, he performed the
>>> oracle testing for 1.2.0.
>>> 
>>> 
>>> Jody
>>> 
>>> On Thu, Aug 19, 2010 at 4:37 AM, Bergenroth, Brandon
>>> <bbergenroth@xxxxxxx> wrote:
>>>> I have yet to see uDig (including 1.2.0) use user_sdo_geom_metadata,
>>>> instead, it seems to always insist on running
>>>> 
>>>> SELECT SDO_AGGR_MBR(GEOMETRY) FROM BIG_SPATIAL_TABLE
>>>> 
>>>> for every table in the schema.
>>>> 
>>>> Will uDig ever use user_sdo_geom_metadata?  Running a full table scan on
>>>> every spatial table makes it pretty much useless for anything but a
>>>> trivial amount of data.
>>>> 
>>>> Thanks,
>>>> Brandon
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> udig-users mailing list
>>>> udig-users@xxxxxxxxxxxxxxxxxxxxx
>>>> http://lists.refractions.net/mailman/listinfo/udig-users
>>>> 
>>> _______________________________________________
>>> udig-users mailing list
>>> udig-users@xxxxxxxxxxxxxxxxxxxxx
>>> http://lists.refractions.net/mailman/listinfo/udig-users
>>> 
>> 
>> 
>> -- 
>> SpatialDB Advice and Design, Solutions Architecture and Programming,
>> Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional
>> Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, FME, Radius Topology and Studio Specialist.
>> 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia.
>> Website: www.spatialdbadvisor.com
>> Email: simon@xxxxxxxxxxxxxxxxxxxx
>> Voice: +61 362 396397
>> Mobile: +61 418 396391
>> Skype: sggreener
>> Longitude: 147.20515 (147° 12' 18" E)
>> Latitude: -43.01530 (43° 00' 55" S)
>> GeoHash: r22em9r98wg
>> NAC:W80CK 7SWP3
>> _______________________________________________
>> udig-users mailing list
>> udig-users@xxxxxxxxxxxxxxxxxxxxx
>> http://lists.refractions.net/mailman/listinfo/udig-users
>