1

I have this statement that is generated by Geoserver

SELECT
shape AS shape
FROM
    (
        SELECT
            c.chantier_id      id,
            sdo_geom.sdo_buffer(c.shape, m.diminfo, 1) shape,
            c.datedebut        datedebut,
            c.datefin          datefin,
            o.nom              operation,
            c.brouillon        brouillon,
            e.code             etat,
            u.utilisateur_id   utilisateur,
            u.groupe_id        groupe
        FROM
            user_sdo_geom_metadata   m, lyv_chantier             c
            JOIN lyv_utilisateur          u ON c.createur_id = u.utilisateur_id
            JOIN lyv_etat                 e ON c.etat_id = e.etat_id
            JOIN lyv_operation            o ON c.operation = o.id
        WHERE
            m.table_name = 'LYV_CHANTIER'
            AND m.column_name = 'SHAPE'
    ) vtable
WHERE
    ( brouillon = 0
      AND ( etat != 'archive'
            OR etat IS NULL )
      AND sdo_filter(shape, mdsys.sdo_geometry(2003, 4326, NULL, mdsys.sdo_elem_info_array(1, 1003, 1), mdsys.sdo_ordinate_array(
      2.23365783691406, 48.665657043457, 2.23365783691406, 48.9341354370117, 2.76649475097656, 48.9341354370117, 2.76649475097656, 48.665657043457, 2.23365783691406, 48.665657043457)), 'mask=anyinteract querytype=WINDOW') = 'TRUE' );

On my local instance (dockerized if that can explain anything) it works fine, but on another instance I get an error :

ORA-13226: interface not supported without a spatial index

I guess that the SDO_FILTER is applied to the result of SDO_BUFFER which is therefore not indexed.
But why is it working on my local instance ?!
Is there some kind of weird configuration shenanigan that could explain the different behavior maybe ?

EDIT : The idea behind this is to get around a bug in Geoserver with Oracle databases where it renders only the first point of MultiPoint geometries, but works fine with MutltiPolygon. I am using a SQL view as layer in Geoserver (hence the subselect I guess).

Morysh
  • 71
  • 10
  • Does the table have a spacial index created? if it doesn't, please try creating the index. There are lots of questions on how to do that, [for example](https://stackoverflow.com/questions/36624479/creating-a-spatial-index-on-oracle/36624902) – micklesh May 06 '20 at 15:09
  • Yes, there is a spatial index on both instances. And the USER_SDO_GEOM_METADATA row for this table is also identical – Morysh May 07 '20 at 06:23
  • You are probably running Oracle 12.2 or later in the dockerized instance, while the other one runs an older version. Since 12.2, spatial indexes are optional: the spatial operators will complete (albeit slower) even if no index exists. In 12.1 and earlier, if no index exists, then you get this error. – Albert Godfrind May 07 '20 at 10:47
  • "Yes, there is a spatial index on both instances." But that is an index on the `SHAPE` column from table `LYV_CHANTIER`. The problem is with the column returned by the subquery. This is obviously not indexed, and older versions of Oracle will complain about that. – Albert Godfrind May 07 '20 at 10:52

1 Answers1

0

First, you need to do some debugging here. Connect to each instance, on the same user as your Geoserver's datasource, and run the sql. From the same connections (in each instance) you must also verify that the user's metadata view (user_sdo_geom_metadata) have an entry for the table and the table has a spatial index - whose owner is the same user as the one you connect.
Also, your query ( select ... from 'vtable') has a column 'shape' which is a buffer of the column lyv_chantier.shape. The sdo_filter, in this sql, expects a spatial index on the vtable.shape - which cannot exist. You should try to use a different alias (e.g. buf_shape) and sdo_filter(buf_shape,...) - to see if the sql fails in both instances, as it should.

I'm in a bit of a hurry right now, so my instructions are summarized. If you want, do this debugging and post the results. We then can go into details.

EDIT: Judging from your efforts, I'd say that the simplest approach is: 1) add a second geometry column to lyv_chantier (e.g. buf_shp). 2) update lyv_chantier set buf_shp = sdo_geom.sdo_buffer(shape,...). 3) insert into user_sdo_geom_metadata the values (lyv_chantier, buf_shp, ...). 4) create a spatial index on column buf_shp. You may need to consider a trigger to update buf_shp whenever shape changes...
This is a very practical approach but you don't provide any info about your case (what is the oracle version, how many rows does the table have, how is it used, why do you want to use sdo_buffer, etc), so that's my recommendation for now.
Also, since you are, most likely, using an sql view as layer in Geoserver (you don't say anything about that, either), you could also consider using pure GS functionality to achieve your goal.
At the end, without describing your goal, it's difficult to provide anything more tailor-made.

GregStef
  • 176
  • 6
  • I ran the SQL from SQLDeveloper, it works on the local instance. Weirdly, event with a new alias buf_shape it still works. I guess the anomaly is that it works on my local instance... I tried using the other form for SDO_BUFFER and creating a function-based index as described [here](https://docs.oracle.com/cd/B12037_01/appdev.101/b10826/sdo_exten.htm#sthref726) : ```CREATE INDEX sidx_lyv_chantier_buffer ON Lyv_chantier(sdo_geom.sdo_buffer(shape, 0.001, 1)) INDEXTYPE IS MDSYS.SPATIAL_INDEX;``` – Morysh May 07 '20 at 12:59
  • Which gets me the following error : ```CREATE INDEX sidx_lyv_chantier_buffer ON Lyv_chantier(sdo_geom.sdo_buffer(shape, 0.001, 1)) INDEXTYPE IS MDSYS.SPATIAL_INDEX Error report - ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine ORA-13203: failed to read USER_SDO_GEOM_METADATA view ORA-13203: failed to read USER_SDO_GEOM_METADATA view ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10 29855. 00000 - "error occurred in the execution of OINDEXCREATE routine" *Cause: Failed to successfully execute the ODCIIndexCreate routine. – Morysh May 07 '20 at 13:04
  • So I tried adding an entry to USER_SDO_GEOM_METADATA : ```INSERT INTO USER_SDO_GEOM_METADATA (table_name, column_name, srid, diminfo) VALUES ('LYV_CHANTIER', 'SDO_GEOM.SDO_BUFFER(SHAPE, 0.001, 1)', 4326, (SELECT diminfo FROM USER_SDO_GEOM_METADATA WHERE table_name='LYV_CHANTIER' AND column_name='CHANTIER_ID')) Error report - ORA-13199: wrong column name: SDO_GEOM.SDO_BUFFER(SHAPE, 0.001, 1) ORA-06512: at "MDSYS.MD", line 1723 ORA-06512: at "MDSYS.MDERR", line 17 ORA-06512: at "MDSYS.SDO_GEOM_TRIG_INS1", line 20 ORA-04088: error during execution of trigger 'MDSYS.SDO_GEOM_TRIG_INS1'``` – Morysh May 07 '20 at 13:05
  • There were some typos/syntax errors, i managed to make the insert in USER_SDO_GEOM_METADATA to work like this : ```INSERT INTO USER_SDO_GEOM_METADATA (table_name, column_name, srid, diminfo) VALUES ('LYV_CHANTIER', 'SDO_GEOM.SDO_BUFFER(SHAPE,0.001,1)', 4326, (SELECT diminfo FROM USER_SDO_GEOM_METADATA WHERE table_name='LYV_CHANTIER' AND column_name='SHAPE'));``` – Morysh May 07 '20 at 13:54
  • However, the index creation still yields an error: ```CREATE INDEX sidx_lyv_chantier_buffer ON Lyv_chantier(SDO_GEOM.SDO_BUFFER(SHAPE,0.001,1)) INDEXTYPE IS MDSYS.SPATIAL_INDEX Error report - ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine ORA-13203: failed to read USER_SDO_GEOM_METADATA view ORA-13203: failed to read USER_SDO_GEOM_METADATA view ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10 29855. 00000 - "error occurred in the execution of ODCIINDEXCREATE routine" *Cause: Failed to successfully execute the ODCIIndexCreate routine.``` – Morysh May 07 '20 at 13:55
  • USER_SDO_GEOM_METADATA expects a column_name, not an sdo_geom.function. See the edit in my original answer. – GregStef May 07 '20 at 19:30
  • I created a new column with a trigger that stores the buffered geometry is it's a MultiPoint and the base geometry if not. I added the USER_SDO_GEOM_METADATA entry for this new column, as well as a spatial index, and it works fine – Morysh May 12 '20 at 11:57
  • I'm glad you made it work. However, I feel the need to point out that I've never encountered such a GS bug and I fear that your solution might not be the right one. That being said, if it works the way you want it, keep it. – GregStef May 13 '20 at 12:12
  • The only source I could find was [this thread](http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-handling-of-Oracle-Multipoint-Geometry-features-Geoserver-BUG-td5298430.html) from late 2016, so I guessed the issue is still pending because almost no one has the same weird setup – Morysh May 13 '20 at 13:40