Rendering error using oracle geometry

Hallo,

Recently started getting the below error pulling polygons from a table with oracle spatial into GeoServer 2.26.2. The data is being published via WMS.

Have built into the data a geometry resolution step with the SDO_UTIL.RECTIFY_GEOMETRY utility but this doesn’t seem to fix the issue.

I did a bit of searching and can only seem to find the external dependency to NetTopologySuite which is throwing this error.

As it’s in the data, I know there’s little on the GeoServer side. However, this then terminates the drawing and the map fails to render.

Is there any advice on how to handle this so that the rest of the map draw completes (mirrors behaviour of ArcGIS)?

Thanks in advance!

2025-06-27T10:06:15     WARNING    Map request error (Status: 200; Response: 
              Rendering process failed. Layers: GDW_BLK_ARE_RD
             ETYPE 2003 (Polygon Interior) no expected in a GeometryCollection(2003 is used to represent polygon holes, in a 1003 polygon exterior)
             ; Content-Type: text/xml;charset=UTF-8; URL: https://<url>/geoserver/<workspace>/ows?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=13673.34000000000015%2C326699.8099999999977%2C278045.0250000000233%2C617920.8260000000009&CRS=EPSG%3A28992&WIDTH=330&HEIGHT=363&LAYERS=GDW_BLK_ARE_RD&STYLES=&FORMAT=image%2Fpng&DPI=120&MAP_RESOLUTION=120&FORMAT_OPTIONS=dpi%3A120&TRANSPARENT=TRUE)

Looks like you have a random interior ring featuring as a top level geometry in a geometry collection… that is not correct, OGC Simple Features wise.
You should try to look into the geometry and see if you can get rid of the ring in question, or see if it can be put inside a polygon.

The Oracle read code could also be modified to handle this case in a more graceful way. If you are interested in following this path, see this guide:

Cheers
Andrea

Hey Andrea,

Thanks so much for the response! Indeed, fixing the geometry on the database side is an apart problem which I have tried to split out. Trying to get that fixed in the db but still would like to have seen GeoServer handle this without fatally failing.

Debugging this is way out of my league I’m afraid, I can see where the error is being triggered in org.geotools.xsd.Encoder and can see where this is triggering an error in org.geotools.data.oracle.sdo.SDO but can’t see how they’re linked.

Even switching the logs to verbose didn’t teach me much more.

I found your comment on a bug report from a few years back saying that there was a decision to ignore any geometry construction failures w/r/t SDO, is that still valid?

I also see someone proposed a fix in [GEOT-239] SDO Polygon Hole Encoding & Exception Handling - JIRA but it looks like it was for a different module.

What’s the best way forward for this? I don’t know whether this should be reported as a bug on geotools or geoserver?

Thanks, Joey

03 Jul 14:42:07 DEBUG  [geotools.jdbc] - CREATE CONNECTION
03 Jul 14:42:07 TRACE  [data.jdbc] - exporting PropertyName
03 Jul 14:42:07 DEBUG  [data.util] - CRSConverterFactory can be applied from Strings to CRS  only.
03 Jul 14:42:07 DEBUG  [data.util] - InterpolationConverterFactory can be applied from Strings to Interpolation only.
03 Jul 14:42:07 DEBUG  [geotools.jdbc] - SELECT * FROM (SELECT GDW_DBK,NEN3610ID,NAAM,BIS_LOCATIECODE,WBB_CODE,WBB_VERVOLGACTIE,GEGEVENSBEHEERDER,GEOMETRY as GEOMETRY FROM BLK.GDW_BLK_DOS_ARE_RD WHERE SDO_FILTER(GEOMETRY, ?, 'mask=anyinteract querytype=WINDOW') = 'TRUE'  ORDER BY GDW_DBK ASC) WHERE ROWNUM <= 1000000
03 Jul 14:42:07 DEBUG  [oracle.sdo] - Using layer SRID: 28992
03 Jul 14:42:07 DEBUG  [geotools.jdbc] - Setting parameter 1 as MDSYS.SDO_GEOMETRY(2003,28992,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),MDSYS.SDO_ORDINATE_ARRAY(-277110.02617699234,317378.55471114686,567736.867524422,627387.5314808702))
03 Jul 14:42:07 DEBUG  [geotools.jdbc] - 1 = POLYGON ((-277110.02617699234 317378.55471114686, 567736.867524422 317378.55471114686, 567736.867524422 627387.5314808702, -277110.02617699234 627387.5314808702, -277110.02617699234 317378.55471114686))
03 Jul 14:42:08 DEBUG  [geoserver.filters] - Compressing output for mimetype: application/gml+xml; version=3.2
03 Jul 14:42:09 DEBUG  [geotools.jdbc] - CLOSE CONNECTION
03 Jul 14:42:09 INFO   [geoserver.servlets] - OutputStream was successfully aborted.
03 Jul 14:42:09 ERROR  [geoserver.ows] - 
java.lang.RuntimeException: Error encoding object to xml-element
	at org.geotools.xsd.Encoder.processChildren(Encoder.java:988)

Hi Joey,

What happens if you execute the SQL select in your Oracle client ?

Here it is according to the log you provided:

SELECT * FROM (SELECT GDW_DBK,NEN3610ID,NAAM,BIS_LOCATIECODE,WBB_CODE,WBB_VERVOLGACTIE,GEGEVENSBEHEERDER,GEOMETRY as GEOMETRY FROM BLK.GDW_BLK_DOS_ARE_RD WHERE SDO_FILTER(GEOMETRY, POLYGON ((-277110.02617699234 317378.55471114686, 567736.867524422 317378.55471114686, 567736.867524422 627387.5314808702, -277110.02617699234 627387.5314808702, -277110.02617699234 317378.55471114686)), ‘mask=anyinteract querytype=WINDOW’) = ‘TRUE’ ORDER BY GDW_DBK ASC) WHERE ROWNUM <= 1000000

Hi there @Olyster76 ,

Thanks for the reply! That will execute fine, the problem is as @aaime-geosolutions indicated in the handling of invalid geometry at the side of GeoServer/GeoTools and not the database itself.

Oracle will serve invalid geometries just fine, but I can verify with the SDO utilities that the geometry is indeed invalid.

Thanks!

Hi,

Then your best bet is to identify those geometries using Oracle commands and correct them with Oracle or with a GIS you’ll be on your way !

Good luck !

Hi @Olyster76

Thanks for your input. I believe that is what @joey-geoloog is doing “behind the scenes”, but his actual question to this community is how to handle invalid geometry data, and the answer to that is, this being an open source project, that someone needs to pay a developer to improve the Oracle read code. We all need to play our part here.

Peter

1 Like

Hey @Peter - agreed! Joy of reading data in from disparate sources is the quality leaves a lot to be desired.
It’s just that it would be great if GeoServer handled this more gracefully instead of just stopping the action.
I tried to dive into the code and really came up nowhere so I think this is a bit of a dead end.
I will exclude these manually for now and if I ever get better at understanding how to fix java I’ll try and commit a fix.
Joey

1 Like

So what is the desired outcome? Skip invalid geometry, or generate a stop sign in the centroid location :slight_smile:

JTS is getting more ways of fixing invalid geometry. Perhaps we could have a “make_safe” function, and then you could use it when needed in geometry transform SLD or FeatureType definition…

1 Like

I think anything other than just firing an impossible to dcode error about an invalid token to the user would be preferred!

edit: I made a bug on jira for this - [GEOS-11890] Oracle reader doesn’t handle invalid geometries and instead stops processing and fails - JIRA