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

["Bergenroth, Brandon" <bbergenroth@xxxxxxx>]

Great news Jody, thanks.



> -----Original Message-----
> From: Jody Garnett [mailto:jody.garnett@xxxxxxxxx]
> Sent: Friday, August 20, 2010 2:27 AM
> To: Bergenroth, Brandon
> Cc: udig-users@xxxxxxxxxxxxxxxxxxxxx
> Subject: 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