Doctrine2 Spatial Laravel Package

Product Decisions This Supports

• Geo-enabled feature delivery: Enables location-aware features such as store/asset locators, “near me” search, delivery-zone checks, radius filtering, and map-based browsing by letting Doctrine entities store and query spatial values like points and polygons.
• Build vs. buy for spatial persistence: Reduces the need to hand-roll database-specific spatial SQL and custom Doctrine mappings. For a small team already on Doctrine 2, this can shorten the path to a geospatial MVP.
• Roadmap sequencing: Useful for deciding whether to ship a lightweight proximity/search feature first—e.g., PostGIS/MySQL spatial columns plus distance queries—versus investing in a full GIS stack with routing, geocoding, and advanced spatial analytics.
• Platform flexibility: Supports multiple database platforms for spatial types/functions, which can inform decisions about supporting MySQL and PostgreSQL without maintaining separate query layers.
• Prioritization of technical debt: Because the package’s last release is from 2017, adopting it is also a decision to carry a legacy dependency. PM should weigh near-term delivery speed against future migration cost, especially if the product roadmap includes Doctrine ORM 3/DBAL 4, PHP 8+, or advanced geospatial requirements.
• Use-case fit: Best suited to CRUD-style spatial data and common proximity queries—not a substitute for a dedicated GIS engine, routing service, geocoder, or high-volume spatial analytics platform.

When to Consider This Package

Consider it when:

• The product is already on Doctrine 2 / older Symfony or Laravel-adjacent PHP stacks where upgrading the ORM is not imminent.
• You need basic spatial persistence and DQL functions—points, distance, bounding-box/radius queries, simple geometry columns—rather than a full GIS platform.
• The engineering team wants to avoid custom DBAL type mappings and database-specific spatial SQL for a time-boxed MVP or internal tool.
• The target databases are supported by the package and the team can validate behavior on the exact database engine, version, PHP version, and Doctrine/DBAL versions in use.
• The dependency can be isolated behind an internal repository/service abstraction so it can be replaced later.
• The license and cost profile (MIT, no vendor contract) fit the team’s tolerance for self-supported open source.

Look elsewhere when:

• The product is greenfield or already on modern Doctrine ORM/DBAL, PHP 8+, or a framework version that no longer aligns with Doctrine 2-era packages.
• You need active maintenance, security patching, long-term vendor support, or guaranteed compatibility with current PHP/database releases.
• Requirements include advanced GIS—routing, isochrones, geofencing at scale, spatial joins across large datasets, raster support, or geocoding.
• The geospatial capability is a core differentiator rather than an enabling implementation detail; in that case, evaluate maintained spatial libraries, PostGIS-native approaches, or a dedicated geospatial service.
• The team cannot absorb the risk of an unmaintained dependency or cannot fork/vendor it if compatibility issues arise.

How to Pitch It (Stakeholders)

Executive summary: creof/doctrine2-spatial is a low-cost, MIT-licensed accelerator for adding basic location-aware features to a legacy Doctrine 2 PHP application. It can help ship proximity search, store locators, and spatial data storage faster by reducing custom database work. The trade-off is age: the last release was in 2017, so it should be treated as a tactical dependency, not a strategic platform. Recommendation: run a short compatibility spike against our exact stack; if it passes, use it behind an internal abstraction for a scoped geo MVP, and budget a migration path for when we modernize Doctrine/PHP or outgrow basic spatial queries.

For engineering: The package provides Doctrine spatial types and DQL functions across supported platforms, reducing bespoke DBAL mappings and database-specific SQL. It is not a GIS system and does not replace geocoding, routing, or advanced spatial analytics. Main risks are maintenance status, PHP/DBAL compatibility, and limited community support. Mitigate by pinning versions, adding integration tests against our database engines, isolating usage, and evaluating maintained alternatives or a fork if adoption becomes long-term.