[Geoserver-users] Debugging Geoserver/Oracle problem

Hi,

We're trying out Geoserver as an alternative engine to our current
commercial product. So far, we have been able to use our own layers
using shapefiles successfully (through WMS, WFS-T and KML).

To allow it to run in a production environment, geoserver needs to use
Oracle Spatial as a datasource. We are currently using the Oracle
Express version 10g.

Geoserver connects successfully to the datasource, but when trying to
add a feature, a lot of extra tables are presented. I think this is a
compatibility issue with newer oracle table naming schemes in
OracleDataStore
(http://www.koders.com/java/fidCDD1E8999683DBADA9799AEA79B1B800A0583EC3.aspx
) function 'allowTable'.

But most importantly, we can not create a new feature based on a table:

"WARNING: Could not map SRID 0 to
CRS:org.geotools.data.DataSourceException: No geometry column row for
srid in table: DGTP_V_RIJWEG, geometry column GEOMETRIE, be sure
column is defined in USER_SDO_GEOM_METADATA"

After some googling, I figured what was going wrong: the datasource
didn't contain any metadata. I inserted the one for this table
manually:

"INSERT INTO USER_SDO_GEOM_METADATA(TABLE_NAME,COLUMN_NAME,DIMINFO,SRID)
values('DGTP_V_RIJWEG','GEOMETRIE',
MDSYS.SDO_DIM_ARRAY(MDSYS.SDO_DIM_ELEMENT('X', 0, 1000,
0.01),MDSYS.SDO_DIM_ELEMENT('Y', 0, 1000, 0.01)), '28992');"

After this, the error did not disappear. My knowledge of spatial
system ends here though, but before calling the dataset corrupt, I
would like to get a sensible error message from geoserver.

Are there any other steps left to try?

We're also currently trying out the data with Oracle Mapviewer, to
check if the data isn't corrupt.

Kind regards,

Pieter Jansen
--
http://pitr.net/

Hi,

Regarding my earlier issue with Oracle Spatial and Geoserver, I have
found that there doesn't seem to be much use of this combination.

I am trying out the new versions of Geoserver now, with puzzling errors as well:

"The FeatureType 'KRTP_WIJKEN' has a NULL extent.
HINT: the dataset is empty or has no default geometry attribute."

The table is filled, the metadata table contains the metadata, and the
error "Could not compute bounding box" appears in the console.

Anyone?

Pieter Jansen
--
http://pitr.net

A more detailed trace ('ALL'):

When I click on 'Generate' (for the bounding box):

1128969 [FINE] org.geotools.data.jdbc.ConnectionPool - Getting
available connection.
1128985 [FINER] org.geotools.data.oracle.OracleDataStore - the sql
statement for srid is SELECT SRID FROM ALL_SDO_GEOM_METADATA WHERE
TABLE_NAME='KT10_SPOORLIJNEN' AND COLUMN_NAME='GEOMETRIE'
1128985 [FINE]
org.geotools.data.jdbc.ConnectionPool$ConnectionListManager -
Connection closed - adding to available connections.
1128985 [FINE] org.vfny.geoserver.action.data.TypesEditorAction -
calculating bbox for their dataset
1128985 [FINE] org.geotools.filter.SQLEncoderOracle -
SQLEncoderOracle: Geometric Column is: GEOMETRIE
1128985 [FINE] org.geotools.filter.SQLEncoderOracle -
SQLEncoderOracle: Geometric Column is: GEOMETRIE
1128985 [FINE] org.geotools.data.jdbc.JDBC1DataStore - calling sql
builder with filter Filter.NONE
1128985 [FINE] org.geotools.data.jdbc.JDBC1DataStore - sql is SELECT
"ID", "OCE_ID", "GEOMETRIE" FROM "KT10_SPOORLIJNEN"
1128985 [FINE] org.geotools.data.jdbc.JDBC1DataStore - About to
execute query:SELECT "ID", "OCE_ID", "GEOMETRIE" FROM
"KT10_SPOORLIJNEN"
1128985 [FINE] org.geotools.data.jdbc.ConnectionPool - Getting
available connection.
1129032 [FINE] org.geotools.data.oracle.attributeio.SDOAttributeIO -
About to create Geometry convertor for KT10_SPOORLIJNEN.GEOMETRIE
1129235 [FINE] org.geoserver.feature.FeatureSourceUtils - Could not
compute the data bounding box. Returning an empty envelope
java.lang.IllegalArgumentException: ETYPE 1.005 must be expected
POLYGON or POLYGON_EXTERIOR (one of 3,1003,)
        at org.geotools.data.oracle.sdo.SDO.ensure(SDO.java:1945)
        at org.geotools.data.oracle.sdo.SDO.createPolygon(SDO.java:2521)
        at org.geotools.data.oracle.sdo.SDO.create(SDO.java:2333)
        at org.geotools.data.oracle.sdo.SDO.create(SDO.java:2300)
        at org.geotools.data.oracle.sdo.GeometryConverter.asGeometry(GeometryConverter.java:106)
        at org.geotools.data.oracle.attributeio.SDOAttributeIO.read(SDOAttributeIO.java:99)
        at org.geotools.data.jdbc.QueryData.read(QueryData.java:185)
        at org.geotools.data.jdbc.JDBCFeatureReader.readFeature(JDBCFeatureReade
r.java:108)
        at org.geotools.data.jdbc.JDBCFeatureReader.next(JDBCFeatureReader.java:
87)
        at org.geotools.data.DefaultFeatureResults.getBounds(DefaultFeatureResul
ts.java:196)
        at org.geoserver.feature.FeatureSourceUtils.getBoundingBoxEnvelope(Featu
reSourceUtils.java:40)
        at org.vfny.geoserver.util.DataStoreUtils.getBoundingBoxEnvelope(DataSto
reUtils.java:255)
        at org.vfny.geoserver.action.data.TypesEditorAction.executeBBox(TypesEdi
torAction.java:180)
        at org.vfny.geoserver.action.data.TypesEditorAction.execute(TypesEditorA
ction.java:121)
        at org.vfny.geoserver.action.ConfigAction.execute(ConfigAction.java:98)
        at org.apache.struts.action.RequestProcessor.processActionPerform(Reques
tProcessor.java:431)
        at org.apache.struts.action.RequestProcessor.process(RequestProcessor.ja
va:236)
        at org.apache.struts.action.ActionServlet.process(ActionServlet.java:119
6)
        at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445
)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1050)
        at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCha
racterEncodingFilter.java:122)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1041)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
54)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:2
26)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:6
27)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:149)
        at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
java:123)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
41)
        at org.mortbay.jetty.Server.handle(Server.java:269)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:43
0)
        at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnectio
n.java:701)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
        at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.jav
a:270)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
1129250 [FINE] org.vfny.geoserver.action.data.TypesEditorAction -
FeatureType 'KT10_SPOORLIJNEN' has a null bounding box

The sql statement for the srid returns:
SRID: 90112

The 2nd sql statement returns a lot of rows (live data set) with three
columns: ID, OCE_ID and GEOMETRIE.

The interface states:
The FeatureType 'KT10_SPOORLIJNEN' has a NULL extent.
HINT: the dataset is empty or has no default geometry attribute.

Hope this helps.

Regards,

Pieter
--
http://pitr.net

Pieter Jansen ha scritto:

A more detailed trace ('ALL'):

When I click on 'Generate' (for the bounding box):

1129235 [FINE] org.geoserver.feature.FeatureSourceUtils - Could not
compute the data bounding box. Returning an empty envelope
java.lang.IllegalArgumentException: ETYPE 1.005 must be expected
POLYGON or POLYGON_EXTERIOR (one of 3,1003,)

Ah... that happens because geometries of type 1005 (compound polygon exterior) cannot be handled in Geotools, since there may be curved segments, and JTS, the geometry library we use, supports only straight
segments.

If there are curved segments, the only way would be to extend the
oracle data store to handle them by approximating curved lines with
small straight segments. If you are willing to do that, we'll gladly
accept a patch. Or we can find someone who can do that for a fee.
I'm unsure, but there may even be some commands in Oracle that linearize
geometries removing curved segments.

If there are no curved segment in reality, then you can try
changing the software that imported the data into Oracle and use
one that uses type 1003 instead (polygon exterior).

Hope this helps
Cheers
Andrea Aime

Hi Andrea,

Thanks for your quick response!

On 1/5/07, Andrea Aime <aaime@anonymised.com> wrote:

Ah... that happens because geometries of type 1005 (compound polygon
exterior) cannot be handled in Geotools, since there may be curved
segments, and JTS, the geometry library we use, supports only straight
segments.

This is beyond my knowledge of geospatial technology :wink: I forwarded
it to the team members with more know-how, and hope they will be able
to answer this next week.

If there are curved segments, the only way would be to extend the
oracle data store to handle them by approximating curved lines with
small straight segments. If you are willing to do that, we'll gladly
accept a patch. Or we can find someone who can do that for a fee.
I'm unsure, but there may even be some commands in Oracle that linearize
geometries removing curved segments.

I will post their findings on here, when I get a response.

Do you know how mature the oracle implementation is? There seem to be
a lot of bugs listed, so I wonder if it is production-ready yet.

Kind regards,

Pieter
--
http://pitr.net

Pieter Jansen ha scritto:

Hi Andrea,

Thanks for your quick response!

I will post their findings on here, when I get a response.

Do you know how mature the oracle implementation is? There seem to be
a lot of bugs listed, so I wonder if it is production-ready yet.

We know. The problem is, the datastore is currently unmaintained (officially there's a maintainer, but he does not fix bugs, so...).

We are looking for someone to sponsor the fixes or get maintainership
and fix the issues, but no one so far has stepped forward.

Yet, there are people using it, so it's good enough for some production
use, it all depends on whether you're fitting the sweep spot were the
datastore works or not.

Cheers
Andrea

On 1/5/07, Andrea Aime <aaime@anonymised.com> wrote:

We know. The problem is, the datastore is currently unmaintained
(officially there's a maintainer, but he does not fix bugs, so...).

We are looking for someone to sponsor the fixes or get maintainership
and fix the issues, but no one so far has stepped forward.

Yet, there are people using it, so it's good enough for some production
use, it all depends on whether you're fitting the sweep spot were the
datastore works or not.

I think this organisation would like to contribute fixes, once they
find it worth to invest in. Till then, this team is trying to set up a
working proof of concept based on the oracle datastore.

We're currently one step further: the DBA told me there shouldn't be
any geometries of that datatype in there. I'll try to pinpoint the
records which contain this specific type.

Kind regards,

Pieter
--
http://pitr.net