I'm pretty sure the SDO_POINT field is only populated if the geometry is in
fact a point (this is to reduce the size of the geometry object). So that
won't work in our case, since the data is polygons.
We could indeed create a new column, populated via a trigger, and create an
index on it (I think - might need a functional spatial index perhaps). But
that's a much heavier weight solution than needed. All the capability is
there in Oracle to make a query returning points using a spatial filter
against the geometry column. GeoServer just needs to be able to emit the
required queries.
On Tue, Mar 10, 2015 at 11:58 AM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:
> SDO_GEOMETRY is built this way:
>
>
> CREATE TYPE sdo_geometry AS OBJECT (
> SDO_GTYPE NUMBER,
> SDO_SRID NUMBER,
> SDO_POINT SDO_POINT_TYPE,
> SDO_ELEM_INFO SDO_ELEM_INFO_ARRAY,
> SDO_ORDINATES SDO_ORDINATE_ARRAY);
>
>
> You can query "select sdo_point from geometry_column" if SDO_POINT has data
> in it.
> Like you query "select SDO_SRID from geometry_column". However, I do not know
> if it works. What should work
> is to create a secondary column of SDO_GEOMETRY, populate it with centroid,
> build spatial index etc. That way
> you would not need to copy all the normal attributes as if you would make a
> new table for points.
>
> -Jukka-
>
>
>
> ------------------------------
> Martin Davis wrote:
>
> > Do you mean creating a new SDO_GEOMETRY on the fly in the query, but
> using only a single point from the original geometry? Wouldn't Oracle
> still detect that the "virtual geometry" doesn't have an index? Or am I
> missing something? Can you give an example of what you mean?
>
> On Tue, Mar 10, 2015 at 11:46 AM, Rahkonen Jukka (MML) <
> jukka.rahko...@maanmittauslaitos.fi> wrote:
>
>> Hi,
>>
>>
>> I am not sure but perhaps you could fool Oracle by inserting the
>> point geometry of the polygon into the SDO_POINT array of SDO_GEOMETRY.
>> Oracle documentation says that if SDO_ELEM_INFO and SDO_ORDINATES arrays
>> are not both null then SDO_POINT will be skipped. However, it would be so
>> nice trick if that works that I suggest to make a try.
>>
>> http://docs.oracle.com/cd/B19306_01/appdev.102/b14255/sdo_objrelschema.htm
>>
>>
>> -Jukka-
>> ------------------------------
>> Martin Davis wrote:
>>
>> Because I was hoping that GeoServer would make use of the GEOMETRY
>> column in the spatial filter. I tried NOT including it first of all, and
>> that didn't work, since the filter was applied on the PT field, causing the
>> no-index error. Unfortunately, GeoServer is too smart - if the SLD is
>> based on the PT column then it uses that column in the spatial filter!
>>
>> On Tue, Mar 10, 2015 at 11:29 AM, Rahkonen Jukka (MML) <
>> jukka.rahko...@maanmittauslaitos.fi> wrote:
>>
>>> Hi,
>>>
>>>
>>> Why do you select geometry and centroid into SQL view if you are only
>>> interested in the centroid?
>>>
>>> "select GEOMETRY, SDO_GEOM.SDO_CENTROID(GEOMETRY, 1) PT from
>>> CUT_BLOCK_SP "
>>>
>>>
>>> -Jukka Rahkonen-
>>>
>>>
>>> ------------------------------
>>> Martin Davis wrote:
>>>
>>> > We're working on tuning a GeoServer implementation over an Oracle
>>> SDO database. We think we are seeing that the network latency of queries is
>>> the hotspot in the performance of GeoServer render requests.
>>>
>>> > It seems that for some situations one way to reduce the data being
>>> pushed over the wire is to reduce the data size in the database query. In
>>> particular, for some datasets of polygons we're happy just to see points
>>> representing the polygons. So we tried using a SQLView with a statement
>>> like:
>>>
>>> select GEOMETRY, SDO_GEOM.SDO_CENTROID(GEOMETRY, 1) PT from
>>> CUT_BLOCK_SP
>>>
>>> and then used an SLD <Geometry> selector to render just the point.
>>>
>>> However, this doesn't work because we get the dreaded ORA-13226:
>>> interface not supported without a spatial index error. This is because
>>> GeoServer is actually emitting the query
>>>
>>> SELECT PT as PT FROM (select GEOMETRY, SDO_GEOM.SDO_CENTROID(GEOMETRY,
>>> 1) PT from CUT_BLOCK_SP t) VTABLE WHERE SDO_FILTER(PT, ?,
>>> 'mask=anyinteract querytype=WINDOW') = 'TRUE'
>>>
>>> and there is no index defined on the PT column.
>>>
>>> Now, this would work if GeoServer could emit the query:
>>>
>>> SELECT PT as PT FROM (select SDO_GEOM.SDO_CENTROID(GEOMETRY, 1) PT
>>> from CUT_BLOCK_SP t) VTABLE WHERE SDO_FILTER(GEOMETRY, ?,
>>> 'mask=anyinteract querytype=WINDOW') = 'TRUE'
>>>
>>> Is there any way to get this to happen?
>>>
>>> Or does anyone have other ideas about how to reduce query data size on
>>> Oracle?
>>>
>>
>>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
