Laravel Geojson Rule Laravel Package

Product Decisions This Supports

• Geo-feature scoping (map/location features). Any roadmap item that accepts user- or partner-supplied geometry — store locators, delivery/service zones, drawn geofences, saved areas, property boundaries, route/waypoint uploads — needs a trust boundary on the payload. This package supplies that boundary at the framework's native validation layer, so the decision to greenlight the feature isn't gated on writing and maintaining a bespoke GeoJSON validator.
• Build vs. buy (lean: adopt). Writing a correct GeoJSON validator is small but deceptively fiddly: RFC 7946 geometry types, coordinate order (lon/lat, not lat/lon), latitude/longitude range clamping, Polygon ring closure, winding order, nested GeometryCollection/Feature/FeatureCollection shapes, and null geometries. This is a classic "cheap to adopt, annoying to own" trade — the value is in the edge cases you don't ship as bugs.
• API contract decisions. Choosing to reject malformed geometry at the edge (422 from the validator) rather than storing and sanitizing later is an architecture and support-cost decision. A rule object makes that a one-line, testable policy that shows up in your form requests and API docs.
• Upgrade/roadmap risk. The 2.0.7 release is Laravel 13.x compatibility. That materially affects the annual framework-upgrade line item: this dependency will not be the blocker pinning you to Laravel 12, and you can keep security patching cadence. It also means the package is tracking framework majors within their release window rather than lagging — a positive maintenance signal worth recording when scoring vendor/OSS dependencies.
• Where it deliberately does not decide anything. It is a format gate, not a spatial capability. It does not index, query, intersect, buffer, reproject, or measure. Choosing it implies a paired decision about the real geo store (PostGIS, SpatiaLite, MySQL spatial types, or a managed service such as Mapbox/Google/PostHog-style geo APIs). Do not let "we have GeoJSON validation" be mistaken in planning for "we have geo support."
• Sequencing insight. Validation is the cheapest, lowest-risk slice of a geo roadmap and is independent of which spatial backend you eventually pick. That makes it a reasonable first increment — it de-risks ingestion and API design before committing to a datastore decision.

When to Consider This Package

Adopt when:

• You are on a supported Laravel version (through 13.x as of 2.0.7) and already accept GeoJSON as an inbound format — or are willing to standardize on it, which has the advantage of being a well-specified, tool-agnostic interchange format that most mapping front ends (Leaflet, Mapbox GL, deck.gl, Turf) emit natively.
• The validation need is genuinely format-level: "is this a structurally valid GeoJSON document of an allowed geometry type?" It fits form requests, Validator::make, and Rule objects cleanly, with no service container or config surface to own.
• You want a small, declarative rule instead of a 100–300 line custom validator plus its test suite — i.e., the fully-loaded cost of ownership exceeds the dependency cost.
• You want a rule you can attach per-endpoint with allowed types and constraints, rather than a global middleware that rejects everything everywhere.
• You want framework-upgrade friction minimized: a patch release adding Laravel 13 support means the dependency is unlikely to hold up your next major upgrade.

Look elsewhere / do not adopt when:

• You need spatial operations — containment tests, intersection, area or distance, nearest-neighbor, indexing. Go to PostGIS or a managed geo API; this rule is complementary, not a substitute.
• Your payloads aren't GeoJSON. Raw WKT/WKB, shapefiles, GPX/KML, TopoJSON, or a proprietary geometry schema are out of scope, and forcing a GeoJSON conversion step in the middle is usually worse than validating the real format.
• Validation strictness is the wrong product behavior. If users draw on a map, the front end has already produced valid-ish geometry and a hard 422 on a self-intersecting polygon is a UX regression — you may want lenient coercion (ST_MakeValid, snapping) instead of rejection.
• The geometry is fully server-generated and never client-supplied. If you construct it yourself, there is no trust boundary to defend and the rule is ceremony.
• Governance sensitivity. This is a small, single-maintainer package. For a regulated or high-blast-radius surface, weigh whether a 200-line in-house rule you control — trivially testable — is preferable to an external dependency for something this narrow. (The 2.0.7 change itself came via an automated laravel-shift compatibility PR, which is a useful read on how much bespoke maintenance is happening versus routine upkeep.)
• It is your only defense. Format validity is not semantic validity: a perfectly valid polygon can still be absurd (wrong hemisphere, sub-meter sliver, continent-sized area, overlapping a competitor's exclusive territory). Business rules belong above this package.

Adoption notes for the squad: pin the version, treat it as a leaf dependency, and add one integration test per endpoint asserting a 422 on a malformed geometry and a 201 on a valid one — that test is the actual value you're buying, and it survives if you ever swap the rule out.

How to Pitch It (Stakeholders)

For executives (one line): A small, low-cost dependency that lets us safely accept map and location data from customers and partners — it prevents a category of corrupt-geometry bugs and data-cleanup work, and the current release confirms it stays current with our Laravel upgrade path, so it won't become an obstacle later.

For executives (short form): Location features are on our roadmap in some form — store finders, delivery zones, drawn areas. Every one of those needs to accept geometry from outside our systems, which is a place bad data enters and becomes a support ticket, a broken map, or a manual cleanup job. This package makes "reject the bad payload at the door" a one-line rule rather than custom code we build and maintain. The cost is negligible, the risk is bounded (it's a validation rule, not infrastructure, and swapping it out later is a day of work), and the 2.0.7 release — Laravel 13 support — tells us the project tracks framework upgrades rather than falling behind, which protects our maintenance budget. It is not, and should not be sold as, our geo strategy: it validates format only, so the real spatial work (storage, querying, maps) is still a separate, larger decision we should scope explicitly.

For engineering:

• Scope is intentionally narrow: an RFC 7946 structural rule that plugs into Validator and form requests. No service provider config, no runtime dependencies, no runtime overhead beyond the validation call.
• 2.0.7 is a patch release with no API change — the only change is Laravel 13.x compatibility. Safe to bump; no migration, no deprecation, no test changes required. This is the kind of release you take on your normal dependency cadence, not a planned work item.
• Recommended integration shape: attach per-form-request with an allowlist of geometry types and any coordinate bounds you care about; assert 422/201 behavior in feature tests; do not treat a passing validation as business-rule approval.
• Explicit non-goals: no indexing, no geometry math, no reprojection, no ST_MakeValid-style repair. Pair it with the actual spatial store and keep business rules (service radius, territory overlap, region allowlists) in your own layer where they're testable and changeable.
• Watch item to record: single-maintainer project, recent Laravel compatibility delivered via an automated laravel-shift PR. Low risk given the trivial surface area, but note it in the dependency register and be prepared to vendor or reimplement the rule if it goes stale.