[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [udig-users] Oracle: sdo_aggr_mbr vs user_sdo_geom_metadata
|
So long and short of it is ... the bug was closed shortly after I reported it. The issue has been fixed in GeoTools 2.7.x and we will get the fix when uDig updates.
Jody
On 19/08/2010, at 10:34 PM, Bergenroth, Brandon wrote:
> I'm not so worried about uDig not using user_sdo_geom_metadata as much as it doing the full table scans to determine the mbr. And then, doing the query on all tables even before I've picked one to actually display.
>
> I'm a little surprised about the negative feedback about user_sdo_geom_metadata, it seems to me the users with problems having correct metadata would be the same users with problems having a correct crs!
>
> In fact, in my experience when loading data with a 3rd party tool like ESRI ArcCatalog, the metadata is inserted correctly with the proper bounds, but it's the crs (srid) that always shows up null.
>
> And Simon's solution suffers a bit as well, an index is not required, I might only want to display a particular layer at full extent and an index is just a waste in that case, but that is probably a rare occurrence compared to everything else.
>
> I guess I've just always seen user_sdo_geom_metadata as a necessary part of having tables with sdo_geometry, so I make sure it is always populated correctly (same with geometry_columns in postgis).
>
> Thanks,
> Brandon
>
>
>
>> -----Original Message-----
>> From: udig-users-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:udig-users-
>> bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Simon Greener
>> Sent: Thursday, August 19, 2010 5:16 AM
>> To: udig-users@xxxxxxxxxxxxxxxxxxxxx
>> Subject: Re: [udig-users] Oracle: sdo_aggr_mbr vs
>> user_sdo_geom_metadata
>>
>> 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
> _______________________________________________
> udig-users mailing list
> udig-users@xxxxxxxxxxxxxxxxxxxxx
> http://lists.refractions.net/mailman/listinfo/udig-users