Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Validation for self-intersection WKT Multipolygon fails at the WKTReader, while works when wrapped in a `GEOMETRYCOLLECTION`

Open
#232 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
java
Domain
backend

Research direction

Start by reproducing both inputs with WKTReader.parse, then read WKTReader.java around parseGeometryCollectionShape and JtsShapeFactory.java around makeShapeFromGeometry and JtsMultiShapeBuilder.build. Compare how the standalone and wrapped MultiPolygon are validated; done means both variants behave consistently for the reported self-intersection case.

Written by the indexing model from the issue text.

Description

bug

Used version 0.8.

We encountered that parsing a WKT MultiPolygon containing a self-intersection works while it will raise a validation error when it is wrapped into a GEOMETRYCOLLECTION.

This code parses the WKT string into a valid MultiPolygon instance.

var reader = (WKTReader) JtsSpatialContext.GEO.getFormats().getWktReader();
var shape = reader.parse(''MULTIPOLYGON (((5 5, 10 5, 10 10, 5 5)), ((6 6, 10 5, 10 10, 6 6)))');

While this one raises a InvalidShapeException:

var reader = (WKTReader) JtsSpatialContext.GEO.getFormats().getWktReader();
var shape = reader.parse(''GEOMETRYCOLLECTION ( MULTIPOLYGON (((5 5, 10 5, 10 10, 5 5)), ((6 6, 10 5, 10 10, 6 6))) )');

Stacktrace:

Caused by: org.locationtech.spatial4j.exception.InvalidShapeException: Self-intersection at or near point (10.0, 5.0, NaN)
	at org.locationtech.spatial4j.shape.jts.JtsGeometry.validate(JtsGeometry.java:127)
	at org.locationtech.spatial4j.shape.jts.JtsShapeFactory.makeShapeFromGeometry(JtsShapeFactory.java:502)
	at org.locationtech.spatial4j.shape.jts.JtsShapeFactory.makeShapeFromGeometry(JtsShapeFactory.java:475)
	at org.locationtech.spatial4j.shape.jts.JtsShapeFactory$JtsMultiShapeBuilder.build(JtsShapeFactory.java:446)
	at org.locationtech.spatial4j.io.WKTReader.parseGeometryCollectionShape(WKTReader.java:356)
	at org.locationtech.spatial4j.io.WKTReader.parseShapeByType(WKTReader.java:165)
	at org.locationtech.spatial4j.io.WKTReader.parseIfSupported(WKTReader.java:110)
	at org.locationtech.spatial4j.io.WKTReader.parse(WKTReader.java:81)

I would expect that both variants behave the same.

Dominant language
Java
Stars
961
Forks
172
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from locationtech/spatial4j

All issues in locationtech/spatial4j

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.