Skip to content

feat: accept closed LineStrings as AOI outlines on import - #7320

Open
dulcetberg wants to merge 2 commits into
hotosm:developfrom
dulcetberg:feat/accept-closed-linestring-aoi
Open

feat: accept closed LineStrings as AOI outlines on import#7320
dulcetberg wants to merge 2 commits into
hotosm:developfrom
dulcetberg:feat/accept-closed-linestring-aoi

Conversation

@dulcetberg

Copy link
Copy Markdown

Summary

Fixes #2285.

GridService._adapt_feature_geometry() (backend/services/grid/grid_service.py) only accepted Polygon/MultiPolygon geometries, silently dropping (returning None) anything else — including LineStrings. This meant a closed area imported as a LineString (exactly what tools like geojson.io produce when converting a closed .osm way to GeoJSON) got rejected outright with "The AOI contains geometries which are not polygons or multipolygons", even though it's unambiguously a valid area outline.

Now, a LineString whose first and last coordinates match (a closed ring) and has at least 4 points is converted into a Polygon using the same coordinates before the existing Polygon/MultiPolygon check runs. An open LineString (a real path, not a boundary) is still rejected, same as before — only genuinely closed rings get converted.

Test plan

  • Verified against 4 cases directly: closed LineString → now converted and accepted as a Polygon; open LineString → still correctly rejected; existing Polygon input → unchanged; a degenerate 3-point "closed" ring (below the 4-point minimum) → still correctly rejected.
  • Couldn't import GridService in isolation to run it against the real class — importing the backend package pulls in its full dependency tree beyond what this static method needs, same situation noted in fix: recover polygon area from GeometryCollection intersections in grid trim #7319. The verification above exercises the exact logic added; deferring to CI for the full suite.

🤖 Generated with Claude Code

Fixes hotosm#2285.

GridService._adapt_feature_geometry() only accepted Polygon/MultiPolygon
geometries, silently dropping (returning None) anything else - including
LineStrings. This meant a closed area imported as a LineString (which is
exactly what tools like geojson.io produce when converting a closed .osm
way to GeoJSON) got rejected outright with "The AOI contains geometries
which are not polygons or multipolygons", even though it's unambiguously
a valid area outline.

Now, a LineString whose first and last coordinates match (a closed ring)
and has at least 4 points is converted into a Polygon using the same
coordinates before the existing Polygon/MultiPolygon check runs. An open
LineString (a real path, not a boundary) is still rejected, same as
before - only genuinely closed rings get converted.

Verified against 4 cases directly (couldn't import GridService in
isolation - importing the backend package pulls in its full dependency
tree beyond what this static method needs, same situation as PR hotosm#7319):
- closed LineString -> now converted and accepted as a Polygon
- open LineString -> still correctly rejected
- existing Polygon input -> unchanged
- a degenerate 3-point "closed" ring (below the 4-point minimum) -> still
  correctly rejected

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Brian Bergstrom <dulcetberg@gmail.com>
@sonarqubecloud

Copy link
Copy Markdown

❌ The last analysis has failed.

See analysis details on SonarQube Cloud

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Accept LineStrings to outline task area with Import

1 participant