Stuart A. Mitchell ha scritto:
> Hi,
>
>
>
> I am in the process of creating a feature based on an Oracle Table that
> is properly indexed and has an entry in USER_SDO_GEOM_METADATA.
>
> Clicking the Generate button to get the extents returned incorrect values.
>
> I checked the MBR with the following code and got the same values as
> OracleNG…
> select sdo_aggr_mbr(geom_location)
> from <tablename>
> 141.8076171875, -16.8662109375, 148.2353515625, -15.568359375
>
>
>
> Obviously OracleNG is using SDO_AGGR_MBR as there’s no way else to get
> the strange results, which
> aren’t so strange when you read the Oracle docs – “…by contrast, the
> SDO_AGGR_MBR function can operate on
> subsets of rows.”
Sorry but I don't understand, what is strange in those results?
Using SDO_AGGR_MBR is the only general way to get bounds as you
have noticed. If it does not return the proper results it
seems to just be a bug with Oracle DBMS to me...
> I then checked using the following statement and got the correct values
> SELECT SDO_TUNE.EXTENT_OF('TABLENAME', 'GEOM_LOCATION')
> FROM DUAL;
>
> 137.6845703125, -29.197265625, 152.1845703125, -10.810546875
> However, SDO_TUNE.EXTENT_OF only works with 2 dimensional geometries.
>
> Now even though we are only working with 2 dims here, if someone is using
>
> an LRS dim or Z, it won’t work.
Not only 2 dimensional, the documentation says not to use it for
geographic coordinates (at least the 10G if my memory serves me
right) which is your case. Maybe you did not specify the SRS
when you created the spatial index?
Moreover, it won't work when you are using a filter to get the
bounds of a selection of features.
>
>
> This provides a reasonable approximation without much of a performance
> hit ...
> SELECT SDO_AGGR_MBR(ch)
> from (select SDO_AGGR_CONVEXHULL(SDOAGGRTYPE(geom_location, 0.001)) ch
> FROM <tablename>);
>
Hum.... what is that doing? Computing the bbox of the convex hull should
be slower in theory:
- nlog(n) time to compute the convex hull
- a linear scan of the convex hull vertices to get the mbr of it
vs
- a linear scan of the original geometry to get the mbr...
> ... but you would have to look up the tolerance from USER_SDO_GEOM_METADATA.
Eh, and you have to assume the user inserted a reasonable tolerance
value... not sure I trust that.
If this is an optimization, it's probably better to enabled it using
a configuration flag of some kind.
Other people have asked that we use the bbox stored in some other
metadata table (something that an admin has to enter properly, again).
Maybe it's what you're talking about below.
> The best solution is just to get the diminfo from
> USER_SDO_GEOM_METADATA. The current
> way of generating the data is flawed in any case for all databases, not
> just Oracle.
Really, how so?
> I know I have put in the diminfo for my entire area of concern even though
> it will be
> two years before the data is fully populated. I would suspect most
> people would put in
> the layer size in the diminfo up front and that the data may not reflect
> the actual bounds
> required.
My experience tells me people do not properly populate metadata, period
;-)
(you should see how many checks we have in the postgis data store to
make it work with real world data where most of the time metadata
is missing or wrong).
> On the other hand, if we are not going to fix this, then there needs to
> be a clear warning about
>
> generated extents possibly (probably) being inaccurate if adding an
> Oracle feature, right next to
>
> the ‘Generate’ button.
And finally I have to add that this requires a custom optimization in
the code for the case where you are not filtering rows, as the call
is FeatureSource.getBounds(Query). Justin?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
