Polygon.fromGeoJSON rejects a GeoJSON Feature whose properties contain a "type" member

Polygon.fromGeoJSON(String) (core, @lucene.experimental) accepts a Polygon or MultiPolygon "optionally embedded under a "type: Feature"", and GeoJSON lets a Feature's properties be any JSON object. The parser behind it, SimpleGeoJSONPolygonParser, tracks where each object sits (geometry, properties, features.[], ...) and reads "coordinates" only at geometry positions, but it reads a member named "type" as a GeoJSON object type at every position except under crs (SimpleGeoJSONPolygonParser.java:186). So a Feature whose properties hold {"type": "x"} is rejected with ParseException: can only handle type FeatureCollection (if it has a single polygon geometry), Feature, Polygon or MultiPolygon, but got x, and {"type": 3} with type should be a string, but got: 3.0. The same Feature without that key parses. Nothing wrong is ever returned: the error is loud and the input is valid. The check came with the parser in LUCENE-7380 (6.2.0, 2016); all 90 releases from 6.2.0 to 10.6.0 and main fail the one-test repro. Reading "type" only where a GeoJSON object can appear fixes it; the recommended fix also keeps the crs checks for a crs on a nested geometry.

• SimpleGeoJSONPolygonParser: the package-private hand-written parser behind Polygon.fromGeoJSON (Polygon.java:255-257). It "does minimal parsing of a GeoJSON object, to extract either Polygon or MultiPolygon" (SimpleGeoJSONPolygonParser.java:47-51).
• Path: the parser's address of the object it is reading, built from member names: "" for the top level, geometry, properties, properties.source, features.[], features.[].geometry.
• Geometry path: isValidGeometryPath (:221-224), the three places a Polygon may sit: "", geometry, features.[].geometry.

1. parseObject parses a member whose value is an object recursively, with path path + "." + key (:146-153); so the Feature's properties object is read with path properties.
2. After each member, line 186 asks if (key.equals("type") && path.startsWith("crs") == false): every "type" member outside crs is read as a GeoJSON object type, wherever it sits.
3. Inside that branch, a non-string value throws type should be a string (:187-190); Polygon and MultiPolygon are accepted only on a geometry path (:192-195); Feature and FeatureCollection only at "" or features.[] (:196-197); anything else throws can only handle type ... but got <value> (:199-204). At path properties no value can pass.
4. The next check, key.equals("coordinates") && isValidGeometryPath(path) (:205), is scoped by path. That asymmetry is the bug: "coordinates" in properties is ignored, "type" in properties is fatal.

Main 645d4fe14a20, Polygon.fromGeoJSON on a one-triangle Polygon wrapped in different Features (a small probe against the build's classes; messages cut before "; fragment"):

Feature, properties {"name": "park"}                 -> OK, 1 polygon
Feature, properties {"type": "x"}                    -> ParseException: can only handle type ... but got x at character offset 127
Feature, properties {"type": 3}                      -> ParseException: type should be a string, but got: 3.0 at character offset 127
Feature, properties {"source": {"type": "survey"}}   -> ParseException: ... but got survey at character offset 138
FeatureCollection of 1 Feature, properties {"category": "boundary", "type": "administrative"}
                                                     -> ParseException: ... but got administrative at character offset 194
Feature, properties = a decoy Polygon object         -> ParseException: ... but got Polygon (the decoy is never used)
Feature with foreign member "centerline": {"type": "LineString", ...}
                                                     -> ParseException: ... but got LineString at character offset 145

Also rejected (study verifiers and the tie-breaker): properties written before geometry, and {"parts": [{"type": "x"}]}, a "type" inside an object inside an array. Not affected: properties without a "type" key, a "coordinates" key in properties, a top-level crs.

• Who is hit. Callers of Polygon.fromGeoJSON (core; Polygon is @lucene.experimental, Polygon.java:41) that pass Features or one-Feature FeatureCollections whose properties (or an object nested in them) hold a key named "type". Default and only behaviour; assertions on or off make no difference.
• Realistic trigger. "type" is an ordinary data name. The output docs of the OpenStreetMap geocoder Nominatim say its GeoJSON format "follows the RFC7946" and list among the properties fields "category, type - key and value of the main OSM tag". Data shaped like that, a one-Feature FeatureCollection with a polygon geometry and properties {"category": "boundary", "type": "administrative"}, is rejected on main and on 10.6.0; it was built from the docs, not fetched from the service. Caveats: the docs give the centroid (a Point, rejected anyway) unless the caller asks for the full geometry with polygon_geojson, and the parser accepts a FeatureCollection only with a single polygon. In OpenStreetMap a multipolygon relation carries the tag type=multipolygon; data that copies such tags into properties is rejected the same way (... but got multipolygon).
• Reach. In the Lucene tree the method has no production caller, only TestPolygon and TestTessellator. A read-only code search found a benchmark call in Elasticsearch and none in OpenSearch (Solr not checked). No relevant public report was found in the recorded searches: likelihood "plausible", priority low.
• What happens. The query area or document cannot be turned into a polygon, and the message is misleading: "but got administrative" names a property value, not a geometry type. Workaround: pass only the geometry object, or drop properties before calling.
• What does not happen. No wrong or different polygon (a decoy geometry in properties is rejected, never used), no hang, no extra cost beyond a normal parse, nothing written to an index.

The ParseException is rethrown as an AssertionError so the failure states expected versus actual. The same test passes with either fix below, with assertions on and off.

As the regression test: the same test, for example as a new method in TestPolygon next to testGeoJSONPolygonFeature.

cp TestGeoJSONFeatureTypeProperty.java $LUCENE/lucene/core/src/test/org/apache/lucene/geo/
cd $LUCENE && ./gradlew :lucene:core:test --tests org.apache.lucene.geo.TestGeoJSONFeatureTypeProperty -Ptests.seed=DEADBEEF
# assertions off: add -Ptests.asserts=false (same result)

# gradle, main 645d4fe14a20, seed DEADBEEF (assertions on; the same with -Ptests.asserts=false)
TestGeoJSONFeatureTypeProperty > testTypeMemberInFeatureProperties FAILED
    java.lang.AssertionError: expected the Feature's polygon, got java.text.ParseException: can only handle type FeatureCollection (if it has a single polygon geometry), Feature, Polygon or MultiPolygon, but got x at character offset 127; fragment leading to this:
    ...[1, 0], [1, 1], [0, 0]]]}, "properties": {"type": "
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:8D822687064FAAE3]:0)
        at org.apache.lucene.geo.TestGeoJSONFeatureTypeProperty.testTypeMemberInFeatureProperties(TestGeoJSONFeatureTypeProperty.java:32)

        Caused by:
        java.text.ParseException: can only handle type FeatureCollection (if it has a single polygon geometry), Feature, Polygon or MultiPolygon, but got x at character offset 127; fragment leading to this:
        ...[1, 0], [1, 1], [0, 0]]]}, "properties": {"type": "
            at org.apache.lucene.geo.SimpleGeoJSONPolygonParser.newParseException(SimpleGeoJSONPolygonParser.java:459)
            at org.apache.lucene.geo.SimpleGeoJSONPolygonParser.parseObject(SimpleGeoJSONPolygonParser.java:201)
            at org.apache.lucene.geo.SimpleGeoJSONPolygonParser.parseObject(SimpleGeoJSONPolygonParser.java:153)
            at org.apache.lucene.geo.SimpleGeoJSONPolygonParser.parse(SimpleGeoJSONPolygonParser.java:65)
            at org.apache.lucene.geo.Polygon.fromGeoJSON(Polygon.java:256)
            at org.apache.lucene.geo.TestGeoJSONFeatureTypeProperty.testTypeMemberInFeatureProperties(TestGeoJSONFeatureTypeProperty.java:30)

# release jars 10.6.0 (assertions on and off): the same failure, newParseException at line 461

• Contract. Polygon.java:248-254: "Parses a standard GeoJSON polygon string. The type of the incoming GeoJSON object must be a Polygon or MultiPolygon, optionally embedded under a "type: Feature"", with a link to the 2008 GeoJSON specification. Its section 2.2: "The value of the properties member is an object (any JSON object or a JSON null value)"; RFC 7946 section 3.2 says the same. The 6.2.0 CHANGES entry promises parsing of "a standard GeoJSON string" (lucene/CHANGES.txt:8978-8980).
• The parser's example and tests. The header comment (SimpleGeoJSONPolygonParser.java:23-45) shows an accepted Feature with "properties": {"prop0": "value0", "prop1": {"this": "that"}}; TestPolygon.testGeoJSONPolygonFeature (TestPolygon.java:176-199) parses it.
• Scoping exists next door. "coordinates" is read only on geometry paths (:205), and crs is exempt from the "type" check (:186) because a crs object has its own "type" (testIllegalGeoJSONLinkedCRS even has "type": "proj4" under crs.properties, TestPolygon.java:283-303). The authors knew "type" occurs outside GeoJSON objects.
• No test asserts it. The tested rejections concern the geometry, the feature count, the crs or trailing data: testIllegalGeoJSONMultipleFeatures (:305-346, "but got Point" at features.[].geometry), testIllegalGeoJSONLinkedCRS (:283-303), testIllegalGeoJSONExtraCrapAtEnd (:268-281). All 16 pass with the fix.
• Intent on record. LUCENE-7380 (#8433): "The parser only handles the various ways that a single Polygon or MultiPolygon can appear in a GeoJSON string, and throws an exception otherwise." A Feature with a Polygon geometry is one of those ways; the issue never discusses "type" keys in properties.
• Precedent. LUCENE-8964 (#10007, 8.3.0, lucene/CHANGES.txt:6239-6240 "Fix geojson shape parsing on string arrays in properties"): the same parser rejected other legal properties content and the project fixed it, in parseArray; this bug reproduces on every release after that fix.

The strongest case for "intended" (the study's intended-behaviour checker, the cross-model review lenses and the adjudication): the parser calls itself "minimal parsing" (:47-51), Polygon is @lucene.experimental, the parser deliberately rejects Point, LineString, GeometryCollection, several features and linked crs, and RFC 7946 section 6.1 says support for foreign members "can vary across implementations".

Why it fails: "minimal parsing" describes what is extracted, not a restriction on properties, and @lucene.experimental is about API stability. The deliberate rejections cover unsupported geometry types, more than one polygon, crs handling and trailing input; none concerns a "type" key in Feature properties, while the rejected input is exactly the documented shape. properties is a core Feature member, not a foreign member, so section 6.1 does not apply to the main case. For foreign members it cuts both ways: support "can vary", but the same section says "GeoJSON semantics do not apply to foreign members and their descendants, regardless of their names and values". The cross-model lenses rated the intended argument weak; the later cross-model fact check rated it moderate (a deliberately narrow parser), with a strong rebuttal for the properties case. Verdict: a defect, low severity.

Two options were run through gradle in a scratch worktree of 645d4fe14a20; B is recommended. Both leave one residual: a foreign member literally named "geometry" (or "features") is still read as a GeoJSON location, but RFC 7946 section 7.1 forbids such members on a Geometry object, so only non-conforming input hits it. A fix conflicts textually with PR #12295 (open as of the 2026-11-01 scan).

In SimpleGeoJSONPolygonParser: line 186 tests isGeoJSONObjectPath(path) (a geometry path or features.[]) instead of path.startsWith("crs") == false, and the two crs checks (:125, :174) run at the crs.properties of any GeoJSON object, not only the top level.

-      if (path.equals("crs.properties") && key.equals("href")) {
+      if (isCrsPropertiesPath(path) && key.equals("href")) {
 ...
-      if (path.equals("crs.properties") && key.equals("name")) {
+      if (isCrsPropertiesPath(path) && key.equals("name")) {
 ...
-      if (key.equals("type") && path.startsWith("crs") == false) {
+      if (key.equals("type") && isGeoJSONObjectPath(path)) {
 ...
+  private boolean isGeoJSONObjectPath(String path) {
+    return isValidGeometryPath(path) || path.equals("features.[]");
+  }
+
+  private boolean isCrsPropertiesPath(String path) {
+    if (path.equals("crs.properties")) {
+      return true;
+    }
+    String suffix = ".crs.properties";
+    return path.endsWith(suffix)
+        && isGeoJSONObjectPath(path.substring(0, path.length() - suffix.length()));
+  }

Trade-offs

• Removes the rejections where "type" is data, and validates a crs on a nested geometry or feature like a top-level one: CRS84 is accepted (main rejects it with the misleading "but got name"), another or a linked crs is rejected with the existing messages.
• Adds one rejection: a nested crs that lacks its required "type" member and names a non-CRS84 or linked system, or whose name is not a string, which main accepts silently, is rejected, as it already is at the top level.
• About 15 lines; no API or format change. Not benchmarked: it adds a few string comparisons per parsed member.

What the checks validated

Gradle in a scratch worktree of 645d4fe14a20 (removed afterwards), seed DEADBEEF:

• the repro fails on the stock build and passes with B, assertions on and off;
• TestPolygon 16 of 16; the org.apache.lucene.geo package incl. the repro: 18 classes, 194 tests, 0 failures (7 skipped in TestTessellator, the other in-tree caller; the run kept no skip list, and by reading that class has six @Nightly tests and one @AwaitsFix test, which a default run skips);
• :lucene:core:check -x test with the repro in place: BUILD SUCCESSFUL;
• a 17-input probe: the repro and 6 wider triggers (non-string, nested, a one-Feature FeatureCollection, a decoy Polygon, a foreign member, a crs-shaped object in properties) now return the Feature's own polygon, never the decoy; Point, GeometryCollection, and an EPSG:4269 or linked crs at the top level or on the geometry are still rejected; a CRS84 crs on the geometry is accepted.

Only the line-186 change and isGeoJSONObjectPath.

-      if (key.equals("type") && path.startsWith("crs") == false) {
+      if (key.equals("type") && isGeoJSONObjectPath(path)) {
 ...
+  private boolean isGeoJSONObjectPath(String path) {
+    return isValidGeometryPath(path) || path.equals("features.[]");
+  }

Trade-offs

The smallest diff (a 1-line condition and a 3-line helper) and fixes every executed trigger. But a crs on a nested geometry is then never checked, because the crs checks run only at the top level: "crs" naming EPSG:4269 or a linked crs on the Feature's geometry, rejected today (with a misleading message), would be accepted and its coordinates read as WGS 84.

What the checks validated

Same scratch worktree: the repro passes (assertions on) and TestPolygon 16 of 16. Probe: the same triggers parse as with B, but a nested EPSG:4269 or linked crs now returns a polygon.

Keep A and throw "crs is only supported at the top level" for a crs member below the top level.

Trade-offs

Also closes A's gap and is simple, but rejects a nested CRS84 crs, which the 2008 spec allows (though it says a crs "should not be repeated or overridden on children or grandchildren"). Not tried.

Method: non-formal (differential testing, then code reading and executed tests). On 2026-10-26 the hunt unit for the LatLon geo queries ran a probe over GeoJSON inputs the parser should accept: Polygon, MultiPolygon, Feature and FeatureCollection with holes, extra members, nulls, exponent numbers and whitespace, each compared with its coordinates as written. While probing extra members it saw a valid Feature rejected because its properties held a "type" key. Reading SimpleGeoJSONPolygonParser found the path.startsWith("crs") == false condition next to the path-scoped "coordinates" check. A public-API JUnit test reproduced it on the stock build; independent checkers reproduced it with their own tests, and it was cut to the one-test repro.