booleanValid incorrectly returns true for coordinates outside valid range (e.g., >180)

[Userluckytian]

@turf/turf： v7.3.0

booleanValid 函数目前不检查坐标值的有效范围（如经度 > 180 或纬度 > 90），这可能导致下游应用在处理这些“几何有效但数值无效”的数据时出错

译：
booleanValid currently does not check the valid range of coordinate values (such as longitude > 180 or latitude > 90), which may lead to errors in downstream applications when processing these "geometrically valid but numerically invalid" data

复现步骤（reproduction steps）

const geom = {
    "type": "Feature",
    "geometry": {
        "type": "Polygon",
        "coordinates": [[[181, 181], [181, 182], [182, 182], [182, 181], [181, 181]]]
    }
};
const result = turf.booleanValid(geom); // 期望是 false，但实际返回 true（The expectation is false, but the actual return is true）
console.log(result);

codepen

https://codepen.io/userluckytian/pen/myrmNeP

[fillipeags]

Hi! I'd like to take on this issue.

I use @turf/turf extensively at work (field asset management with heavy geospatial processing) and this seems like a good first contribution on the turf repo .
As i checked the current implementation validates structural correctness (closed rings, minimum coordinate count, spikes/punctures) but doesn't check whether coordinate values fall within the valid WGS84 range (longitude [-180, 180], latitude [-90, 90]).

My plan would be to add a helper that validates coordinate bounds and call it across all geometry type branches in the switch statement, plus add .geojson fixtures in test/false/ to cover the failing cases.

However, RFC 7946 uses "SHOULD" (not "MUST") for coordinate ranges, and some use cases intentionally work
with extended ranges (e.g., antimeridian-crossing representations, tiled coordinate systems). So the question is:

Should coordinate range validation be always-on, or would we rather prefer it as an opt-in option (e.g., booleanValid(geom, { enforceCoordinateBounds: true }))?

[smallsaucepan]

Hi @fillipeags. Thanks for offering to take a look.

Examining more closely it might not actually be a bug. As you point out, the spec provides some flexibility around coordinate systems. Also the current documentation only talks about validation against the "OGC Simple Feature Specification" which seems to be more about the shape of the geometry rather than the scale.

@Userluckytian can you please tell us more about your use case?

[Userluckytian]

Hi @smallsaucepan sand @fillipeags ,
Thank you both for your insights.
Let me explain why I encountered this problem. It happened purely by accident — a backend API unexpectedly returned an abnormal coordinate (with values out of range). When my frontend application tried to render this geometry, the page simply failed to display it without throwing any error or warning. This made debugging very confusing and time-consuming. Through my investigation, I realized that turf.booleanValid was not sensitive to out-of-range coordinate values — it let the invalid coordinate data pass through. That's why I opened this issue.

I believe adding an optional coordinate range validation (like { enforceCoordinateBounds: true }) would be very helpful. It would allow developers to choose strict validation when needed (e.g., when consuming external or untrusted data sources) while maintaining backward compatibility for those who intentionally work with extended coordinate ranges.

I understand that the GeoJSON spec uses "SHOULD" rather than "MUST" for coordinate ranges. However, for practical purposes — especially when dealing with unknown or external data — having the ability to validate coordinate bounds would save developers a lot of debugging time and prevent silent rendering failures.

Thank you for considering this use case.