[fdo-internals] RE: FDO Function SpatialExtents

Tue Nov 18 13:37:07 EST 2008

Not sure what you mean. SDO_ROOT_MBR is not MBR of geometries.

SpatialExtent will not return exact MBR of all geometries for class because priority is speed in MAP 3D.

Haris

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Tuesday, November 18, 2008 5:28 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO Function SpatialExtents

Ø  It will not return exact extents of geometries but will return what is written in index meatada (SDO_ROOT_MBR from sdo_index_metadata).

Harris, as I said before, watch out for geodetic coordinate systems.

Dan.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Tuesday, November 18, 2008 10:29 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO Function SpatialExtents

I have implemented in King.Oracle special case of SpatialExtents for all geometries in class.

It will not return exact extents of geometries but will return what is written in index meatada (SDO_ROOT_MBR from sdo_index_metadata).

If there is filter set with SelectAggregate command then correct extent will be returned ( using SDO_AGR_MBR Oracle function ).

I have implemented in such way because MAP 3D is using SpatialExtents every time when layer is to be displayed and because of that rendering in MAP becomes slow.

I think it is not correct that SpatialExtent will not return exact MBR but because MAP 3D is obviously very important FDO client priorities are reordered :)

I would suggest ( RFC ? ) that we would have dedicated commands/functions which are used in typical applications.

-          command to return just "zoom extent" of layer

-          command to get geometries and keys from window query (envelope intersect)

-          command to get selection based on rectangular window 

-          few more...

Right now providers are parsing select command and try to discover those special cases which are basically not special cases but standard cases coming from practical use.

Haris

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Tuesday, November 18, 2008 12:47 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO Function SpatialExtents

I think it is very important question.

Autodesk Oracle provider is not returning correct result if (and I think it is) SpatialExtent is supposed to return exact MBR of geometries.

I am looking now at SqlSrever provider and there are 2 special cases for Count and SpatialEXtents for whole layer.

For those 2 special cases there is special code and special OptimizedAggregateReader etc...

What looks wrong to me is that we used exact SpatialExtent function to return something what doesn't need to be exact.

Shouldn't be better to have special command or special function to return count, extents of layer etc..

Now it looks to me that code of provider is more complicated and also we have function which could or could not return expected result.

Haris

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Tuesday, November 18, 2008 12:17 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO Function SpatialExtents

It's a question of practicality, not belief. J

SpatialExtents exists only so that providers which can provide a faster implementation than the naïve iteration over all features can make that feature accessible. If you want to provide the naïve implementation of iterating over all features and computing the union of their MBRs, then save yourself the effort, since Map already has this fallback.

Traian

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Monday, November 17, 2008 6:34 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO Function SpatialExtents

Traian,

Now I don't understand you :)

I would believe SpatialExtents should return exact MBR value of geometries in Select query.

Haris

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Tuesday, November 18, 2008 12:04 AM
To: 'FDO Internals Mail List'
Subject: RE: [fdo-internals] RE: FDO Function SpatialExtents

Theoretically it has to return the MBR of its argument. 

In practice, it doesn't need to be exact, since the code that uses it does not need it to be exact.

You don't have a choice anyway, if you want it to perform at all...

Traian

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Monday, November 17, 2008 6:22 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO Function SpatialExtents

Hm, but what is SpatialExtent function, exact MBR or not ?

Haris

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Monday, November 17, 2008 11:54 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO Function SpatialExtents

Yes, just return the bounding box of all the geometries. Map does not need exact BBOX, just an extent it can zoom to in order to show something once you add the layer.

Traian

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Monday, November 17, 2008 6:16 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO Function SpatialExtents

Yes, SDO_AGGR_MBR could be slow.

In Oracle there is index METADATA table with SDO_ROOT_MBR ( perhaps that is what Orest was saying ? ) but that is not correct MBR of geometries.

I understood that SelectExtents is supposed to :

return exact MBR of geometries

works for SQL queries, works for subsets of data

It looks to me that Map is using SpatialExtents it to get not necessary exact extent of layer (class) not geometries.

So my question is, is SpatialExtents supposed to return MBR of geometries ?

I think for class extent we should have another command.

Haris

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Robert Fortin
Sent: Monday, November 17, 2008 11:24 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO Function SpatialExtents

Map will use the SelectExtents function (if is exists) in order to compute the extent of the data set before it starts populating the cache.

The slower the SelectExtents  function is the slower Map rendering will be.  SDO_AGGR_MBR is probably not efficient enough for that purpose.

RF

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Monday, November 17, 2008 5:36 PM
To: FDO Internals Mail List
Subject: [fdo-internals] FDO Function SpatialExtents

Hi,

I have implemented support for SelectAggregates in King.Oracle.

I am testing SpatialExtent function and I need help in understanding how clients, MAP 3D , is using it. I am not sure if I understand how is it supposed to be used.

I have implemented function using Oracle SDO_AGGR_MBR. That is rather slow process .

What I noticed is that MAP 3D 2009 is calling FDO command SelectAggregates with SpatialExtents function.

That makes rendering of layers very slow in MAP 3D.

I know I am asking about non-open source client like MAP 3D but from what I see makes me wonder if I understand SpatialExtents function correctly.

Thank you,

Haris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20081118/e15ce9c9/attachment-0001.html