Stuart A. Mitchell ha scritto:
...
>>> 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...
> It's documented as I wrote from the Oracle doco - "...by contrast, the
> SDO_AGGR_MBR function can operate on subsets of rows.
Hem... I read that sentence as "you can have it work on the rows
matched by your WHERE clause" as opposed to SDO_TUNE.EXTENT_OF
which does not allow for that.
You believe it's only using a subset of the rows returned by
the WHERE clause to compute the bounds?
>>> 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.
> It works fine despite the doco.
When I tried last time it was even slower than SDO_AGGR_MBR thought
(in the case of geographic data). How big is the dataset you're
using for your tests right now?
>> Maybe you did not specify the SRS
>> when you created the spatial index?
> No mistake.
As in, the SRS was properly specified?
>>>
>>>
>>> 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.
> I wasn't proposing this as a solution but I wasn't clear about that.
Oh ok, then I'm confused. What were you proposing then?
>> 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).
> Garbage in - garbage out. Just throw exceptions if people are too lazy
> to do their job properly.
The datastore is there to be used for various applications, not only
for GeoServer. The API says the bounds returned must be the current
ones, and must match an eventual filter.
I'm perfectly ok with the metadata optimization, but only as long
as the user _asked_ for it before.
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
